A SWAY session by Joanne of Royal Far West School. http://sway.org.au/ via https://coviu.com/ SWAY is an oral language and literacy program based on Aboriginal knowledge, culture and stories. It has been developed by Educators, Aboriginal Education Officers and Speech Pathologists at the Royal Far West School in Manly, NSW.
Meeting opened at 19:36 AEST by Sae Ra and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
Fwd: DrupalCon License Agreement [Needs review by LA council, esp VP and Treasurer]
The data debate: AI training datasets are the bone of contention [discussion of an Open Source AI Definition]
Tax Invoice #1717290 – Please Do Not Reply [receipt for renewal of slug.org.au and taslug.org.au
[Announce] Linux Australia’s 2024 Grants Program is now open
Date error in grants webpage shown when not logged in to the website [closing date in the Grants Program Announcement was wrong, but has now been fixed by Jonathan. It was evidently a WordPress glitch.]
Re: Payment to Acquamarina Hotel – DrupalCon Asia
linux-aus post from yifei@zhan.science requires approval [Grant report]
Grant Application from Jonah Sullivan for Canberra Python User Group
Grants Program now posted to website and socials – please do share [From Kathy Reid promoting the Grants Program]
Enquiry from Felicity Brand via the Linux Australia Website Contact Form [invitation to sponsor Write the Docs Australia 2024]
[LACTTE] Moving forward with 2024 Grants program [after accepting some suggestions from @lloy0076 the PR has been merged and the new policy is in effect]
3. Items for discussion
Drupal sub committee update
Things are ticking along. Big question is building out the Melbourne conference. Ongoing saga, some difficulties settling on a final venue. Two on the short list.
RMIT
Suspiciously affordable catering, good for a community venue, but lots of little rooms spread over several levels, but not much common space or vendor space).
ACME
Is the preferred venue but is more expensive. Good facilities and AV. AV could be improved from the last few conferences. The catering is very expensive.
Sae Ra suggests that there is some common space at RMIT and the food options and location are very good.
Both venues depend on support from sponsors. A slide deck has been prepared by Michael for an upcoming sponsors webinar. Both venues need more sponsorship than last year and may need higher ticket prices.
Sponsorship and Costs
There is a list of more companies to approach for sponsorship, from outside the Drupal market.
There is the possibility that the conference will run at a loss, which will mean reconsidering whether to run in Melbourne or finding other ways to reduce costs, or accepting a loss. It’s possible that the conference may not run at all this year.
Per attendee costs up by about 30% over the last three years and sponsorship down by about 10%. If sponsorship increases then that would allow more activities, but otherwise the conference may need to be more focused on a community program rather than growing the market.
A separate discussion between the Drupal Subcommittee and the LA Council about these issues might be a good idea.
GovCMS have asked about running another event in Canberra. Costs would be around $5,000 to $10,000. It would be good to bring that cost down a bit. No guarantee that last year’s sponsors will return for the next event.
Drupal South is preparing to run an election for their committee.
Drupal Asia
Everything is going very well. Sessions are open until 8 July, 50 have been received so far. Early bird tickets are on sale. Everything is on track. The two outstanding issues are paying the venue and sorting out licensing for the Drupal brand.
Planning for the next Drupal Cons is starting. If Singapore goes well then the hope is for Japan in 2025 and India in 2026.
KiwiPyCon
Large overlap between the committees for Python NZ and Kiwi Pycon. Python NZ are sorting out issues left over from before.
For KiwiPyCon the website is 99% complete. Financial assistance program complete. Volunteers are nearly complete. Communication channels have been set up both for the conference and the wider community.
The only things left to do before the conference is pushing ticket sales and sponsorship. Ticket details are pretty much complete so purchasers should have all the information they need to make a decision.
Danny has received his invitation from the bank and has confirmed that he has access through the app.
There is space for Linux Australia banners as LA is a phoenix sponsor. Just need some banners. LA doesn’t believe that there are any banners in NZ currently. LA will provide money and designs to print banners.
Ticket sales are as usual expected to come in at the last moment. Currently there are 116 attendees. The record for a Kiwi PyCon is 235. The venue capacity is 360. Expecting to exceed 200, and hoping to get to 360. Workshops will probably sell out at 50 participants.
15 people were rejected for financial assistance. 8 people were accepted, 3 of them being speakers.
Sponsorship has been lower than expected. Early commitments from Google and the PSF. Sponsorship is currently at about 50% of what was expected, but there are still potential sponsors to follow up.
Python NZ are seeking an arrangement with the NZ Tax office, but it has not yet been decided.
Admin team update
SSL certs are done (expired last week)
Domain names have been renewed (taslug, slug and a few others). We will continue to receive reminders even though the domain have been renewed
An upgrade to a more recent mailman 2 is planned for Friday which allows migration to a new server. Mailman 3 may happen later, but is not even in the planning stage until after than mailman 2 migration is complete.
Disks need to be replaced in the VM hypervisors, but will need to be coordinated with the call for papers for EO2025. Disk swap will probably happen in August. In the meantime any critical VMs will be migrated to a secondary server.
SLUG has a very old VM that needs to be upgraded. If there is a SLUG committee they need to be involved in this process.
Steve will be an apology for next month’s meeting due to travel.
Joomla sub committee update
No update
PyCon AU sub committee update
Some confusion with MCEC. The invoiced amount was too low. This has been corrected but the invoices are not going to the PyConAu organisers but to Joel instead.
Flounder sub committee update
Monthly meetings are still happening. Nothing of particular to note, but a grant report for the PinePhone work has been submitted.
LUV sub committee update
Online meetings have declining attendance, but the in person meetings are still well attended. Possibly two online and one in person meetings per month are too many.
The plan is to hold elections in August or September. Meetings will likely be rationalised after the election.
WordPress sub committee
Ticket sales have opened and 30 tickets have been sold, including 4 sponsor tickets, even without a program being announced.
34 speaker applications have been received. Speaker applications close on 2 July. Quite a few international applications.
Money is starting to arrive from sponsors (about 28000 plus 15000 from WordCamp global) 5 sponsors soi far with another two or three possibilities to talk to. One sponsor is interested in providing travel assistance. The sponsor will handle the financial aspect with the Wordcamp committee assisting with selecting candidates.
The AV company and Saturday evening social venue have sent in invoices to lock in dates.
Everything Open 2025
The pandas at Adelaide zoo will probably be replaced with new ones which means that the Penguin Dinner venue will probably not be available.
Two volunteers Thomas Sprinkmeier and Charelle Collette (Speaker Coordinator).
Joel and Sae Ra will organise a planning meeting for next Wednesday.
purplecon
No update
4. Items for noting
5. Other business
Admin access to LA mailing lists – Sae Ra will provide passwords to Neill
Everything Open Session selection Committee
6. In camera
No items were discussed in camera
7. Action items
Sae Ra and Russell to review the DrupalCon Asia licence agreement
Jonathan to respond to Felicity Brand
7.1 Completed Items
7.2 Carried Forward
Meeting closed at 21:10
Next meeting is scheduled for 2024-07-03 – 7:30pm AEST / 7:00pm ACST
Meeting opened at 19:36 AEST (UT+1000) by Joel and quorum was achieved.
Minutes taken by Neill.
2. Log of correspondence
WISE topup to pay Germans – would you authorise please [Kiwi PyCon – Russell has responded]
Linux Australia Registered Charity Australian Business Number? [Drupa South/Asia query. Russell and Joel have responded]
Question about “address of recipient” wrt to 029 [Donation from PSF for Kiwi PyCon – Russell has responded]
90 Day Renewal Reminder 2024-08-07 [for taslug.org.au – admin team will deal with this]
Phoenix Sponsor, banners at conference [Kiwi PyCon acknowledgement of Linux Aus – looks good]
LINUX AUSTRALIA INC. is now registered at Australia! [With connecting Up]
Please sign the attached anz.co.nz mandate [Still sorting out NZ ANZ bank access]
Payment to Acquamarina Hotel – DrupalCon Asia [Venue payment for Drupal Asia – Russell has responded, still in progress. Follow up may be required]
SG Bank Account Details [DrupalCon Asia – Russell has responded]
[Purplecon] Invoice payment request – Art design [Russell has responded]
Fwd: PyCon AU 2024 Financial Induction [Russell has responded]
FW: FW: Add Authoriser to ANZ Direct Online – 417289 Linux Australia (Incorporated) – ATTN Cameron – new mandate [ ANZ NZ bank access – Russell is dealing with this]
Missing wire payment – any suggestions ? [PSF payment to Kiwi PyCon – Russell has responded, appears to be a problem for the bank to sort out. May need the PSF to get involved]
Fwd: 12:47,Debit initiated from your bank account [DrupalCon Asia – Russell has responded]
Invitation: Linux Australia – EO2025 Subcommittee @ Wed, May 22 2024 19:55 AEST [Discussion about EO2025 venues etc. Joel has responded]
Re: SG Bank Account Details [Discussions about bank accounts for Drupal Asia. Russell has responded]
Unlicensed Use of Reuters News & Media Inc Imagery – Reference Number: 7536-1819-1990 [Another baseless legal demand]
Upcoming Domain Renewal Notice – Please Do Not Reply [for slug.org.au]
Open Source Congress: registration open
3. Items for discussion
Everything Open 2025
Announcement has been sent to the mailing list. Websites are being updated.
Mike O’Connor attended our meeting to discuss progress with EO2025
Venue deposits have been paid. A quote for the penguin dinner has been received.
Some discussion with the local Maker Faire group who may be interested in an activity before or after the main conference.
There may be some scope for having a fair of some sort in the coffee room. Or a poster session / O-week style area, or a space for sponsors. At any rate a space is available and discussions about how to best use it should happen.
Mike will send another recruitment email from his personal address. There have been two people who have expressed interest in helping so far.
Sae Ra has finalised the EO2025 sponsorship prospectus. Two organisations have already expressed an interest in sponsoring the conference.
Connecting Up
Connecting Up helps non profit organisations access resources.
They have asked for some more details.
It looks like we may not qualify as we are not income tax exempt, and may not qualify as a non profit organisation.
This came up in response to Drupal South and Drupal Asia trying to get access to an slack enterprise licence.
Joel would like other council members to read through the ATO documentation to see if we think we may qualify.
4. Items for noting
Grants Program
The email about the proposed changes to the grants program has been sent to the mailing list.
EO2024 financial result
The final result is a profit of $17,000. A remarkable result for a conference run in challenging circumstances.
Meeting opened at 19:31 AEST by Joel and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
A resolution to our Google problem – is this OK with you ? [Discussion about invoicing for Pycon NZ] – Russell has responded
Lodge Linux Australia Activity Statement January..March 2023 [Activity statement has been lodged and paid]
FW: FW: Add Authoriser to ANZ Direct Online – 417289 Linux Australia (Incorporated) – ATTN Cameron [We’re still sorting out Linux Australia NZ bank account
Tax Invoice 79793 & Credit Note 333337344 – Everything Open 2024 held on the 15th to 19th April 2024 [Sorting out the final payment to the Gladstone Entertainment Centre]
Did a socials post for upcoming LA events [Kathy reid has posted about upcoming events on LA’s social media accounts]
Re: [LACTTE] Payment ref / Payer name [Discussion about paying invoices for Pycon NZ]
Details for WordCamp Sydney 2024 [Russell has setup Xero and Westpac access for the Wordcamp subcommittee]
DrupalAsia SC Update [details below]
Phoenix Sponsor, banners at conference [Pycon NZ have listed LA as a “Phoenix” sponsor in recognition of our assistance]
Public Liability Insurance for Django Girls events [Django Girls Adelaide would like to sign up as a subcommittee]
OSAID reaches v0.0.8, receives Sloan Fdn. grant [OSI are working on an Open Source AI Definition and would like feedback]
PyCon AU 2024 Financial Induction [PyCon AU have provided details of the Xero access they need]
Re: [LACTTE] Inquiry: running an information security conference (Purplecon)
3. Items for discussion
Drupal sub committee update
Drupal South
Have a two person subcommittee starting planning for Melbourne (Julie and Carl). Looking at venues 38(!) possibilities being investigated. Trick is finding somewhere affordable that can accommodate the expected numbers. Short list is three locations. A site visit at the preferred location (ACMI) has happened and a contract has been received. The subcommittee will meet tomorrow. There are local agencies keen to help once a venue has been selected. The conference is planned for the end of March 2025.
A sponsorship meeting is planned both with current sponsors and also with sponsors who did not participate this year. Sponsorship costs will be increasing. They haven’t changed since 2017.
The full subcommittee should be running by June. Dave hopes to be less involved in running the conference.
Elections for the committee (as opposed to the conference subcommittee) are planned for announcement in July, with results announced in October. The committee is considering opening the charter to allow participation from people in Oceania outside of Australia and New Zealand.
DrupalCon Portland
Held in May, well received. Previous Next were recognised as a leading agency and will be part of the Drupal Starshot programme. Good result for our region.
Developer Survey
83% of respondents have been working with Drupal for 10 or more years. The community is keen to bring younger people on board.
Drupal Asia
Report for Michael who could not attend tonight:
Hello,
I wanted to provide an update from the DrupalAsia Steering Committee in writing this month, as unfortunately I’ve been very unwell this past week and won’t be able to dial in to the meeting tonight.
We announced DrupalCon Singapore at DrupalCon Portland two weeks ago. There was a miscommunication where we were advised Dries (the Drupal founder and a major keynote speaker) could make our original dates, but in fact he could not. So, we’ve shifted the dates now to Dec 9-11.
I shopped around sponsorships in Portland and last week in Japan and the response has been very positive. I originally expected most of our sponsorship dollars would need to come from US and EU sponsors looking to get into the Asian market, but there is actually some very good interest from Singapore, India, and Japan.
Our priorities for the coming month will be sponsorship sales (slightly delayed while I’ve been sick) and reviewing the speaker submissions.
Aside from the last-minute date change, it is all pretty smooth sailing.
I apologise I can’t make the meeting today. Next month I’ll bring another steering committee member with me so there’s some redundancy in place for future meetings.
Regards,
Michael Richardson
KiwiPyCon
No update this month
Admin team update
No update this month.
Joomla sub committee update
No update this month
PyCon AU sub committee update
Another deposit is due, Joel will contact them about paying it.
The PyCon Au have done the financial induction and supplied a budget and a list of the organisers.
Flounder sub committee update
Planning to do some more phone related work, as well as SE Linux and RISC V
LUV sub committee update
Still going, still trying to get young people to turn up. Still trying to organise elections.
WordPress sub committee
Several sponsors have come forward (3 platinum and 1 diamond) plus the WordCamp global sponsors which brings the total amount to $44,000 (a bit more than half the goal). There are two other sponsors in talks and another company interested in helping with assistance for financial hardship.
The call for speakers has gone out and 18 people have responded so far. There is about a month left before the call for speakers closes. There have been a few international speakers, but Wordcamp prefers local speakers.
Stripe access has been set up.
Two tiers for tickets, normal tickets plus mini sponsors for people who want to contribute a bit extra.
The committee is working well. Currently coordinating on Trello.
AV quotes have been received, but a selection has not yet been made. The WordCamp Brisbane equipment is too old to be useful. Linux Australia may be able to offer AV equipment, once we document how it works.
There are several people interested in running a WordCamp in 2025, which is a promising sign.
Everything Open 2025
Contract is now signed. Deposit will be paid shortly. Russell will provide a bank account and area.
The domain name is registered and the website will be up soon.
Radio silence from Mike at the moment.
Everything Open 2024
Videos are not ready yet, but will be worked on soon.
purplecon
Anton and Jeremy attended their first subcommittee meeting.
purplecon was run in 2018 and 2019 in Wellington, this is the first year running it in Sydney. The committee has members in both New Zealand and Australia.
Russell has run the financial induction.
The venue has been confirmed – the State Library of NSW.
Meeting opened at 19:34 AEDT (UT+1000) by Joel and quorum was achieved.
Minutes taken by Jonathan and Neill.
2. Log of correspondence
Fwd: Fwd: Re: Linux Australia Inc, Client ID 417289 ATTN : Cameron -Russell has responded
Insurance Doc for WordCamp Sydney – Joel has responded
Public liability certificate expired – Joel has responded
Details for incoming international payments – Russell has responded
LA Scanned Post
Fwd: Re: Inquiry: running an information security conference (Purplecon)
DrupalCon Singapore Budget Approval – Joel has responded
Does LA have an Ariba Account – Russell has responded
Xero Orientation for WordCamp Sydney
Joe Chin Contact Details – Russell has responded
Everything Open 2025 – Joel has responded
Enquiry from Serghei Anicheev via the Linux Australia Website Contact Form (EO/LCA2025) – Jonathan has responded
PyCon AU 2024 bank account signatories – Russell has responded
Enquiry from Robyn Willison via the Linux Australia Website Contact Form (Grants) – Jonathan has responded
Inquiry: running an information security conference (Purplecon) – Russell has responded
GST on a conference in Singapore
Report for Linux Australia grant: Girls Canberra #1 – (Expenses) – Russell has responded
Enable MFA on the root user of your account [AWS Account: 103334912252]
Upcoming Domain Renewal Notice – Please Do Not Reply (slug.org.au)
Activity statements are available online [SEC=OFFICIAL:Sensitive]
3. Items for discussion
Everything Open 2025
Have not yet established a subcommittee or approved budgets. This needs to be done soon so that we can get back to the venue.
There is a google drive folder for the 2025 conference.
The budget is very similar to Melbourne in terms of expected attendees. Ticket prices have been raised slightly to recognise increased costs (particularly for the Penguin Dinner).
Joel is comfortable with the projected attendee numbers. It’s modelled vaguely on the most recent Melbourne conference.
Sponsorship could be tight in the current climate within the tech sector. There is a need to identify new organisations. The Adelaide Economic Development Agency is having a funding round soon. NBN is another possibility.
MOTION: Linux Australia accepts the EO2025 Budget to allow venue bookings to commence.
Seconded: Sae Ra
Carried unanimously.
Joel will get contracts sent through so they can be signed. He will also work with Mike over the coming weekend to finalise the announcements.
LCA2022 Swag Badge
This has not been fully dealt with, contrary to Council’s original belief. The Open Hardware team have given some badges out to those who were at the 2023 conference. Those who weren’t missed out. Since the money went to LA, we should be able to provide a refund. However, the preference would be to get the hardware to those who purchased them. Unfortunately, attempts to reach the Open Hardware team have been met with silence so it’s difficult to fully understand the situation. There is no definitive list of who has received hardware and who hasn’t.
Sae Ra has a list of people which can be compared to the conference attendee list. This allows them to be contacted to ask them what their situation is. Those who didn’t can just be refunded. It appears that this is the easiest option. Sae Ra will take the lead on this.
LA has not received an invoice from the Open Hardware for the expenses for the 2022 Swag Badge. It would be good to attempt another contact about this so legitimate expenses can be paid. Andrew Pam will try to make physical contact with the relevant people.
If badges are to be sent then LA will pick up the cost of postage. Sae Ra will collect hardware and arrange postage if needed.
Grants email
Open grants
Request feedback on proposal for hardware grants
The additions to the guidelines are in github. A short community consultation will commence in the next couple of days. The consultation period will be open until Fri 24 May. The changes can be finalised over the weekend, with grants opening on 27 May. Joel will send an email out to the list to this effect.
EO2026, EO2027 EOI
Joel will send the emails out soon. If anyone wants changes to the standard template they should mention it to Joel.
Subcommittee Meetings
Add Clinton to PyCon AU section
This will be done by Neill. Clinton will act as a backup if Richard Jones can’t make it.
Invite EO2025 representative
Mike will be invited. This may be adjusted as the team comes together.
NZPUG
For NZPUG, Danny and Tom should be invited along with RIchard Shea.
Some minor adjustments to times will be made to accommodate those in NZ as best we can.
4. Items for noting
Recordings for EO2024 are being worked on. The aim is to put a first batch available by the end of the coming weekend. Announcements of the video availability will be tied in with those for EO2025.
5. Other business
It’s emerged that a number of people are not aware that linux.conf.au has evolved into Everything Open because they only check linux.conf.au. There is a need to put a notification on the linux.conf.au site to point visitors at everythingopen.au. Joel will do this while setting up the EO2025 site.
Meeting opened at 19:35 AEST by Joel and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
Lodge Linux Australia Activity Statement January..March 2023
Insurance Doc for WordCamp Sydney
Everything Open 2025
Fwd: Public liability certificate expire
Github PR request created for hardware grant clarifications
DrupalAsia Budget Review Request
Fwd: Re: [Linux-aus] LCA2022 SwagBadge
Re: Fwd: [EO2025 Venue]
Re: Linux Australia Inc, Client ID 417289 ATTN : Madhura
Re: Uni Adelaide contact
ATO CFP, Board election results, Open Source AI 0.07
Image License Inquiry for Reuters News & Media Inc – Reference Number: 7536-1819-1990 – council will look into this, but our expectation this has no validity
NZ payment on ANZ to approve [Approved by Sae Ra]
Tasks for Linux Australia Incorporated
Draft AGM minutes
Re: DrupalSouth Invoices for Payment [Done by Russell]
Re: Payment please and a question about WISE [Russel has responded]
Linux Australia and WordCamp Central Memorandum of Understanding 2024 revised [Russel has responded – item is complete]
3. Items for discussion
Drupal sub committee update
Drupal South
Quiet month post Drupal South. Good feedback, but limited responses (40/250) to the post event survey. Should have the final budget for Sydney within the next week .Only one invoice outstanding.
Setting up a new subcommittee for 2025 in Melbourne. Have a potential venue and have done an initial inspection. Should be cheaper than Sydney, but still expensive.
Had a BoF session at Sydney with potential sponsors. WIll have more discussion with them. That will help with finalising the 2025 budget.
Keen to broaden speaker choice. Some feedback that delegates would like a broader range of topics.
Only 3% of speakers identified as being from a diverse/underrepresented group. How do we encourage more diversity?
LA response:
Joel: We have encountered the same problem. Starts with having diverse backgrounds on the session selection committee who can reach out to people from their communities. EO/LCA has not attempted to have a completely blind selection process for a couple of reasons (one we seek to get maintainers, two because we probably can’t fully de-identify.
Sae Ra: We hold a “how to submit a paper” session. We encourage users as well as maintainers to submit papers. THis has helped somewhat. Useful to explain both the process and what is being looked for. Reassuring potential submitters that we’re not harsh critics and are willing to help. Sae Ra is willing to run a session for the Drupal conference, or supply slides.
Committee
Elections coming up, must be held by October. Will aim to hold elections in July. Have one new person helping the committee and another express interest.
Drupal Asia
Ready to go! The Drupal Association is keen to get started. The web page is ready. Hotel is booked. Agency dinner on the first night – networking session. Good opportunity for cross country/culture discussion.
Sponsorship package is ready to go. Based on the existing Drupal Cons. Major sponsors from Europe/North America are keen to be involved. Budget looks good.
Mike will be going to DrupalCon in Portland and announcing DrupalCon Asia, subject to approval from the LA Council.
LA Council will need to hold a formal vote, but the expectation is that it will be approved. Need to sort out insurance as well, some questions to be resolved about whether there is a single venue or not. Good news on the tax from – we do not need to pay GST unless turnover is over $1,000,000.
Still need Jim to push a transaction through Wise. Mike will follow up. We do need two people to operate the bank account because it requires two to sign.
Singapore Tourist Bureau – did not go ahead because of conflicting requirements.
ACTION: That Linux Australia establishes DrupalCon Singapore 2024 as an event subcommittee, in line with the provided budget and plan.
Mover: Joel Addison
Seconder: Jonathan
Passed unanimously
KiwiPyCon
No update
Admin team update
Another pass on the mailman migration. The problem is that we are on mailman 1.18. Mailman 2 needs python2.7. Not supported by modern distros. Need to use mailman 3 instead. This is causing some issues converting the archives. One possibility is Debian 10 (but is leaving support on 30 Jun) or Alma Linux which is supported until 2027 . Ubuntu may be another possibility with the recent announcement of 12 years of LTS support.
We’ve had an NVME fail in one of the servers. There is a budget for disk replacement. So that process is about to start.
Next year there will be a face to face meeting for the admin team.
Steve is also about to look into some possible problems with backup destinations.
Sae Ra asks – can we just dump the old archives to flat files rather than trying to convert them? This is possible, but probably not the preferred option.
The plan is to move to mailman 3, but preferably a little later when the admin team has more time available.
The admin@ email address is to be deprecated (unless APNIC requires it). Use admin-team@ instead.
Joomla sub committee update
Reconnect with Joomla event was held in Brisbane. 19 delegates, which was one below the budget, but unexpected sponsorship meant that a profit was made.
Planning for an event in Melbourne next year has started, expected to have higher numbers.
FInal report is nearly ready. Some issues with banking access for the Joomla treasurer.
A discussion about becoming a Linux Australia subcommittee happened at the event. In principle agreement to continue, but need to simplify the constitution. Rather than copying the Linux Australia constitution Nathan is looking at producing something tailor to Joomla.
If the Joomla subcommittee charges for membership Linux Australia will probably need to charge a fee to cover the costs of processing payments. Probably similar to the fee collected from conferences. The council will discuss this and then talk to the Joomla subcommittee.
Linux Australia agrees to waive the fee for this year’s conference.
PyCon AU sub committee update
No Update
Flounder sub committee update
Andrew reports that Flounder is planning to hold an Everything Open retrospective on Saturday.
LUV sub committee update
Is there any possibility to assist local user groups run hybrid meetings? Do we have any equipment?
We do have some equipment, but we need to look at its suitability. For small meetings would zoom or similar be sufficient?
Someone has approached LA about VHS recordings of old LUV meetings. They would like to get in touch with the current LUV committee to work out what could happen with these, eg. being put on the LA mirror.
WordPress sub committee update (from Wil, via email to council at 19:41 UT+1000)
Apologies but I [Wil] won’t be able to make 8pm tonight. On the way back from a WordPress meetup.
Here’s a quick update on WordCamp Sydney.
Site launched
over 350 people on the email list
call for sponsors is out
one secured sponsorship for Sat Evening Social Event, four others interested
contacting our list of previous and potential sponsors
Jo and Jordan have still to do LA finance training. Have asked them to hurry up as we’ll soon need access to Xero and Stripe
hope to announce ticket sales as soon as we have stripe access
That’s all.
Thanks for your support!
Wil.
Everything Open 2024
Done!
Overall it went pretty well. A few hiccups with AV and streaming, which is unsurprising given it was a new approach.
Kathy’s Report:
EO succeeded because of the work that had been done on many previous conferences.
A number of challenging externalities. Economic issues affected sponsorship and also the remote location was also very expensive. The desire to go into the regions is admirable, but it makes it hard for delegates to attend.
Advice to the council is that we should look for good project management and team leadership skills in the future.
Did we do the right thing in charging for streaming? Did we provide $79 worth of value? Kathy believes that we did, even though it wasn’t perfect. We should charge for it in future because streaming does impose a cost on the conference.
For comms next year – cost of tickets are incredibly low relative to the value provided. Not suggesting that we raise the prices, but we need to communicate the cost to provide it (if we didn’t have volunteer labour) and emphasise the value received.
Recommend that the conference needs a full time communications person. Adelaide should be starting communications now. Comms and media can also help with session selection.
Perhaps we should look to provide some project management training to the lead organisers.
Induction training. Shadowing?
Pipeline – our grass root communities have dissipated post COVID. How do we address this? Encourage local tech meetups? Build relationships with Universities.
Sorting out NZ banking
Neill and Jenny need to get this done as soon as possible.
4. Items for noting
5. Other business
Australian Institute of Management (AIM) courses as part of grants?
6. In camera
One item was discussed in camera
7. Action items
7.1 Completed Items
7.2 Carried Forward
Respond to DjangoGirls request – Neill Cox
Meeting closed at 21:17
Next meeting is scheduled for 2024-05-08 – 7:30pm AEST / 7:00pm ACST
Meeting opened at 19:37 AEST by Joel and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
Enquiry from Julia Topliss via the Linux Australia Website Contact Form – Joel has enabled Julia’s membership. Joel will confirm that Julia has been notified
Everything Open 2025 – Mike O’Conner – Russell has responded
New MoU with WordCamp Central – Now signed and complete
Linux Australia and WordCamp Central Memorandum of Understanding 2024 revised
Singapore Tourism Board Grant [for DrupalConAsia] – this is for DrupalConAsia to deal with
Requesting Help – David Hayes – Jonathan has responded
Fw: Your Stripe transactions have exceeded a tax threshold in 2 locations
Collecting foreign VAT (related to above)
Insurance Doc for WordCamp Sydney – need dates of event to complete
Fwd: Status of transfer #${payment} – in progress. Russell has responded
Question about email with subject ” BAS Time” – 3rd April – in progress
BAS Time – in progress
All Universal Analytics services cease to function starting 1 July 2024 – not an issue for LA.
Your PO Box lease has been renewed
Kiwi Pycon payments question and ANZ question – dealt with
Re: PyCon AU 2024 bank account signatories – ongoing
Email from PurpleCon
EverythingOpen 2025 – Russell has asked the University of Adelaide if they will host EO2025.
Re: Joe Chin Contact Details – Joe now has an account with Wise, but has not yet gone through the identification process.
3. Items for discussion
ANZ Identification – Neill and Jenny yet to get documents certified.
Minutes for the AGM not yet complete, because Neill
4. Items for noting
There are ongoing issues with email to treasurer@linux.org.au and other council addresses – Sae Ra and Steve will investigate, but this may have to wait until after EO2024.
5. Other business
LA Tax
LA should consider increasing the 6% “LA Tax” so that we can adequately cover our expenses and maintain our reserves.
Foreign VAT
Stripe have told us that we have exceeded tax thresholds in France, which will require us to pay VAT to the French government.
Notionally this should only apply for goods and services consumed in France.
This theoretically requires us to deal with every countries VAT/GST requirements.
Our accountant has advised us that this should not apply, but we need to convince Stripe of this.
We really don’t want to have to deal with individual jurisdictions if we can possibly avoid it.
PurpleCon
PurpleCon have requested our help. Not financial, but help with insurance, bank accounts, tax etc. There would be some work and costs for us which could be covered by the 6% LA tax.
Russell will respond explaining the process and requirements for LA to auspice their conference.
Motion: That we accept PurpleCon as a subcommittee, subject to them complying with LA’s subcommittee requirements
The new Hardware grants process document was discussed. The proposed wording will be committed to LA’s github and provided to the community as a draft for comment.
6. In camera
No items were discussed in camera
7. Action items
Add KiwiPyCon to the SubCommittee meeting list
7.1 Completed Items
7.2 Carried Forward
Respond to DjangoGirls request – Neill Cox
Meeting closed at 20:29
Next meeting is scheduled for 2024-04-24 (Subcommittee)
Meeting opened at 20:03 AEDT by Joel and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
Fwd: ID for Linux Australia Inc, Client ID 417289 ATTN : Madhura [Wi]
Latest email to Wise
Fwd: Status of transfer #${payment}
Pretalx/Pretix invoices due
PyCon AU 2024 bank account signatories
Fwd: OSI Election and Candidate Information
Hardware grant guidelines
Enquiry from Julia Topliss via the Linux Australia Website Contact Form – Jonathan has sent an initial response, follow up is needed. Joel to do this.
Requesting Help – Jonathan has sent an initial response, discussion needed. JOnathan will follow up: explain what LA does, ask for more information about what the club does (whether they do Open Source-like things, etc).
Everything Open 2025 – Adelaide is still a possibility. Need to confirm venue and team composition.
3. Items for discussion
Drupal sub committee update
Drupal South Sydney was last week. Generally very successful in terms of attendance and feedback. 255 attendees. Significant number of new delegates, many local. Over half the tickets came in at the latebird price so ticket revenue was up at $65k, but sponsorship was down. Looking at a projected loss of $13.2K
Good feedback from the Drupal Association. Good coverage on Drupal industry media.
The committee had a session. An election is coming up. Not too many volunteers for the committee, but more enthusiasm for being involved in other ways.
It’s probably too expensive to run events in Sydney in the future.
Question from Joel: LA’s insurance is up for renewal so we need to know how many events will Drupal South be running? What size?
Answer: Planning an event in Melbourne, discussions about whether to continue the large corporate event and the feedback is that it is worth doing. Don’t want to reduce the conference to a single track.
Drupal Asia
Don’t quite have a final budget but DrupalCon Asia was announced at Drupal South Sydney. In the final stages of finding a venue. The experience of finding a venue in Singapore is very different from Australia/NZ. Need to spend much more effort on chasing the venues
DrupalCon will have a quite different sponsorship model. Rather than just a Gold/Silver/Bronze there is a core sponsorship and then many possible add ons. Sponsorship prices are based on attendance.
At this point the budget looks like it will break even.
The Drupal Association is not looking to make a major profit, but is keen to make a deal. At this point it looks like the DA will take a 30% cut of profit.
Mike has not yet spoken to the Singapore Tourism Board. Sae Ra suggests that they might be a useful resource. They’re keen to help conferences come to Singapore.
There are a large group of European agencies looking at expanding into Asia. They should be a good source of sponsors.
Ticket prices are more likely to be an issue. Ticket prices are low for a DrupalCon, but quite hight relative to local incomes.
It might be worth looking at the possibility of travel grants. EO/LCA/PyConAU have traditionally included a DEI sponsorship, so maybe this is worth considering for DrupalCon Asia.
Applications for assistance normally come through a web form that asks for what assistance is needed (travel, accommodation, tickets) and what the grant would allow the delegate to do.
Question from Mike – will a decision need to wait for the next council meeting or can we do something sooner.
Answer: We can do things outside of meetings, but we only do so if there is an urgent need.
Looking at 4-6 December.
Linux Australia will look into insurance, the Drupal Association will not provide any financial assistance, including insurance.
Linux Australia will also need to provide bank accounts. Probably through Wise.
Michael and the DrupalCon Asia (Joe Chin) will need to be able to operate on the bank accounts. They will need to complete a financial induction with Linux Australia and we need to get them authenticated to Wise ASAP.
Admin team update
New mail server is almost ready to go. Needs some reassembly. Will put it together over the long weekend. Otherwise once EO is done will look to move the mail and lists for EO to FastMail which will remove the last blockers for maintenance of our servers.
We have bought the professional plan at retail price, but do not currently have the reseller option attached to it. Sae Ra has people to contact at FastMail to sort this out. We will probably be able to move to a cheaper plan once our migration is complete, but in the meantime we need support.
Joomla sub committee update
No representative present.
PyCon AU sub committee update
No representative present.
Flounder sub committee update
No representative present.
LUV sub committee update
Usual meetings are continuing (two technical meetings and one social each month). Looking at collaborating with ComputerBank. Seeing some young people coming to the meetings, but not all of them come back.
No progress on an election yet.
WordPress sub committee update
Good progress for Sydney. Venue pencilled in with dates of 2 and 3 Nov.
Financial induction to do for some members of the committee.
The budget has been sent to the LA council
WordCamp is a branded conference. There is a meeting with WordCamp to finalise the budget for WordCamp Sydney.
There have been some discussions with WordCamp who were hoping that the AV could be done by volunteers, but there are a lot of risks involved and the decision is currently that it should be done by professionals.
The MoU has been signed by Linux Australia. Sae Ra will check to see if it has been sent to WordCamp.
Everything Open 2024
Have sold 110 tickets. Sales are accelerating
APNIC are organising their meeting around EO
Looking at the hybrid options. The ticket type has been created.
Making sure speakers are locked in.
There are only six taxis in Gladstone! May use the bus for transport.
Sorting out NZ banking
Need Neill to produce minutes for the 2024 AGM
Also all council members need to get their IDs sorted out by the end of next week.
Council members will sign the minutes and constitution as per requirements from ANZ, then we will send this.
4. Items for noting
5. Other business
6. In camera
Nothing was discussed in camera
7. Action items
7.1 Completed Items
7.2 Carried Forward
Respond to DjangoGirls request – Neill Cox
Meeting closed at 21:33
Next meeting is scheduled for 2024-04-10 – 7:30pm AEST / 7:00pm ACST
Meeting opened at 20:08 AEDT by Joel and quorum was achieved.
Minutes taken by Neill
2. Log of correspondence
Inquiry: running an information security conference (Purplecon) – Russell Stuart has responded with an outline of what is required.
[LACTTE] Kiwi Pycon – Possible to transfer ANZ funds to cover Wise payments ? – Russell Stuart has responded
New MoU with WordCamp Central – Russell Stuart has responded
Cancellation of Membership – as per Dwight Walker’s request his LA membership has been cancelled
Enquiry from Bogusz WupLUG via the Linux Australia Website Contact Form
Fwd: OSI Affiliate candidate – Miles has been accepted as an OSI board candidate (representing KDE?)
WordCamp Sydney 2024 – Request to form a LA subcommittee – Russell Stuart has advised Wil Brown of the LA Councils acceptance of the proposal to accept WordCamp as an LA Subcommittee
Payment Approval Request [Drupal] – Russell Stuart has responded
Payment to Wise – business details mismatch? – Russell Stuart has responded
Enquiry from Zahra Alizadeh via the Linux Australia Website Contact Form [DjangoGirls workshop in Adelaide]
30 Day Renewal Reminder 2024-03-20 [for linux.com.au]
Your Wise concern – Russell Stuart has responded
3. Items for discussion
DjangoGirls session in Adelaide
Team is looking to run an event in May. They are wondering about insurance coverage from Linux Australia.
We can provide insurance to them if they come onboard as an event subcommittee. Neill will respond to them with this information.
[JW] Grants:
Do we have funds for this? Yes.
If so, what amount are we looking at? $10000.
If we can offer a grants program, will we tweak the 2024 model or just roll with it?
Some concerns about the value for money of the hardware grants. We need to come up with a way of measuring the value. Both positive and negative results are fine, as the point of experimentation is to determine what value can be gained.
We only had one community grant taken up last year, but there seem to be several groups trying to establish themselves so running community grants again this year seems worthwhile.
We would like to come up with a framework for measuring outcomes from grants, especially hardware and software projects. This should be developed by Council initially, then shared with the community via LinuxAus and Grants mailing lists for feedback. Ideally this should not be too onerous, but will be enough to give LA and the community confidence in the grants that are awarded.
If a grants program can happen, when can we open it?
How should we communicate grant proposals?
Grants list? General list? Website? Social Media
Perhaps announce proposals on the website, general list and social media, but keep detailed discussions on the Grants List.
Open Source Tools – Video conferencing, Document collaboration
Who could take on investigating these, doing a needs analysis and writing a document with possible options?
Insurance
Renewal is coming up. We need a list of all events for the coming year, including locations and expected attendee numbers.
4. Items for noting
Wise is still in progress, getting everything sorted.
NZPUG has a payment due. Sae Ra will follow up with them to get this sorted.
5. Other business
6. In camera
Two items were discussed in camera
7. Action items
Respond to DjangoGirls request – Neill Cox
Speak to KiwiPycon re: payments – Sae Ra Germaine
Produce a proposal for a way of measuring the value of hardware grants (to be shared with the wider community for comment later) – Jonathan Woithe
Draft a document discussing alternative video conferencing and collaboration tools – Sae Ra Germaine
Produce a list of upcoming events for insurance purposes – Joel Addison
7.1 Completed Items
7.2 Carried Forward
Meeting closed at 20:58
Next meeting is scheduled for 2024-03-27 (Subcommittee)
Delivers on the title. Interesting explanations of types of lakes, how they came to be and how they evolve. Great writing and lots of interesting information 4/5
A Veteran TV Writer and Showrunner writes about his career, the business and how to make it as a TV writer and possibly eventually a showrunner. Excellent 4/5
This book did not go where I expected it to. Sure, it has a species uplift plot which is similar to Children of Time, but that’s not all that’s happening here. If the previous book was about refugees and redemption, this book is about alternative ways of structuring societies (I don’t want to ruin the surprise by being too specific). Let’s just say some of these societies are small and some are big, but they both cooperate to achieve their goals better than perhaps our society does. There’s definitely a pattern forming about how books in this series resolve their conflicts.
I’m not normally into horror as a genre, and there are definitely horror elements to this story. I probably wouldn’t have bought this book if I’d known how it was going to be different from the previous one. That said, the horror element decreases after a mid-book peak and overall I enjoyed the story although not as much as that of the first book in the series.
Children of Ruin
Adrian Tchaikovsky
Fiction
Pan
February 20, 2020
564
Thousands of years ago, Earth's terraforming program took to the stars. On the world they called Nod, scientists discovered alien life - but it was their mission to overwrite it with the memory of Earth. Then humanity's great empire fell, and the program's decisions were lost to time
Two months ago I bought a Thinkpad X1 Yoga Gen3 [1]. I’m still very happy with it, the screen is a great improvement over the FullHD screen on my previous Thinkpad. I have yet to discover what’s the best resolution to have on a laptop if price isn’t an issue, but it’s at least 1440p for a 14″ display, that’s 210DPI. The latest Thinkpad X1 Yoga is the 7th gen and has up to 3840*2400 resolution on the internal display for 323DPI. Apple apparently uses the term “Retina Display” to mean something in the range of 250DPI to 300DPI, so my current laptop is below “Retina” while the most expensive new Thinkpads are above it.
I did some tests on external displays and found that this Thinkpad along with a Dell Latitude of the same form factor and about the same age can only handle one 4K display on a Thunderbolt dock and one on HDMI. On Reddit u/Carlioso1234 pointed out this specs page which says it supports a maximum of 3 displays including the built in TFT [2]. The Thunderbolt/USB-C connection has a maximum resolution of 5120*2880 and the HDMI port has a maximum of 4K. The latest Yoga can support four displays total which means 2*5K over Thunderbolt and one 4K over HDMI. It would be nice if someone made a 8000*2880 ultrawide display that looked like 2*5K displays when connected via Thunderbolt. It would also be nice if someone made a 32″ 5K display, currently they all seem to be 27″ and I’ve found that even for 4K resolution 32″ is better than 27″.
With the typical configuration of Linux and the BIOS the Yoga Gen3 will have it’s touch screen stop working after suspend. I have confirmed this for stylus use but as the finger-touch functionality is broken I couldn’t confirm that. On r/thinkpad u/p9k told me how to fix this problem [3]. I had to set the BIOS to Win 10 Sleep aka Hybrid sleep and then put the following in /etc/systemd/system/thinkpad-wakeup-config.service :
Now it works fine, for stylus at least. I still get kernel error messages like the following which don’t seem to cause problems:
wacom 0003:056A:5146.0005: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
When it wasn’t working I got the above but also kernel error messages like:
wacom 0003:056A:5146.0005: wacom_wac_queue_insert: kfifo has filled, starting to drop events
This change affected the way suspend etc operate. Now when I connect the laptop to power it will leave suspend mode. I’ve configured KDE to suspend when the lid is closed and there’s no monitor connected.
MrWhosTheBoss made a good YouTube video reviewing recent Huawei products [2]. At 2:50 in that video he shows how you can link a phone and tablet, control one from the other, drag and drop of running apps and files between phone and tablet, mirror the screen between devices, etc. He describes playing a video on one device and having it appear on the other, I hope that it actually launches a new instance of the player app as the Google Chromecast failed in the market due to remote display being laggy. At 7:30 in that video he starts talking about the features that are available when you have multiple Huawei devices, starting with the ability to move a Bluetooth pairing for earphones to a different device.
At 16:25 he shows what Huawei is doing to get apps going including allowing apk files to be downloaded and creating what they call “Quick Apps” which are instances of a web browser configured to just use one web site and make it look like a discrete app, we need something like this for FOSS phone distributions – does anyone know of a browser that’s good for it?
Another thing that we need is to have an easy way of transferring open web pages between systems. Chrome allows sending pages between systems but it’s proprietary, limited to Chrome only, and also takes an unreasonable amount of time. KDEConnect allows sharing clipboard contents which can be used to send URLs that can then be pasted into a browser, but the process of copy URL, send via KDEConnect, and paste into other device is unreasonably slow. The design of Chrome with a “Send to your devices” menu option from the tab bar is OK. But ideally we need a “Send to device” for all tabs of a window as well, we need it to run from free software and support using your own server not someone else’s server (AKA “the cloud”). Some of the KDEConnect functionality but using a server rather than direct connection over the same Wifi network (or LAN if bridged to Wifi) would be good.
I recently had someone describe a Mac Mini as a “workstation”, which I strongly disagree with. The Wikipedia page for Workstation [1] says that it’s a type of computer designed for scientific or technical use, for a single user, and would commonly run a multi-user OS.
The Mac Mini runs a multi-user OS and is designed for a single user. The issue is whether it is for “scientific or technical use”. A Mac Mini is a nice little graphical system which could be used for CAD and other engineering work. But I believe that the low capabilities of the system and lack of expansion options make it less of a workstation.
The latest versions of the Mac Mini (to be officially launched next week) have up to 64G of RAM and up to 8T of storage. That is quite decent compute power for a small device. For comparison the HP ML 110 Gen9 workstation I’m currently using was released in 2021 and has 256G of RAM and has 4 * 3.5″ SAS bays so I could easily put a few 4TB NVMe devices and some hard drives larger than 10TB. The HP Z640 workstation I have was released in 2014 and has 128G of RAM and 4*2.5″ SATA drive bays and 2*3.5″ SATA drive bays. Previously I had a Dell PowerEdge T320 which was released in 2012 and had 96G of RAM and 8*3.5″ SAS bays.
In CPU and GPU power the recent Mac Minis will compare well to my latest workstations. But they compare poorly to workstations from as much as 12 years ago for RAM and storage. Which is more important depends on the task, if you have to do calculations on 80G of data with lots of scans through the entire data set then a system with 64G of RAM will perform very poorly and a system with 96G and a CPU less than half as fast will perform better. A Dell PowerEdge T320 from 2012 fully loaded with 192G of RAM will outperform a modern Mac Mini on many tasks due to this and the T420 supported up to 384G.
Another issue is generic expansion options. I expect a workstation to have a number of PCIe slots free for GPUs and other devices. The T320 I used to use had a PCIe power cable for a power hungry GPU and I think all the T320 and T420 models with high power PSUs supported that.
I think that a usable definition of a “workstation” is a system having a feature set that is typical of servers (ECC RAM, lots of storage for RAID, maybe hot-swap storage devices, maybe redundant PSUs, and lots of expansion options) while also being suitable for running on a desktop or under a desk. The Mac Mini is nice for running on a desk but that’s the only workstation criteria it fits. I think that ECC RAM should be a mandatory criteria and any system without it isn’t a workstation. That excludes most Apple hardware. The Mac Mini is more of a thin-client than a workstation.
My main workstation with ECC RAM could run 3 VMs that each have more RAM than the largest Mac Mini that will be sold next week.
If 32G of non-ECC RAM is considered enough for a “workstation” then you could get an Android phone that counts as a workstation – and it will probably cost less than a Mac Mini.
This has been a particularly contentious debate, centred primarily on whether the data used to train a model needs to be openly available for the resulting model to be considered open source.
On one side of the debate is a very pragmatic, practical perspective – the data used to create a model is often private, proprietary to an organisation, and the pre-processing steps difficult to reproduce. On the other is an idealist viewpoint – that for a model to claim to be open source, not only the code and model architecture need to be open, so to does the dataset on which it was trained.
“The new definition requires Open Source models to provide enough information about their training data so that a ‘skilled person can recreate a substantially equivalent system using the same or similar data”.
While my personal position is that open source AI models should be constituted from open data to earn the moniker – at the risk of open washing – there is a broader issue that is yet to enter the discourse.
In order to provide information about training data, we require dataset documentation.
Dataset documentation is information about a dataset that describes how that dataset was constituted, what it is constituted from and where it is intended to be used. One way of thinking about dataset documentation is like a nutrition label on a can – it tells you the ingredients, properties, and what percentage of its contents are fat, sugar, sodium and so on. That is, it helps you better understand what’s in the can.
In the research space, academic organisations like the Association for Computational Linguistics now require dataset documentation to be provided with any dataset that is published with a research paper – a strong step forward. However, platforms that host such data, such as Hugging Face, while providing the structures to create dataset documentation, do not mandate it.
For example, HF has uploaded Mozilla‘s Common Voice dataset to the platform – a dataset with which I am intimately familiar – however, it lacks any meaningful dataset documentation, making it harder for practitioners and researchers to make informed decisions about how speech models trained on this data will perform across axes such as genders, ages and accents.
That is, dataset documentation is the missing piece of the puzzle in the Open Source AI definition. Without effective dataset documentation practices, proformas, and platforms that support these, the Open Source AI definition risks paying lip service to reproducibility.
To move forward, I would like to see the Open Source Initiative become involved in efforts that help to standardise and improve practices and proformas around dataset documentation. Taking the position they have – that data does not need to be openly available – but must be adequately documented – commits the Open Source Initiative to advocating for better dataset documentation for AI training data.
Let’s work together to make sure that dataset documentation becomes just as important as data, model architectures or code for Open Source AI.
Late last month there was an announcement of a “severity 9.9 vulnerability” allowing remote code execution that affects “all GNU/Linux systems (plus others)” [1]. For something to affect all Linux systems that would have to be either a kernel issue or a sshd issue. The announcement included complaints about the lack of response of vendors and “And YES: I LOVE hyping the sh1t out of this stuff because apparently sensationalism is the only language that forces these people to fix”.
He seems to have a different experience to me of reporting bugs, I have had plenty of success getting bugs fixed without hyping them. I just report the bug, wait a while, and it gets fixed. I have reported potential security bugs without even bothering to try and prove that they were exploitable (any situation where you can make a program crash is potentially exploitable), I just report it and it gets fixed. I was very dubious about his ability to determine how serious a bug is and to accurately report it so this wasn’t a situation where I was waiting for it to be disclosed to discover if it affected me. I was quite confident that my systems wouldn’t be at any risk.
Analysis
Not All Linux Systems Run CUPS
When it was published my opinion was proven to be correct, it turned out to be a series of CUPS bugs [2]. To describe that as “all GNU/Linux systems (plus others)” seems like a vast overstatement, maybe a good thing to say if you want to be a TikTok influencer but not if you want to be known for computer security work.
For the Debian distribution the cups-browsed package (which seems to be the main exploitable one) is recommended by cups-daemon, as I have my Debian systems configured to not install recommended packages by default that means that it wasn’t installed on any of my systems. Also the vast majority of my systems don’t do printing and therefore don’t have any part of CUPS installed.
CUPS vs NAT
The next issue is that in Australia most home ISPs don’t have IPv6 enabled and CUPS doesn’t do the things needed to allow receiving connections from the outside world via NAT with IPv4. If inbound port 631 is blocked on both TCP and USP as is the default on Australian home Internet or if there is a correctly configured firewall in place then the network is safe from attack. There is a feature called uPnP port forwarding [3] to allow server programs to ask a router to send inbound connections to them, this is apparently usually turned off by default in router configuration. If it is enabled then there are Debian packages of software to manage this, the miniupnpc package has the client (which can request NAT changes on the router) [4]. That package is not installed on any of my systems and for my home network I don’t use a router that runs uPnP.
The only program I knowingly run that uses uPnP is Warzone2100 and as I don’t play network games that doesn’t happen. Also as an aside in version 4.4.2-1 of warzone2100 in Debian and Ubuntu I made it use Bubblewrap to run the game in a container. So a Remote Code Execution bug in Warzone 2100 won’t be an immediate win for an attacker (exploits via X11 or Wayland are another issue).
To check SE Linux access I first use the “semanage fcontext” command to check the context of the binary, cupsd_exec_t means that the daemon runs as cupsd_t. Then I checked what file access is granted with the sesearch program, mostly just access to temporary files, cupsd config files, the faillog, the Kerberos cache files (not used on the Kerberos client systems I run), Samba run files (might be a possibility of exploiting something there), and the security_t used for interfacing with kernel security infrastructure. I then checked the access to the security class and found that it is permitted to check contexts and access-vectors – not access that can be harmful.
The next test was to use sesearch to discover what capabilities are granted, which unfortunately includes the sys_admin capability, that is a capability that allows many sysadmin tasks that could be harmful (I just checked the Fedora source and Fedora 42 has the same access). Whether the sys_admin capability can be used to do bad things with the limited access cupsd_t has to device nodes etc is not clear. But this access is undesirable.
So the SE Linux policy in Debian and Fedora will stop cupsd_t from writing SETUID programs that can be used by random users for root access and stop it from writing to /etc/shadow etc. But the sys_admin capability might allow it to do hostile things and I have already uploaded a changed policy to Debian/Unstable to remove that. The sys_rawio capability also looked concerning but it’s apparently needed to probe for USB printers and as the domain has no access to block devices it is otherwise harmless. Below are the commands I used to discover what the policy allows and the output from them.
This is an example of how not to handle security issues. Some degree of promotion is acceptable but this is very excessive and will result in people not taking security announcements seriously in future. I wonder if this is even a good career move by the researcher in question, will enough people believe that they actually did something good in this that it outweighs the number of people who think it’s misleading at best?
This tutorial illustrates Advanced Normalization Tools (ANTs) to do image registration in 3D using data from Brain/MINDS data portal and how to apply the transforms/inverse transforms from image registration using the Slurm Workload Manager.
"Advanced Normalization Tools (ANTs) is a C++ library available through the command line that computes high-dimensional mappings to capture the statistics of brain structure and function. It allows one to organize, visualize and statistically explore large biomedical image sets. Additionally, it integrates imaging modalities in space + time and works across species or organ systems with minimal customization."
This tutorial is derived from the tutorial at the Brain/MINDS data portal.
As with all Slurm jobs, start with the resource requests. Note that ANTs is memory intensive, so the request on our system is double what what would normally be allocated per CPU. Also, note that the application is multi-threaded.
Let's download some brains! And what marvellous brains they are!
"The dataset includes NIfTI files of MRI T2 ex-vivo data; reconstructed Nissl stained images of the same brain, registered to the shape of the MRI; brain region segmentation (with separate color lookup table); and gray, mid-cortical and white matter boundary segmentation" (BMA 2017 Ex Vivo (Brain Space 1)
"This atlas is composed of a population average ex-vivo MRI T2WI contrast mapped with the BMA 2017 Ex Vivo (published by Woodward et al. The Brain/MINDS 3D digital marmoset brain atlas). The population average MRI was constructed based on scans of 25 individual brains. The 25 brains were aligned with one another by iteratively applying linear and non-linear registration and averaging the transformation files until convergence. Data of individual brains were then resampled with an isotropic spatial resolution of 100×100×100µm3 and averaged across brain." BMA 2019 Ex Vivo (Brain Space 2)
From: https://dataportal.brainminds.jp/atlas-package-download-main-page/bma-20...
This can be added to the job submission script as follows:
Now register brain1 to brain2. The options are -d 3 (the dimensions of the brain, 3 in this case), -f the fixed image or the image we want to register to, in our case, this will be brain2., -m the moving image or the image we want to register, in our case, this will be brain1., -o the output prefix, in this example, the output files will all have the prefix "brain1_tobrain2"., -n the number of threads; add this to the end of the command. Thus we get the following command:
Now conduct an inverse transform (map label2 to brain1). The option -d is the same as above., -i represents the the volume we want to register, -r is the refences image (brain1)., -o is the output file., -t are the transforms, applied right to left in this case the inverse of the affine transforms, then the inverse displacement field., -n the interpolation method to be used, nothing to do with the number of threads (see previous command).
If you want to compare the result with the label map before registration, you can do it by loading sp2_label_512_v1.0.0.nii.gz and bma-1-mri.nii.gz with an application like 3DSlicer.
In the past I haven’t had a high opinion of MG cars, decades ago they were small and expensive and didn’t seem to offer anything I wanted. As there’s a conveniently located MG dealer I decided to try out an MG electric car and see if they are any good. I brought two friends along who are also interested in new technology.
I went to the MG dealer without any preconceptions or much prior knowledge of the MG electric cars apart from having vaguely noticed that they were significantly cheaper than Teslas. I told the salesperson that I didn’t have a model in mind and I just wanted to see what MG offers, so they offered me a test driver of a “MG4 64 EXCITE”. The MG web site isn’t very good and doesn’t give an indication of what this model costs, my recollection is that it’s something like $40,000, the base model is advertised at $30,990. I’m not particularly interested in paying for extras above the base model and the only really desirable feature that the “Excite 64” offers over the “Excite 51” is the extra range (the numbers 51 and 64 represent the battery capacity in KWh). The base model has a claimed range of 350KM which is more than I drive in a typical week, generally there are only about 4 days a year when I need to drive more than 300KM in a day and on those rare days I can spend a bit of time at a charging station without much inconvenience.
The experience of driving an MG4 is not much different from other EVs I’ve driven, the difference between that and the Genesis GV60 (which was advertised at $117,000) [1] isn’t significant. The Genesis has some nice camera features giving views from all directions and showing a view of the side on the dash when you put your turn indicator on. Also some models of Genesis (not the one I test drove) have cameras instead of side mirrors. The MG4 lacks most of those cameras but has a very effective reversing camera which estimates the distance to an “obstacle” behind you in cm. Some of the MG electric cars have a sunroof or moonroof (sunroof that just opens to transparent glass not open to the air), the one I tested didn’t have them and I didn’t feel I was missing much. While a moonroof is a nice feature I probably won’t want to pay as much extra as they will demand for it.
The dash of the MG4 doesn’t have any simulation of the old fashioned dash unlike the Genesis GV60 which had a display in the same location as is traditionally used which displays analogue instruments (except when the turn indicators are on). The MG4 has two tablets, a big one in the middle of the front for controlling heating/cooling and probably other things like the radio and a small one visible through the steering wheel which has the instruments. I didn’t have to think about the instruments, they just did the job which is great.
For second hand cars I looked at AutoTrader which seems to be the only Australian site for second hand cars that allows specifying electric as a search criteria [2]. For the EVs advertised on that site the cheapest are around $13,000 for cars about 10 years old and $21,000 for a 5yo LEAF. If you could only afford to spend $21,000 on a car then a 5yo LEAF would definitely be better than nothing, but when comparing a 5yo car for $21,000 and a new car for $31,000 the new car is the obvious choice if you can afford it. There was an Australian company importing used LEAFs and other EVs and selling them over the web for low prices, if they were still around and still selling LEAFs for $15,000 then that would make LEAF vs MG3 a difficult decision for me. But with the current prices for second hand LEAFs the decision is easy.
When I enrolled for the test drive the dealer took my email address and sent me an automated message with details about the test drive and an email address to ask for more information. The email address they used bounced all mail, even from my gmail account. They had a contact form on their web site but that also doesn’t get a response. MG really should periodically test their dealer’s email addresses, they are probably losing sales because of this.
On the same day I visited a Hyundai dealer to see what they had to offer. A salesman there said that the cheapest Hyundai was $60,000 and suggested that I go elsewhere if I am prepared to buy a lesser car to save money. I don’t need to get negged by a car dealer and I really don’t think there’s much scope for a car to be significantly better than the MG3 while also not competing with the Genesis cars. Genesis is a Hyundai brand and their cars are very nice, but the prices are well outside the range I’m prepared to pay.
Next I have to try the BYD. From what I’ve heard they are mostly selling somewhat expensive cars in Australia (a colleague recently got one which was about $60,000 which he is extremely happy with) but hopefully they have some of the cheaper ones available too. I don’t want to flex on my neighbors, I just want a reliable and moderately comfortable car that doesn’t cost too much.
I’m reading about SPIFFE / SPIRE at the moment in the form of the official project ebook. I’m going to list it here because if I read 194 pages I am going to write it up, regardless of if the book has been formally published or not.
This book is probably the best introduction to SPIFFE / SPIRE I’ve seen. There are a lot of videos covering the basics in a relatively superficial way, and many blog posts along the same lines too, but I felt this was the best way I’ve found to really “get” what SPIFFE is trying to do.
However, I did think it was a bit weird for this ebook to admonish me to ensure I have good runbooks for my environment in case something goes wrong, but of course the SPIFFE / SPIRE projects do not provide reasonable default runbooks as a starting point.
Is asking software projects to include operational runbooks in their documentation unreasonable? I get that they’d have to be customized depending on deployment choices, but why is it that we expect end-users to produce runbooks from scratch instead of giving them a starting point to work from?
Congratulations on your decision to fork WordPress! You’ve taken on a mammoth task, I’m impressed with your willingness step up to the challenge of a lifetime. I’m here to give some advice on the things you might not have thought about yet, and what you’ll need to help the long term success of your fork.
Forking, I’m please to share, is beautiful. It continues to be an important feature of the Open Source ethos, even if it has become more involved as projects have matured. Forking is a valuable tool for Open Source communities to demonstrate that they believe a project should move in a different direction.
Before we get into the details, however, I do have to offer a few disclaimers. This post is not:
An active call for people to fork WordPress. In the spirit of Open Source, I think it’s important that we publicly talk about what this process looks like, even if it can be an uncomfortable discussion.
An announcement that I’m forking WordPress. I don’t have the free time for that.
An offer to wrangle your fork of WordPress. I am happy to discuss your plans and offer advice, though.
Disclaimers out of the way, let’s begin!
Before you Announce
First of all, let’s talk about that big old elephant in the room: the current level of instability in the WordPress world. I wouldn’t be surprised to learn that this the major factor in motivating your fork. Unfortunately, this approach won’t get you very far, so the first thing you need to do is take any feelings you have about it, and set them aside. You need to decide what you’re in favour of, instead. What are are the positive motivational factors that will make you jump out of bed, and push this project forward for the next decade or more? What will motivate others to join you for the long haul?
Think carefully about what your fork is going to be named. I’m willing to bet that you first jumped to calling it {Adjective}Press, or perhaps something with “WP” in the name. That’s a great idea if you’re planning on your project being forever defined as a protest against WordPress, but you need to think beyond that. How will you define your brand to keep it relevant for decades to come?
Oh, and make sure you can get the domains and social media handles for your name. Having to try and get them later is just expensive and frustrating.
Talk to people. Not just your circle of friends and colleagues who agree with you, find people who can offer different perspectives, and decide how your fork is going to help them. Talk to WordPress core contributors (not just committers!), and learn their take on it. Can you present an argument that would convince long term contributors to switch to working on your fork?
Figure out funding, at least enough to bootstrap your project. As much as I’d love to be, most of us are not post-economic. You can only get so far as a volunteer project, you’re going to need at least some people to be paid to work on it. There are big, complex problems that crop up along the way, it’s hard to solve them if everyone has to context switch between their day job, and their volunteer work.
The Meta Project
If you’ve made it this far into starting your fork, give yourself a pat on the back. You’ve made it much further than many others do. Your next challenge is deciding the process of building it. You could stick with the BDFL approach, which certainly has benefits, particularly when first starting out. It might be hard to sell what many folks see as a key weakness in WordPress, though. Perhaps you might like to explore a democratic governance model, or some sort of hybrid approach. Everything has a set of benefits and trade-offs, you’ll need to decide what works for you.
You’re going to have a bunch of technical dirty work to figure out. Where will the code be hosted? How will you track issues? Provide support? Discuss plans? Build community? Track data? Host themes, and plugins? What will you do about mobile apps?
At first glance, each of these are fairly straightforward to answer, but it’s very easy to get lost in the possibilities. My advice here is simple: pick something, use it until it stops being valuable. You can always switch to something different later. Switching governance models might be hard, but switching server-side tools is relatively easy.
Start thinking about how you’ll build your in-person community. Meetups, conferences, hack days, helping people move to your project, there are countless opportunities here to build your community.
The Moat
WordPress has three substantial factors that have made it largely unassailable for many years.
First, there’s the massive community that’s built up around WordPress over the years. Regular meetups and conferences are an integral part of building a popular Open Source project. You can’t really piggy back off the work that WordPress has done over the years here, either. The only way forward is to put in the work to build and maintain a community that you’re proud to be a part of.
Second, there’s the vast selection of plugins and themes that are available to download for free. The quality between options vary wildly, of course, but that’s largely irrelevant. The fact that so many options exist means there really is something for everyone. You’re going to need to figure out how to either maintain long term compatibility with existing WordPress plugins and themes, or you’re going to find yourself reproducing them all.
Finally, you’ll need to deal with inertia. The vast majority of WordPress site owners have no need or motivation to change, so you need to make it easy (ideally, your fork would be a drop-in replacement), and beneficial. What will your fork do better to solve real problems?
Tell Your Friends!
It’s around about this point that you’re probably getting ready to talk about your fork publicly. Go ahead, you’ve earned it!
Launch day is inevitably a mix of strong emotions. Elation if you get a huge positive response from the public, maybe discouragement if the public response is a bit more muted. Relief at having made it this far. Optimism about the future. Maybe even some doubt could creep in that you’re the right person to be wrangling such a huge endeavour. Whatever you end up experiencing, try not to stress about it too much. It’s a big day, but what really defines your project is what you do with it tomorrow. Next week. Next year.
Go right back to the start, and remind yourself of the positive reasons that you’re choosing to build this project. Tell the world those positive reasons, and welcome anyone who wants to join you on the journey.
The Long Haul
Not every day is launch day, however. Most of your days will be… kinda boring, to be honest. That’s a good thing! Too much excitement will inevitably burn out you and your community. Sustainable effort, day after day, is how you build something to last.
Of course, there’ll be ups and downs. It’s always okay to go back to the start, and reminder yourself (and your community!) of the positive reasons that you’re all working together on this.
Oh, and please try to remember that one day, you’re probably not going to be the right person to lead your project any more. This isn’t something to fear, or to look forward to, really: projects, communities, and individuals all grow and change. It’s probably going to be a weird time when you get to this point, but it doesn’t have to be a time of upheaval and uncertainty. If you’ve run the project well, you should hopefully have a deep pool of talented folks who can step in to continue what you began.
Have Fun!
Finally, it would be remiss of me not to remind you to have fun! It’s easy to get lost in conflict at times, but it’s important to remember that… it’s just a CMS. It’s not going to be the end of the world if you take time away from the project, it’s actively beneficial for you to have a life outside of the internet. Friends, family, pets, hobbies: make time for the things that matter in your life.
This book continues the story of General Electric in the period after that covered by The Man Who Broke Capitalism, thus presenting an opportunity to validate if Jack Welch really was the bad guy while also learning more about where Welchism took General Electric in the longer term. This book is very readable, with nice short chapters — for example it introduces Welch as a character, but does not dwell on his time at General Electric more than is necessary.
Immelt’s time as CEO got off to a rocky start, with the 911 attacks occurring on just his second day in the job. GE was financially exposed to these events, both as an insurer of some of the destroyed buildings, but also as a major manufacturer of aerospace equipment whose grounding reduced demand.
My second day as chairman, a plane I lease, flying with engines I built, crashed into a building I insure, and it was covered with a network I own”
Then of course came Enron. While the book asserts that GE’s behaviour lacked Enron’s criminality, GE was certainly creative and opaque with its accounting and would have to clean up its act under the new stricter post-Enron accounting standards introduced with Sarbanes-Oxley. That is, Welch exited just in time to not have to deal with the mess made on his watch.
Then to continue the fun there was the 2009 sub-prime mortgage crisis, a market in which GE had been a big player. Unfortunately for GE, it was “not a bank” (a thing they had previously boasted about), and therefore it took much longer to be rescued by the US Federal Government than traditional banks did. This, coupled with eventual fines for accounting fraud tarnished GE’s reputation as a solid stable industrial player instead of a high risk financial engineering organization.
On the other hand, Immelt was responsible for his own messes — accounting at GE Power that claimed revenue from future service contracts as profit now, a terrible investment in oil and gas equipment manufacturing as the oil market declined, a completely bonkers merger with a French power company, and a general unwillingness to listen to the advice of others.
Overall I’d say that while Immelt was unlucky, he was also complicit in the process that put GE into its perilous state, and then too arrogant to see the approaching freight train when things got really bad. It certainly didn’t help that he made it very clear over his tenure that delivering bad news to the CEO was a poor career move. Immelt was also GE CEO for 16 years, which should have been plenty of time to correct any historical misdeeds and stabilize the company.
So what of Welsh? Clearly he built a company that was just waiting to fail — but Immelt certainly didn’t do much to correct the ship before it ran aground.
Lights Out
Thomas Gryta, Ted Mann
Business & Economics
Mariner Books
May 4, 2021
368
How could General Electric--perhaps America's most iconic corporation--suffer such a swift and sudden fall from grace? This is the definitive history of General Electric's epic decline, as told by the two Wall Street Journal reporters who covered its fall. Since its founding in 1892, GE has been more than just a corporation. For generations, it was job security, a solidly safe investment, and an elite business education for top managers. GE electrified America, powering everything from lightbulbs to turbines, and became fully integrated into the American societal mindset as few companies ever had. And after two decades of leadership under legendary CEO Jack Welch, GE entered the twenty-first century as America's most valuable corporation. Yet, fewer than two decades later, the GE of old was gone. ​Lights Out examines how Welch's handpicked successor, Jeff Immelt, tried to fix flaws in Welch's profit machine, while stumbling headlong into mistakes of his own. In the end, GE's traditional win-at-all-costs driven culture seemed to lose its direction, which ultimately caused the company's decline on both a personal and organizational scale. Lights Out details how one of America's all-time great companies has been reduced to a cautionary tale for our times.
Hello there, friends! It’s been a couple of months since my last open source update, so what have I been up to? A bunch of things, all culminating in a new Hanami 2.2 beta!
RedDotRubyConf returns!
First came RedDotRubyConf 2024 in Singapore, back again after seven years! It was great: excellent mix of talks, a small but engaged crowd, and as always, amazing hospitality. Thank you to Ted and all the organisers for bringing it back! I hope it can continue into the future!
RedDotRubyConf is a special event for me: it was my first opportunity to speak at a Ruby conference, as well as my first chance to give a workshop. Before ths one, I’d attended three different editions over the years, dating all the way back to Andy’s last event in 2012. My talk this year was a nice bookend to how I started. All the way back in 2013, I presented my stack of dry-rb, ROM and Roda as a vision for a new generation of Ruby apps. This year I presented that vision brought to its complete and streamlined conclusion in Hanami. For those of us cultivating Ruby on the side, some fruit takes time to bear.
Speaking of time: after I returned from Singapore, things were slow for a while. I had made a big push to release 2.2.0.beta1 before the conference, and that pace was not something I could maintain. This, alongside attending a Buildkite off-site, meant things were pretty quiet for a few weeks.
Hanami actions, meet validation contracts
It wasn’t long before I found a productive groove again. One of the things that helped here was some work that Krzysztof Piotrowski did to explore using full dry-validation contracts as the means of params validation in Hanami actions.
Contracts in actions has been a much-demanded feature! In fact, some work began on it all the way back at the RubyConf hack day in November 2023 (thanks to Dan Healy). While that effort petered out, Krzysztof progressed things far enough to arrive at a fully functional implementation, ready for review. He’d also been making some great contributions to Hanami lately, so I didn’t want to keep him waiting.
After reviewing Krzysztof’s work, I managed to put together another iteration of the feature that I was happy to see go in. And thanks to some helpful feedback from Adam Lassek, I came back and did one more thing, making it so that straight-up Dry::Validation::Contract classes could be used for the validation, rather than the Hanami::Params subclasses that were required in the older, 1.x-era behaviour that we had inherited for this feature.
The result is a useful spectrum of options. You can start with the simplest approach, embedding a contract directly in your action. Now instead of the params blocks you could use before (which exposed the dry-schema features only), you can use contract:
class Create < MyApp::Action
contract do
required(:title).filled(:string)
required(:slug).filled(:string)
end
end
If you have a contract that you want to share across actions, you can also reference its class directly:
class Create < MyApp::Action
contract Posts::Contract
end
One of the internal adjustments I made was to defer the initialization of contracts until the time the action is itself initialized. This allows you to take advantage of one of dry-validation’s most powerful features: contracts that can interact with the rest of your app via external dependencies. For example:
module MyApp
module Posts
class Contract < Dry::Validation::Contract
include Deps["repos.post_repo"]
params do
required(:title).filled(:string)
required(:slug).filled(:string)
end
rule(:slug) do
unless post_repo.unique_slug?(values[:slug])
key.failure("must be unique")
end
end
end
end
end
With external dependencies, your validation contracts can leverage business logic anywhere in your app, while still allowing for that logic to reside in, well, a logical place. And when you use validation contracts in a Hanami app, our Deps mixin makes this as easy as can be.
(Why exactly is deferring initialization of the contract required for this? It’s because the default dependencies you specify with Deps are resolved at the time of calling .new on the contract. We can’t call that too early, like in the class body of an action, because otherwise we’d run into all sorts of load ordering troubles.)
In fact, there’s one last little dependency-related treat for you in this feature. You saw above how contracts could take their dependencies via Deps? Well now you can do exactly the same with actions, with the contract itself as a dep!
class Create < MyApp::Action
include Deps["posts.contract"]
end
This is especially nice if you’re sharing your contracts between actions as well as other kinds of classes in your app, because it means you can use Deps as a consistent approach for using them across all places:
class CreatePost < MyApp::Operation
# Another class, same Dep!
include Deps["posts.contract"]
end
I started this post with a little Ruby reminiscence, so why not do a little more. Back in its early days, dry-validation was one of the most important gems in spurring dry-rb adoption. Input validation is something that every app needs, and there are few solutions out there as complete and portable as dry-validation (try it in your Rails app, really!). Today, dry-validation is as relevant as ever, and with it now fully integrated into Hanami, it’s also easier to use than ever.
In fact, I think the code snippets above serve as a great example of the kind of vision we’re building towards with Hanami: actions as standalone classes, input validation as an first-class concern itself provided by standalone classes, and a simple and universal dependencies mixin to bring them together where required. Small, focused components, each with its place, and a clear strategy for connecting them. These are not the Ruby apps you’re used to. We’re bringing something new. The little integration you see above is in many ways the the culmination of 10 years of multiple streams of volunteer OSS work.
I think that enabling development approaches like this is vital part of fostering a vibrant and diverse Ruby ecosystem. If this resonates with you, we’d love your support.
What gives me heart is that after all these years, we’re still finding new champions and contributors. If it wasn’t for Krzysztof taking on the challenge to bring contracts to actions, it would not be shipping in 2.2. Thank you, Krzysztof!
Hello again, MySQL
I really didn’t intend this post to become a treatise on input validation and its meaning for the greater Ruby community, so let’s keep things moving!
Here’s something much more straighforward: when we introduced our new database layer in beta1, we included SQLite and Postgres support. There was one major database missing: MySQL. Now it’s here.
The experience is as you’d expect: hanami new my_app --database=mysql will give you everything you need to get started with Hanami and MySQL, and after that, all the hanami db commands will work with your MySQL database as required. This was one of the last big outstanding items on our to-do list for 2.2, and now it’s done!
What’s more, we also had another new contributor come in and help make our database layer just that little bit nicer. Thanks to Kyle Plump, now if for any reason your Gemfile doesn’t contain the right gem(s) for your configured database(s), we’ll give you a helpful warning. Thank you Kyle! It’s been tremendous to work with you these last couple months.
New ways to go multi-database
The astute among you will have noticed my use of “gem(s)” for “database(s)” in the last paragraph. There’s reason for this, even putting aside my predilection for syntactical whimsy: in this last month, I introduced a whole new way to work with multiple databases in Hanami!
Since beta1, we’ve supported multiple databases along one axis: while Hanami slices may all share a single database, each may also have its own. This is as easy to configure as prefixing your database URL env var with a slice name: MY_SLICE__DATABASE_URL. Hanami takes care of the rest. (Of course, you can also choose to configure slice databases explicitly where you need greater control.)
This arrangement was how I was intending to leave things. Shipping a new fully-featured database layer for Hanami already felt ambitious enough. But friend-of-the-framework Phil Arndt needed something more: to work with multiple databases within a single slice.
Speifically, Phil needed to set up multiple ROM gateways. Gateways are ROM’s abstraction for a connection to a specific data source (remember: ROM works with more than just SQL, it also has adapters for things like HTTP and CSV and YAML and more!).
What I love about this is that I was able to maintain the same zero-config approach we’ve had for our database layer so far. So now your ENV vars can take you even further than before. You can start with a single database (let’s use MySQL here, to stick with the theme of this dissertation blog post):
DATABASE_URL=mysql2://localhost/my_app
Then from there, you can go multi-database within an app by appending a suffix for each gateway:
Slices can come to the party too. Combine slice prefixes with gateway suffixes for the ultimate in code/database granularity:
# Configure multiple databases for an `Artifacts` slice
ARTIFACTS__DATABASE_URL=postgres://localhost/my_app_artifacts
ARTIFACTS__DATABASE_URL__LEGACY=postgres://localhost/my_app_artifacts_legacy
Zero-config is the start but not the end. Like many of the features in Hanami 2, progressive disclosure is at the core of our design for gateways. If you need more than the basics, there’s another layer waiting for you. So aside from the environment variables, you can also configure gateways directly in your :db provider:
Hanami.app.configure_provider :db do
config.gateway :extra do |gw|
# If not given, this will still be filled from `ENV["DATABASE_URL__EXTRA"]`
gw.database_url = "..."
# Specify an adapter to use by name (more on this later)
gw.adapter :yaml
# Or configure an adapter explicitly
gw.adapter :yaml do |a|
# You can call `a.plugin` here
# Or also `a.extension` if this is an `:sql` adapter
end
end
# Multiple gateways can be configured
config.gateway :another do |gw|
# ...
end
end
If you have a provider with a complex multi-gateway setup, then you can also configure adapters separately, and they’ll be used across all relevant gateways:
Hanami.app.configure_provider :db do
# This adapter config will apply to all sql gateways
config.adapter :sql do |a|
a.extension :is_distinct_from
end
config.gateway :extra do |gw|
# ...
end
# More gateways here...
end
As well as receive useful suggestions if you invoke the CLI with a typo:
$ ./my-cli comma
I don't know how to 'comma'. Did you mean: 'command' ?
Commands:
my-cli command # This is a command
I have to make an apology here. Benoit shipped these PRs a couple of months ago. But since that time I’ve been pretty much single-mindedly working through all the things above. It took a friendly nudge from Benoit on Mastodon (I love Mastodon — let’s be friends) for these to get back on my radar again. I was frankly a little embarrassed at how I’d let down a smart new contributor by this long delay.
It’s not easy dong Hanami maintenance on nights and weekends. I wrote about needing to find balance in my last update. Once Hanami 2.2 is out, I hope will become easier to stay on top of contributions like this, because I won’t have the spectre of large, uncompleted features (like a whole database layer) weighing me down.
Anyway, I’ll be making sure we cut a new dry-cli release soon, with both of these included, as well as documentable command namespaces.
Just before: a release!
Speaking of releases, the one big goal I had after after all of the above was getting them packaged up and out into people’s hands for testing. I did this last week, releasing Hanami 2.2.0.beta2. Step by step, we’re getting there.
I’d really love it if you could check out the announcement, then run a gem install hanami --pre and kick the tyres on all the new features. This is how we get things in truly tip top shape.
Right now: a break!
The release came when it did, because as of this last week, I’m away on a three week holiday with my family.
After all the work on Hanami things (not to mention Buildkite things), I’m hoping to truly disconnect and recharge. If you’re waiting on issue/PR feedback from me, please forgive the brief interruption. I’ll be back again in late October.
Up next: 2.2 by RubyConf!
I’m looking forward to attending my second RubyConf in Chicago later this year! Last year in sunny San Diego I got to reintroduce Hanami to America through my talk and at the Hack Day.
In the leadup to RubyConf 2023, we worked very hard to get 2.1 out. Alas, it didn’t quite work out that way, but that’s no reason not to try again! So this year, we’re working very hard to get 2.2 out.
We have a couple of very good motivators for this:
I’ll be back again represeting Hanami at the Hack Day, ready to help anyone wanting to contribute.
I really want everyone coming into contact with Hanami over RubyConf to be able to gem install hanami and receive in return our full vision for maintainable, layered, database-backed Ruby apps.
If we succeed, I’ll look forward to showing and talking Hanami 2.2 to many of you in Chicago! Let’s do this!
Thank you (again!) to Hanami’s contributors
There’s a certain lovely vibe to this post: I’m not working alone. So many of the improvements above were spurred on by Hanami contributors, new and old. So let me thank all of you one more time:
Thank you Krzysztof Piotrowski, for spurring on the work on contracts in actions
Thank you Sean Collins, for everything you’re doing to prepare for the RubyConf workshop!
And I know this isn’t everyone. For example, a few weeks ago Damian Rossney and Kyle Plump got together to pair on a fix to this gnarly hanami-router issue. I love to see this! I already replied in the issue, but reviewing this is my number one thing to do when I get back from my break.
A cheeky question
Whew! What an update! If you made it this far, thank you for reading!
Since you’re here, you dedicated few, let me ask something of you. I’ve been writing these open source updates since March 2020. This is my 31st edition! I’m not the fastest writer, so each one takes some hours, typically a whole night of writing, provided I start early enough. So tell me: should I keep writing these updates? What do you take from these? Is there anything you think I could do differently? Or on the flip side, if any of you are regular long-form journallers: how do you keep it up?
I believe buying a Kindle in 2024 is a bad idea, even if you only intend to use it for reading DRM-free locally stored ebooks. Basic functions such as organizing books into folders/collections are locked until the device is registered and with each system update the interface has became slower and more bloated.
Initially I purchased this device because Amazon book store isn’t too bad and it’s one of the easier way to buy Japanese books outside of Japan, but with all the anti-features Amazon add in I don’t think it’s still worth using.
Using a recent exploit and with this downgrader thread on the mobileread forum, I’m able to downgrade my paperwhite to an older 5.11.2 firmware which has a simpler interface while being much more responsive. If you already have a Kindle perhaps this is worth doing.
It’s possible to install alternative UI and custom OS to many Kindle models but they generally run slower than the default launcher. On the open hardware side Pine64 is making an e-ink tablet called the PineNote with an Rockchip RK3566 and 4G of RAM it should be fast enough to handle most documents/ebooks, but currently there is no usable Linux distribution for it.
At 20, Chris Knight set off into the woods to avoid society. He didn’t come out apart from to commit petty theft for supplies for 27 years, when he was finally caught after about 1,000 burglaries. Catherine and I are a bit divided on this story — I think Chris clearly had something wrong in terms of mental health, whereas Catherine thinks he crossed a line when he committed theft to survive. Either way, I don’t think you could claim that Chris was living in luxury in isolation, especially when research has shown that extended isolation is generally very bad for mental health.
I came across this book because Digital Minimalism recommended it as a good exploration of solitude, but most of the book really isn’t about that. Mostly the book is a description of Knight and his life for those 27 years. That said, it’s still an interesting read.
I’d avoid the book if talk of suicide is a trigger for you, although Knight does not appear to have carried through on his threat.
The Stranger in the Woods
Michael Finkel
May 17, 2018
224
*THE NEW YORK TIMES BESTSELLER* Could you leave behind all that you know and live in solitude for three decades? This is the extraordinary story of the last true hermit - Christopher Knight. 'This was a breath-taking book to read and many weeks later I am still thinking about the implications for our society and - by extension - for my own life' Sebastian Junger, bestselling author of The Perfect Storm 'A wry meditation on one man's attempt to escape life's distractions and look inwards, to find meaning not by doing, but by being' Martin Sixsmith, bestselling author of Philomena and Ayesha's Gift 'Not all heroes wear capes. My latest one is a man called Christopher Knight - a silent idol for anyone who has felt the urge to just sack it all off and live the life of a hermit' Lucy Mangan, Stylist 'An extraordinary story about solitude, community, identity and freedom' Guardian 'A meditation on solitude, wildness and survival. It is also, unexpectedly, a tribute to the joys of reading' The Wall Street Journal In 1986, twenty-year-old Christopher Knight left his home in Massachusetts, drove to Maine, and disappeared into the woods. He would not speak to another human being until three decades later when he was arrested for stealing food. Christopher survived by his wits and courage, developing ingenious ways to store food and water in order to avoid freezing to death in his tent during the harsh Maine winters. He broke into nearby cottages for food, clothes, reading material and other provisions, taking only what he needed. In the process, he unwittingly terrified a community unable to solve the mysterious burglaries. Myths abounded amongst the locals eager to find this legendary hermit. Based on extensive interviews with Knight himself, this is a vividly detailed account of his secluded life and the challenges he faced returning to the world. The Stranger in the Woods is a riveting story of survival that asks fundamental questions about solitude and what makes for a good life. Above all, this is a deeply moving portrait of a man determined to live life his own way.
This is a book about motivation, specifically about how our assumptions that biological urges and extrinsic motivation are sufficient to model all human behaviours. It turns out that’s not true — intrinsic motivation plays an important part, and in fact badly applied extrinsic motivators can harm the much more powerful intrinsic motivating factors.
(It will be interesting to see what corporations currently cutting bonus payouts experience in terms of overall productivity now that they’ve removed an extrinsic motivator).
Intrinsic motivation is more important for heuristic work where the outcomes aren’t algorithmic or clear cut the book argues. It’s not as simple as just cranking and handle and creativity comes out the other end. However, that’s just what traditional management is — a series of carrots and sticks to crinkle that handle as fast as possible.
Its important to note here that the book repeatedly states that intrinsic motivation only works if the person’s baseline needs are already met. That is, you need to be earning enough to pay your bills and so forth before you start valuing how interesting work is.
Instead, the book encourages companies to consider things like 20% time, self organizing teams, flexible work hours, and so forth. The book is from the hopeful days of 2009, where companies like Zappos and Google were doing such things. Notably I think both have now backed away from these ideas. I wonder if this explains why seemingly everyone is leaving Google these days? They used to be intrinsically motivated to “change the world”, but now it’s clearly just about money and that doesn’t motivate in the same way.
The book also argues that intrinsically motivated employees seek mastery of whatever it is they do, and this rings true for me. The strongest engineers I’ve ever worked with are the ones who are always trying to understand better how the machine works, in order to better bend the machine to their will.
Overall this book really resonated with me, especially the concepts of intrinsic motivation being important to creative work, the reinforcement of the importance of flow, and the encouragement to seek mastery.
Drive
Daniel H. Pink
Business & Economics
Canongate Books
2011
257
The author of the bestseller "A Whole New Mind" is back with a paradigm-changing examination of how to harness motivation to find greater satisfaction in life. This book of big ideas discusses the surest pathway to high performance, creativity, and well-being.
This book lied to me. It purports to start out with a description of a hostage situation in New York city. However, the twist is it turns out that its a simulation instead of the real deal. The deception is complete! However, this is a pretty unusually effective way to “hook” people at the beginning of a non-fiction book. Importantly, the book also points out that the techniques that hostage negotiators use to take the heat out of a situation don’t work for your marriage:
Note to self: something designed for terrorists and emotionally disturbed people isn’t perfect for your family.
That opening is indicative of the rest of the book — very readable, and good at keeping your interest. I guess that’s good in a psychology book? Every chapter starts with a story, and sometimes the stories are event related to the topic at hand, which is admirable. The whole book is written in a lighthearted style that is fun without coming across as forced, which I think is a pretty impressive thing to have achieved.
The book starts out discussing if you can judge a book by its cover — that is, how good are humans at reading the intentions of other humans? For example, are criminal profiles effective at describing likely criminals? It is asserted that the answer is no. In fact, it would appear that humans rely pretty heavily on initial impressions, and it’s very hard to get people to change their mind. Even better, apparently we’re pretty bad at spotting a liar too.
It then moves on to attempting to determine if “a friend in need is a friend indeed”, which I’ve always taken to mean that people are more friendly when they want something from you. Apparently a 2009 study found the average American has four close relationships, two of which are friends. This means most Americans eat about as many hamburgers a week as they have close relationships, which is a pretty exciting thing to learn. It is asserted that increasing this number even a little bit has a direct relationship with happiness, although the quality of the relationship matters more than the quantity of relationships. Around 65 studies show that our brains process information about close friends using the same regions as information about ourselves, that is, our brains blur the line between close friends and our own identity — they are processed as a group. I find that finding really interesting.
Next the book moves on to examining if “love really does cure all”, which turned out to be a series of chapters on successful marriages. While this section was interesting, I don’t think there was a lot of apply there for me — it’s mostly things like assume good intent and go on more exciting dates. I’d love to go on more dates with Cat, but first we need the kids to be just a little bit older. We’ll get there in time. That said, this quote does stand out to me:
Everyone asks how you got together (with your partner); nobody asks how you stayed together.
And then finally the book talks about loneliness and how its a relatively recent concept. This is blended with a discussion of placebos and their effectiveness in medical treatment, where the underlying point is that the important bit is that people need to feel that someone cares for them. That is, we’re social animals, and a lot of our current rise in psychological problems is because of increased isolation and loneliness in modern societies. I find that hard to disagree with.
Finally, the book attempts to address the meaning of life. Honestly it’s answer doesn’t suck, but I won’t ruin it for you.
Plays Well with Others
Eric Barker
2022-06
320
From the author of the Wall Street Journal bestseller Barking Up the Wrong Tree comes a cure-all for our increasing emotional distance and loneliness--a smart, surprising, and thoroughly entertaining guide to help build better friendships, reignite love, and get closer to others, whether you're an extrovert or introvert, socially adept or socially anxious. Can you judge a book by its cover Is a friend in need truly a friend indeed Does love conquer all Is no man an island In Plays Well With Others, Eric Barker dives into these questions, drawing on science to reveal the truth beyond the conventional wisdom about human relationships. Combining his compelling storytelling and humor, Barker explains what hostage negotiation techniques and marital arguments have in common, how an expert con-man lied his way into a twenty-year professional soccer career, and why those holding views diametrically opposed to our own actually have the potential to become our closest, most trusted friends. Leveraging the best evidence available--free of platitudes or magical thinking--Barker analyzes multiple sides of an issue before rendering his verdict. What he's uncovered is surprising, counterintuitive, and timely--and will change the way you interact in the world and with those around you just when you need it most.
I guess it’s no surprise that work uses Argo CD, so it seemed like time to understand it a bit better. Unfortunately this book has what I have come to expect from Packt publishing — it could do with a more solid editorial pass to be honest. The English in the book is awkward, and a simple grammar pass by an experienced editor would have made a big improvement to the whole book. Worse, its clear little technical review occurred either, there is at least one case where a Kubernetes YAML field is typo’ed in the text and simply wont work as published.
As an aside, I went and looked at my technical bookshelf, and I have literally zero books from Packt that I’ve bothered to keep. I am very close to just stopping buying books published by them.
This book starts with an introduction to Kubernetes, which is a bit repetitive if you already use it. Given Kubernetes is a prerequisite for using Argo CD, it certainly seems like that will be the case for many readers. Explaining Kubernetes makes sense in the context of explaining where Argo CD fits in, but I can’t help but think there should be some level of assumed knowledge in a book like this. The book then implements a simple operator which does much of what Argo CD does — it pulls a git repo and then applies it. This is an interesting approach — it works well if your readers can read golang, and not so well if they can’t.
The book then moves on to explain Argo CD terminology and architecture before having us install Argo CD onto our Kubernetes cluster. Unfortunately the book glosses over the commands required, just listing them and not really explaining what they do. Specifically, we create a Helm application called “ch02”, but that isn’t explained at all. In fact that’s another weird thing about this book, it provides an introduction to Kubernetes but not to Helm, despite both being required knowledge for its examples. Worse, we then get to type out a big block of YAML to configure our first application, but without little details like what filename or directory structure to use to save it. Finally, we’re asked to run the argocd command line command to finish the tutorial, but we haven’t been told how to install that either.
The next chapter then installs Argo CD again, but this time using Kustomize. Oh, except the instructions don’t seem to work because they’re incompatible with current versions of Kustomize. We also spend a lot of time being told how to setup Argo CD in a high availability mode when they haven’t even really told us what Argo CD is yet or how it works.
In the end I wanted to like this book, because I wanted to learn about Argo CD, but this book failed to engage and was difficult to read. I’ll be honest, I didn’t finish it.
Argo CD in Practice
Liviu Costea, SPIROS. COSTEA ECONOMAKIS (LIVIU.),
Application software
November 18, 2022
Build CD pipelines following GitOps principles like declarative and immutable changes stored in version control, all continuously reconciled by Argo CD, and minimize the failure of deployments.
Another really good if a bit short book. My only real criticism of the first four books in this series is they really should have been one book.
Exit Strategy
Martha Wells
Fiction
Tordotcom
October 2, 2018
143
Murderbot wasn’t programmed to care. So, its decision to help the only human who ever showed it respect must be a system glitch, right? Having traveled the width of the galaxy to unearth details of its own murderous transgressions, as well as those of the GrayCris Corporation, Murderbot is heading home to help Dr. Mensah — its former owner (protector? friend?) — submit evidence that could prevent GrayCris from destroying more colonists in its never-ending quest for profit. But who’s going to believe a SecUnit gone rogue? And what will become of it when it’s caught?
A Star Trek parody from the POV of five ensigns who realise something is very strange on their ship. Plot moves steadily and the humour and action mostly work. 3/5
An account of the discover and lives of Neanderthals, Denisovans and others hominids who shared the earth with Homo sapiens in the last 300,000 years. 4/5
The basic Linux command for directory creation is mkdir $DIRNAME, with the most common options being -p to create parent directories and the handy verbose flag (-v) to print the directories to standard output as they are created. An array of subdirectories can also be created. e.g.,
$ mkdir -p -v examples/{dir1,dir2,dir3}
mkdir: created directory 'examples'
mkdir: created directory 'examples/dir1'
mkdir: created directory 'examples/dir2'
mkdir: created directory 'examples/dir3'
$ for d in examples/*/; do mkdir -v "${d}RHEL7"; done
mkdir: created directory 'examples/ABAQUS/RHEL7'
..
Then checked with the ever-veristile find command:
$ find . -type d -name RHEL7
./GROMACS/RHEL7
./R/RHEL7
..
A short script copies the 2015 and 2019 application files, which the author had the foresight to use the Year as a prefix naming convention. This makes use of an expanded variable, globbing, find, conditional tests, branching, redirection of standard error, and moving files.
A list of symlinks was also identified with find; find . -mindepth 1 -maxdepth 2 -type l -ls.
Since it opened in 2017 Parnell Station has been one of the least busy stations in Auckland. In the year to June 2019 there were just 168,000 boardings at the Station, ranking 36th out of 40 stations on the network.
While the suburb of Parnell is fairly high density and has a good mixture of retail, entertainment, office and residential is it under-served by the station.
Parnell Station’s main problem is that it is in a valley with the Auckland Domain on one side and a steep hill to Parnell Road on the other. The way up the hill is steep, indirect and is not suitable for people with mobility issues. The route to the museum is a rough walking track. There is a dedicated path to the Carlaw Park student village and business centre however.
The poor accessibility to the main Parnell Road shopping/business area and even worse access to the St Georges Bay Road business area have hurt the station’s usage. These problems have been written about previously on Greater Auckland, twice.
A wheelchair accessible underpass between the two platforms was added to the station in early 2024. This enabled safer and easier transfer between platforms and to access to the boardwalk to Carlaw Park. However the hill to Parnell Road is still a problem.
A Possible Solution – A Pedestrian Tunnel
My proposal is a pedestrian tunnel running from near the Parnell Station to the North-West under the main hill and emerging on St Georges Bay Road. Around the middle of the tunnel there would be elevators going up to Parnell Road. The tunnel would be around 550 metres long. The ends are at similar heights so the tunnel would be relatively flat while the central elevators would need to travel around 20 metres. The tunnel should be wide, well-lit and have security cameras etc to make people using it feel safe.
The elevators would be around 3 minutes walk from Parnell Station on 4-5 minutes from St Georges Bay Road. I’ve place the street level access to the elevators in Heard Park on the corner of Parnell Road and Ruskin Street (at the bend in the above map). Probably several elevators would be required for redundancy and since traffic will probably be bursty.
The St Georges Bay Road entrance could be at the bottom of Garfield Street. It would probably be easiest to take up some street/footpath space and run parallel to the road before turning South-West once significantly deep. There are several hundred jobs within a couple of minutes walk of this entrance. There is also a Saturday Market nearby.
Overall the project should be only moderately expensive to build and improve the catchment and value of Parnell Station as well as linking three parts of Parnell better together.
This Blog is about a variety of topics that I’m interested in. My top posts are listed below. I also do regular posts on Audiobooks I’ve listened to and notes from conferences I attend.
It’s been a hot minute since my last open source status update. The fact is, I’ve been too busy working on open source to write about my work on open source.
One thing I realise, however, is that work not proclaimed is work not noticed, so let me tell you what I’ve been doing.
In the nine months since September, I:
Worked on Hanami 2.1
Presented on Hanami at RubyConf (San Diego) and RubyConf Taiwan
Prepared to present at RedDotRubyConf in Singapore
That’s a lot! And herein was a pattern, repeated twice:
Plan to announce a major new release at a conference
Push hard to get it ready (oh, and prepare the talk too)
End up not quite making it
Go do the conference anyway (always fun, at least!)
Then come home to yet another big push to finally finish everything off
In the first instance, it was Hanami 2.1 and RubyConf. We were so close to release, but discovered a deal-breaking limitation our assets handling. After frantic hours attempting workarounds from California/Rome/Christchurch, we pulled the plug. There was no easy fix. So after a short break, I overhauled that part of assets system (the right decision: it’s now more flexible and better fits Hanami architecture!) and finally shipped Hanami 2.1 in February.
In the second case, it’s been Hanami 2.2 and RedDotRubyConf (I’m flying to Singapore as I write this!). This time around, we didn’t get so close to a full release, but far enough to put out a beta. Once I’m back, I expect another month or two of concerted work to get everything finished.
So, a pattern of near misses, but real progress nonetheless! I’m also encouraged by some promising signs in this latter instance.
This time around, we have some new active contributors, without whom we couldn’t have shipped the beta. Thank you Adam, Sean, and Marc! This time around, we went from release plan to a quite-complete beta in less than 60 days, instead of the 15 months between the previous major releases. This time around, we’re mere steps away from finishing the full stack vision for Hanami 2, from providing the streamlined experience we envisioned more than five years ago.
Here’s the rub: everything I’ve done with Hanami has been a fully “nights and weekends” deal for me. For the case of Hanami 2.2, it’s meant practically every night and weekend for two straight months. It’s not sustainable. This is why I couldn’t write you those monthly updates. Speaking of patterns: I’ve done this now for too many years, missed too much family time already, and I need to break this cycle.
I’m optimistic, though. Change is coming. The above was the old era. We’re about the enter the new: Hanami 2.2 is on the way! This is something to be excited for! It’s exciting for you, because with just a few commands you’ll have yourself a whole new way of building modular, maintainable, database-backed apps of all shapes in Ruby. It’s also exciting for me, because it means I can at last look up to the horizon and start planning all the great ways we can promote and build upon this new foundation.
It also means I plan to figure out ways to make this whole endeavour sustainable for me. This is the only way we can serve the Hanami and Ruby communities long into the future. Hanami turns 10 this year, and I want it to live for decades more. If you’re experienced with funding OSS, I’d love to chat with you about this.
So there we are, you’re all caught up on a productive few months for Hanami! I’m looking forward to sharing my next update with you, where I hope we can celebrate the release of 2.2 and the beginning of our new era!
Converting between filesystems can be fraught with difficulties, especially if one is dealing with a proprietary filesystem. One such system is APFS, the Apple File System, designed by Apple for its devices, introduced originally for macOS Sierra in 2017 and later, iOS 10.3, tvOS 10.2, watchOS 3.2, and all versions of iPadOS, and designed to replace HFS Plus. The question here is how does one access APFS on Linux when a kind individual has provided you, for example, a USB device that has been written with this filesystem. The following are some brief notes on how to do this with Ubuntu Linux 20.04.6 LTS.
The first step is to install libfsapfs-utils, which is a library to access the Apple File System (APFS). One can install this from source if desired for performance or developmental reasons. In this case, we'll just install the package.
$ sudo apt install libfsapfs-utils
The next step is to go into sudo mode and run fdisk, a command to manipulate disk partition table. Understandably, such a command requires privileged access and responsibility. But our purpose here is just to list what devices are present to find the device file of our drive.
$ sudo -s
# fdisk -l
..
Device Start End Sectors Size Type
/dev/sda1 40 409639 409600 200M EFI System
/dev/sda2 409640 15769559 15359920 7.3G unknown
There it is, /dev/sda2. Now we want to mount it, using fsapfsmount, which mounts an Apple File System (APFS) volume. The option -f is used to specify the specific file system ("1" is typical), then the dev file and finally where it is being mounted to (in this case, /mnt.
# fsapfsmount -f 1 /dev/sda2 /mnt.
From here, it's a simple matter of copying the files over to the directory of choice, in this case the current working directory.
# cp -r /mnt/ACFSPres/ .
After that unmount the device.
# fusermount -u /mnt
Change ownership of the file and directories (because they are currently owned by root) to the user who needs access to them.
Hello amazing teachers! Are you looking for a fun and engaging way to bring history to life for your students? Meet Sabaton, a Swedish heavy metal band known for their powerful songs about historical events. While heavy metal might not be the first thing that comes to mind for a primary school setting, Sabaton’s music […]
Neuro-divergence, encompassing conditions such as autism spectrum, ADHD, and sensory processing, can profoundly influence how individuals perceive and respond to their bodily signals.
While neurotypical individuals generally recognise and respond to hunger, thirst, and satiety cues with relative ease, neuro-divergent individuals often face unique challenges in this area. Understanding these challenges is crucial for fostering empathy and supporting effective strategies for well-being.
This article is written so it is directly readable and useful (in terms of providing action items) for people in your immediate surroundings, but naturally it can be directly applied by neuro-spicy people themselves!
Hunger and Thirst Cues
For many neuro-divergent people, recognising hunger and thirst cues can be a complex task. These signals, which manifest as subtle physiological changes, might not be as easily identifiable or may be misinterpreted.
For instance, someone on the spectrum might not feel hunger as a straightforward sensation in the stomach but instead experience it as irritability or a headache. Similarly, those with ADHD may become so hyper-focused on tasks that they overlook or ignore feelings of hunger and thirst entirely.
Sensory Processing and Signal Translation
Sensory processing issues can further complicate the interpretation of bodily signals. Neuro-divergent individuals often experience heightened or diminished sensory perception.
This variability means that sensations like hunger pangs or a dry mouth might be either too intense to ignore or too faint to detect. The result is a disconnection from the body’s natural cues, leading to irregular eating and drinking habits.
Satiety and Fullness
Recognising satiety and fullness presents another layer of difficulty. For neuro-divergent individuals, the brain-gut communication pathway might not function in a typical manner.
This miscommunication can lead to difficulties in knowing when to stop eating, either due to a delayed recognition of fullness or because the sensory experience of eating (such as the textures and flavours of food) becomes a primary focus rather than the physiological need.
Emotional and Cognitive Influences
Emotions and cognitive patterns also play significant roles. Anxiety, a common experience among neuro-divergent individuals, can mask hunger or thirst cues, making it harder to recognise and respond appropriately.
Additionally, rigid thinking patterns or routines, often seen with autism spectrum, might dictate eating schedules and behaviours more than actual bodily needs.
Strategies for Support
Understanding these challenges opens the door to effective strategies and support mechanisms:
Routine and structure: Establishing regular eating and drinking schedules can help bypass the need to rely on internal cues. Setting alarms or reminders can ensure that meals and hydration are not overlooked.
Mindful eating practices: Encouraging mindful eating, where individuals pay close attention to the sensory experiences of eating and drinking, can help in recognising subtle signals of hunger and fullness.
Sensory-friendly options: Offering foods and beverages that align with an individual’s sensory preferences can make the experience of eating and drinking more enjoyable and less overwhelming. This is a really important aspect!
Environmental adjustments: Creating a calm, distraction-free eating environment can help individuals focus more on their bodily cues rather than external stimuli.
Education and awareness: Educating neuro-divergent individuals about the importance of regular nourishment and hydration, and how their unique experiences might affect this, can empower them to develop healthier habits. This is, of course, more a longer term strategy.
Understanding the complex interplay between neuro-divergence and bodily signals underscores the importance of personalised approaches and compassionate support.
By acknowledging and addressing these challenges, we can help neurodivergent individuals achieve better health and well-being!
(this post was created using some information from ChatGPT in addition to our own research)
In my previous article I covered why Light Metro is the best technology of the next major stage of Auckland’s train network. Here I present a couple of lines that could be the basis for a future network.
The lines are designed to form a mesh an enable transfers (especially in the CBD) but are of course just ideas. One problem I have encountered is steep sections of track, these will require the track to smooth our the height differences and for trains able to handle climbs of around 5%.
I am estimating costs as $300m/km for elevated sections and $1b/km for underground sections. Hence I have used elevated line wherever possible.
Light Metro Technology
As outlined in my previous article Light Metro is Automated, Grade Separated with Short Trains and High Frequencies. It is well suited to Auckland where requirements exceed Light Rail but a full metro would be overkill.
The key advantages of Light Metro over street running light rail is it’s high capacity, frequency and higher speed. Attempting to push Light Rail beyond it’s natural sweet-spot result in a grade-separated system that costs as much as Light Metro but is worse and often costs more to run.
The below table shows the capacity of a Light Metro line (in each direction). For Auckland the stations outside the CBD could be serviced by buses to further increase coverage area. Trains could start at short length and frequency increased as high as possible before longer trains should be used.
Headway / Trains per Hour
2 Cars
3 Cars
4 Cars
6 Cars
5 min / 12 tph
2,400
3,600
4,800
7,200
3 min / 20 tph
4,000
6,000
8,000
12,000
2 min / 30 tph
6,000
9,000
12,000
18,000
90 sec / 40 tph
8,000
12,000
16,000
24,000
Max Passengers per hour per direction
If the system is run with 4-car trains then each has the capacity over double one of the major Auckland motorways such as the Western or Southern.
Line 1 – A North/South Metro Line from Albany to the Airport
This line would upgrade the Northern Busway on the North Shore, run under the CBD and connect to the Airport in the South.
The line would be grade separated above the road as much as possible since this is cheaper than under-grounding. It would be underground though the central city however.
Total length would be around 36km of which around 5.5 would be underground. Cost would be something like $15b
Northern Section
This would start at the exiting Albany bus centre and follow the Northern busway to Akoranga station. It would then go along the shore until roughly opposite Sulphur point where it would either go in a tunnel or bridge over the Harbour to Wynyard Quarter. Stations would be Albany, Rosedale, Constellation, Sunnynook, Smales Farm, Akoranga
The Northern Busway should be kept South of Akoranga Station for use by buses from Takapuna, Northcote and Brikenhead. This would give the system more capacity and is easier than those people transferring from a bus to a train for such a short ride.
Travel time from Albany to the Te Waihorotiu Station (Aotea) should hopefully be around 25 minutes.
City Section
Once over the Harbour the line should head underground and have a series of stops in the Central City. I would suggest
Central Wynyard Quarter near Madden St
Near Les Mills on Victoria St West
Te Waihorotiu Station (Aotea)
University / Symonds St
The Te Waihorotiu CRL station is apparently already future-proofed with space for a North/South line. The station will effectively be the centre of the Auckland System. There should also be a surface Light Rail line nearby on Queen Street.
The University station would be quite deep and probably be a an elevator-only station.
Southern Section
South of Grafton Valley the line would go under the domain before going through Newmarket. The line could either be above or below ground though Newmarket but will be above ground once it reach Manukau Road.
Update: Feedback has convinced me the line should have a stop under Park Road near the Hospital and another at the bottom of Carton Gore Rd.
I don’t think having a station for the Museum is justified but there could also be a station at the North of Newmarket near Sarawia St. There should be at least one station in Central Newmarket near the existing Train station to allow transfers
South of Newmarket the line will travel above Manukau Rd and continue South through Onehunga and Mangere Bridge.
Possible stations could be (at roughly 1km intervals):
Near corner Manukau and Great South Road
Corner of Manukau Rd and Ranfurly Road
Corner of Manukau Rd and Queen Mary Ave (Alexandra Park, Green Lane West Rd)
Corner of Manukau and Pah Roads
Royal Oak Mall
Corner of Manukau Rd and Trafalgar St
Onehunga Mall Road near Grey Street
Onehunga Station
Mangere Bridge Village
Corner of McKenzie and Millar Rd
Corner of Bader Dr and Idlewild Ave
Mangere Town Centre (see below)
Airport Drive Area
Airport Terminal
The Southern Section would have roughly 16 stations and take over 18km and would take around 30 minutes to cover from the Airport to Te Waihorotiu/Aoetea Station.
Previous proposals have followed the motorway but I’ve switched this to following roads inside the suburb of Mangere Bridge and giving the suburb 3 stations with the Millar Rd one having good connectivity to Favona.
The Mangere Town Centre station would be a branch off the Bader Drive station. It could be run as a shuttle. Eventually the line could be extended East along Buckland Road to Papatoetoe Station then North to Otara and/or South to Manukau
Line 2: North-West Metro Line from Westgate to the City
This line is intended to fill the gaps to the North of the existing Western Rail Line and use the Motorway corridor. Closer to town it will go above Great South Rd and Karangahape Rd.
It will then do an above-ground spiral around the city to improve coverage and transfers.
Total length would be around 20km and all above ground. Cost would be something like $6b
Western Section
This would run from Westgate to Karangahape Road mainly along the North Western Motorway and Great North Road (GNR). It would be roughly 16km long and 100% overhead.
Stops could be: Westgate Shopping Centre, Royal Road, Huruhuru Road, Lincoln Road, Te Atatu Road, Rosebank, Point Chevalier Shops, Zoo / MOTAT, Corner GNR & Bond St, Corner GNR & Williamson Ave, Corner GNR and Newton Rd, St Kevins Arcade.
City Section
The St Kevins Arcade stop on Karangahape Rd should be designed to allow people to easily transfer to either the Dominion Rd Light rail on Queen St or the Karanga-a-Hape CRL station.
After the St Kevins Arcade stop the line continues east along Karangahape Rd and then turns down Symonds Street, Anzac Ave, Customs Street and then across the Viaduct Basin to Madden street.
St Kevins Arcade
Symonds St near City Rd
Symonds St near the Engineering School
Symond St near Parliament St
Customs St near Britomart
Customs St West near Market lane
Madden St near Daldy St
The line has seven stations in the CBD and intersects all the other lines twice. This enhances the coverage of the other lines via transfers. Extra stations are also a lot easier and cheaper to build on this line than the underground lines.
eg Someone coming from the North Shore on the N/S Metro could get off at Wynyard Station and Transfer to the Western Metro Line. They would then only have to wait a couple of minutes to catch a train to the Britomart station.
Dominion Road Light Rail
This has been covered elsewhere in detail but building a Lower Queen St to SH20 surface Light rail line fills a gap in coverage and provides additional capacity along Queen Street fairly cheaply.
The line would be mostly separate from car traffic on dedicated lanes in the Center of Dominion Rd and Queen Street. Length would be 8km.
Followups Lines
The above two lines probably give Central Auckland significant metro coverage to last many years. Future lines in Ponsonby, Sandringham, Mt Eden, The CDB, and Newmarket would probably be best served by cheaper street running light rail.
Further out Light Metro may suit the longer distances. Lines or Branches like:
Te Atatu
Point Chev to Onehunga
Mangere to Papatoetoe
Papatoetoe to Otara and then on to Botany
Manukau to Papatotoe, Howick and Manurewa
Takapuna
Orewa
Areas like Remuera could use either technology or just retain bus-based feeders
Questions
Q: Why not Light Rail?
A: Street running light rail is suitable for many sections but it lacks the higher capacity and speed of Light Metro. This is need for long busy routes like the link to the North Shore. If you Grade Separate the Light Rail then you end up spending as much as Light Metro for an inferior product.
However Light Rail is suitable for many routes that don’t justify the extra speed/capacity. This includes Dominion Road and additional filler routes around the CBD that need a step-up from buses.
Q: Why not Heavy Rail?
A: A System compatible with New Zealand’s current service would not work. It would not be able to handle turns, climbs and automated operation without extremely expensive changes which would lose all compatibility. The existing routes (including the CRL) are already full so no savings via reuse is gained.
Q: Why elevated instead of tunneled?
A: Because it is cheaper. Cost for tunneled is usually at least twice that of overhead and can often be more. Yes, not everybody likes the look of overhead lines but going underground can increase the cost by enough to derail the project.
Q: What about steep sections?
A: Certain section of the lines are quite steep due to Auckland’s terrain. This may cause a problem with the route. Light Metro can handle steep slopes than Heavy Rail but handling it may require additional measure like altering the height of lines so they smooth out slopes.
Several months ago, YouTube began "a global effort" to prevent users from blocking advertisements. This process included allowing users with an adblocker, once detected, a few videos, then a warning, and then outright prevention. There was an implicit suggestion that one could receive the desired ad-free service from a Premium subscription. Methods employed by YouTube to implement these blocks include embedding advertisements in the video itself, serving advertisements from the same domain as the video, or using browser fingerprinting to detect ad-blocking extensions.
Since then there have been a variety of methods employed by users to bypass the prevention of ad-blockers. For a while, use of uBlockOrigin was recommended as an ad-blocker. Fingerprinting could be circumvented by extensions like Canvas Fingerprint Defender. Others recommended disabling javascript on YouTube, using alternative browsers (e.g., Firefox), or even using Discord. A specific ad-block extension even exists for YouTube. As useful as these are they are likely to face further restrictions according to the Manifest3 development in Chrome.
From YouTube's perspective, ad-blockers reduce their income and, by extension, the income of content creators or providers. As much as this has a kernel of truth, the provision of advertisements on YouTube is so bad that even if an advertising algorithm manages to match well with a viewer's watch history, it is likely to put people off. Advertisements interspersed throughout a video, lengthy, unskippable advertisements and advertisements of questionable taste. There is, obviously, a significant difference between including skippable advertisements at the beginning and end of a video to what is being provided. For what it's worth, YouTube's adblocker detection is believed to break EU privacy laws, and the use of ad-blockers is actually recommended by the FBI to prevent fraud.
One excellent tool that works around these restrictions and provides a backup of the video for asynchronous viewing is yt-dlp with binaries available for Linux, MacOS, MS-Windows, and source code. As a general video downloader, it operates on thousands of sites, has extensive documentation for the enormous variety of options, and actively seeks improvements from outside contributors. When someone suggests a YouTube video to watch, one can simply download it from the command line, or even script it and run it in batch, in a manner convenient to the user. This is the way that audio and video content should be provided.
I’ve been daily driving the PinePhone Pro with swmo for some times now, it’s not perfect but I still find it be one of the most enjoyable devices I’ve used. Probably only behind BlackBerry Q30/Passport which also has a decent keyboard and runs an unfortunately locked-down version of QNX. For me it’s less like a phone and more like a portable terminal for times when using a full size laptop is uncomfortable or impractical, and with the keyboard it’s possible to write lengthy articles on the go.
This isn’t the only portable Linux terminal I owned, before this I used a Nokia N900 which till this day is still being maintained by the maemo leste team, but the shutdown of 3G network in where I live made it significantly less usable as a phone and since it doesn’t have a proper USB port I cannot use it as a serial console easily.
The overall experience on the PPP now as of 2024 isn’t as polished as that of the BlackBerry Passport, and adhoc hacks are often required to get the system going, however as the ecosystem progress the experience will also improve with new revisions of hardware and better software.
I use sxmo and swmo interchangeably in this post, they refer to the same framework running under Xorg and wayland, the experience is pretty much the same.
The default scaling of sxmo doesn’t allow the many desktop applications to display their window properly, especially when such application is written under the assumption of being used on a larger screen. To set the scaling to something more reasonable, add the following line to ~/.config/sxmo/sway:
exec wlr-randr --output DSI-1 --scale 1.3
When using swmo environment initialization is mostly done in ~/.config/sxmo/sway and ~/.config/sxmo/xinit is not used.
Scaling for Firefox needs to be adjusted separately by first enabling compact UI and then set settings -> default zoom to your liking.
To rotate Linux framebuffer, add fbcon=rotate:1 to the U_BOOT_PARAMETERS line in /usr/share/u-boot-menu/conf.d/mobian.conf and run u-boot-update to apply.
I also removed quiet splash from U_BOOT_PARAMETERS to disable polymouth animation as it isn’t very useful on landscape mode.
Swmo doesn’t come with a secure screen locker. but swaylock works fine and it can be bind to a key combination with sway’s configure file. To save some battery life, systemctl suspend can be triggered after swaylock, to bind that to Meta+L:
The default keymap for the PinePhone keyboard is missing a few useful keys, namely F11/F12 and PgUp/PgDown. To create those keys I used evremap(1) to make a custom keymap. Unfortunately the Fn key cannot be mapped as a layer switcher easily, so I opted to remap AltG and Esc as my primary modifiers.
I’m working on a Debian package for evremap and it will be made available for Debian/Mobian soon.
Incus is a container/VM manager for Linux, it’s available for Debian from bookworm/backports and is a fork of LXD by the original maintainers behind LXD. It works well for creating isolated and unprivileged containers. I have multiple incus containers on the PinePhone Pro for Debian packaging and it’s a better experience than manually creating and managing chroots. In case there is a need for running another container inside an unprivileged incus container, it’s possible to configure incus to intercept certain safe system calls and forward them to the host, removing the need for using privileged container.
Sway is decently usable in convergence mode, in which the phone is connected to a dock that outputs to an external display and keyboard and mouse are used as primary controls instead of the touchscreen.
This isn’t surprising since sway always had great support for multi monitor, however another often overlooked convergence mode is with waypipe. In this mode another Linux machine (e.g. a laptop) can be used to interact with applications running on the phone and the phone will be kept charged by the laptop. This is particularly useful for debugging phone applications or for accessing resources on the phone (e.g. sending and receiving sms). One thing missing in this setup is that graphic applications cannot roam between the phone and the external system (e.g. move running applications from one machine to another). Xpra does this for Xorg but doesn’t work with wayland.
Due to the simplicity of the swmo environment it’s not too difficult to get the system running with SELinux in Enforcing mode, and I encourage everyone reading this to try it. If running debian/mobian a good starting point is the SELinux/Setup page on Debian wiki.
Note: selinux-activate won’t add the required security=selinux kernel option to u-boot (it only deals with GRUB) so you have to manually add it to the U_BOOT_PARAMETERS line in /usr/share/u-boot-menu/conf.d/mobian.conf and run u-boot-update after selinux-activate. The file labeling process can easily take 10 minutes and the progress won’t be displayed on the framebuffer (only visible via the serial console).
SELinux along with the reference policy aren’t enough for building a reasonably secure interactive system, but let’s leave that for a future post.
The April 2024 meeting is the first meeting after Everything Open 2024 and the discussions are primarily around talks and lectures people found interesting during the conference, including the n3n VPN and the challenges of running personal email server. At the start of the meeting Yifei Zhan demonstrated a development build of Maemo Leste, an active Maemo-like operating system running on a PinePhone Pro.
Other topics discussed including modern network protocol ossification, SIP and possible free and open source VoLTE implementation.
The PinePhone keyboard contains a battery, which will be used to charge the PinePhone when the keyboard is attached. Althrough there are existing warnings on the pine64 wiki which sums up to ‘don’t charge or connect anything to your pinephone’s type C interface when the keyboard is attached’, my two pinephone keyboards still managed to fry themselves, with one releasing stinky magic smoke and the other melting the plastic around the pogo pins on the pinephone backplate.
This all happened while the pinephone’s type C interface being physically block when attached to the keyboard. In the first case, the keyboard’s controller PCB blew up when I tried to charge it, in the latter case the keyboard somehow overheated and melted the plastic near the pogo interface on the phone side.
Pine64 provided me a free replacement keyboard after multiple emails back and forth, but according to Pine64 there will be no more free replacement for me in future, and there is no guarantee that this will not happen to my replacement keyboard.
The cost for replacing all the fried parts with spare parts from the Pine64 store is about 40 USD (pogo pins + backplate + keyboard PCB), and considering this problem is likely to happen again, I don’t think purchasing those parts is a wise decision.
Both the melting plastic and the magic smoke originated from the fact that charges are constantly shuffled around when the keyboard is attached to the pinephone, and since the keyboard can function independently from the battery, we can disconnect and remove the battery from the keyboard case to make sure it will not blow up again. After such precedure the keyboard will keep functioning althrough the keyboard-attached pinephone might flip over much more easily due to the lightened keyboard base. Be aware that the keyboard isn’t designed to be taken apart, and doing so will likely result in scratches on the case. As for me, I’d much rather have a keyboard case without builtin battery than have something that can overheat or blow up.
On Friday, 1st March, it will be exactly one year since I walked into
Zen Motorcycles, signed the
paperwork, and got on my brand new Energica Experia electric motorbike. I
then rode it back to Canberra, stopping at two places to charge along the
way, but that was more in the nature of making sure - it could have done the
trip on one better-chosen charging stop.
I got a call yesterday from a guy who had looked at the Experia Bruce has at
Zen and was considering buying one. I talked with him for about three
quarters of an hour, going through my experience, and to sum it up simply I
can just say: this is a fantastic motorbike.
Firstly, it handles exactly like a standard motorbike - it handles almost
exactly like my previous Triumph Tiger Sport 1050. But it is so much easier
to ride. You twist the throttle and you go. You wind it back and you slow
down. If you want to, the bike will happily do nought to 100km/hr in under
four seconds. But it will also happily and smoothly glide along in traffic.
It says "you name the speed, I'm happy to go". It's not temperamental or
impatient; it has no weird points where the throttle suddenly gets an extra
boost or where the engine braking suddenly drops off. It is simple to ride.
As an aside, this makes it perfect for lane filtering. On my previous bike
this would always be tinged with a frisson of danger - I had to rev it and
ease the clutch in with a fair bit of power so I didn't accidentally stall it,
but that always took some time. Now, I simply twist the throttle and I am
ahead of the traffic - no danger of stalling, no delay in the clutch gripping,
just power. It is much safer in that scenario.
I haven't done a lot of touring yet, but I've ridden up to Gosford once and
up to Sydney several times. This is where Energica really is ahead of pretty
much every other electric motorbike on the market now - they do DC fast
charging. And by 'fast charger' here I mean anything from 50KW up; the
Energica can only take 25KW maximum anyway :-) But this basically means I
have to structure any stops we do around where I can charge up - no more
stopping in at the local pub or a cafe on a whim for morning tea. That has
to either offer DC fast charging or I'm moving on - the 3KW onboard AC
charger means a 22KW AC charger is useless to me. In the hour or two we
might stop for lunch I'd only get another 60 - 80 kilometres more range on
AC; on DC I would be done in less than an hour.
But OTOH my experience so far is that structuring those breaks around where I
can charge up is relatively easy. Most riders will furiously nod when I say
that I can't sit in the seat for more than two hours before I really need to
stretch the legs and massage the bum :-) So if that break is at a DC charger,
no problems. I can stop at Sutton Forest or Pheasant's Nest or even
Campbelltown and, in the time it takes for me to go to the toilet and have a
bit of a coffee and snack break, the bike is basically charged and ready to
go again.
The lesson I've learned, though, is to always give it that bit longer and
charge as much as I can up to 80%. It's tempting sometimes when I'm standing
around in a car park watching the bike charge to move on and charge up a bit
more at the next stop. The problem is that, with chargers still relatively
rare and there often only being one or two at each site, a single charger
not working can mean another fifty or even a hundred kilometres more riding.
That's a quarter to half my range, so I cannot afford to risk that. Charge
up and take a good book (and a spare set of headphones).
In the future, of course, when there's a bank of a dozen DC fast chargers in
every town, this won't be a problem. Charger anxiety only exists because
they are still relatively rare. When charging is easy to find and always
available, and there are electric forecourts like the UK is starting to get,
charging stops will be easy and will fit in with my riding.
Anyway.
Other advantages of the Experia:
You can get it with a complete set of Givi MonoKey top box and panniers. This
means you can buy your own much nicer and more streamlined top box and it fits
right on.
Charging at home takes about six hours, so it's easy to do overnight. The
Experia comes with an EVSE so you don't need any special charger at home. And
really, since the onboard AC charger can only accept 3KW, there's hardly any
point in spending much money on a home charger for the Experia.
Minor niggles:
The seat is a bit hard. I'm considering getting the
EONE
Canyon saddle, although I also just need to try to work out how to get
underneath the seat to see if I can fit my existing sheepskin seat cover.
There are a few occasional glitches in the display in certain rare situations.
I've mentioned them to Energica, hopefully they'll be addressed.
Supercomputing Asia 2024 was held in Sydney from the 19th to 23rd of February with over 1,000 attendees, most of whom were from Australia, the United States, Singapore, Japan, Thailand, and Aotearoa New Zealand, with a notable exception from the conference was China given their importance to both supercomputing and Asia, and one speaker noted wryly that "Australia is now apparently part of Asia". The program consisted of plenary sessions in the morning and multiple streams in the afternoon of each day. My attendance was at the IBM Storage Scale User Group for the entirety of the first day, the HPC Leadership Forum on the second, Skills and Training on the third, and the Accelerated Data Analytics and Computing Institute (ADAC) symposium on the fourth. The Storage Scale User Group was useful for a roadmap of their systems (e.g., IBM Storage Scale System 6000, Fusion HCI) and case studies. The Leadership Forum and the ADAC symposium both gave an overview of some of the major systems in the region, which included the two largest systems, Frontier (no 1), Aurora (no 2), along with Fugaku (no 4).
Of note from Fugaku was a Hyperion study on their macroeconomic return on investment for their HPC which was between $63 to $91 per dollar invested, following the 2013 IDN study of HPC in general indicating $44 per dollar invested. The larger figure is explained because of the tighter integration with national objectives in the peak system. Also of note, a concurring with a report written in September 2022 ("Microprocessor Trend Usage in HPC Systems for 2022-2023") was the rise of systems using AMD CPUs and the ubiquity of CPU/GPU heterogeneity. Thailand's Supercomputing Centre of note, rising from a relatively small system to one with 31744 AMD CPUs, 704 A100s, and no 94 in the top500 with 50% of their operating revenue now coming from fee-for-service from "national interest" private industries. In Australia, there is the leadership from NCI in developing the Indo-Pacific Exascale Consortium, modelled after the EuroHPC Joint Undertaking effort.
About 50 people attended the talk I gave at SCAsia 2024 on "HPC Certification Forum & Skill Tree: An Update". There was quite an enthusiastic discussion that followed with several questions about micro-credentials, the potential use of OpenBadge as part of the certification process, and strong interest from several other HPC centres (UWA, CSIRO, NeSI) and Intersect in participating eco-system approach about using the skill tree approach for training content and contributing back. The potential of this sort of collaboration within Australia at the very least will be extremely valuable in improving the HPC on-boarding process for researchers. The talk also dovetailed with a poster presentation, "HPC Training Generates HPC Results", which pointed out longitudinal correlations between the two in terms of training sessions, computer hours, and job completion.
Running topics of note throughout the conference and especially in the plenary sessions (a nice quirk was that the voice of Siri, Karen Jacobsen, was the MC for these sessions), was a focus on AI/machine learning/LLMs and quantum computing. The former topic especially noted the advantages of GPUS which bodes well for our own large GPU partition. Differentiation must be considered between quantum computing and quantum computers; as a recent Spartan-citing paper pointed out quantum algorithms on "classical" computers (e.g., HPC) are preferable to quantum computers which are very much still in the experimental phase. To differentiate, quantum computing is any method to generate quantum effects whereby qubit states can exist in superposition (0,1, both) rather than binary states (0,1). The typical system to do quantum computing, or at least simulate it, is usually HPC. In contrast, a quantum computer uses a system that directly uses a quantum system. For example, GENCI in France uses a photonic computer, LRZ in Germany uses superconducting qubits, PSNC in Poland uses trapped ions, etc.
Opportunities to speak with vendors is always important and in particular longer discussions were held with Dell with their roadmap, DDN on their new filesystem, and Altair's HPCWorks application (which, at the moment, only operates with PBSPro). Notably, many vendors continue to make a pitch in favour of monopolisation under the guise of convenience ("we'll do everything for you") rather than interoperability. Special thanks are given to Xenon Systems for an evening hosted at L'Aqua on Cockle Bay Wharf.
Overall, attendance and participation at the conference were extremely valuable for direct knowledge improvements in storage, useful collaborations with other centres for HPC training, awareness of vendor products, system developments in Asia and US, and developing an understanding of the overall direction of AI/LLM and quantum computing in HPC environments.
Over the last few months, I upgraded my Debian machines from
bullseye to
bookworm. The process was
uneventful (besides the asterisk
issue described below), but I ended up reconfiguring several things afterwards in
order to modernize my upgraded machines.
Logcheck
I noticed in this release that the transition to
journald is essentially
complete. This means that rsyslog is no longer needed on most of my systems:
apt purge rsyslog
Once that was done, I was able to comment out the following lines in
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles:
#/var/log/syslog
#/var/log/auth.log
I did have to adjust some of my custom logcheck rules, particularly the ones that
deal with kernel messages:
Then I moved local entries from /etc/logcheck/logcheck.logfiles to /etc/logcheck/logcheck.logfiles.d/local.logfiles
(/var/log/syslog and /var/log/auth.log are enabled by default when
needed) and removed some files that are no longer used:
Finally, I had to fix any unescaped | characters in my local rules. For example
error == NULL || \*error == NULL must now be written as error == NULL \|\| \*error == NULL.
Networking
After the upgrade, I got a notice that the isc-dhcp-client is now
deprecated and so I removed if from my system:
apt purge isc-dhcp-client
This however meant that I need to ensure that my network configuration
software does not depend on the now-deprecated DHCP client.
On my laptop, I was already using
NetworkManager for my main
network interfaces and that has built-in DHCP support.
Migration to systemd-networkd
On my backup server, I took this opportunity to switch from ifupdown to
systemd-networkd by
removing ifupdown:
apt purge ifupdown
rm /etc/network/interfaces
putting the following in /etc/systemd/network/20-wired.network:
On my Linode server, I did the same as on the backup server, but I put the
following in /etc/systemd/network/20-wired.network since it has a static
IPv6 allocation:
Also, if you haven't migrated to systemd-networkd yet and are still using
ifupdown with a static IP address, you will likely run into DNS
problems which
can be fixed using the following patch to /etc/network/if-up.d/resolved:
@@ -43,11 +43,11 @@ if systemctl is-enabled systemd-resolved > /dev/null 2>&1; then
fi
if [ -n "$NEW_DNS" ]; then
cat <<EOF >"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DNS"="$NEW_DNS"
+$DNS="$NEW_DNS"
EOF
if [ -n "$NEW_DOMAINS" ]; then
cat <<EOF >>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DOMAINS"="$NEW_DOMAINS"
+$DOMAINS="$NEW_DOMAINS"
EOF
fi
fi
@@ -66,7 +66,7 @@ EOF
# ignore errors due to nonexistent file
md5sum "$mystatedir/isc-dhcp-v4-$interface" "$mystatedir/isc-dhcp-v6-$interface" "$mystatedir/ifupdown-inet-$interface" "$mystatedir/ifupdown-inet6-$interface" > "$newstate" 2> /dev/null || true
if ! cmp --silent "$oldstate" "$newstate" 2>/dev/null; then
- DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
+ unset DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
# v4 first
if [ -e "$mystatedir/isc-dhcp-v4-$interface" ]; then
. "$mystatedir/isc-dhcp-v4-$interface"
and make sure you have nameservers setup in your static config, for example
one of my servers' /etc/network/interfaces looks like this:
I moved my customizations in /etc/chkrootkit.conf to
/etc/chkrootkit/chkrootkit.conf after seeing this message in my logs:
WARNING: /etc/chkrootkit.conf is deprecated. Please put your
settings in /etc/chkrootkit/chkrootkit.conf instead: /etc/chkrootkit.conf
will be ignored in a future release and should be deleted.
sshd[6283]: pam_env(sshd:session): deprecated reading of user environment enabled
I changed the following in /etc/pam.d/sshd:
--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -44,7 +44,7 @@ session required pam_limits.so
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
-session required pam_env.so user_readenv=1 envfile=/etc/default/locale
+session required pam_env.so envfile=/etc/default/locale
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context. Only sessions which are intended
I also made the following changes to /etc/ssh/sshd_config.d/local.conf
based on the advice of ssh-audit 2.9.0:
I ran into a problem with one of my servers where it would suspend
itself after a certain amount of time. This was due to default GDM behaviour
it turns out and while I could tell gdm not to sleep on inactivity,
I instead put the following in /etc/systemd/sleep.conf.d/nosuspend.conf to fully
disable systemd-based suspend or hibernate:
The only major problem I ran into while upgrading to bookworm is that I discovered
that Asterisk has been removed from stable and testing.
For some reason, this was not mentioned in the release notes
and I have not yet found a good solution.
If you upgrade to bookworm, be warned that the bullseye packages will remain
installed (and will work fine in my experience) unless you "clean them up" with
apt purge '~o' accidentally and then you'll have to fetch these old debs manually.
Using NetworkManager and systemd-resolved together in Debian
bookworm does not work out of the box. The first sign of trouble was these constant
messages in my logs:
avahi-daemon[pid]: Host name conflict, retrying with hostname-2
Then I realized that CUPS printer discovery didn't work: my network
printer could not be found. Since this discovery now relies on Multicast DNS,
it would make sense that both problems are related to an incompatibility
between NetworkManager and Avahi.
What didn't work
The first attempt I made at fixing this was to look for known bugs in Avahi.
Neither of the work-arounds I found worked:
The real problem turned out to be the fact that NetworkManager turns on full
mDNS support in systemd-resolved which conflicts with the mDNS support in
avahi-daemon.
You can see this in the output of resolvectl status:
Global
Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp6s0)
Current Scopes: DNS mDNS/IPv4 mDNS/IPv6
Protocols: +DefaultRoute -LLMNR +mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
DNS Domain: lan
which includes +mDNS for the main network adapter.
The solution was to tell NetworkManager to set mDNS to resolve-only mode in
systemd-resolved by adding the following to
/etc/NetworkManager/conf.d/mdns.conf:
[connection]
connection.mdns=1
leaving /etc/avahi/avahi-daemon.conf to the default Debian configuration.
Verifying the configuration
After rebooting, resolvectl status now shows the following:
Global
Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp6s0)
Current Scopes: DNS mDNS/IPv4 mDNS/IPv6
Protocols: +DefaultRoute -LLMNR mDNS=resolve -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
DNS Domain: lan
Avahi finally sees my printer (called hp in the output below):
$ avahi-browse -at | grep Printer
+ enp6s0 IPv6 hp @ myprintserver Secure Internet Printer local
+ enp6s0 IPv4 hp @ myprintserver Secure Internet Printer local
+ enp6s0 IPv6 hp @ myprintserver Internet Printer local
+ enp6s0 IPv4 hp @ myprintserver Internet Printer local
+ enp6s0 IPv6 hp @ myprintserver UNIX Printer local
+ enp6s0 IPv4 hp @ myprintserver UNIX Printer local
I know that people rave about GMail's spam filtering, but it didn't work for
me: I was seeing too many false positives. I personally prefer to see some
false negatives (i.e. letting some spam through), but to reduce false
positives as much as possible (and ideally have a way to tune this).
Here's the local SpamAssassin setup I
have put together over many years. In addition to the parts I describe here,
I also turn off
greylisting on my email
provider (KolabNow) because I don't want to have to
wait for up to 10 minutes for a "2FA" email to go through.
This setup assumes that you download all of your emails to your local
machine. I use fetchmail for this, though
similar tools should work too.
Three tiers of emails
The main reason my setup works for me, despite my receiving hundreds of spam
messages every day, is that I split incoming emails into three tiers via
procmail:
not spam: delivered to inbox
likely spam: quarantined in a soft_spam/ folder
definitely spam: silently deleted
I only ever have to review the likely spam tier for false positives, which
is on the order of 10-30 spam emails a day. I never even see the the
hundreds that are silently deleted due to a very high score.
This is implemented based on a threshold in my .procmailrc:
# Use spamassassin to check for spam
:0fw: .spamassassin.lock
| /usr/bin/spamassassin
# Throw away messages with a score of > 12.0
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
:0:
* ^X-Spam-Status: Yes
$HOME/Mail/soft_spam/
# Deliver all other messages
:0:
${DEFAULT}
I also use the following ~/.muttrc configuration to easily report false
negatives/positives and examine my likely spam folder via a shortcut in
mutt:
unignore X-Spam-Level
unignore X-Spam-Status
macro index S "c=soft_spam/\n" "Switch to soft_spam"
# Tell mutt about SpamAssassin headers so that I can sort by spam score
spam "X-Spam-Status: (Yes|No), (hits|score)=(-?[0-9]+\.[0-9])" "%3"
folder-hook =soft_spam 'push ol'
folder-hook =spam 'push ou'
# <Esc>d = de-register as non-spam, register as spam, move to spam folder.
macro index \ed "<enter-command>unset wait_key\n<pipe-entry>spamassassin -r\n<enter-command>set wait_key\n<save-message>=spam\n" "report the message as spam"
# <Esc>u = unregister as spam, register as non-spam, move to inbox folder.
macro index \eu "<enter-command>unset wait_key\n<pipe-entry>spamassassin -k\n<enter-command>set wait_key\n<save-message>=inbox\n" "correct the false positive (this is not spam)"
Custom SpamAssassin rules
In addition to the default ruleset that comes with SpamAssassin, I've also
accrued a number of custom rules over the years.
Finally, I wrote a few custom rules of my
own based
on specific kinds of emails I have seen slip through the cracks. I haven't
written any of those in a long time and I suspect some of my rules are now
obsolete. You may want to do your own testing before you copy these outright.
In addition to rules to match more spam, I've also written a ruleset to
remove false positives in French
emails
coming from many of the above custom rules. I also wrote a rule to get a
bonus to any email that comes with a patch:
describe FM_PATCH Includes a patch
body FM_PATCH /\bdiff -pruN\b/
score FM_PATCH -1.0
since it's not very common in spam emails
SpamAssassin settings
When it comes to my system-wide SpamAssassin configuration in
/etc/spamassassin/, I enable the following plugins:
Some of these require extra helper packages or Perl libraries to be
installed. See the comments in the relevant *.pre files or use this
command to install everything:
as well as manual score
reductions
due to false positives, and manual score
increases
to help push certain types of spam emails over the 12.0 definitely spam
threshold.
Finally, I have the FuzzyOCR
package installed since it has
occasionally flagged some spam that other tools had missed. It is a little
resource intensive though and so you may want to avoid this one if you are
filtering spam for other people.
As always, feel free to leave a comment if you do something else that works
well and that's not included in my setup. This is a work-in-progress.
Way back in the distant past, when the Apple ][ and the Commodore 64 were king, you could read the manual for a microprocessor and see how many CPU cycles each instruction took, and then do the math as to how long a sequence of instructions would take to execute. This cycle counting was used pretty effectively to do really neat things such as how you’d get anything on the screen from an Atari 2600. Modern CPUs are… complex. They can do several things at once, in a different order than what you wrote them in, and have an interesting arrangement of shared resources to allocate.
So, unlike with simpler hardware, if you have a sequence of instructions for a modern processor, it’s going to be pretty hard to work out how many cycles that could take by hand, and it’s going to differ for each micro-architecture available for the instruction set.
When designing a microprocessor, simulating what a series of existing instructions will take to execute compared to the previous generation of microprocessor is pretty important. The aim should be for it to take less time or energy or some other metric that means your new processor is better than the old one. It can be okay if processor generation to generation some sequence of instructions take more cycles, if your cycles are more frequent, or power efficient, or other positive metric you’re designing for.
Programmers may want this simulation too, as some code paths get rather performance critical for certain applications. Open Source tools for this aren’t as prolific as I’d like, but there is llvm-mca which I (relatively) recently learned about.
llvm-mca is a performance analysis tool that uses information available in LLVM (e.g. scheduling models) to statically measure the performance of machine code in a specific CPU.
So, when looking at an issue in the IPv6 address and connection hashing code in Linux last year, and being quite conscious of modern systems dealing with a LOT of network packets, and thus this can be quite CPU usage sensitive, I wanted to make sure that my suggested changes weren’t going to have a large impact on performance – across the variety of CPU generations in use.
There’s two ways to do this: run everything, throw a lot of packets at something, and measure it. That can be a long dev cycle, and sometimes just annoying to get going. It can be a lot quicker to simulate the small section of code in question and do some analysis of it before going through the trouble of spinning up multiple test environments to prove it in the real world.
So, enter llvm-mca and the ability to try and quickly evaluate possible changes before testing them. Seeing as the code in question was nicely self contained, I could easily get this to a point where I could easily get gcc (or llvm) to spit out assembler for it separately from the kernel tree. My preference was for gcc as that’s what most distros end up compiling Linux with, including the Linux distribution that’s my day job (Amazon Linux).
In order to share the results of the experiments as part of the discussion on where the code changes should end up, I published the code and results in a github project as things got way too large to throw on a mailing list post and retain sanity.
I used a container so that I could easily run it in a repeatable isolated environment, as well as have others reproduce my results if needed. Different compiler versions and optimization levels will very much produce different sequences of instructions, and thus possibly quite different results. This delta in compiler optimization levels is partially why the numbers don’t quite match on some of the mailing list messages, although the delta of the various options was all the same. The other reason is learning how to better use llvm-mca to isolate down the exact sequence of instructions I was caring about (and not including things like the guesswork that llvm-mca has to do for branches).
One thing I learned along the way is how to better use llvm-mca to get the results that I was looking for. One trick is to very much avoid branches, as that’s going to be near complete guesswork as there’s not a simulation of the branch predictor (at least in the version I was using.
The big thing I wanted to prove: is doing the extra work having a small or large impact on number of elapsed cycles. The answer was that doing a bunch of extra “work” was essentially near free. The CPU core could execute enough things in parallel that the incremental cost of doing extra work just… wasn’t relevant.
This helped getting a patch deployed without impact to performance, as well as get a patch upstream, fixing an issue that was partially fixed 10 years prior, and had existed since day 1 of the Linux IPv6 code.
Naturally, this wasn’t a solo effort, and that’s one of the joys of working with a bunch of smart people – both at the same company I work for, and in the broader open source community. It’s always humbling when you’re looking at code outside your usual area of expertise that was written (and then modified) by Really Smart People, and you’re then trying to fix a problem in it, while trying to learn all the implications of changing that bit of code.
Anyway, check out llvm-mca for your next adventure into premature optimization, as if you’re going to get started with evil, you may as well start with what’s at the root of all of it.
After a three year break, I spoke at five conferences in the last twelve months:
RubyConf Thailand — a wonderful second edition of this event, the chance to share Hanami 2 on the stage for the first time, and first-time in person hangs with another Buildkiter!
RubyConf AU — a joyous reunion for my home community. Good to be back, and positive signs for the future. Met many Buildkiters in person here!
Brighton Ruby — I’ve admired Andy and this event for the longest time. To attend and contribute a talk was a dream come true.
RubyConf — my first time at the US-based RubyConf, and a brilliant time all around: made new friends, had many great conversations, and got to work with some first-time Hanami contributors during the hack day!
RubyConf Taiwan — What a revelation! A whole thriving Ruby community I had no idea about, and a conference was chock-a-block with interesting talks. Being able to keynote opposite Matz was a real honour.
I’d commend any of these conferences to you, and I hope to get back to each of them in the future.
Being able to talk at so many events was definitely not my plan at the outset of the year! But one thing led to another, and I just rolled with it. It was a pleasure to share Hanami with people in so many places.
One thing I appreciated over this period was the chance to refine my method of introducing Hanami, and moreover, how I deliver conference talks in general. I’m very happy with how this ended up. I ended the year giving two very different presentations, each in their own way imbuing the audience (I hope!) with a sense of both whimsy and possibility: one involved song and dance, and the other, a surprise costume reveal!
A near-release of Hanami
Back at the end of 2021, we made a big push to get Hanami 2.0 released before I made it to RubyConf Thailand, and we succeeded!
I then spent all of 2022 working towards Hanami 2.1, which would introduce our view layer and a completely new approach to handling assets. As RubyConf approached in November, we attempted to do the same thing, to use the conference as motivation and make a big push to get the release out. I spent 2+ months working every night and weekend towards this, and we got so close, but didn’t quite make it.
Just two days before my talk, while I was already at the conference, we discovered what turned out to a release-blocking issue with our front end assets compilation. After a scramble at various stopgap fixes, we decided nothing would quite cut the mustard, and deferred the release. This was disappointing, but was the best choice for the project. After a break over Christmas, I’m now ready to take a final pass at this and make the right choices for the future.
Given this, I hope for 2024 to be a big two-release year for Hanami, with 2.1 happening next month, followed by 2.2 whenever it’s ready.
Family trips!
Once the Brighton Ruby opportunity came up, we decided to make the most of it and turn it into a family trip to Europe, our first overseas trip in the post-2020 era. It was an excellent time. We got to spend a bonus summer across Brighton, London, Paris, Amsterdam, Rotterdam and Brussels. The kids travelled very well, and we all can’t wait to do it again.
We also took a few nice road trips over the year, visiting Orange, Wagga Wagga, and ending the year with a relaxing week over Christmas in a house at Bawley Point.
Work at Buildkite
I had a good year at Buildkite. I spent the year in the same team I joined in 2022. Early in the year we hired some folks and brought the team to its full complement. Everyone is lovely, and we put in some great work towards fourdifferentquarterlyreleases.
I reached my first “bikkiversary” milestone in July, I joined an active on-call roster for the first time, I helped establish some clear direction for our future in front end development, and ended the year acting as an engineering manager, just to help keep things steady while my existing manager took some leave. Every one of these has been a pleasure. I’m continually humbled by the talent that surrounds me at Buildkite, and I’m looking forward to another year of learning.
Best of all, we gathered for our BIPOP (Buildkite In-Person On-site Party; yes, we love acronyms), our whole-company event in Cairns. This was a blast.
Reading
I read 22 books. In order:
Distress, Greg Egan
Sea of Tranquility, Emily St. John Mandel
The Water Knife, Paolo Bacigalupi
Shards of Earth, Adrian Tchaikovsky
Eyes of the Void, Adrian Tchaikovsky
The Thousand Earths, Stephen Baxter
Eversion, Alastair Reynolds
Lords of Uncreation, Adrian Tchaikovsky
Fractal Noise, Christopher Paolini
Me, Ricky Martin
Ancillary Justice, Ann Leckie
Ancillary Sword, Ann Leckie
Ancillary Mercy, Ann Leckie
Provenance, Ann Leckie
Translation State, Ann Leckie
Creation Node, Stephen Baxter
The Spare Man, Mary Robinette Kowal
Some Desperate Glory, Emily Tesh
Fugitive Telemetry, Martha Wells
System Collapse, Martha Wells
Fourth Wing, Rebecca Yarros
Iron Flame, Rebecca Yarros
I enjoyed them all! Adrian Tchaikovsky’s Final Architecture trilogy was thrilling, and discovering Ann Leckie’s Imperial Radch world was a true wonder: I’m so glad I got to binge all five stories together. It was a joy to revisit Murderbot with the most recent two books, and I don’t think I’ve read anything faster than I did Fourth Wing while hanging around a coast house at Christmas.
This year I also figured out my ideal e-reading situation. It’s the iPad mini, and Apple’s Books app in particular. Nothing beats its responsiveness and ease of use. And the iPad mini helps with the occasional tech book I read too. And thanks to Calibre and the Obok plugin, I can also buy books from Kobo and get them into Apple Books in short order.
Assorted things
We ended the year by giving the kids (9 & 7) each their own bedrooms. My desk/office is once again located next to my bed. Given I did this for three years already in our previous apartment, I expect this to work out well enough.
I started using the Retro app to share photos with a small group of friends. It’s brilliant! It has me sharing photos much more regularly, and helped me end the year with a nice collection of memories.
Thanks to several long plane rides, I did a decent amount of movie watching. Notables: No Time to Die (sob), Shotgun Wedding (fun), Jules (surprising), and Indy 5 (a triumph). Best soundtracks? Tetris, The Thomas Crown Affair.
I continue to pay attention to the little computer on my wrist telling me to exercise, though this unfortunately wavered towards the end of the year during my crunch on Hanami and conference talks.
At this rate, there is no real blogging here, regardless of the lofty plans to starting writing more. Stats update from Hello 2023:
219 days on the road (less than 2022! -37, over a month, shocking), 376,961km travelled, 44 cities, 17 countries.
Can’t say why it was less, because it felt like I spent a long time away…
In Kuala Lumpur, I purchased a flat (just in time to see Malaysia go down), and I swapped cars (had a good 15 year run). I co-founded a company, and I think there is a lot more to come.
2024 is shaping up to be exciting, busy, and a year, where one must just do.
Since late in 2007 I have been involved in the field of high performance computing. Initially, this was at the Victorian Partnership for Advanced Computing, but just before that organisation closed its doors in December 2015 I accepted a similar role at the University of Melbourne. The end of the year provides a reason for reflection, an annual report if one likes, and whilst activities not related to my vocation and profession will be dealt with in a subsequent entry, the opportunity is taken here to review workplace activities and in particular, changes in the environment for the University's general HPC system, Spartan. Spartan now has 6159 accounts across 2109 projects in diverse disciplines in the life sciences, engineering, economics, mathematics, and more and has been cited in 62 papers in the past year.
Some of those papers led to presentations to the Research Computing Services (RCS) team through the Cultural Working Group (CWG), which I have chaired for the past two years and held responsibility for organising these talks. In total six presentations were held this year, with a personal favourite on the use of AI algorithms, a supercomputer (Spartan), and robotics to sort plastic waste from two researchers at the Department of Infrastructure Engineering. The CWG was formed in 2020 following recognition from a staff survey that not all was well in RCS in terms of staff awareness of the group's objective, work between the different groups within the RCS, transparency in decision-making, involvement, and influence in decisions, career-progression opportunities, and job security. The staff-led CWG (with one management representative) made a concerted effort across those targetted areas and, following a survey in the middle of this year, substantial improvements were found in every criterion. At the end of this year, just after the last tech/researcher presentation, it brought great pleasure to say that whilst operations would continue, the group had succeeded in achieving its objectives and could close down as a formal body and as a successful project.
A very large part of my role at the University consists of training various postgraduate and postdoctoral researchers on how to use the system. This year included some 24 days of workshops involving close to 500 participants, roughly on par with other years and deliberately pulling back a bit from the first year of COVID, when over 40 of such workshops were conducted. Of particular note was early in the year a review was conducted of usage from those who had received training the previous year, resulting in the very surprising metric that at least 54.14% of cluster utilisation in 2022 was conducted by users after they had received training. I have always emphasized how important HPC training is but it was astounding to see such a metric as proof. As another form of training this year I continued with my regular activity as a guest lecturer and tutor for the master's level course Cluster and Cloud Computing. My role in this, previously just a single lecture, has now been extended to six lectures and workshops and is likely to expand in 2024. I must also mention here a presentation on RCS services to the Quantitative and Applied Ecology Research Group, with a future paper in development from that body on software citations.
Another major part of my role is scientific software optimisation and installation. Apart from the usual work in this field this year had the bonus of Spartan receiving its first major operating system upgrade since it was first turned on in 2015. Changing the underlying major release of the operating system (and indeed, jumping from RHEL v7 to v9) required existing software to be recompiled. In a one-month period, working with demonic fury, I was primarily responsible for around 500 software builds and an expansion in job submission examples. At the same time, Spartan also finally had the opportunity to run the LINPACK tests to be recognised as one of the world's supercomputers. It was an award that was long overdue (we've had sufficient performance to be on that list for years) and even then the certificate was for only part of the entire system.
Other activities included establishing the Spartan HPC Champions group among power-users of the system who can provide training advice to other members of their research teams, and continued involvement as a Board member of the international HPC Certification Forum and as an irregular contributor to the EasyBuild code repository. I have no doubt that these and other activities will all continue in 2024, however, there will be an additional role as well, following a necessary and considered restructure of RCS, I have found myself as the recipient of a small promotion in role and responsibility. It will be a position I will take with the appropriate seriousness; after all, supercomputing is one of those activities that has made a massive change to improving the world and will continue to do so. For the technical staff, it can be challenging and rewarding as they provide the researchers the tools to make great discoveries and inventions. But those staff also need to be in an environment where they feel secure and can flourish - and that means listening to their technical advice, as they actually do know best for such matters. This will be certainly the most significant challenge in the coming year.
Following the successful first conference last year, this year’s 2023 International Conference on Green and Innovation-driven Development in Cities and Towns was hosted in Suzhou with proceedings held at the recently opened Suzhou International Conference Hotel. The lead host of the conference was the Foreign Affairs Office of the Jiangsu Provincial People’s Government, and the main organiser was the Xiangcheng District People’s Government of Suzhou City. Suzhou is a major city in east China, founded in 514 BCE and is now the most populous city in Jiangsu Province, with a population of roughly 7.5 million in the city and 14 million in the administrative area.
The conference theme was “Jointly creating a new platform for a new ecology for shared new benefits” which develops on President Xi Jinping’s statements on eco-civilization as embodied in the Chinese Constitution: “The construction of ecological civilization is a millennial plan for the sustainable development of the Chinese nation” of which the “two mountains theory”, i.e., “Green waters and green mountains are [as valuable as] mountains of gold and silver” (Lǜ shuǐ qīngshān
jiùshì jīnshān yín shān) also applies. With the world facing ever-increasing human-caused global warming that causes more extreme weather such an approach is necessary for both raising the income and wealth of people, as well as protecting and enhancing the welfare of all life on our shared planet.
Over 350 attendees were at the conference including Local and international dignitaries, academics, engineers, and scientists. International guests were from Japan, Malaysia, Vietnam, Portugal, Italy, New Zealand, and Australia. Following a welcoming banquet by Xiangcheng’s District People’s Government,
the formal proceedings included the opening ceremony followed by parallel sessions on towns with distinctive features, integrated development on urban and rural areas, and heritage protection with sustainable development. My own attendance was to the latter, which included a number of international and local speakers and case studies with examples from Italy, Portugal, the Netherlands, and Suzhou itself. There was, of course, an extensive comparison between Suzhou and Venice as two cities with extensive historical canals and other waterways.
The majority of the conference proceeding however was spent on visits to Suzhou, combining the two vectors of heritage conservation and environmental technologies. From the former, this included visits to the Imperial Kiln Bricks Museum, the Silk Museum, Embroidery Art Museum, the especially beautiful
Taihu Lake Wetland Park, and the UNESCO World Heritage site, the Humble Administrator’s Garden. For the latter, this included the Suzhou City Industrial Park Exhibition Centre, the Higer Bus Company, the High-Tech Zone Exhibition Hall, the Urban Planning Exhibition Hall (with its strong connections to Singapore), the High-Tech Rail Tram Limited, and the new local campus of Nanjing University, China’s most famous university.
The two vectors give credence to both the “two mountains theory” but also illustrate the genuine and successful attempt of Suzhou city and the region to integrate both heritage conservation, environmental protection, and technological development. It is difficult enough to achieve the former two, but when coupled with the latter great care and intelligence is required. The
development shown by Suzhou city illustrates the superficial contradiction between the “two mountains” can be resolved. One cannot help but be impressed by the dedication shown in the development of ICVs (Intelligent Connected Vehicles) and electric vehicles. The sheer quantity of electric cars
on the road is already apparent, and the numbers indicate that soon electric vehicles will make up the majority of new car sales in China, and the rest of the world will follow.
For international guests it must be mentioned with great appreciation that the hospitality shown by Foreign Affairs Office of the Jiangsu Provincial People’s Government was absolutely second to none. We were given a vision of a city that is prosperous, populous, harmonious, green, high-tech, planned, and showed a great sensitivity and appreciation of its history and culture. There is sensitivity to the fact that this was a relatively well-off city within China, and the city was very keen to promote itself on a local level in preference to discussing more regional, national, or even global environmental challenges. A desire was expressed by many to have greater detail and even an extra day in the proceedings that would discuss at a lower level various environmental and technological challenges. This is, of course, less of a criticism and more of a desire that attendees wanted the conference to be even longer and deeper.
If I may be so bold to finish on a personal note, often in the afternoons and evenings after the day’s proceedings I would take a walk around the lake and its environs that the hotel faced. Whilst there was the vista of the city with its gleaming towers of steel and glass, I would find myself among the foliage and fauna of the lakeside in a peaceful and contemplative setting. It was in this place that I could not help but be absolutely charmed by a solar-powered intelligent robot boat that would make its way over the lake, cleaning whatever rubbish it could find of which, of course, there was very little. What a different and beautiful world it would be, I thought to myself, it would be if such robots were everywhere. This is the vision of the future that is offered to us: “green and innovation-driven development in cities and towns”. It would do us all well, to look at this example.
Published in the Australia-China Friendship Society Victorian Branch Newsletter, November 2023
Way back in 2015 the University of Melbourne had a general-purpose high performance computer system called "Edward", which itself replaced an even smaller system called "Alfred", both named after the Kings of Wessex. Edward was a fairly typical machine for its vintage and, as is normal, when a system is being retired the main researchers were asked what should be different in the new system. What was also normal was their answers; more cores, faster CPUs, etc. Consideration was given to not having an HPC system at all, potentially offloading the demand to a national facility. But cooler heads that possibly understood network throughput and the advantages of fine-tuning a local system to the needs of local researchers prevailed.
One of the interesting things about the review of Edward's utilisation was how it differed from what many researchers thought they needed. Rather than a system with more cores etc, what was really needed was faster throughput. Researchers simply didn't like their jobs sitting in the queue. Coupled with the fact that finances to fund the system weren't great (the naming of Spartan was a laconic reference to its lean cost-efficiency), necessity became the mother of invention. The Nectar research cloud had plenty of cores and, according to the metrics, the overwhelming majority of Edward's jobs were being run for capacity, rather than capability; over 75% were single-core jobs and over 90% were single-node jobs. Rather than spend a lot of money on high-speed interconnect, which is typical in HPC systems, a decision was made to have a smaller traditional HPC partition ("physical") and use a partition virtual machines ("cloud") with a slow interconnect for those singe-node jobs.
It was an innovative design and received a well-deserved initial launch, followed by a world-tour explaining the architecture to various conferences and HPC centres, including Multicore World, Wellington, 2016, and 2017; eResearchAustralasia 2016, Center for Scientific Computing (CSC) Goethe University Frankfurt, 2016, High Performance Computing Center (HLRS) University of Stuttgart, 2016, High Performance Computing Centre Albert-Ludwigs-University Freiburg, 2016; European Organization for Nuclear Research (CERN), 2016, Centre Informatique National de l’Enseignement Supérieur, Montpellier, 2016; Centro Nacional de Supercomputación, Barcelona, 2016, and the OpenStack Summit, at Barcelona 2016, and featured in OpenStack and HPC Workload Management in Stig Telfer (ed), "The Crossroads of Cloud and HPC: OpenStack for Scientific Research" (Open Stack, 2016).
The success of Spartan's architecture soon became apparent. Whilst Edward had completed just over 375,000 jobs in 2015, Spartan completed more than a million in its first year from launch. The system expanded with additional compute nodes from specialist projects, departments, and research agencies that had purchased their own hardware. But the most significant expansion was the addition of a substantial GPGPU partition, of 68 nodes and 272 nVidia P100 GPGPU cards, funded by a Linkage Infrastructure, Equipment and Facilities (LIEF) grant. Later, Spartan also introduced FastX for interactive remote desktops, and interactive sessions through Open OnDemand for Jupyer notebooks, RStudio, and Cryosparc.
The introduction of the GPGPU partition really transformed Spartan. It was what changed Spartan from being a small, experimental, but extremely successful system, to a world-class computing system. At the time we estimated that it would have entered at c200 on the top500.org list. However, running the tests to enter into that celebrated list requires both a lot of fine-tuning and, of course, it means that users, which have priority on our system, won't be able to use the nodes. On Spartan, it is typical that 100% of workers nodes are fully allocated, so for literally years there was little opportunity for the tests to be conducted.
Recently however, Spartan finally took the leap to change from running RedHat 7.x, which we had been doing since 2015, gradually working our way up the point-released, to RedHat 9.x. This provided a well-advertised two-week window of opportunity and whilst many other changes occurred to the operating system, the hardware, and the recompilation of hundreds of applications, a work colleague, Naren Chinnam (with necessary coordination with the rest of the HPC, Network and DC teams in getting the cluster stable enough for the benchmarks to finish), completed the LINPACK test for part of the system. As a result, Spartan now has a nice certificate, rated at 454 in the world (and third in Australia, after NCI/Gadi and Pawsey), with a benchmark score of 2.14 PetaFlops, representing the performance of the GPU partitions alone. It has already been noted that we actually have 88 A100 GPU nodes, not the 72 that were tested, which would have brought us up to 337 in the world, plus another 1/3rd of our performance could have come from the CPU-only partitions.
At the time of writing, Spartan has run 53881908 HPC jobs. There are 6134 users from the University of Melbourne and around the world, across 2097 projects. The original architecture (with our friends at the University of Freiburg with their alternative cluster-cloud combination) was also featured at the IEEE 13th International Conference on e-Science in 2017, and in the Science, Technology and Engineering Systems Journal in 2019, with other presentations on Spartan including use of the GPGPU partition at eResearch 2018, its development path at eResearchAU 2020, interactive HPC at eResearchNZ 2021, and over 250 papers citing Spartan as a contributing factor their research. Spartan continues to grow in users, usage, performance and, most importantly, research outcomes. Spartan may have finally received its laurels, but we are not resting on them.
I use
reboot-notifier
on most of my
servers to let me
know when I need to reboot them for kernel updates since I want to decide
exactly when those machines go down. On the other hand, my home backup
server has very predictable usage patterns and so I decided to go one step
further there and automate these necessary reboots.
To do that, I first installed
reboot-notifier
which puts the following script in /etc/kernel/postinst.d/reboot-notifier
to detect when a new kernel was installed:
#!/bin/sh
if [ "$0" = "/etc/kernel/postinst.d/reboot-notifier" ]; then
DPKG_MAINTSCRIPT_PACKAGE=linux-base
fi
echo "*** System restart required ***" > /var/run/reboot-required
echo "$DPKG_MAINTSCRIPT_PACKAGE" >> /var/run/reboot-required.pkgs
Note that
unattended-upgrades
puts a similar script in /etc/kernel/postinst.d/unattended-upgrades:
#!/bin/sh
case "$DPKG_MAINTSCRIPT_PACKAGE::$DPKG_MAINTSCRIPT_NAME" in
linux-image-extra*::postrm)
exit 0;;
esac
if [ -d /var/run ]; then
touch /var/run/reboot-required
if ! grep -q "^$DPKG_MAINTSCRIPT_PACKAGE$" /var/run/reboot-required.pkgs 2> /dev/null ; then
echo "$DPKG_MAINTSCRIPT_PACKAGE" >> /var/run/reboot-required.pkgs
fi
fi
and so you only need one of them to be installed since they both write to
/var/run/reboot-required. It doesn't hurt to have both of them though.
Then I created the following cron job (/etc/cron.daily/reboot-local) to
actually reboot the server:
#!/bin/bash
REBOOT_REQUIRED=/var/run/reboot-required
if [ -s $REBOOT_REQUIRED ] ; then
cat "$REBOOT_REQUIRED" | /usr/bin/mail -s "Rebooting $HOSTNAME" root
/bin/systemctl reboot
fi
With that in place, my server will send me an email and then automatically
reboot itself.
This is a work in progress because I'd like to add some checks later on to
make sure that no backup is in progress during that time (maybe by looking
for active ssh connections?), but it works well enough for now. Feel free to
leave a comment if you've got a smarter script you'd like to share.
It’s time for a review of the second year of operation of our Redflow ZCell battery and Victron Energy inverter/charger system. To understand what follows it will help to read the earlier posts in this series:
Go With The Flow (what all the pieces are, what they do, some teething problems)
TANSTAAFL (review/analysis of the first year of operation)
In case ~12,000 words of background reading seem daunting, I’ll try to summarise the most important details here:
We have a 5.94kW solar array hooked up to a Victron MPPT RS solar charge controller, two Victron 5kW Multi-Plus II inverter/chargers, a Victron Cerbo GX console, and a single 10kWh Redflow ZCell battery. It works really well. We’re using most of our generated power locally, and it’s enabled us to blissfully coast through several grid power outages and various other minor glitches. The Victron gear and the ZCell were installed by Lifestyle Electrical Services.
Redflow batteries are excellent because you can 100% cycle them every day, and they aren’t a giant lump of lithium strapped to your house that’s impossible to put out if it bursts into flames. The catch is that they need to undergo periodic maintenance where they are completely discharged for a few hours at least every three days. If you have more than one, that’s fine because the maintenance cycles interleave (it’s all automatic). If you only have one, you can’t survive grid outages if you’re in a maintenance period, and you can’t ordinarily use the Cerbo’s Minimum State of Charge (MinSoC) setting to perpetually keep a small charge in the battery in case of emergencies. As we still only have one battery, I’ve spent a fair bit of time experimenting to mitigate this as much as I can.
The system itself requires a certain amount of power to run. Think of the pumps and fans in the battery, and the power used directly by the inverters and the console. On top of that a certain amount of power is simply lost to AC/DC conversion and charge/discharge inefficiencies. That’s power that comes into your house from the grid and from the sun that your loads, i.e. the things you care about running, don’t get to use. This is true of all solar PV and battery storage systems to a greater or lesser degree, but it’s not something that people always think about.
With the background out of the way we can get on to the fun stuff, including a roof replacement, an unexpected fault after a power outage followed by some mains switchboard rewiring, a small electrolyte leak, further hackery to keep a bit of charge in the battery most of the time, and finally some numbers.
The big job we did this year was replacing our concrete tile roof with colorbond steel. When we bought the house – which is in a rural area and thus a bushfire risk – we thought: “concrete brick exterior, concrete tile roof – sweet, that’s not flammable”. Unfortunately it turns out that while a tile roof works just fine to keep water out, it won’t keep embers out. There’s a gadzillion little gaps where the tiles overlap each other, and in an ember attack, embers will get up in there and ignite the fantastic amount of dust and other stuff that’s accumulated inside the ceiling over several decades, and then your house will burn down. This could be avoided by installing roof blanket insulation under the tiles, but in order to do that you have to first remove all the tiles and put them down somewhere without breaking them, then later put them all back on again. It’s a lot of work. Alternately, you can just rip them all off and replace the whole lot with nice new steel, with roof blanket insulation underneath.
Of course, you need good weather to replace a roof, and you need to take your solar panels down while it’s happening. This meant we had twenty-two solar panels stacked on our back porch for three weeks of prime PV time from February 17 – March 9, 2023, which I suspect lost us a good 500kW of power generation. Also, the roof job meant we didn’t have the budget to get a second ZCell this year – for the cost of the roof replacement, we could have had three new ZCells installed – but as my wife rightly pointed out, all the battery storage in the world won’t do you any good if your house burns down.
We had at least five grid power outages during the year. A few were brief, the grid being down for only a couple of minutes, but there were two longer ones in September (one for 30 minutes, one for about an hour and half). We got through the long ones just fine with either the sun high in the sky, or charge in the battery, or both. One of the earlier short outages though uncovered a problem. On the morning of May 30, my wife woke up to discover there was no power, and thus no running water. Not a good thing to wake up to. This happened while I was away, because of course something like this would happen while I was away. It turns out there had been a grid outage at about 02:10, then the grid power had come back, but our system had not. The Multis ended up in some sort of fault state and were refusing to power our loads. On the console was an alarm message: “#8 – Ground relay test failed”.
Note the times in the console messages are about 08:00. I confirmed via the logs from the VRM portal that the grid really did go out some time between 02:10 and 02:15, but after that there was nothing in the logs until 07:59, which is when my wife used the manual changeover switch to shift all our loads back to direct grid power, bypassing the Victron kit. That brought our internet connection back, along with the running water. I contacted Murray Roberts from Lifestyle Electrical and Simon Hackett for assistance, Murray logged in remotely and reset the Multis, my wife flicked the changeover switch back and everything was fine. But the question remained, what had gone wrong?
The ground relay in the Multis is there to connect neutral to ground when the grid fails. Neutral and ground are already physically connected on the grid (AC input) side of the Multis in the main switchboard, but when the grid power goes out, the Multis disconnect their inputs, which means the loads on the AC output side no longer have that fixed connection from neutral to ground. The ground relay activates in this case to provide that connection, which is necessary for correct operation of the safety switches on the power circuits in the house.
The ground relay is tested automatically by the Multis. Looking up Error 8 – Ground relay test failed on Victron’s web site indicated that either the ground relay really was faulty, or possibly there was a wiring fault or an issue with one of the loads in our house. So I did some testing. First, with the battery at 50% State of Charge (SoC), I did the following:
Disconnected all loads (i.e. flipped the breaker on the output side of the Multis)
Killed the mains (i.e. flipped the breaker on the input side of the Multis)
Verified the system switched to inverting mode (i.e. running off the battery)
Restored mains power
Verified there was no error
This demonstrated that the ground relay and the Multis in general were fine. Had there been a problem at that level we would have seen an error when I restored mains power. I then reconnected the loads and repeated steps 2-5 above. Again, there was no error which indicated the problem wasn’t due to a wiring defect or short in any of the power or lighting circuits. I also re-tested with the heater on and the water pump running just in case there may have been an issue specifically with either of those devices. Again, there was no error.
The only difference between my test above and the power outage in the middle of the night was that in the middle of the night there was no charge in the battery (it was right after a maintenance cycle) and no power from the sun. So in the evening I turned off the DC isolators for the PV and deactivated my overnight scheduled grid charge so there’d be no backup power of any form in the morning. Then I repeated the test:
Disconnected all loads
Killed the mains.
Checked the console which showed the system as “off”, as opposed to “inverting”, as there was no battery power or solar generation
Restored mains power
Shortly thereafter, I got the ground relay test failed error
The underlying detailed error message was “PE2 Closed”, which meant that it was seeing the relay as closed when it’s meant to be open. Our best guess is that we’d somehow hit an edge case in the Multi’s ground relay test, where they maybe tried to switch to inverting mode and activated the ground relay, then just died in that state because there was no backup power, and got confused when mains power returned. I got things running again by simply power cycling the Multis.
So it kinda wasn’t a big deal, except that if the grid went out briefly with no backup power, our loads would remain without power until one of us manually reset the system. This was arguably worse than not having the system at all, especially if it happened in the middle of the night, or when we were away from home. The fact that we didn’t hit this problem in the first year of operation is a testament to how unlikely this event is, but the fact that it could happen at all remained a problem.
One fix would have been to get a second battery, because then we’d be able to keep at least a tiny bit of backup power at all times regardless of maintenance cycles, but we’re not there yet. Happily, Simon found another fix, which was to physically connect the neutral together between the AC input and AC output sides of the Multis, then reconfigure them to use the grid code “AS4777.2:2015 AC Neutral Path externally joined”. That physical link means the load (output) side picks up the ground connection from the grid (input) side in the swichboard, and changing the grid code setting in the Multis disables the ground relay and thus the test which isn’t necessary anymore.
Murray needed to come out anyway to replace the carbon sock in the ZCell (a small item of annual maintenance) and was able to do that little bit of rewriting and configuration at the same time. I repeated my tests both with and without backup power and everything worked perfectly, i.e. the system came back immediately by itself after a grid outage with no backup power, and of course switched over to inverting just fine when there was backup power available.
This leads to the next little bit of fun. The carbon sock is a thing that sits inside the zinc electrolyte tank and helps to keep the electrolyte pH in the correct operating range. Unfortunately I didn’t manage to get a photo of one, but they look a bit like door snakes. Replacing the carbon sock means opening the case, popping one side of the Gas Handling Unit (GHU) off the tank, pulling out the old sock and putting in a new one. Here’s a picture of the ZCell with the back of the case off, indicating where the carbon sock goes:
When Murray popped the GHU off, he noticed that one of the larger pipes on one side had perished slightly. Thankfully he happened to have a spare GHU with him so was able to replace the assembly immediately. All was well until later that afternoon, when the battery indicated hardware failure due to “Leak 1 Trip” and shut itself down out of an abundance of caution. Upon further investigation the next day, Murry and I discovered there was a tiny split in one of the little hoses going into the GHU which was letting the electrolyte drip out.
This small electrolyte leak was caught lower down in the battery, where the leak sensor is. Murray sucked the leaked electrolyte out of there, re-terminated that little hose and we were back in business. I was happy to learn that Redflow had obviously thought about the possibility of this type of failure and handled it. As I said to Murray at the time, we’d rather have a battery that leaks then turns itself off than a battery that catches fire!
Aside from those two interesting events, the rest of the year of operation was largely quite boring, which is exactly what one wants from a power system. As before I kept a small overnight scheduled charge and a larger late afternoon scheduled charge active on weekdays to ensure there was some power in the battery to use at peak (i.e. expensive) grid times. In spring and summer the afternoon charge is largely superfluous because the battery has usually been well filled up from the solar by then anyway, but there’s no harm in leaving it turned on. The one hack I did do during the year was to figure out a way to keep a small (I went with 15%) MinSoC in the battery at all times except for maintenance cycle evenings, and the morning after. This is more than enough to smooth out minor grid outages of a few minutes, and given our general load levels should be enough to run the house for more than an hour overnight if necessary, provided the hot water system and heating don’t decide to come on at the same time.
My earlier experiment along these lines involved a script that ran on the Cerbo twice a day to adjust scheduled charge settings in order to keep the battery at 100% SoC at all times except for peak electricity hours and maintenance cycle evenings. As mentioned in TANSTAAFL I ran that for all of July, August and most of September 2022. It worked fine, but ultimately I decided it was largely a waste of energy and money, especially when run during the winter months when there’s not much sun and you end up doing a lot of grid charging. This is a horribly inefficient way of getting power into the battery (AC to DC) versus charging the battery direct from solar PV. We did still use those scripts in the second year, but rather more judiciously, i.e. we kept an eye on the BOM forecasts as we always do, then occasionally activated the 100% charge when we knew severe weather and/or thunderstorms were on the way, those being the things most likely to cause extended grid outages. I also manually triggered maintenance on the battery earlier than strictly necessary several times when we expected severe weather in the coming days, to avoid having a maintenance cycle (and thus empty battery) coincide with potential outages. On most of those occasions this effort proved to be unnecessary. Bearing all that in mind, my general advice to anyone else with a single ZCell system (aside from maybe adding scheduled charges to time-shift expensive peak electricity) is to just leave it alone and let it do its thing. You’ll use most of your locally generated electricity onsite, you’ll save some money on your power bills, and you’ll avoid some, but not all, grid outages. This is a pretty good position to be in.
That said, I couldn’t resist messing around some more, hence my MinSoC experiment. Simon’s installation guide points out that “for correct system operation, the Settings->ESS menu ‘Min SoC’ value must be set to 0% in single-ZCell systems”. The issue here is that if MinSoC is greater than 0%, the Victron gear will try to charge the battery while the battery is simultaneously trying to empty itself during maintenance, which of course just isn’t going to work. My solution to this is the following script, which I run from a cron job on the Cerbo twice a day, once at midnight UTC and again at 06:00 UTC with the --check-maintenance flag set:
Midnight UTC corresponds to the end of our morning peak electricity time, and 06:00 UTC corresponds to the start of our afternoon peak. What this means is that after the morning peak finishes, the MinSoC setting will cause the system to automatically charge the battery to the value specified if it’s not up there already. Given it’s after the morning peak (10:00 AEST / 11:00 AEDT) this charge will likely come from solar PV, not the grid. When the script runs again just before the afternoon peak (16:00 AEST / 17:00 AEDT), MinSoC is set to either the value specified (effectively a no-op), or zero if it’s a maintenance day. This allows the battery to be discharged correctly in the evening on maintenance days, while keeping some charge every other day in case of emergencies. Unlike the script that tries for 100% SoC, this arrangement results in far less grid charging, while still giving protection from minor outages most of the time.
In case Simon is reading this now and is thinking “FFS, I wrote ‘MinSoC must be set to 0% in single-ZCell systems’ for a reason!” I should also add a note of caution. The script above detects ZCell maintenance cycles based solely on the configured maintenance time limit and the duration since last maintenance. It does not – and cannot – take into account occasions when the user manually forces maintenance, or situations in which a ZCell for whatever reason hypothetically decides to go into maintenance of its own accord. The latter shouldn’t generally happen, but it can. The point is, if you’re running this MinSoC script from a cron job, you really do still want to keep an eye on what the battery is doing each day, in case you need to turn that setting off and disable the cron job. If you’re not up for that I will reiterate my general advice from earlier: just leave the system alone – let it do its thing and you’ll (almost always) be perfectly fine. Or, get a second ZCell and you can ignore the last several paragraphs entirely.
Now, finally, let’s look at some numbers. The year periods here are a little sloppy for irritating historical reasons. 2018-2019, 2019-2020 and 2020-2021 are all August-based due to Aurora Energy’s previous quarterly billing cycle. The 2021-2022 year starts in late September partly because I had to wait until our new electricity meter was installed in September 2021, and partly because it let me include some nice screenshots when I started writing TANSTAAFL on September 25, 2022. I’ve chosen to make this year (2022-2023) mostly sane, in that it runs from October 1, 2022 through September 30, 2023 inclusive. This is only six days offset from the previous year, but notably makes it much easier to accurately correlate data from the VRM portal with our bills from Aurora. Overall we have five consecutive non-overlapping 12 month periods that are pretty close together. It’s not perfect, but I think it’s good enough to work with for our purposes here.
YeaR
Grid In
Solar In
Total In
Loads
Export
2018-2019
9,031
6,682
15,713
11,827
3,886
2019-2020
9,324
6,468
15,792
12,255
3,537
2020-2021
7,582
6,347
13,929
10,358
3,571
2021-2022
8,531
5,640
14,171
10,849
754
2022-2023
8,936
5,744
14,680
11,534
799
Overall, 2022-2023 had a similar shape to 2021-2022, including the fact that in both these years we missed three weeks of solar generation in late summer. In 2022 this was due to replacing the MPPT, and in 2023 it was because we replaced the roof. In both cases our PV generation was lower than it should have been by an estimated 500-600kW. Hopefully nothing like this happens again in future years.
All of our numbers in 2022-2023 were a bit higher than in 2021-2022. We pulled 4.75% more power from the grid, generated 1.84% more solar, the total power going into the system (grid + solar) was 3.59% higher, our loads used 6.31% more power, and we exported 5.97% more power than the previous year.
I honestly don’t know why our loads used more power this year. Here’s a table showing our consumption for both years, and the differences each month (note that September 2022 is only approximate because of how the years don’t quite line up):
Month
2022
2023
Diff
October
988
873
-115
November
866
805
-61
December
767
965
198
January
822
775
-47
February
638
721
83
March
813
911
98
April
775
1,115
340
May
953
1,098
145
June
1,073
1,149
76
July
1,118
1,103
-15
August
966
1,065
99
September
1,070
964
-116
Here’s a graph:
Did we use more cooling this December? Did we use more heating this April and May? I dug the nearest weather station’s monthly mean minimum and maximum temperatures out of the BOM Climate Data Online tool and found that there’s maybe a degree or so variance one way or the other each month year to year, so I don’t know what I can infer from that. All I can say is that something happened in December and April, but I don’t know what.
Another interesting thing is that what I referred to as “the energy cost of the system” in TANSTAAFL has gone down. That’s the kW figure below in the “what?” column, which is the difference between grid in + solar in – loads – export, i.e. the power consumed by the system itself. In 2021-2022, that was 2,568 kW, or about 18% of the total power than went into the system. In 2022-2023 it was only 1,838kWh, or 12.5%:
Year
Grid In
Solar In
Total In
Loads
Export
Total Out
what?
2021-2022
8,531
5,640
14,171
10,849
754
11,603
2,568
2022-2023
8,963
5,744
14,680
11,534
799
12,333
1,838
The cause of this reduction is almost certainly that we didn’t spend two and a half months doing lots of grid charging of the battery in 2022-2023. This again points to the advisability of just letting the system do its thing and not messing with it too much unless you really know you need to.
The last set of numbers I have involve actual money. Here’s what our electricity bills looked like over the past five years:
Year
From Grid
Total Bill
Cost/kWh
2018-2019
9,031
$2,278.33
$0.25
2019-2020
9,324
$2,384.79
$0.26
2020-2021
7,582
$1,921.77
$0.25
2021-2022
8,531
$1,731.40
$0.20
2022-2023
8,936
$1,989.12
$0.22
Note that cost/kWh as I have it here is simply the total dollar amount of our bills divided by the total power drawn from the grid (I’m deliberately ignoring the additional power we use that comes from the sun in this calculation). The bills themselves say “peak power costs $X, off-peak costs $Y, you get $Z back for power exported and there’s a daily supply charge of $SUCKS_TO_BE_YOU”, but that’s all noise. What ultimately matters in my opinion is what I call the effective cost per kilowatt hour, which is why those things are all smooshed together here. The important point is that with our existing solar array we were previously effectively paying about $0.25 per kWh for grid power. After getting the battery and switching to Peak & Off-Peak billing, that went down to $0.20/kWh – a reduction of 20%. Now we’ve inched back up to $0.22/kWh, but it turns out that’s just because power prices have increased. As far as I can tell Aurora Energy don’t publish historical pricing data, so as a public service, I’ll include what I’ve been able to glean from our prior bills here:
July 2023 onwards:
Daily supply charge: $1.26389
Peak: $0.36198/kWh
Off-Peak: $0.16855/kWh
Feed-In Tariff: $0.10869/kWh
July 2022 – July 2023
Daily supply charge: $1.09903
Peak: $0.33399/kWh
Off-Peak: $0.15551/kWh
Feed-In Tariff: $0.08883/kWh
Before July 2022:
Daily supply charge: $0.98
Peak: $0.29852
Off-Peak: $0.139
Feed-In Tariff: $0.06501
It’s nice that the feed-in tariff (i.e. what you get credited when you export power) has gone up quite a bit, but unless you’re somehow able to export 2-3x more power than you import, you’ll never get ahead of the ~20% increase in power prices over the last two years.
Having calculated the effective cost/kWh for grid power, I’m now going to do one more thing which I didn’t think to do during last year’s analysis, and that’s calculate the effective cost/kWh of running our loads, bearing in mind that they’re partially powered from the grid, and partially from the sun. I’ve managed to dig up some old Aurora bills from 2016-2017, back before we put the solar panels on. This should make for an interesting comparison.
Year
From Grid
Total Bill
Grid $/kWh
Loads
Loads $/kWh
2016-2017
17,026
$4,485.45
$0.26
17,026
$0.26
2018-2019
9,031
$2,278.33
$0.25
11,827
$0.19
2019-2020
9,324
$2,384.79
$0.26
12,255
$0.19
2020-2021
7,582
$1,921.77
$0.25
10,358
$0.19
2021-2022
8,531
$1,731.40
$0.20
10,849
$0.16
2022-2023
8,936
$1,989.12
$0.22
11,534
$0.17
The first thing to note is the horrifying 17 megawatts we pulled in 2016-2017. Given the hot water and lounge room heat pump were on a separate tariff, I was able to determine that four of those megawatts (i.e. about 24% of our power usage) went on heating that year. Replacing the crusty old conventional electric hot water system with a Sanden heat pump hot water service cut that in half – subsequent years showed the heating/hot water tariff using about 2MW/year. We obviously also somehow reduced our loads by another ~3MW/year on top of that, but I can’t find the Aurora bills for 2017-2018 so I’m not sure exactly when that drop happened. My best guess is that I probably got rid of some old, always-on computer equipment.
The second thing to note is how the cost of running the loads drops. In 2016-2017 the grid cost/kWh is the same as the loads cost/kWh, because grid power is all we had. From 2018-2021 though, the load cost/kWh drops to $0.19, a saving of about 26%. It remains there until 2021-2022 when we got the battery and it dropped again to $0.16 (another 15% or so). So the big win was certainly putting the solar panels on and swapping the hot water system, with the battery being a decent improvement on top of that.
Further wins are going to come from decreasing our power consumption. In previous posts I had mentioned the need to replace panel heaters with heat pumps, and also that some of our aging computer equipment needed upgrading. We did finally get a heat pump installed in the master bedroom this year, and we replaced the old undersized lounge room heat pump with a new correctly sized unit. This happened on June 30 though, so will have had minimal impact on this years’ figures. Likewise an always-on computer that previously pulled ~100W is now better, stronger and faster in all respects, while only pulling ~50W. That will save us ~438kW of power per year, but given the upgrade happened in mid August, again we won’t see the full effects until later.
I’m looking forward to doing another one of these posts in a year’s time. Hopefully I will have nothing at all interesting to report.
As an OpenBSD package maintainer, I often need to watch for updates on packages I maintain. I used to do this using repology.org, which has the benefit of tracking package updates in many distros, but it can be unreliable for OpenBSD packages due to network delay and parsing problems.
One better way to watch for upstream update is using OpenBSD’s portroach service, it monitors new upstream release and provides a JSON API that can be combined with jq(1) to produce clear information.
To find all packages that can be updated for a given maintainer, first find the maintainer page on portroach, you can search by maintainer name and the page’s URL should be similar to the following:
This endpoint will return all the packages maintained by a given maintainer, regardless of having an update or not. To only show packaged that can be updated, jq(1) can be used as a powerful filter and formatter:
Please be mindful that portroach is not infaillible, it may produce inaccurate result for some upstreams. The hosted version is a community resource, so please don’t abuse it, If you want, you can selfhost it with source code from its GitHub repository.
A few weeks ago, I upgraded a few machines from Ubuntu 20.04 (focal) to
22.04 (jammy). Here are the things that needed fixing after the upgrade.
Network problems
Firstly, I had to fix the resolution of .local domains the same
way
as I did when I upgraded a different machine from 18.04 (bionic) to 20.04
(focal).
ssh agent problems
Then, I found that ssh-add no longer worked and instead returned this error:
Could not open connection to your authentication agent
While this appears to be a known
issue, the
work-around suggested in the i3
forum didn't work for me. What
did work was the solution described in this blog
post:
I'm not sure why ED25519 keys don't work in gnome-keyring since that
bug was supposedly fixed
a while back, but starting gnome-keyring-ssh.service instead of
ssh-agent.service didn't work for me.
Packages
When it comes to specific packages, I removed this obsolete package:
As always, I put any packages I backport from Debian unstable into my
PPA.
So far with jammy, I only had to update
tiger to silence some bogus warnings.
At this point, all of the traffic from that browser should be flowing
through your mitmproxy instance.
Android setup
On Android, it's a little less straightforward:
Start mitmproxy on your desktop:
mitmproxy --mode regular --listen-port 9000
Open that port on your desktop firewall if needed.
On your Android device, change your WiFi settings for the current access point:
Proxy: Manual
Proxy hostname: 192.168.1.100 (IP address of your desktop)
Proxy port: 9000
Turn off any VPN.
Turn off WiFi.
Turn WiFi back on.
Open http://mitm.it in a browser to download the certificate authority file.
Open the system Settings, Security and privacy, More security and
privacy, Encryption & credentials, Install a certificate and finally
choose CA certificate.
Tap Install anyway to dismiss the warning and select the file you just downloaded.
Once you have gone through all of these steps, you should be able to monitor
(on your desktop) the HTTP and HTTPS requests made inside of your Android
browsers.
With the two big PRs introducing our next generation of asset support merged (here and here), September was a month for rapid iteration and working towards getting assets out in a 2.1 beta release.
The pace was lively! Towards the end of the month, Luca and I were trading PRs and code reviews on almost a daily basis. Thanks our opposing timezones, Hanami was being written nearly 24h a day!
There was one interesting piece though. Earlier in this release cycle (back in June!), I overhauled our user-facing error handling. I added a middleware to catch errors and render static error pages intended display in production. As part of this change, I adjusted our router to raise exceptions for not found routes: doing this would allow the error to be caught and a proper 404 page displayed. So that was production sorted. For development, we integrated the venerable better_errors, wrapped by our own hanami-webconsole gem.
It was only some months later that we realised 404s in development were being returned as 500s. This turned out to be because better_errors defaults to a 500 response code at all times. In its middleware:
Well, maybe not quite at all times. The lines right beneath status_code = 500:
status_code = 500
if defined?(ActionDispatch::ExceptionWrapper) && exception
status_code = ActionDispatch::ExceptionWrapper.new(env, exception).status_code
end
Looks like Ruby on Rails gets its own little exception carved out here, via some hard-coded constant checks that reach deep inside Rails internals. This will allow better_errors to return a 404 for a not found error in Rails, but not in any other Ruby framework.
This is not a new change. It arrived over ten years ago, and I can hardly blame the authors for wanting a way to make this work nicely with the predominant Ruby application framework of the day.
Today, however, is a different day! We’re here to change the Ruby framework balance. � So we needed a way to make this work for Hanami. What didn’t feel feasible at this point was a significant change to better_errors: our time was limited and at best we had the appetite only for a minor tactical fix.
module BetterErrorsExtension
# The BetterErrors middleware always returns a 500 status when rescuing an exception
# (outside of Rails). This is not not always appropriate, such as for a
# `Hanami::Router::NotFoundError`, which should be a 404.
#
# To account for this, gently patch `BetterErrors::Middleware#show_error_page` (which is
# called only when an exception has been rescued) to pass that rescued exception to a proc
# we inject into the rack env here in our own middleware. This allows our middleware to know
# the about exception class and provide the correct status code after BetterErrors is done
# with its job.
#
# @see Webconsole::Middleware#call
def show_error_page(env, exception = nil)
if (capture_proc = env[CAPTURE_EXCEPTION_PROC_KEY])
capture_proc.call(exception)
end
super
end
end
BetterErrors::Middleware.prepend(BetterErrorsExtension)
In order to know which response code to use for the page, we need access to the exception that better_error is catching. Right now it provides no hooks to expose that. So instead we prepend some behaviour in front of their #show_error_page, which is only called by the time an error is to be rendered. We look for a proc on the rack env, and if one is there, we pass the exception to it, and then let better_errors get on with the rest of its normal work.
Then, in our own webconsole middleware, we set that proc to capture the exception, using Ruby closure semantics to assign that exception directly to a local variable:
def call(env)
rescued_exception = nil
env[CAPTURE_EXCEPTION_PROC_KEY] = -> ex { rescued_exception = ex }
# ...
end
After that, we call the better_errors middleware, letting it do its own thing:
def call(env)
rescued_exception = nil
env[CAPTURE_EXCEPTION_PROC_KEY] = -> ex { rescued_exception = ex }
status, headers, body = @better_errors.call(env)
end
And then once that is done, we can use the exception (if we have one) to fetch an appropriate response code from the Hanami app config, and then override better_errors’ response code with our own:
def call(env)
rescued_exception = nil
env[CAPTURE_EXCEPTION_PROC_KEY] = -> ex { rescued_exception = ex }
status, headers, body = @better_errors.call(env)
# Replace the BetterErrors status with a properly configured one for the Hanami app
if rescued_exception
status = Rack::Utils.status_code(
@config.render_error_responses[rescued_exception.class.name]
)
end
[status, headers, body]
end
That’s it! Given how light touch this is, and how stable better_errors is, I’m confident this will serve our purposes quite well for now.
We don’t want to live with this forever, however. In our future I see a fit for purpose developer errors reporter that is fully integrated with Hanami’s developer experience. Given current timelines, this will probably won’t come for at least 12 months, so if this is something you’re interested in helping with, please reach out!
Kickstarting dry-operation!
While the work on Hanami continued, I also helped kickstart work on a new dry-rb gem: dry-operation! Serving as the successor to dry-transaction, with dry-operation we’ll introduce significant new flexibility to modelling composable business operations, while still keeping a high-level API that presents their key flows in an easy to follow way.
I’m excited we’re finally providing a bridge to the future for dry-transaction, and at the same time building one of the final pieces of the puzzle for full stack Hanami apps. This is an interesting one for me personally, too, since I’m acting more as a “product manager� for this effort, with Marc doing most of the direct development work. Marc’s been in the dry-rb/Hanami orbit for a while now, and I’m excited for this opportunity for him to step up his contributions. More on this in the future!
Releasing Hanami 2.1.0.beta2!
After all of this, we capped the month off with the release of Hanami 2.1.0.beta2! This was a big step: our first beta to include both views and assets together. In the time since this release we’ve already learnt a ton and found way to take things to another level… but more on that next month. 😉 See you then!
and then adding apparmor=1 security=apparmor to the kernel command line
(GRUB_CMDLINE_LINUX) in /etc/default/grub.
Move away from using Linode's kernels
As mentioned in this blog
post, I found out that
these parameters are ignored by the Linode kernels.
I had to:
login to the Linode Manager (i.e.
https://cloud.linode.com/linodes/<linode ID>/configurations),
click the node relevant node,
click "Edit" next to the configuration profile, and
change the kernel to "GRUB 2".
Fix grub
Next I found out that grub doesn't actually install itself properly because
it can't be installed directly on the virtual drives provided by Linode
(KVM). Manually running this
hack
worked for me:
grub-install --grub-setup=/bin/true /dev/null
Unbound + Let's Encrypt fix
Finally, my local Unbound
installation stopped
working because it couldn't access the Let's Encrypt certificates anymore.
The solution to this was pretty
straightforward. All I needed to do was to add the following to
/etc/apparmor.d/local/usr.sbin.unbound:
August turned out to bring a lot of forward motion for our work on Hanami’s front end assets support. While Luca was taking his summer break, I carried on his work preparing hanami-assets 2.1 and its integration into the Hanami framework. Last week we caught up for a quick chat about these, and now both are merged!
Personally, I think this was an exciting evolution of how Luca and I work together. While previously we each took care of fairly distinct lines of work (there was enough to do, after all!), here we literally worked in tandem on one specific area, and it came out great!
Luca and I also hopped on another video call during August, this time with Seb Wilgosz of Hanami Mastery to record a special core team interview for the site’s 50th episode! I really enjoyed the chance to answer community questions about Hanami, and personally, it was a moment of reassurance that we’re still on the right track and are delivering useful things to people.
The episode isn’t published yet, but one thing that did arise from the episode is a new Hanami 2.1 GitHub project that I put together for tracking our remaining work for the release. Previously, this was in Trello, and with the move to GitHub I hope it will make not our remaining work move visible, but also create clearer opportunities for potential contributors.
Now, with those big two PRs merged and our remaining work more clearly listed, the pace is picking up! We’re now at the point where we can focus on the direct user experience of working with assets within a full Hanami app. I expect a lot will shake out from this in quick order. But more on that next month!
I (relatively) recently went down the rabbit hole of trying out personal finance apps to help get a better grip on, well, the things you’d expect (personal finances and planning around them).
In the past, I’ve had an off-again-on-again relationship with GNUCash. I did give it a solid go for a few months in 2004/2005 it seems (I found my old files) and I even had the OFX exports of transactions for a limited amount of time for a limited number of bank accounts! Amazingly, there’s a GNUCash port to macOS, and it’ll happily open up this file from what is alarmingly close to 20 years ago.
Back in those times, running Linux on the desktop was even more of an adventure than it has been since then, and I always found GNUCash to be strange (possibly a theme with me and personal finance software), but generally fine. It doesn’t seem to have changed a great deal in the years since. You still have to manually import data from your bank unless you happen to be lucky enough to live in the very limited number of places where there’s some kind of automation for it.
So, going back to GNUCash was an option. But I wanted to survey the land of what was available, and if it was possible to exchange money for convenience. I am not big on the motivation to go and spend a lot of time on this kind of thing anyway, so it had to be easy for me to do so.
For my requirements, I basically had:
Support multiple currencies
Be able to import data from my banks, even if manually
Some kind of reporting and planning tools
Be easy enough to use for me, and not leave me struggling with unknown concepts
The ability to export data. No vendor lock-in
I viewed a mobile app (iOS) as a Nice to Have rather than essential. Given that, my shortlist was:
I’ve used it before, its web site at https://www.gnucash.org/ looks much the same as it always has. It’s Free and Open Source Software, and is thus well aligned with my values, and that’s a big step towards not having vendor lock-in.
I honestly could probably make it work. I wish it had the ability to import transactions from banks for anywhere I have ever lived or banked with. I also wish the UI got to be a bit more consistent and modern, and even remotely Mac like on the Mac version.
Honestly, if the deal was that a web service would pull bank transactions in exchange for ~$10/month and also fund GNUCash development… I’d struggle to say no.
Here’s an option that has been around forever – https://www.quicken.com/ – and one that I figured I should solidly look at. It’s actually one I even spent money on…. before requesting a refund. It’s Import/Export is so broken it’s an insult to broken software everywhere.
Did you know that Quicken doesn’t import the Quicken Interchange Format (QIF), and hasn’t since 2005?
Me, incredulously, when trying out quicken
I don’t understand why you wouldn’t support as many as possible formats that banks export your transaction data as. It cannot possibly be that hard to parse these things, nor can it possibly be code that requires a lot of maintenance.
This basically meant that I couldn’t import data from my Australian Banks. Urgh. This alone ruled it out.
It really didn’t build confidence in ever getting my data out. At every turn it seemed to be really keen on locking you into Quicken rather than having a good experience all-up.
This one was new to me – https://www.wiz.money/ – and had a fancy URL and everything. I spent a bunch of time trying MoneyWiz, and I concluded that it is pretty, but buggy. I had managed to create a report where it said I’d earned $0, but you click into it, and then it gives actual numbers. Not being self consistent and getting the numbers wrong, when this is literally the only function of said app (to get the numbers right), took this out of the running.
It did sync from my US and Australian banks though, so points there.
Intuit used to own Quicken until it sold it to H.I.G. Capital in 2016 (according to Wikipedia). I have no idea if that has had an impact as to the feature set / usability of Quicken, but they now have this Cloud-only product called Mint.
The big issue I had with Mint was that there didn’t seem to be any way to get your data out of it. It seemed to exemplify vendor lock-in. This seems to have changed a bit since I was originally looking, which is good (maybe I just couldn’t find it?). But with the cloud-only approach I wasn’t hugely comfortable with having everything there. It also seemed to be lacking a few features that I was begging to find useful in other places.
It is the only product that links with the Apple Card though. No idea why that is the case.
The price tag of $0 was pretty unbeatable, which does make me wonder where the money is made from to fund its development and maintenance. My guess is that it’s through commission on the various financial products advertised through it, and I dearly hope it is not through selling data on its users (I have no reason to believe it is, there’s just the popular habit of companies doing this).
This is what I’ve settled on. It seemed to be easy enough for me to figure out how to use, sync with an iPhone App, be a reasonable price, and be able to import and sync things from accounts that I have. Oddly enough, nothing can connect and pull things from the Apple Card – which is really weird. That isn’t a Banktivity thing though, that’s just universal (except for Intuit’s Mint).
I’ve been using it for a bit more than a year now, and am still pretty happy. I wish there was the ability to attach a PDF of a statement to the Statement that you reconcile. I wish I could better tune the auto match/classification rules, and a few other relatively minor things.
Periodically in life I’ve had the desire to be somewhat fit, or at least have the benefits that come with that such as not dying early and being able to navigate a mountain (or just the city of Seattle) on foot without collapsing. I have also found that holding myself accountable via data is pretty vital to me actually going and repeatedly doing something.
So, at some point I got myself a Garmin watch. The year was 2012 and it was a Garmin Forerunner 410. It had a standard black/grey LCD screen, GPS (where getting a GPS lock could be utterly infuriatingly slow), a sensor you attached to your foot, a sensor you strap to your chest for Heart Rate monitoring, and an ANT+ dongle for connecting to a PC to download your activities. There was even some open source software that someone wrote so I could actually get data off my watch on my Linux laptops. This wasn’t a smart watch – it was exclusively for wearing while exercising and tracking an activity, otherwise it was just a watch.
However, as I was ramping up to marathon distance running, one huge flaw emerged: I was not fast enough to run a marathon in the time that the battery in my Garmin lasted. IIRC it would end up dying around 3hr30min into something, which at the time was increasingly something I’d describe as “not going for too long of a run”. So, the search for a replacement began!
The year was 2017, and the Garmin fenix 5x attracted me for two big reasons: a battery life to be respected, and turn-by-turn navigation. At the time, I seldom went running with a phone, preferring a tiny SanDisk media play (RIP, they made a new version that completely sucked) and a watch. The attraction of being able to get better maps back to where I started (e.g. a hotel in some strange city where I didn’t speak the language) was very appealing. It also had (what I would now describe as) rudimentary smart-watch features. It didn’t have even remotely everything the Pebble had, but it was enough.
So, a (non-trivial) pile of money later (even with discounts), I had myself a shiny and virtually indestructible new Garmin. I didn’t even need a dongle to sync it anywhere – it could just upload via its own WiFi connection, or through Bluetooth to the Garmin Connect app to my phone. I could also (if I ever remembered to), plug in the USB cable to it and download the activities to my computer.
One problem: my skin rebelled against the Garmin fenix 5x after a while. Like, properly rebelled. If it wasn’t coming off, I wanted to rip it off. I tried all of the tricks that are posted anywhere online. Didn’t help. I even got tested for what was the most likely culprit (a Nickel allergy), and didn’t have one of them, so I (still) have no idea what I’m actually allergic to in it. It’s just that I cannot wear it constantly. Urgh. I was enjoying the daily smart watch uses too!
So, that’s one rather expensive watch that is special purpose only, and even then started to get to be a bit of an issue around longer activities. Urgh.
So the hunt began for a smart watch that I could wear constantly. This usually ends in frustration as anything I wanted was hundreds of $ and pretty much nobody listed what materials were in it apart from “stainless steel”, “may contain”, and some disclaimer about “other materials”, which wasn’t a particularly useful starting point for “it is one of these things that my skin doesn’t like”. As at least if the next one also turned out to cause me problems, I could at least have a list of things that I could then narrow down to what I needed to avoid.
So that was all annoying, with the end result being that I went a long time without really wearing a watch. Why? The search resumed periodically and ended up either with nothing, or totally nothing. That was except if I wanted to get further into some vendor lock-in.
Honestly, the only manufacturer of anything smartwatch like which actually listed everything and had some options was Apple. Bizarre. Well, since I already got on the iPhone bandwagon, this was possible. Rather annoyingly, they are very tied together and thus it makes it a bit of a vendor-lock-in if you alternate phone and watch replacement and at any point wish to switch platforms.
That being said though, it does work well and not irritate my skin. So that’s a bonus! If I get back into marathon level distance running, we’ll see how well it goes. But for more common distances that I’ve run or cycled with it… the accuracy seems decent, HR monitor never just sometimes decides I’m not exerting myself, and the GPS actually gets a lock in reasonable time. Plus it can pair with headphones and be the only thing I take out with me.
A few random notes about things that can make life on macOS (the modern one, as in, circa 2023) better for those coming from Linux.
For various reasons you may end up with Mac hardware with macOS on the metal rather than Linux. This could be anything from battery life of the Apple Silicon machines (and not quite being ready to jump on the Asahi Linux bandwagon), to being able to run the corporate suite of Enterprise Software (arguably a bug more than a feature), to some other reason that is also fine.
My approach to most of my development is to have a remote more powerful Linux machine to do the heavy lifting, or do Linux development on Linux, and not bank on messing around with a bunch of software on macOS that would approximate something on Linux. This also means I can move my GUI environment (the Mac) easily forward without worrying about whatever weird workarounds I needed to do in order to get things going for whatever development work I’m doing, and vice-versa.
Terminal emulator? iTerm2. The built in Terminal.app is fine, but there’s more than a few nice things in iTerm2, including tmuxintegration which can end up making it feel a lot more like a regular Linux machine. I should probably go read the tmux integration best practices before I complain about some random bugs I think I’ve hit, so let’s pretend I did that and everything is perfect.
I tend to use the Mac for SSHing to bigger Linux machines for most of my work. At work, that’s mostly to a Graviton 2 EC2 Instance running Amazon Linux with all my development environments on it. At home, it’s mostly a Raptor Blackbird POWER9 system running Fedora.
Running Linux locally? For all the use cases of containers, Podman Desktop or finch. There’s a GUI part of Podman which is nice, and finch I know about because of the relatively nearby team that works on it, and its relationship to lima. Lima positions itself as WSL2-like but for Mac. There’s UTM for a full virtual machine / qemu environment, although I rarely end up using this and am more commonly using a container or just SSHing to a bigger Linux box.
There’s XCode for any macOS development that may be needed (e.g. when you want that extra feature in UTM or something) I do use Homebrew to install a few things locally.
Last week I had occasion to test deploying ceph-csi on a k3s cluster, so that Kubernetes workloads could access block storage provided by an external Ceph cluster. I went with the upstream Ceph documentation, because assuming everything worked it’d then be really easy for me to say to others “just go do this”.
Everything did not work.
I’d gone through all the instructions, inserting my own Ceph cluster’s FSID and MON IP addresses in the right places, applied the YAML to deploy the provisioner and node plugins, and all the provisioner bits were running just fine, but the csi-rbdplugin pods were stuck in CrashLoopBackOff:
The csi-rbdplugin pod consists of three containers – driver-registrar, csi-rbdplugin, liveness-prometheus – and csi-rbdplugin wasn’t able to load the rbd kernel module:
> kubectl logs csi-rbdplugin-22zjr --container csi-rbdplugin
I0726 10:25:12.862125 7628 cephcsi.go:199] Driver version: canary and Git version: d432421a88238a878a470d54cbf2c50f2e61cdda
I0726 10:25:12.862452 7628 cephcsi.go:231] Starting driver type: rbd with name: rbd.csi.ceph.com
I0726 10:25:12.865907 7628 mount_linux.go:284] Detected umount with safe 'not mounted' behavior
E0726 10:25:12.872477 7628 rbd_util.go:303] modprobe failed (an error (exit status 1) occurred while running modprobe args: [rbd]): "modprobe: ERROR: could not insert 'rbd': Key was rejected by service\n"
F0726 10:25:12.872702 7628 driver.go:150] an error (exit status 1) occurred while running modprobe args: [rbd]
Matching “modprobe: ERROR: could not insert ‘rbd’: Key was rejected by service” in the above was an error on each host’s console: “Loading of unsigned module is rejected”. These hosts all have secure boot enabled, so I figured it had to be something to do with that. So I logged into one of the hosts and ran modprobe rbd as root, but that worked just fine. No key errors, no unsigned module errors. And once I’d run modprobe rbd (and later modprobe nbd) on the host, the csi-rbdplugin container restarted and worked just fine.
So why wouldn’t modprobe work inside the container? /lib/modules from the host is mounted inside the container, the container has the right extra privileges… Clearly I needed to run a shell in the failing container to poke around inside when it was in CrashLoopBackOff state, but I realised I had no idea how to do that. I knew I could kubectl exec -it csi-rbdplugin-22zjr --container csi-rbdplugin -- /bin/bash but of course that only works if the container is actually running. My container wouldn’t even start because of that modprobe error.
Having previously spent a reasonable amount of time with podman, which has podman run, I wondered if there were a kubectl run that would let me start a new container using the upstream cephcsi image, but running a shell, instead of its default command. Happily, there is a kubectl run, so I tried it:
> kubectl run -it cephcsi --image=quay.io/cephcsi/cephcsi:canary --rm=true --command=true -- /bin/bash
If you don't see a command prompt, try pressing enter.
[root@cephcsi /]# modprobe rbd
modprobe: FATAL: Module rbd not found in directory /lib/modules/5.14.21-150400.24.66-default
[root@cephcsi /]# ls /lib/modules/
[root@cephcsi /]#
Ohhh, right, of course, that doesn’t have the host’s /lib/modules mounted. podman run lets me add volume mounts using -v options , so surely kubectl run will let me do that too.
At this point in the story, the notes I wrote last week include an awful lot of swearing.
See, kubectl run doesn’t have a -v option to add mounts, but what it does have is an --overrides option to let you add a chunk of JSON to override the generated pod. So I went back to the relevant YAML and teased out the bits I needed to come up with this monstrosity:
But at least I could get a shell and reproduce the problem:
> kubectl run -it cephcsi-test [honking great horrible chunk of JSON]
[root@cephcsi-test /]# ls /lib/modules/
5.14.21-150400.24.66-default
[root@cephcsi-test /]# modprobe rbd
modprobe: ERROR: could not insert 'rbd': Key was rejected by service
A certain amount more screwing around looking at the source for modprobe and bits of the kernel confirmed that the kernel really didn’t think the module was signed for some reason (mod_verify_sig() was returning -ENODATA), but I knew these modules were fine, because I could load them on the host. Eventually I hit on this:
[root@cephcsi-test /]# ls /lib/modules/*/kernel/drivers/block/rbd*
/lib/modules/5.14.21-150400.24.66-default/kernel/drivers/block/rbd.ko.zst
Wait, what’s that .zst extension? It turns out we (SUSE) have been shipping zstd-compressed kernel modules since – as best as I can tell – some time in 2021. modprobe on my SLE Micro 5.3 host of course supports this:
# grep PRETTY /etc/os-release
PRETTY_NAME="SUSE Linux Enterprise Micro for Rancher 5.3"
# modprobe --version
kmod version 29
+ZSTD +XZ +ZLIB +LIBCRYPTO -EXPERIMENTAL
modprobe in the CentOS Stream 8 upstream cephcsi container does not:
Mystery solved, but I have to say the error messages presented were spectacularly misleading. I later tried with secure boot disabled, and got something marginally better – in that case modprobe failed with “modprobe: ERROR: could not insert ‘rbd’: Exec format error”, and dmesg on the host gave me “Invalid ELF header magic: != \x7fELF”. If I’d seen messaging like that in the first place I might have been quicker to twig to the compression thing.
Anyway, the point of this post wasn’t to rant about inscrutable kernel errors, it was to rant about how there’s no way anyone could be reasonably expected to figure out how to do that --overrides thing with the JSON to debug a container stuck in CrashLoopBackOff. Assuming I couldn’t possibly be the first person to need to debug containers in this state, I told my story to some colleagues, a couple of whom said (approximately) “Oh, I edit the pod YAML and change the container’s command to tail -f /dev/null or sleep 1d. Then it starts up just fine and I can kubectl exec into it and mess around”. Those things totally work, and I wish I’d thought to do that myself. The best answer I got though was to use kubectl debug to make a copy of the existing pod but with the command changed. I didn’t even know kubectl debug existed, which I guess is my reward for not reading the entire manual
So, finally, here’s the right way to do what I was trying to do:
> kubectl debug csi-rbdplugin-22zjr -it \
--copy-to=csi-debug --container=csi-rbdplugin -- /bin/bash
[root@... /]# modprobe rbd
modprobe: ERROR: could not insert 'rbd': Key was rejected by service
(...do whatever other messing around you need to do, then...)
[root@... /]# exit
Session ended, resume using 'kubectl attach csi-debug -c csi-rbdplugin -i -t' command when the pod is running
> kubectl delete pod csi-debug
pod "csi-debug" deleted
In the above kubectl debug invocation, csi-rbdplugin-22zjr is the existing pod that’s stuck in CrashLoopBackOff, csi-debug is the name of the new pod being created, and csi-rbdplugin is the container in that pod that has its command replaced with /bin/bash, so you can mess around inside it.
It’s been a hot minute since my last open source status update! Let’s get caught up, and hopefully we can resume the monthly cadence from here.
Released Hanami 2.0
In Novemver we released Hanami 2.0.0! This was a huge milestone! Both for the Hanami project and the Ruby communuity, but also for us as a development team: we’d spent a long time in the wilderness.
All of this took some doing. It was a mad scramble to get here. The team and I worked non-stop over the preceding couple of months to get this release ready (including me during the mornings of a family trip to Perth).
Anyway, if you’ve followed me here for a while, most of the Hanami 2 features should hopefully feel familiar to you, but if you’d like a refresher, check out the Highlights of Hanami 2.0 that I wrote to accompany the release announcement.
Given I was 100% focused on Hanami dev work until the release, this is probably the least amount of time I’ve had for conference talk preparation, but I was happy with the result. I found a good hook (“new framework, new you�, given the new year approaching) and put together a streamlined introduction to Hanami that fit within the ~20 minutes alotted to the talks (in this case, it was a boon that we hadn’t yet released our view or persistence layers 😆).
Check it out here:
Overhauled hanami-view internals and improved performance
With the 2.0 release done, we decided to release our view and persistence layers progressively, as 2.1 and 2.2 respectively. This would allow us to keep our focus on one thing at a time and improve the timeliness of the upcoming releases.
So over the Christmas break (including several nights on a family trip to the coast), I started work on the first big blocker for our view layer: hanami-view performance. We were slower than Rails, and that just doesn’t cut the mustard for a framework that advertises itself as fast and light.
Finding the right approach here took several goes, and it was finally ready for this pull request at the end of February. I managed to find a >2x performance boost while simplifying our internals, improving the ergonomics of Hanami::View::Context and our part and scope builders, and still retaining all existing features.
Spoke at RubyConf Australia
Also in February, I spoke at RubyConf Australia 2023! After a 3 year hiatus, this was a wonderful reunion for the Ruby community across Australia and New Zealand. It looked like we lost no appetite for these events, so I’m encouraged for next year and beyond.
To fit the homecoming theme, I brought a strong tinge of Australiana to my talk, and expanded it to include a preview of the upcoming view and persistence layers. Check it out:
Created Hanami::View::ERB, a new ERB engine
After performance, the next big issue for hanami-view was having our particular needs met by our template rendering engines, as well as making auto-escaping the default for our “first party supported� engines (ERB, Haml, Slim) that output HTML.
ERB support was an interesting combination of all these issues. For hanami-view, we don’t expect any rendering engine to require explicit capturing of block content. This is what allows methods on parts and scopes simply to yield and have the returned value match content provided to the block from within the template.
To support this with ERB, we previously had to require our users install and use the erbse gem, a little-used and incomplete ERB implementation that provided this implicit block capturing behaviour by default (but did not support auto-escaping of HTML-unsafe values). For a long while we also had to require users use hamlit-block for the same reasons, and as such we had to build a compatibility check between ourselves and Tilt to ensure the right engines were available. This arrangement was awkward and untenable for the kind of developer experience we want for Hanami 2.
So to fix all of this, I wrote our own ERB engine! This provides everything we need from ERB (implicit block capture as well as auto-escaping) and also allows for hanami-view to be used out of the box without requiring manual installation of other gems.
Meanwhile, in the years since my formative work on hanami-view (aka dry-view), Haml and Slim evolved to both use Temple and provide configuration hooks for all the behaviour we require, so this allowed me to drop our template engine compatibility checks and instead just automatically configure Haml or Slim to match our needs if they’re installed.
To support our auto-escaping of HTML-unsafe values, we’ve adopted the Object and String#html_safe? patches that are prevalent across relevant libraries in the Ruby ecosystem. This gives us the broadest possible compatibility, as well as a streamlined and unsurprising user experience. While you might see folks decry monkey patches in general, this is one example where it makes sense for Hanami to take a pragmatic approach, and I’m very pleased with the outcome.
Implemented helpers for hanami-view
After performance and rendering/HTML safety, the last remaining pre-release item for hanami-view was support for helpers. This needed a bit of thinking to sort out, since the new hanami-view provides a significantly different set of view abstractions compared to the 1.x edition.
After this, all helpers should appear whereer you need them in your views, whether in templates, part classes or scope classes. Each slice will also generate a Views::Helpers module to serve as the starting point for your own collection of helpers, too.
With hanami-view providing parts and scopes, the idea is that you can and should use available-everywhere helpers less than before, but they can still be valuable from time to time, and with their introduction, now you have every possible option available for building your views.
Added friendly error pages
While focused on views, I also took the chance to make our error views friendly too. Now we:
Alongside all of this, Luca has been working hard on our support for front end assets via an esbuild plugin and its integration with the framework. This has been nothing short of heroic: he’s been beset by numerous roadblocks but overcome each one, and now we’re getting really close.
Back in June, Luca and I had our first ever pairing session on this work! We got a long way in just a couple of hours. I’m looking forward to pitching in with this as my next focus.
Prepared the Hanami 2.1.0.beta1 release
With all the views work largely squared away, I figured it was time to make a beta release and get this stuff out there for people to test, so we released it as 2.1.0.beta1 at the end of June.
Spoke at Brighton Ruby!
Also at the end of June I spoke at Brighton Ruby! I’ve wanted to attend this event for the longest time, and it did not disappoint. I had a wonderful day at the conference and enjoyed meeting a bunch of new Ruby friends.
For my talk I further evolved the content from the previous iterations, and this time included a look at how we might grow a Hanami app into a more real thing, as well as reflections on what Hanami 2’s release might mean for the Ruby community. I also experimented with a fun new theme and narrative device, which you shall be able to see once the video is out 😜
Thank you so much to Andy for the invitation and the support. ��
Took a holiday
After all of that, I took a break! You might’ve noticed my mentions of all the Hanami work I was doing while ostensibly on family trips. Well, after Brighton Ruby, I was all the way in Europe with the family, and made sure to have a good proper 4 weeks of (bonus summer) holiday. It was fanastic, and I didn’t look at Ruby code one bit.
What’s next
Now that I’m back, I’ll focus on doing whatever is necessary to complete our front end assets integration and get that out as a 2.1 beta2 release. Our new assets stuff is the completely new, so some time for testing and bug fixing will be useful.
Over the rest of the beta period I hope to complete a few smaller general framework improvements and fixes, and from there we can head towards 2.1.0 final.
I suspect it will take at least one more OSS status updates before that all happens, so I can check in with you about it all then!
The July 2023 meeting sparked multiple new topics including Linux security architecture, Debian ports of LoongArch and Risc-V as well as hardware design of PinePhone backplates.
On the practical side, Russell Coker demonstrated running different applications in isolated environment with bubblewrap sandbox, as well as other hardening techniques and the way they interact with the host system. Russell also discussed some possible pathways of hardening desktop Linux to reach the security level of modern Android. Yifei Zhan demonstrated sending and receiving messages with the PineDio USB LoRa adapter and how to inspect LoRa signal with off-the-shelf software defined radio receiver, and discussed how the driver situation for LoRa on Linux might be improved. Yifei then gave a demonstration on utilizing KVM on PinePhone Pro to run NetBSD and OpenBSD virtual machines, more details on running VMs on the PinePhone Pro can be found on this blog post from Yifei.
We also had some discussion of the current state of Mobian and Debian ecosystem, along with how to contribute to different parts of Mobian with a Mobian developer who joined us.
I’ve had a pretty varied experience with photo management on Linux over the past couple of decades. For a while I used f-spot as it was the new hotness. At some point this became…. slow and crashy enough that it was unusable. Today, it appears that the GitHub project warns that current bugs include “Not starting”.
At some point (and via a method I have long since forgotten), I did manage to finally get my photos over to Shotwell, which was the new hotness at the time. That data migration was so long ago now I actually forget what features I was missing from f-spot that I was grumbling about. I remember the import being annoying though. At some point in time Shotwell was no longer was the new hotness and now there is GNOME Photos. I remember looking at GNOME Photos, and seeing no method of importing photos from Shotwell, so put it aside. Hopefully that situation has improved somewhere.
At some point Shotwell was becoming rather stagnated, and I noticed more things stopping to work rather than getting added features and performance. The good news is that there has been some more development activity on Shotwell, so hopefully my issues with it end up being resolved.
One recommendation for Linux photo management was digiKam, and one that I never ended up using full time. One of the reasons behind that was that I couldn’t really see any non manual way to import photos from Shotwell into it.
With tens of thousands of photos (~58k at the time of writing), doing things manually didn’t seem like much fun at all.
As I postponed my decision, I ended up moving my main machine over to a Mac for a variety of random reasons, and one quite motivating thing was the ability to have Photos from my iPhone magically sync over to my photo library without having to plug it into my computer and copy things across.
So…. how to get photos across from Shotwell on Linux to Photos on a Mac/iPhone (and also keep a very keen eye on how to do it the other way around, because, well, vendor lock-in isn’t great).
It would be kind of neat if I could just run Shotwell on the Mac and have some kind of import button, but seeing as there wasn’t already a native Mac port, and that Shotwell is written in Vala rather than something I know has a working toolchain on macOS…. this seemed like more work than I’d really like to take on.
Luckily, I remembered that Shotwell’s database is actually just a SQLite database pointing to all the files on disk. So, if I could work out how to read it accurately, and how to import all the relevant metadata (such as what Albums a photo is in, tags, title, and description) into Apple Photos, I’d be able to make it work.
So… is there any useful documentation as to how the database is structured?
Semi annoyingly, Shotwell is written in Vala, a rather niche programming language that while integrating with all the GObject stuff that GNOME uses, is largely unheard of. Luckily, the database code in Shotwell isn’t too hard to read, so was a useful fallback for when the documentation proves inadequate.
Programming the Mac side of things, it was a good excuse to start looking at Swift, so knowing I’d also need to read a SQLite database directly (rather than use any higher level abstraction), I armed myself with the following resources:
From here, I could work on getting the first half going, the ability to view my Shotwell database on the Mac (which is what I posted a screenshot of back in Feb 2022).
But also, I had to work out what I was doing on the other end of things, how would I import photos? It turns out there’s an API!
A bit of SwiftUI code:
import SwiftUI
import AppKit
import Photos
struct ContentView: View {
@State var favorite_checked : Bool = false
@State var hidden_checked : Bool = false
var body: some View {
VStack() {
Text("Select a photo for import")
Toggle("Favorite", isOn: $favorite_checked)
Toggle("Hidden", isOn: $hidden_checked)
Button("Import Photo")
{
let panel = NSOpenPanel()
panel.allowsMultipleSelection = false
panel.canChooseDirectories = false
if panel.runModal() == .OK {
let photo_url = panel.url!
print("selected: " + String(photo_url.absoluteString))
addAsset(url: photo_url, isFavorite: favorite_checked, isHidden: hidden_checked)
}
}
.padding()
}
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
Combined with a bit of code to do the import (which does look a bunch like the examples in the docs):
import SwiftUI
import Photos
import AppKit
@main
struct SinglePhotoImporterApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
func addAsset(url: URL, isFavorite: Bool, isHidden: Bool) {
// Add the asset to the photo library.
let path = "/Users/stewart/Pictures/1970/01/01/1415446258647.jpg"
let url = URL(fileURLWithPath: path)
PHPhotoLibrary.shared().performChanges({
let addedImage = PHAssetChangeRequest.creationRequestForAssetFromImage(atFileURL: url)
addedImage?.isHidden = isHidden
addedImage?.isFavorite = isFavorite
}, completionHandler: {success, error in
if !success { print("Error creating the asset: \(String(describing: error))") } else
{
print("Imported!")
}
})
}
This all meant I could import a single photo. However, there were some limitations.
There’s the PHAssetCollectionChangeRequest to do things to Albums, so it would solve that problem, but I couldn’t for the life of me work out how to add/edit Titles and Descriptions.
It was so close!
So what did I need to do in order to import Titles and Descriptions? It turns out you can do that via AppleScript. Yes, that thing that launched in 1993 and has somehow survived the transition of m68k based Macs to PowerPC based Macs to Intel based Macs to ARM based Macs.
So, just to make it easier to debug what was going on, I started adding code to my ShotwellImporter tool that would generate snippets of AppleScript I could run and check that it was doing the right thing…. but then very quickly ran into a problem…. it appears that the AppleScript language interpreter on modern macOS has limits that you’d be more familiar with in 1993 than 2023, and I very quickly hit limits where the script would just error out before running (I was out of dictionary size allegedly).
But there’s a new option! Everything you can do with AppleScript you can now do with JavaScript – it’s just even less documented than AppleScript is! But it does work! I got to the point where I could generate JavaScript that imported photos, into all the relevant albums, and set title and descriptions.
In my last post, I wrote about how I taught sesdev (originally a tool for deploying Ceph clusters on virtual machines) to deploy k3s, because I wanted a little sandbox in which I could break learn more about Kubernetes. It’s nice to be able to do a toy deployment locally, on a bunch of VMs, on my own hardware, in my home office, rather than paying to do it on someone else’s computer. Given the k3s thing worked, I figured the next step was to teach sesdev how to deploy Longhorn so I could break that learn more about that too.
Install nfs-client, open-iscsi and e2fsprogs packages on all nodes.
Make an ext4 filesystem on /dev/vdb on all the nodes that have extra disks, then mount that on /var/lib/longhorn.
Use kubectl label node -l 'node-role.kubernetes.io/master!=true' node.longhorn.io/create-default-disk=true to ensure Longhorn does its storage thing only on the nodes that aren’t the k3s master.
Install Longhorn with Helm, because that will install the latest version by default vs. using kubectl where you always explicitly need to specify the version.
Create an ingress so the UI is exposed… from all nodes, via HTTP, with no authentication. Remember: this is a sandbox – please don’t do this sort of thing in production!
So, now I can do this:
> sesdev create k3s --deploy-longhorn
=== Creating deployment "k3s-longhorn" with the following configuration ===
Deployment-wide parameters (applicable to all VMs in deployment):
- deployment ID: k3s-longhorn
- number of VMs: 5
- version: k3s
- OS: tumbleweed
- public network: 10.20.78.0/24
Proceed with deployment (y=yes, n=no, d=show details) ? [y]: y
=== Running shell command ===
vagrant up --no-destroy-on-error --provision
Bringing machine 'master' up with 'libvirt' provider…
Bringing machine 'node1' up with 'libvirt' provider…
Bringing machine 'node2' up with 'libvirt' provider…
Bringing machine 'node3' up with 'libvirt' provider…
Bringing machine 'node4' up with 'libvirt' provider…
[... lots more log noise here - this takes several minutes... ]
=== Deployment Finished ===
You can login into the cluster with:
$ sesdev ssh k3s-longhorn
Longhorn will now be deploying, which may take some time.
After logging into the cluster, try these:
# kubectl get pods -n longhorn-system --watch
# kubectl get pods -n longhorn-system
The Longhorn UI will be accessible via any cluster IP address
(see the kubectl -n longhorn-system get ingress output above).
Note that no authentication is required.
…and, after another minute or two, I can access the Longhorn UI and try creating some volumes. There’s a brief period while the UI pod is still starting where it just says “404 page not found”, and later after the UI is up, there’s still other pods coming online, so on the Volume screen in the Longhorn UI an error appears: “failed to get the parameters: failed to get target node ID: cannot find a node that is ready and has the default engine image longhornio/longhorn-engine:v1.4.1 deployed“. Rest assured thisgoes away in due course (it’s not impossible I’m suffering here from rural Tasmanian internet lag pulling container images). Anyway, with my five nodes – four of which have an 8GB virtual disk for use by Longhorn – I end up with a bit less than 22GB storage available:
Now for the fun part. Longhorn is a distributed storage solution, so I thought it would be interesting to see how it handled a couple of types of failure. The following tests are somewhat arbitrary (I’m really just kicking the tyres randomly at this stage) but Longhorn did, I think, behave pretty well given what I did to it.
Volumes in Longhorn consist of replicas stored as sparse files on a regular filesystem on each storage node. The Longhorn documentation recommends using a dedicated disk rather than just having /var/lib/longhorn backed by the root filesystem, so that’s what sesdev does: /var/lib/longhorn is an ext4 filesystem mounted on /dev/vdb. Now, what happens to Longhorn if that underlying block device suffers some kind of horrible failure? To test that, I used the Longhorn UI to create a 2GB volume, then attached that to the master node:
Then, I ssh’d to the master node and with my 2GB Longhorn volume attached, made a filesystem on it and created a little file:
> sesdev ssh k3s-longhorn
Have a lot of fun...
master:~ # cat /proc/partitions
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
8 0 2097152 sda
master:~ # mkfs /dev/sda
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: 3709b21c-b9a2-41c1-a6dd-e449bdeb275b
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
master:~ # mount /dev/sda /mnt
master:~ # echo foo > /mnt/foo
master:~ # cat /mnt/foo
foo
Then I went and trashed the block device backing one of the replicas:
> sesdev ssh k3s-longhorn node3
Have a lot of fun...
node3:~ # ls /var/lib/longhorn
engine-binaries longhorn-disk.cfg lost+found replicas unix-domain-socket
node3:~ # dd if=/dev/urandom of=/dev/vdb bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.486205 s, 216 MB/s
node3:~ # ls /var/lib/longhorn
node3:~ # dmesg|tail -n1
[ 6544.197183] EXT4-fs error (device vdb): ext4_map_blocks:607: inode #393220: block 1607168: comm longhorn: lblock 0 mapped to illegal pblock 1607168 (length 1)
At this point, the Longhorn UI still showed the volume as green (healthy, ready, scheduled). Then, back on the master node, I tried creating another file:
master:~ # echo bar > /mnt/bar
master:~ # cat /mnt/bar
bar
That’s fine so far, but suddenly the Longhorn UI noticed that something very bad had happened:
Ultimately node3 was rebooted and ended up stalled with the console requesting the root password for maintenance:
Meanwhile, Longhorn went and rebuilt a third replica on node2:
…and the volume remained usable the entire time:
master:~ # echo baz > /mnt/baz
master:~ # ls /mnt
bar baz foo lost+found
That’s perfect!
Looking at the Node screen we could see that node3 was still down:
That’s OK, I was able to fix node3. I logged in on the console and ran mkfs.ext4 /dev/vdb then brought the node back up again.The disk remained unschedulable, because Longhorn was still expecting the ‘old’ disk to be there (I assume based on the UUID stored in /var/lib/longhorn/longhorn-disk.cfg) and of course the ‘new’ disk is empty. So I used the Longhorn UI to disable scheduling for that ‘old’ disk, then deleted it. Shortly after, Longhorn recognised the ‘new’ disk mounted at /var/lib/longhorn and everything was back to green across the board.
So Longhorn recovered well from the backing store of one replica going bad. Next I thought I’d try to break it from the other end by running a volume out of space. What follows is possibly not a fair test, because what I did was create a single Longhorn volume larger than the underlying disks, then filled that up. In normal usage, I assume one would ensure there’s plenty of backing storage available to service multiple volumes, that individual volumes wouldn’t generally be expected to get more than a certain percentage full, and that some sort of monitoring and/or alerting would be in place to warn of disk pressure.
With four nodes, each with a single 8GB disk, and Longhorn apparently reserving 2.33GB by default on each disk, that means no Longhorn volume can physically store more than a bit over 5.5GB of data (see the Size column in the previous screenshot). Given that the default setting for Storage Over Provisioning Percentage is 200, we’re actually allowed to allocate up to a bit under 11GB.
So I went and created a 10GB volume, attached that to the master node, created a filesystem on it, and wrote a whole lot of zeros to it:
…there was a lot of unpleasantness on the master node’s console…
…the replicas became unschedulable due to lack of space…
…and finally the volume faulted:
Now what?
It turns out that Longhorn will actually recover if we’re able to somehow expand the disks that store the replicas. This is probably a good argument for backing Longhorn with an LVM volume on each node in real world deployments, because then you could just add another disk and extend the volume onto it. In my case though, given it’s all VMs and virtual block devices, I can actually just enlarge those devices. For each node then, I:
Shut it down
Ran qemu-img resize /var/lib/libvirt/images/k3s-longhorn_$NODE-vdb.qcow2 +8G
Started it back up again and ran resize2fs /dev/vdb to take advantage of the extra disk space.
After doing that to node1, Longhorn realised there was enough space there and brought node1’s replica of my 10GB volume back online. It also summarily discarded the other two replicas from the still-full disks on node2 and node3, which didn’t yet have enough free space to be useful:
As I repeated the virtual disk expansion on the other nodes, Longhorn happily went off and recreated the missing replicas:
Finally I could re-attach the volume to the master node, and have a look to see how many of my zeros were actually written to the volume:
master:~ # cat /proc/partitions
major minor #blocks name
254 0 44040192 vda
254 1 2048 vda1
254 2 20480 vda2
254 3 44016623 vda3
8 0 10485760 sda
master:~ # mount /dev/sda /mnt
master:~ # ls -l /mnt
total 7839764
-rw-r--r-- 1 root root 8027897856 May 3 04:41 big-lot-of-zeros
drwx------ 2 root root 16384 May 3 04:34 lost+found
Recall that dd claimed to have written 9039773696 bytes before it stalled when the volume faulted, so I guess that last gigabyte of zeros is lost in the aether. But, recall also that this isn’t really a fair test – one overprovisioned volume deliberately being quickly and deliberately filled to breaking point vs. a production deployment with (presumably) multiple volumes that don’t fill quite so fast, and where one is hopefully paying at least a little bit of attention to disk pressure as time goes by.
It’s worth noting that in a situation where there are multiple Longhorn volumes, assuming one disk or LVM volume per node, the replicas will all share the same underlying disks, and once those disks are full it seems all the Longhorn volumes backed by them will fault. Given multiple Longhorn volumes, one solution – rather than expanding the underlying disks – is simply to delete a volume or two if you can stand to lose the data, or maybe delete some snapshots (I didn’t try the latter yet). Once there’s enough free space, the remaining volumes will come back online. If you’re really worried about this failure mode, you could always just disable overprovisioning in the first place – whether this makes sense or not will really depend on your workloads and their data usage patterns.
All in all, like I said earlier, I think Longhorn behaved pretty well given what I did to it. Some more information in the event log could perhaps be beneficial though. In the UI I can see warnings from longhorn-node-controller e.g. “the disk default-disk-1cdbc4e904539d26(/var/lib/longhorn/) on the node node1 has 3879731200 available, but requires reserved 2505089433, minimal 25% to schedule more replicas” and warnings from longhorn-engine-controller e.g. “Detected replica overprovisioned-r-73d18ad6 (10.42.3.19:10000) in error“, but I couldn’t find anything really obvious like “Dude, your disks are totally full!”
Later, I found more detail in the engine manager logs after generating a support bundle ([…] level=error msg=”I/O error” error=”tcp://10.42.4.34:10000: write /host/var/lib/longhorn/replicas/overprovisioned-c3b9b547/volume-head-003.img: no space left on device”) so the error information is available – maybe it’s just a matter of learning where to look for it.
We – that is to say the storage team at SUSE – have a tool we’ve been using for the past few years to help with development and testing of Ceph on SUSE Linux. It’s called sesdev because it was created largely for SES (SUSE Enterprise Storage) development. It’s essentially a wrapper around vagrant and libvirt that will spin up clusters of VMs running openSUSE or SLES, then deploy Ceph on them. You would never use such clusters in production, but it’s really nice to be able to easily spin up a cluster for testing purposes that behaves something like a real cluster would, then throw it away when you’re done.
I’ve recently been trying to spend more time playing with Kubernetes, which means I wanted to be able to spin up clusters of VMs running openSUSE or SLES, then deploy Kubernetes on them, then throw the clusters away when I was done, or when I broke something horribly and wanted to start over. Yes, I know there’s a bunch of other tools for doing toy Kubernetes deployments (minikube comes to mind), but given I already had sesdev and was pretty familiar with it, I thought it’d be worthwhile seeing if I could teach it to deploy k3s, a particularly lightweight version of Kubernetes. Turns out that wasn’t too difficult, so now I can do this:
> sesdev create k3s
=== Creating deployment "k3s" with the following configuration ===
Deployment-wide parameters (applicable to all VMs in deployment):
deployment ID: k3s
number of VMs: 5
version: k3s
OS: tumbleweed
public network: 10.20.190.0/24
Proceed with deployment (y=yes, n=no, d=show details) ? [y]: y
=== Running shell command ===
vagrant up --no-destroy-on-error --provision
Bringing machine 'master' up with 'libvirt' provider...
Bringing machine 'node1' up with 'libvirt' provider...
Bringing machine 'node2' up with 'libvirt' provider...
Bringing machine 'node3' up with 'libvirt' provider...
Bringing machine 'node4' up with 'libvirt' provider...
[...wait a few minutes(there's lots more log information output here in real life)
...]
=== Deployment Finished ===
You can login into the cluster with:
$ sesdev ssh k3s
…and then I can do this:
> sesdev ssh k3s
Last login: Fri Mar 24 11:50:15 CET 2023 from 10.20.190.204 on ssh
Have a lot of fun…
master:~ # kubectl get nodes
NAME STATUS ROLES AGE VERSION
master Ready control-plane,master 5m16s v1.25.7+k3s1
node2 Ready 2m17s v1.25.7+k3s1
node1 Ready 2m15s v1.25.7+k3s1
node3 Ready 2m16s v1.25.7+k3s1
node4 Ready 2m16s v1.25.7+k3s1
master:~ # kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system local-path-provisioner-79f67d76f8-rpj4d 1/1 Running 0 5m9s
kube-system metrics-server-5f9f776df5-rsqhb 1/1 Running 0 5m9s
kube-system coredns-597584b69b-xh4p7 1/1 Running 0 5m9s
kube-system helm-install-traefik-crd-zz2ld 0/1 Completed 0 5m10s
kube-system helm-install-traefik-ckdsr 0/1 Completed 1 5m10s
kube-system svclb-traefik-952808e4-5txd7 2/2 Running 0 3m55s
kube-system traefik-66c46d954f-pgnv8 1/1 Running 0 3m55s
kube-system svclb-traefik-952808e4-dkkp6 2/2 Running 0 2m25s
kube-system svclb-traefik-952808e4-7wk6l 2/2 Running 0 2m13s
kube-system svclb-traefik-952808e4-chmbx 2/2 Running 0 2m14s
kube-system svclb-traefik-952808e4-k7hrw 2/2 Running 0 2m14s
…and then I can make a mess with kubectl apply, helm, etc.
One thing that sesdev knows how to do is deploy VMs with extra virtual disks. This functionality is there for Ceph deployments, but there’s no reason we can’t turn it on when deploying k3s:
> sesdev create k3s --num-disks=2
> sesdev ssh k3s
master:~ # for node in \
$(kubectl get nodes -o 'jsonpath={.items[*].metadata.name}') ;
do echo $node ; ssh $node cat /proc/partitions ; done
master
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
node3
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
253 16 8388608 vdb
253 32 8388608 vdc
node2
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
253 16 8388608 vdb
253 32 8388608 vdc
node4
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
253 16 8388608 vdb
253 32 8388608 vdc
node1
major minor #blocks name
253 0 44040192 vda
253 1 2048 vda1
253 2 20480 vda2
253 3 44016623 vda3
253 16 8388608 vdb
253 32 8388608 vdc
As you can see this gives all the worker nodes an extra two 8GB virtual disks. I suspect this may make sesdev an interesting tool for testing other Kubernetes based storage systems such as Longhorn, but I haven’t tried that yet.
I recently bought an
Energica
Experia - the latest, largest and longest distance of Energica's
electric motorbike models.
The decision to do this rather than build my own was complicated, and I'm
going to mostly skip over the detail of that. At some time I might put it in
another blog post. But for now it's enough to say that I'd accidentally
cooked the motor in my Mark I, the work on the Mark II was going to take ages,
and I was in the relatively fortunate situation of being able to afford the
Experia if I sold my existing Triumph Tiger Sport and the parts for the Mark
II.
For other complicated reasons I was planning to be in Sydney after the weekend
that Bruce at Zen Motorcycles told
me the bike would be arriving. Rather than have it freighted down, and since
I would have room for my riding gear in our car, I decided to pick it up and
ride it back on the Monday. In reconnoitering the route, we discovered that
by pure coincidence Zen Motorcycles is on Euston Road in Alexandria, only
200 metres away from the entrance to WestConnex and the M8. So with one
traffic light I could be out of Sydney.
I will admit to being more than a little excited that morning. Electric
vehicles are still, in 2023, a rare enough commodity that waiting lists can be
months long; I ordered this bike in October 2022 and it arrived in March 2023.
So I'd had plenty of time to build my expectations. And likewise the thought
of riding a brand new bike - literally one of the first of its kind in the
country (it is the thirty-second Experia ever made!) - was a little daunting.
I obtained PDF copies of the manual and familiarised myself with turning the
cruise control on and off, as well as checking and setting the regen braking
levels. Didn't want to stuff anything up on the way home.
There is that weird feeling in those situations of things being both very
ordinary and completely unique. I met Bruce, we chatted, I saw the other
Experia models in the store, met Ed - who had come down to chat with Bruce,
and just happened to be the guy who rode a Harley Davidson Livewire from
Perth to Sydney and then from Sydney to Cape Tribulation and back. He shared
stories from his trip and tips on hypermiling. I signed paperwork, picked up
the keys, put on my gear, prepared myself.
Even now I still get a bit choked up just thinking of that moment. Seeing
that bike there, physically real, in front of me - after those months of
anticipation - made the excitement real as well.
So finally, after making sure I wasn't floating, and making sure I had my
ear plugs in and helmet on the right way round, I got on. Felt the bike's
weight. Turned it on. Prepared myself. Took off. My partner followed
behind, through the lights, onto the M8 toward Canberra. I gave her the
thumbs up.
We planned to stop for lunch at Mittagong, while the NRMA still offers the
free charger at the RSL there. One lady was charging her Nissan Leaf on the
ChaDeMo side; shortly after I plugged in a guy arrived in his Volvo XC40
Recharge. He had the bigger battery and would take longer; I just needed a
ten minute top up to get me to Marulan.
I got to Marulan and plugged in; a guy came thinking he needed to tell the
petrol motorbike not to park in the electric vehicle bay, but then realised
that the plug was going into my bike. Kate headed off, having charged up as
well, and I waited another ten minutes or so to get a bit more charge. Then
I rode back.
I stopped, only once more - at Mac's Reef Road. I turned off and did a U
turn, then waited for the traffic to clear before trying the bike's
acceleration. Believe me when I say this bike will absolutely do a 0-100km/hr
in under four seconds! It is not a light bike, but when you pull on the power
it gets up and goes.
Here is my basic review, given that experience and then having ridden it for
about ten weeks around town.
The absolute best feature of the Energica Experia is that it is perfectly
comfortable riding around town. Ease on the throttle and it gently takes off
at the traffic lights and keeps pace with the traffic. Ease off, and it
gently comes to rest with regenerative braking and a light touch on the rear
brake after stopping to hold it still. If you want to take off faster, wind
the throttle on more. It is not temperamental or twitchy, and you have no
annoying gears and clutch to balance.
In fact, I feel much more confident lane filtering, because before I would
have to have the clutch ready and be prepared to give the Tiger Sport lots of
throttle lest I accidentally stall it in front of an irate line of traffic.
With the Experia, I can simply wait peacefully - using no power - and then
when the light goes green I simply twist on the throttle and I am away ahead
of even the most aggressive car driver.
It is amazingly empowering.
I'm not going to bore you with the stats - you can probably look them up
yourself if you care. The main thing to me is that it has DC fast charging,
and watching 75KW go into a 22.5KWHr battery is just a little bit terrifying
as well as incredibly cool. The stated range of 250km on a charge at highway
speeds is absolutely correct, from my experience riding it down from Sydney.
And that plus the fast charging means that I think it is going to be quite
reasonable to tour on this bike, stopping off at fast or even mid-level
chargers - even a boring 22KW charger can fill the battery up in an hour.
The touring group I travel with stops often enough that if those stops can be
top ups, I will not hold anyone up.
Some time in the near future I hope to have a nice fine day where I can take
it out on the Cotter Loop. This is an 80km stretch of road that goes west of
Canberra into the foothills of the Brindabella Ranges, out past the Deep
Space Tracking Station and Tidbinbilla Nature Reserve. It's a great
combination of curving country roads and hilly terrain, and reasonably well
maintained as well. I did that on the Tiger Sport, with a GoPro, before I
sold it - and if I can ever convince PiTiVi to actually compile the video
from it I will put that hour's ride up on a platform somewhere.
I want to do that as much to show off Canberra's scenery as to show off the
bike.
And if the CATL battery capacity improvement comes through to the rest of the
industry, and we get bikes that can do 400km to 500km on a charge, then
electric motorbike touring really will be no different to petrol motorbike
touring. The Experia is definitely at the forefront of that change, but it
is definitely possible on this bike.
Rustup (the community package manage for the Rust language) was starting to really suffer : CI times were up at ~ one hour.
We’ve made some strides in bringing this down.
Caching factory for test scenarios
The first thing, which achieved about a 30% reduction in test time was to stop recreating all the test context every time.
Rustup tests the download/installation/upgrade of distributions of Rust. To avoid downloading gigabytes in the test suite, the suite creates mocks of the published Rust artifacts. These mocks are GPG signed and compressed with multiple compression methods, both of which are quite heavyweight operations to perform – and not actually the interesting code under test to execute.
Previously, every test was entirely hermetic, and usually the server state was also unmodified.
There were two cases where the state was modified. One, a small number of tests testing error conditions such as GPG signature failures. And two, quite a number of tests that were testing temporal behaviour: for instance, install nightly at time A, then with a newer server state, perform a rustup update and check a new version is downloaded and installed.
We’re partway through this migration, but compare these two tests:
The former version mutates the date with set_current_dist_date; the new version uses two scenarios, one for the earlier time, and one for the later time. This permits the server state to be constructed only once. On a per-test basis it can move as much as 50% of the time out of the test.
Single binary for the integration test suite
The next major gain was moving from having 14 separate integration test binaries to just one. This reduces the link cost of linking the test binaries, all of which link in the same library. It also permits us to see unused functions in our test support library, which helps with cleaning up cruft rather than having it accumulate.
Hard linking rather than copying ‘rustup-init’
Part of the test suite for each test is setting up an installed rustup environment. Why not start from scratch every time? Well, we obviously have tests that do that, but most tests are focused on steps beyond the new-user case. Setting up an installed rustup environment has a few steps, but particular ones are copying a binary of rustup into the test sandbox, and hard linking it under various names: cargo, rustc, rustup etc.
A debug build of rustup is ~20MB. Running 400 tests means about 8GB of IO; on some platforms most of that IO won’t hit disk, on others it will.
In review now is a PR that changes the initial copy to a hardlink: we hardlink the rustup-init built by cargo into each test, and then hardlink that to the various binaries. That saves 8GB of IO, which isn’t much from some perspectives, but it adds pressure on the page cache, and is wasted work. One wrinkle is a very low max-links limit on NTFS of 1023; to mitigate that we count the links made to rustup-init and generate a new inode for the original to avoid failures happening.
Future work
In GitHub actions this lowers our test time to 19m for Linux, 24m for Windows, which is a lot better but not great.
I plan on experimenting with separate actions for building release artifacts and doing CI tests – at the moment we have the same action do both, but they don’t share artifacts in the cache in any meaningful way, so we can probably gain parallelism there, as well as turning off release builds entirely for CI.
We should finish the cached test context work and use it everywhere.
Also we’re looking at having less integration tests and more narrow close to the code tests.
Back in 2012, I received a box of eight hundred openSUSE 12.1 promo DVDs, which I then set out to distribute to local Linux users’ groups, tech conferences, other SUSE crew in Australia, and so forth. I didn’t manage to shift all 800 DVDs at the time, and I recently rediscovered the remaining three hundred and eighty four while installing some new shelves. As openSUSE 12.1 went end of life in May 2013, it seemed likely the DVDs were now useless, but I couldn’t bring myself to toss them in landfill. Instead, given last week was Hack Week, I decided to use them for an art project. Here’s the end result:
Making that mosaic was extremely fiddly. It’s possibly the most annoying Hack Week project I’ve ever done, but I’m very happy with the outcome
The backing is a piece of 900mm x 600mm x 6mm plywood, primed with some leftover kitchen and bathroom undercoat, then spray pained black. I’d forgotten how bad spray paint smells, but it makes for a nice finish. To get the Geeko shape, I took the official openSUSE logo, then turned it into an outline in Inkscape, saved that as a PNG, opened it in GIMP, and cut it into nine 300mm x 200mm pieces which I then printed on A4 paper, stuck together with tape, and cut out to make a stencil. Of course, the first time I did that, nothing quite lined up, so I had to reprint it but with “Ignore page margins” turned off and “Draw crop marks” turned on, then cut the pages down along the crop marks before sticking them together the second time. Then I placed the stencil on the backing, glued the eye down (that just had to be made from the centre of a DVD!) and started laying out cut up DVD shards.
I initially tried cutting the DVDs with tin snips, which is easy on the hands, but had a tendency to sometimes warp the DVD pieces and/or cause them to delaminate, so I reverted to a large pair of scissors which was more effort but ultimately less problematic.
After placing the pieces that made up the head, tail, feet and spine, and deciding I was happy with how they looked, I glued each piece down with superglue. Think: carefully pick up DVD shard without moving too many other shards, turn over, dab on a few tiny globs of superglue, lower into place, press for a few seconds, move to next piece. Do not get any superglue on your fingers, or you’ll risk sticking your fingers together and/or make a gluey mess on the shiny visible side of the DVD shards.
It was another three sessions of layout-then-glue-down to fill in the body. I think I stuck my fingers together about six, or eight, or maybe twenty times. Also, despite my best efforts to get superglue absolutely nowhere near the stencil at all, when I removed the stencil, it had stuck to the backing in several places. I managed to scrape/cut that off with a combination of fingernails, tweezers, and the very sharp knife in my SLE 12 commemorative Leatherman tool, then touched up the remaining white bits with a fine point black Sharpie.
Judging from the leftover DVD centre pieces, this mosaic used about 12 DVDs in all, which isn’t very many considering my initial stash. I had a few other ideas for the remainder, mostly involving hanging them up somehow, which I messed around with earlier on while waiting for the paint to dry on the plywood.
One (failed) idea was to use a cutting wheel on my Dremel tool to slice half way through a few DVDs, then slot them into each other to make a hanging thingy that would spin in the wind. I was unable to make a smooth/straight enough cut for this to work, and superglue doesn’t bridge gaps. You can maybe get an idea of what I was aiming at from this photo:
My wife had an idea for a better way to do this, which is to take a piece of dowel, cut slots in the sides, and glue DVD halves into the slots using Araldite (that’s an epoxy resin, in case you didn’t grow up with that brand name). I didn’t get around to trying this, but I reckon she’s onto something. Next time I’m at the hardware store, I’ll try to remember to pick up some suitably sized dowel.
I did make one somewhat simpler hanging thingy, which I call “Geeko’s Tail (Uncurled)”. It’s just DVDs superglued together on the flat, hanging from fishing line, but I think it’s kinda cool:
Also, I’ve discovered that Officeworks has an e-waste recycling program, so any DVDs I don’t use in future projects needn’t go to landfill.
I have long said “Long Malaysians, Short Malaysia” in conversation to many. Maybe it took me a while to tweet it, but this was the first example: Dec 29, 2021. I’ve tweeted it a lot more since.
Malaysia has a 10th Prime Minister, but in general, it is a very precarious partnership. Consider it, same shit, different day?
5/n: Otherwise, there will be no change.
So change via “purported democracy” is never going to happen with a country like Malaysia, rotten to the core. It is a crazy dream.
I just have to get off the Malaysian news diet. Malaysians elsewhere, are generally very successful. Malaysians suffering by their daily doldrums, well, they just need to wake up, see the light, and succeed.
In the end, as much as people paraphrase, ask not what the country can do for you, legitimately, this is your life, and you should be taking good care of yourself and your loved ones. You succeed, despite of. Politics and the state happens, regardless of.
Me, personally? Ideas are abound for how to get Malaysians who see the light, to succeed elsewhere. And if I read, and get angry at something (tweet rage?), I’m going to pop RM50 into an investment account, which should help me get off this poor habit. I’ll probably also just cut subscriptions to Malaysian news things… Less exposure, is actually better for you. I can’t believe that it has taken me this long to realise this.
I did poorly blogging last year. Oops. I think to myself when I read, This Thing Still On?, I really have to do better in 2023. Maybe the catalyst is the fact that Twitter is becoming a shit show. I doubt people will leave the platform in droves, per se, but I think we are coming back to the need for decentralised blogs again.
I have 477 days to becoming 40. I ditched the Hobonich Techo sometime in 2022, and just focused on the Field Notes, and this year, I’ve got a Monocle x Leuchtturm1917 + Field Notes combo (though it seems my subscription lapsed Winter 2022, I should really burn down the existing collection, and resubscribe).
2022 was pretty amazing. Lots of work. Lots of fun. 256 days on the road (what a number), 339,551km travelled, 49 cities, 20 countries.
The getting back into doing, and not being afraid of experimenting in public is what 2023 is all about. The Year of The Rabbit is upon us tomorrow, hence why I don’t mind a little later Hello 2023 :)
Get back into the habit of doing. And publishing by learning and doing. No fear. Not that I wasn’t doing, but its time to be prolific with what’s been going on.
I like using Catalyst Cloud to host some of my personal sites. In the past I used to use CAcert for my TLS certificates, but more recently I've been using Let's Encrypt for my TLS certificates as they're trusted in all browsers. Currently the LoadBalancer as a Service (LBaaS) in Catalyst Cloud doesn't have built in support for Let's Encrypt. I could use an apache2/nginx proxy and handle the TLS termination there and have that manage the Let's Encrypt lifecycle, but really, I'd rather use LBaaS.
So I thought I'd set about working out how to get Dehydrated (the Let's Encrypt client I've been using) to drive LBaaS (known as Octavia). I figured this would be of interest to other people using Octavia with OpenStack in general, not just Catalyst Cloud.
There's a few things you need to do. These instructions are specific to Debian:
Install and configure Dehydrated to create the certificates for the domain(s) you want.
apt install barbican
Create the LoadBalancer (use the API, ClickOps, whatever), just forward port 80 for now (see sample Apache configs below).
Save the sample hook.sh below to /etc/dehydrated/hook.sh, you'll probably need to customise it, mine is a bit more complicated!
Insert the UUID of your LoadBalancer in hook.sh where LB_LISTENER is set.
Create /etc/dehydrated/catalystcloud/password as described in hook.sh
Save OpenRC file from the Catalyst Cloud dashboard as /etc/dehydrated/catalystcloud/openrc.sh
Install jq, openssl and the openstack tools, on Debian this is:
You should be able to rename the latest certs /var/lib/dehydrated/certs/$DOMAIN and then run dehydrated -c to have it reissue and then deploy a cert.
As we're using HTTP-01 Challenge Type here, you need to have the LoadBalancer forwarding port 80 to your website to allow for the challenge response. It is good practice to have a redirect to HTTPS, here's an example virtual host for Apache:
You all also need this in /etc/apache2/conf-enabled/letsencrypt.conf:
Alias /.well-known/acme-challenge /var/lib/dehydrated/acme-challenges
<Directory /var/lib/dehydrated/acme-challenges>
Options None
AllowOverride None
# Apache 2.x
<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>
# Apache 2.4
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
</Directory>
And that should be all that you need to do. Now, when Dehydrated updates your certificate, it should update your LoadBalancer as well!
Sample hook.sh:
deploy_cert() {
local DOMAIN="${1}" KEYFILE="${2}" CERTFILE="${3}" FULLCHAINFILE="${4}" \
CHAINFILE="${5}" TIMESTAMP="${6}"
shift 6
# File contents should be:
# export OS_PASSWORD='your password in here'
. /etc/dehydrated/catalystcloud/password
# OpenRC file from the Catalyst Cloud dashboard
. /etc/dehydrated/catalystcloud/openrc.sh --no-token
# UUID of the LoadBalancer to be managed
LB_LISTENER='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# Barbican uses P12 files, we need to make one.
P12=$(readlink -f $KEYFILE \
| sed -E 's/privkey-([0-9]+)\.pem/barbican-\1.p12/')
openssl pkcs12 -export -inkey $KEYFILE -in $CERTFILE -certfile \
$FULLCHAINFILE -passout pass: -out $P12
# Keep track of existing certs for this domain (hopefully no more than 100)
EXISTING_URIS=$(openstack secret list --limit 100 \
-c Name -c 'Secret href' -f json \
| jq -r ".[]|select(.Name | startswith(\"$DOMAIN\"))|.\"Secret href\"")
# Upload the new cert
NOW=$(date +"%s")
openstack secret store --name $DOMAIN-$TIMESTAMP-$NOW -e base64 \
-t "application/octet-stream" --payload="$(base64 < $P12)"
NEW_URI=$(openstack secret list --name $DOMAIN-$TIMESTAMP-$NOW \
-c 'Secret href' -f value) \
|| unset NEW_URI
# Change LoadBalancer to use new cert - if the old one was the default,
# change the default. If the old one was in the SNI list, update the
# SNI list.
if [ -n "$EXISTING_URIS" ]; then
DEFAULT_CONTAINER=$(openstack loadbalancer listener show $LB_LISTENER \
-c default_tls_container_ref -f value)
for URI in $EXISTING_URIS; do
if [ "x$URI" = "x$DEFAULT_CONTAINER" ]; then
openstack loadbalancer listener set $LB_LISTENER \
--default-tls-container-ref $NEW_URI
fi
done
SNI_CONTAINERS=$(openstack loadbalancer listener show $LB_LISTENER \
-c sni_container_refs -f value | sed "s/'//g" | sed 's/^\[//' \
| sed 's/\]$//' | sed "s/,//g")
for URI in $EXISTING_URIS; do
if echo $SNI_CONTAINERS | grep -q $URI; then
SNI_CONTAINERS=$(echo $SNI_CONTAINERS | sed "s,$URI,$NEW_URI,")
openstack loadbalancer listener set $LB_LISTENER \
--sni-container-refs $SNI_CONTAINERS
fi
done
# Remove old certs
for URI in $EXISTING_URIS; do
openstack secret delete $URI
done
fi
}
HANDLER="$1"; shift
#if [[ "${HANDLER}" =~ ^(deploy_challenge|clean_challenge|sync_cert|deploy_cert|deploy_ocsp|unchanged_cert|invalid_challenge|request_failure|generate_csr|startup_hook|exit_hook)$ ]]; then
if [[ "${HANDLER}" =~ ^(deploy_cert)$ ]]; then
"$HANDLER" "$@"
fi
Hello there, friends! This is going to be a short update from me because I’m deep in the throes of Hanami 2.0 release preparation right now. Even still, I didn’t want to let September pass without an update, so let’s take a look.
A story about Hanami::Action memory usage
September started and ended with me looking at the r10k memory usage charts for hanami-controller versus Rails. The results were surprising!
We’d been running some of these checks as part of our 2.0 release prep, the idea being that it’d help us shake out any obvious performance improvements we’d need to make. And it certainly did in this case! Hanami (just like its dry-rb underpinnings) is meant to be the smaller and lighter framework; why were we being outperformced by Rails?
To address this I wrote a simple memory profile script for Hanami::Action inheritance (now checked in here) and started digging.
Total allocated: 184912288 bytes (1360036 objects)
Total retained: 104910880 bytes (780031 objects)
allocated memory by gem
-----------------------------------
56242240 concurrent-ruby-1.1.10
53282480 dry-configurable-0.15.0
34120000 utils-8585be837309
30547488 other
10720080 controller/lib
That’s 185MB allocated for 10k subclasses, with concurrent-ruby, dry-configurable and hanami-utils being the top three gems allocating memory.
This led me straight to dry-configurable, and after a couple of weeks of work, I arrived at this PR, separating our storage of setting definitions from their configured values, among other things. This change allows us to copy less data at the moment of class inheritance, and in the case of a dry-configurable-focused memory profile, cut the allocated memory by more than half.
Total allocated: 32766232 bytes (90004 objects)
Total retained: 32766232 bytes (90004 objects)
allocated memory by gem
-----------------------------------
21486072 other
10880120 dry-configurable-0.16.1
400040 3.1.2/lib
Yes, we brought 185MB allocated memory down to 33MB! This also brought us on par with Rails in the extreme end of the r10k memory usage benchmark:
Here’s a thing though: the way r10k generates actions for its Rails benchmark is to create a single controller class with a method per action. So for the point on the far right of that chart, that’s a single class with 10k methods. Hardly realistic.
So I made a quick tweak to see how things would look if the r10k Rails benchmark generated a class per endpoint like we do with Hanami::Action:
That’s more like it. This is another extreme, however: more realistically, we’d see Rails apps with somewhere between 5-10 actions per controller class, which would lower its dot a little in that graph. In my opinion this would be a useful thing to upstream into r10k. It’s already a contrived benchmark, yes, but it’d be more useful if it at least mimicked realistic application structures.
Either way, we finished the month much more confident that we’ll be delivering on our promise of Hanami as the lighter, faster framework alternative. A good outcome!
Along the way, however, things did feel bleak at times. I wasn’t confident that I’d be able to make things right, and it didn’t feel great to think we might’ve spent years putting somethign together that wasn’t going to be able to deliver on some of those core promises. Luckily, I found all the wins we needed, and learnt a few things along the way.
Hanami 2.0, here we come
What else happened in September? Possibly the biggst thing is that we organised ourselves for the runway towards the final Hanami 2.0.0 release.
We want to do everything possible to make sure the release happens this year, so I spent some time organising the remaining tasks on our Trello board into date-based lists, aiming for a release towards the end of November. It looked achievable! The three of us in the core team re-committed ourselves to doing everything we could to complete these tasks in our estimated timeframes.
So far, things have gone very well!
We’ve all been working tremendously hard, and so far, this has let us keep everything to the schedule. I’ll have a lot to share about our work across October, but that’s all for next month’s update. So in the meantime, I have to put my head back down and get back to shipping a framework. See you all again soon!
It’s been a little over a year since our Redflow ZCell battery and Victron Energy inverter/charger kit were installed on our existing 5.94kW solar array. Now that we’re past the Southern Hemisphere spring equinox it seems like an opportune time to review the numbers and try to see exactly how the system has performed over its first full year. For background information on what all the pieces are and what they do, see my earlier post, Go With The Flow.
As we look at the figures for the year, it’s worth keeping in mind what we’re using the battery for, and how we’re doing it. Naturally we’re using it to store PV generated electricity for later use when the sun’s not shining. We are also charging the battery from the grid at certain times so it can be drawn down if necessary during peak times, for example I set up a small overnight charge to ensure there was power for the weekday morning peak, when the sun isn’t really happening yet, but grid power is more than twice as expensive. More recently in the winter months, I experimented with keeping the battery full with scheduled charges during most non-peak times. This involved quite a bit more grid charging, but got us through a couple of three hour grid outages without a hitch during some severe weather in August.
I spent some time going through data from the VRM portal for the last year, and correlating that with current bills from Aurora energy, and then I tried to compare our last year of usage with a battery, to the previous three years of usage without a battery. For reasons that will become apparent later, this turned out to be a massive pain in the ass, so I’m going to start by looking only at what we can see in the VRM portal for the past year.
The VRM portal has three summary views: System Overview, Consumption and Solar. System Overview tells us overall how much total power was pulled from the grid, how much was exported to the grid, how much was produced locally, and how much was consumed by our loads. The Consumption view (which I wish they’d named “Loads”, because I think that would be clearer) gives us the same consumption figure, but tells us how much of that came from the grid, vs. what came from the battery vs. what came from solar. The Solar view tells us how much PV generation went to the grid, how much went to the battery, and how much was used directly. There is some overlap in the figures from these three views, but there are also some interesting discrepancies, notably: the “From Grid” and “To Grid” figures shown under System Overview are higher than what’s shown in the Consumption and Solar views. But, let’s start by looking at the Consumption and Solar views, because those tell us what the system gives us, and what we’re using. I’ll come back after that to the System Overview, which is where things start to get weird and we discover what the system costs to run.
The VRM portal lets you chose any date range you like to get historical figures and bar charts. It also gives you pie charts of the last 24 hours, 7 days, 30 days and 365 days. To make the figures and bar charts match the pie charts, the year we’re analysing starts at 4pm on September 25, 2021 and ends at 4pm on September 25, 2022, because that’s exactly when I took the following screenshots. This means we get a partial September at each end of the bar chart. I’m sorry about that.
Here’s the Consumption view:
This shows us that in the last 12 months, our loads consumed 10,849kWh of electricity. Of that, 54% (5,848kWh) came from the grid, 23% (2,506kWh) came direct from solar PV and the final 23% (2,494kWh) came from the battery.
From the rough curve of the bar chart we can see that our consumption is lower in the summer months and higher in the winter months. I can’t say for certain, but I have to assume that’s largely due to heating. The low in February was 638kWh (an average of 22.8kWh/day). The high in July was 1,118kWh (average 36kWh/day).
Now let’s look at the Solar view:
In that same time period we generated 5,640kWh with our solar array, of which 44% (2,506kWh) was used directly by our loads, 43% (2,418kWh) went into the battery and 13% (716kWh) was exported to the grid.
Unsurprisingly our generation is significantly higher in summer than in winter. We got 956kWh (average 30kWh/day) in December but only 161kWh (5.3kWh/day) in June. Peak summer figures like that mean we’ll theoretically be able to do without grid power at all during that period once we get a second ZCell (note that we’re still exporting to the grid in December – that’s because we’ve got more generation capacity than storage). The winter figures clearly indicate that there’s no way we can provide anywhere near all our own power at that time of year with our current generation capacity and loads.
Now look closely at the summer months (December, January and February). There should be a nice curve evident there from December to March, but instead January and February form a weird dip. This is because we were without solar generation for three weeks from January 20 – February 11 due to replacing a faulty MPPT. Based on figures from previous years, I suspect we lost 500-600kWh of potential generation in that period.
Another interesting thing is that if we compare “To Battery” on the Solar view (2,418kWh) with “From Battery” on the Consumption view (2,494kWh), we see that our loads consumed 76kWh more from the battery than we actually put into it with solar generation. This discrepancy is due to the fact that in addition to charging the battery from solar, we’ve also been charging it from the grid at certain times, but the amount of power sent to the battery from the grid isn’t broken out explicitly anywhere in the VRM portal.
Now let’s look at the System Overview:
Here we see the same figures for “Production” (5,640kWh) and “Consumption” (10,849kWh) as were in the Consumption and Solar views, and the bar chart shows the same consumption and generation curves (ignore the blue overlay and line which indicate battery minimum/maximum and average state of charge – that information is largely meaningless at this scale, given we cycle the battery completely every day).
Now look at “To Grid” and “From Grid”. “To Grid” is 754 kWh, i.e. we somehow sent 38kWh more to the grid than came from solar. “From Grid”, at 8,531kWh, is a whopping 2,683kWh more than the 5,848kWh grid power consumed by our loads (i.e. close to half as much again).
So, what’s going on here?
One factor is that we’re charging the battery from the grid at certain times. Initially that was a few hours overnight and a few hours in the afternoon on weekdays, although the afternoon charge is obviously also provided by the solar if the sun is shining. For all of July, August and most of September though I was using a charge schedule to keep the battery full except for peak times and maintenance cycle nights, which meant quite a bit more grid charging overnight than earlier in the year, as well as grid charging most of the day during days with no or minimal sunshine. Grid power sent to the battery isn’t visible in the “From Grid” figure on the Consumption view – that view shows only our loads, i.e. the equipment the system is powering – but it is part of the “From Grid” figure in the System Overview.
Similarly, some of the power we export to the grid is actually exported from the battery, as opposed to being exported from solar generation. That usually only happens during maintenance cycles when our loads aren’t enough to draw the battery down at the desired discharge rate. But again, same thing, that figure is present here on the system overview page as part of “To Grid”, but of course is not part of the “To Grid” figure on the Solar view.
Another factor is that the system itself needs some amount of power to operate. The Victron kit (the MultiPlus II Inverter/Chargers, the Cerbo GX, the MPPT) use some small amount of power themselves. The ZCell battery also requires power to operate its pumps and fans. When the sun is out this power can of course come from solar. When solar power is not available, power to run the system needs to come from some combination of the remaining charge in the battery, and the grid.
On that note, I did a little experiment to see how much power the system uses just to operate. On July 9 (which happened to be a maintenance cycle day), I disabled all scheduled battery charges, and I shut off the DC isolators for the solar PV, so the battery would remain online (pumps and fans running) but empty for all of July 10. The following day I went and checked the figures on the System Overview, which showed we drew 35kWh, but that our consumption was 33kWh. So, together, the battery doing nothing other than running its pumps and fans, plus the Multis doing nothing other than passing grid power through, used 2kWh of power in 24 hours. Over a year, that’s 730kWh. As mentioned above, ordinarily some of that will be sourced from mains and some from solar, but if we look at the total power that came into the system as a whole (5,640kWh from solar + 8,531kWh from the grid = 14,171kWh), 730kWh is just slightly over 5% of that.
The final factor in play is that a certain amount of power is naturally lost due to conversion at various points. The ZCell has a maximum 80% DC-DC stack efficiency, meaning in the absolute best case if you want to get 10kW out of it, you have to put 12.5kW in. In reality you’ll never hit the best case: the lifetime charge and discharge figures the BMS currenly shows for our ZCell are 4,423 and 3,336kWh respectively, which is a bit over 75%. The Multis have a maximum efficiency of 96% when doing their invert/charge dance, so if we grid charge the battery, we lose at least 4% on the way in, and at least 4% on the way out as well, going to and from AC/DC. Again, in reality that loss will be higher than 4% each way, because 96% is the maximum efficiency.
A bunch of the stuff above just doesn’t apply to the previous system with the ABB inverter and no battery. I also don’t have anything like as much detailed data to go on for the old system, which makes comparing performance with the new system fiendishly difficult. The best comparison I’ve been able to come up with so far involves looking at total power input to the system (power from grid plus solar generation), total consumption by loads (i.e. actual locally usable power), and total power exported.
Prior to the Victron gear and Redflow battery installation, I had grid import and export figures from my Aurora Energy bills, and I had total generation figures from the ABB inverter. From this I can synthesise what are hopefully reasonably accurate load consumption figures by adding adding grid input to total PV generation minus grid export.
I had hoped to do this analysis on a quarterly basis to line up with Aurora bills, because then I would also be able to see how seasonal solar generation and usage went up and down. Unfortunately the billing for 2020 and 2021 was totally screwed up by the COVID-19 pandemic, because there were two quarters during which nobody was coming out to read the electricity meter. The bills for those quarters stated estimated usage (i.e. were wrong, especially given they estimated grid export as zero), with subsequent quarters correcting the figures. I have no way to reliably correlate that mess with my PV generation figures, except on an annual basis. Also, using billing periods from pre-battery years, the closest I can get to the September 25 based 2021-2022 year I’m looking at now is billing periods starting and ending in mid-August. But, that’s close enough. We’ve still got four pretty much back-to-back 12 month periods to look at.
Year
Grid In
Solar In
Total In
Loads
Export
2018-2019
9,031
6,682
15,713
11,827
3,886
2019-2020
9,324
6,468
15,792
12,255
3,537
2020-2021
7,582
6,347
13,929
10,358
3,571
2021-2022
8,531
5,640
14,171
10,849
754
One thing of note here is that in the 2018-2019 and 2019-2020 years, our annual consumption was pretty close to 12MWh, whereas in 2020-2021 and 2021-2022 it was closer to 10.5MWh. If I had to guess, I’d say that ~1.5MWh/year drop is due to a couple of pieces of computer equipment that were previously always on, now mostly running in standby mode except when actually needed. A couple of hundred watts constant draw is a fair whack of power over the course of a year. Another thing to note is the big drop in power exported in 2021-2022, because most of our solar generation is now used locally.
The thing that freaked me out when looking at these figures is that in the battery year, while our loads consumed 491kWh more than in the previous non-battery year, we pulled 949kWh more power in from the grid! This is the opposite of what I had expected to see, especially having previously written:
In the eight months the system has been running we’ve generated 4631kWh of electricity and “only” sent 588kWh to the grid, which means we’ve used 87% of what we generated locally – much better than the pre-battery figure of 45%. I suspect we’ve reduced the amount of power we pull from the grid by about 30% too, but I’ll have to wait until we have a full year’s worth of data to be sure.
When I wrote that, I was looking at August 31, 2021 through April 27, 2022, and comparing that to the August 2020 to May 2021 grid power figures from my old Aurora bills. The mistake I must have made back then was to look at “From Grid” on the Consumption view, rather than “From Grid” on the System Overview. I’ve just done this exercise again, and the total grid draw from our Aurora bills from August 2020 to May 2021 is 4,980kWh. “From Grid” on the Consumption view for August 2021 to May 2022 is 3,575kWh, which is about 30% less, but “From Grid” on the System Overview is 4,754kWh, which is only about 5% less. So our loads pulled about 30% less from the grid than the same time the year before, but our system as a whole didn’t.
Now let’s break our ridiculous September-based year down further into months, to see if we can see more detail. I’ve highlighted some interesting periods in bold.
Month
Grid In
Solar In
Total In
Loads
Export
Sep 21 (part)
153
101
254
213
6
Oct 21
636
629
1,265
988
55
Nov 21
430
747
1,177
866
97
Dec 21
232
956
1,188
767
176
Jan 22
652
450
1,102
822
74
Feb 22
470
430
900
638
83
Mar 22
498
568
1,066
813
64
Apr 22
609
377
986
775
27
May 22
910
238
1,148
953
3
Jun 22
1,114
161
1,275
1073
2
Jul 22
1,163
223
1,386
1118
11
Aug 22
910
375
1,285
966
64
Sep 22 (part)
754
385
1,139
857
92
Total
8,531
5,640
14,171
10,849
754
December is great. We generated about 25% more power than our loads use (956/767=1.25), and our grid input was only about 30% of the total of our loads (232/767=0.30).
January and February show the effects of missing three weeks of potential generation. I mean, just look at December through February 2021-2022 versus the previous three summers.
2018-2019
2019-2020
2020-2021
2021-2022
December
919
882
767
956
January
936
797
818
450
February
699
656
711
430
June and July are terrible. They’re our highest load months, with the lowest solar generation and we pulled 3-4% more power from the grid than our loads actually consumed. I’m going to attribute the latter largely to grid charging the battery.
If I dig a couple of interesting figures out for June and July I see “To Battery” on the Solar view shows 205kWh, and “From Battery” on the Consumption view shows 558kWh. Total consumption in that period was 2,191kWh, with the total “From Grid” reported in System Overview of 2,277kWh. Let’s mess with that a bit.
Bearing in mind the efficiency numbers mentioned earlier, if 205kWh went to the battery from PV, that means no more than 154kWh of what we got out of the battery was from PV generation (remember: real world DC-DC stack efficiency of about 75%). The remaining 404kWh out of the battery is power that went into it from the grid. And that means at least 538kWh in (404/0.75). Note that total from grid for these two months was 86kWh more than the 2,191kWh used by our loads. If I hadn’t been keeping the battery topped up from the grid, I’d’ve saved at least 134kWh of grid power, which would have brought our grid input figure back down below our consumption figure. Note also that this number will actually be higher in reality because I haven’t factored in AC/DC conversion losses from the Multis.
Now let’s look at some costs. When I started trying to compare the new system to the previous system, I went in thinking to look at in in terms of total power input to the system, total consumption by loads, and total power exported. There’s one piece missing there, so let’s add another couple of columns to an earlier table:
Year
Grid In
Solar In
Total In
Loads
Export
Total Out
what?
2021-2022
8,531
5,640
14,171
10,849
754
11,603
2,568
The total usable output of the system was 11,603kWh for 14,171kWh input. The difference between these two figures – 2,568kWh, or about 18% – went somewhere else. Per my earlier experiment, 5% is power that went to actually operate the system components, including the battery. That means about 13% of the power input to the system over the course of the year must have gone to some combination of charge/discharge and AC/DC conversion (in)efficiencies. We can consider this the energy cost of the system. To have the ability to time-shift expensive peak grid electricity, and to run the house without the grid if the sun is out, or from the battery when it has charge, costs us 18% of the total available energy input.
Finally, speaking of expensive grid electricity, let’s look at how much we paid Aurora Energy over the past four years for our power. The bills are broken out into different tariffs, for which you’re charged different amounts per kilowatt hour and then there’s an additional daily supply charge, and also credits for power exported. We can simplify that by just taking the total dollar value of all the power bills and dividing that by the total power drawn from the grid to arrive at an effective cost per kilowatt hour for the entire year. Here it is:
Year
From Grid
Total Bill
Cost/kWh
2018-2019
9,031
$2,278.33
$0.25
2019-2020
9,324
$2,384.79
$0.26
2020-2021
7,582
$1,921.77
$0.25
2021-2022
8,531
$1,731.40
$0.20
So, the combination of the battery plus the switch from Flat Rate to Peak & Off-Peak billing has reduced the cost of our grid power by about 20%. I call that a win.
Going forwards it will be interesting to see how the next twelve months go, and, in particular, what we can do to reduce our power consumption. A significant portion of our power is used by a bunch of always-on computer equipment. Some of that I need for my work, and some of that provides internet access, file storage and email for us personally. Altogether, according to the UPSes, this kit pulls 200-250 watts continuously, but will pull more than that during the day when it’s being used interactively. If we call it 250W continuous, that’s a minimum of 6kWh/day, which is 2,190kWh/year, or about 20% of the 2021-2022 consumption. Some of that equipment should be replaced with newer, more power efficient kit. Some of it could possibly even be turned off or put into standby mode some of the time.
We still need to get a heat pump to replace the 2400W panel heater in our bedroom. That should save a huge amount of power in winter. We’re also slowly working our way through the house installing excellent double glazed windows from Elite Double Glazing, which will save on power for heating and cooling year round.
And of course, we still need to get that second ZCell.
August’s OSS work landed one of the last big Hanami features, saw another Hanami release out the door, began some thinking about memory usage, and kicked off a fun little personal initiative. Let’s dive in!
Conditional slice loading in Hanami
At the beginning of the month I merged support for conditional slice loading in Hanami. I’d wanted this feature for a long time, and in fact I’d hacked in workarounds to achieve the same more than 2 years ago, so I was very pleased to finally get this done, and for the implementation work to be as smooth as it was.
The feature provides a new config.slices setting on your app class, which you can configure like so:
module MyApp
class App < Hanami::App
config.slices = %w[admin]
end
end
For an app consisting of both Admin and Main slices and for the config above, when the app is booted, only the Admin slice will be loaded:
require "hanami/prepare"
Hanami.app.slices.keys # => [:admin]
Admin::Slice # exists, as expected
Main # raises NameError, since it was never loaded
As we see from Main above, slices absent from this list will not have their namespace defined, nor their slice class loaded, nor any of their Ruby source files. Within that Ruby process, they effectively do not exist.
Specifying slices to load can be very helpful to improve boot time and minimize memory usage for specific deployed workloads of your app.
Imagine you have a subset of background jobs that run via a dedicated job runner, but whose logic is otherwise unneeded for the rest of your app to function. In this case, you could organize those jobs into their own slice, and then load only that slice for the job runner’s process. This arrangement would see the job runner boot as quickly as possible (no extraneous code to load) as well as save all the memory otherwise needed by all those classes. You could also do the invserse for your main deployed process: specify all slices except this jobs slice, and you gain savings there too.
Organising code into slices to promote operational efficiency like this also gives you the benefit of greater clarity in the separation of responsibilities between those slices: when a single slice of code is loaded and the rest of your app is made to disappear, that will quickly surface any insidious dependencies from that slice to the rest of your code (they’ll be raised as exceptions!). Cleaning these up will help ensure your slices remain useful as abstractions for reasoning about and maintaining your app.
To make it easy to tune the list of slices to load, I also introduced a new HANAMI_SLICES env var that sets this config without you having to write code inside your app class. In this way, you could use them in your Procfile or other similar deployment code:
This effort was also another example of why I’m so happy to be working alongside the Hanami core team. After initially proposing a more complex arrangement including separate lists for including or excluding slices, Luca jumped in and help me dial this back to the much simpler arrangement of the single list only. For an Hanami release in which we’re going to be introducing so many new ideas, the more we can keep simple around them, the better, and I’m glad to have people who can remind me of this.
Fixed how slice config is applied to component classes
Our action and view integration code relies on their classes detecting when they’re defined inside a slice’s namespace, then applying relevant config from the slice to their own class-level config object. It turned out our code for doing this broke a little when we adjusted our default class hierarchies. Thanks to some of our wonderful early adopters, we picked this up quickly and I fixed it. Now things just work like you expect however you choose to configure your action classes, whether through the app-level config.actions object, or by directly updating config in a base action class.
In doing this work, I became convinced we need an API on dry-configurable to determine whether any config value has been assigned or mutated by the user, since it would help so much in reliably detecting whether or not we should ignore config values at particular levels. For now, we could work around it, but I hope to bring this to dry-configurable at some point in the future.
Released Hanami 2.0.0.beta2
Another month passed, so it was time for another release! With my European colleagues mostly enjoying some breaks over their summer, I hunkered down in chilly Canberra and took care of the 2.0.0.beta2 release. Along with the improvements above, this release also included slice and action generators (hanami generate slice and hanami generate action, thank you Luca!), plus a very handle CLI middlewares inspector (thank you Marc!):
The list of things to do over the beta phase is getting smaller. I don’t expect we’ll need too many more of these releases!
Created memory usage benchmarks for dry-configurable
As the final 2.0 release gets closer, we’ve been doing various performance tests just to make sure the house is in order. One thing we discovered is that Hanami::Action is not as memory efficient as we’d like it to be. One of the biggest opportunities to improve this looked to be in dry-configurable, since that’s what is used to manage the per-class action configuration.
I suspected any effort here would turn out to be involved (and no surprise, it turned out to be involved 😆), so I thought it would be useful as a first step to establish a memory benchmark to revisit over the course of any work. This was also a great way to get my head in this space, which turned out to take over most of my September (but more on that next month).
I was immensitely proud of what Decaf Sucks became, and for the collaboration with Max Wheeler in building it.
Unfortunately, as various internet APIs changed, the site atrophied, eventually became disfunctional, and we had to take it down. I still have the database, however, and I want to bring it back!
This time around, my plan is to do it as a fully open source Hanami 2 example application. Max is even on board to bring back all the UI goodness. For now, you can follow along with the early steps on GitHub. Right now the app is little more than the basic Hanami skeleton with added database integration and a CI setup (Hello Buildkite!), but I plan to grow it bit by bit. Perhaps I’ll try to have something small that I can share with each of these monthly OSS updates.
After Hanami 2 ships, hopefully this will serve as a useful resource for people wanting to see how it plays out in a real working app. And beyond that, I look forward to it serving once again as a place for me to commemorate my coffee travels!
My team at SUSE is working on a new S3-compatible storage solution for Kubernetes, based on Ceph’s RADOS Gateway (RGW), except without any of the RADOS bits. The idea is that you can deploy our s3gw container on top of Longhorn (which provides the underlying replicated storage), and all this is running in your Kubernetes cluster, along with your applications which thus have convenient access to a local S3-compatible object store.
We’ve done this by adding a new storage backend to RGW. The approach we’ve taken is to use SQLite for metadata, with object data stored as files in a regular filesystem. This works quite neatly in a Kubernetes cluster with Longhorn, because Longhorn can provide a persistent volume (think: an ext4 filesystem), on which s3gw can store its SQLite database and object data files. If you’d like to kick the tyres, check out Giuseppe’s deployment tutorial for the 0.2.0 release, but bear in mind that as I’m writing this we’re all the way up to 0.4.0 so some details may have changed.
While s3gw on Longhorn on Kubernetes remains our primary focus for this project, the fact that this thing only needs a filesystem for backing storage means it can be run on top of just about anything. Given “just about anything” includes an old school two node Pacemaker cluster with DRBD for replicated storage, why not give that a try? I kinda like the idea of a good solid highly available S3-compatible storage solution that you could shove into the bottom of a rack somewhere without too much difficulty.
It’s probably eight years since I last deployed Pacemaker and DRBD, so to refresh my memory I ran with SUSE’s latest Highly Available NFS Storage with DRBD and Pacemaker document, but skipped all the NFS bits. That gives a filesystem mounted on one node, which will fail over to the other node if something breaks. On top of that, we need to run the s3gw container, the s3gw-ui container, an nginx HTTPS reverse proxy to smoosh those two together, and a virtual/floating IP, so the whole lot is accessible to the outside world.
Here’s the interesting parts of my Pacemaker configuration:
# crm configure show
[...]
primitive drbd_s3 ocf:linbit:drbd \
params drbd_resource=s3 drbdconf="/etc/drbd.conf" \
op monitor interval=29s role=Master \
op monitor interval=31s role=Slave
primitive fs_s3 Filesystem \
params device="/dev/drbd0" directory="/data" fstype=ext4 \
meta target-role=Started \
op start timeout=60s interval=0 \
op stop timeout=60s interval=0 \
op monitor interval=20s timeout=40s
primitive https nginx \
op start timeout=40s interval=0 \
op stop timeout=60s interval=0 \
op monitor timeout=30s interval=10s \
op monitor timeout=30s interval=30s \
op monitor timeout=60s interval=20s
primitive s3-ip IPaddr2 \
params ip=192.168.100.50 \
op monitor interval=10 timeout=20
primitive s3gw podman \
params image="ghcr.io/aquarist-labs/s3gw:latest" run_opts="-p 7480:7480 -v/data:/data" \
op start interval=0 timeout=90s \
op stop interval=0 timeout=90s \
op monitor interval=30s timeout=30s
primitive s3gw-ui podman \
params image="ghcr.io/aquarist-labs/s3gw-ui:latest" run_opts="-p 8080:8080 -e RGW_SERVICE_URL=https://s3gw.sleha.test" \
op start interval=0 timeout=90s \
op stop interval=0 timeout=90s \
op monitor interval=30s timeout=30s
group g-s3 fs_s3 s3gw s3gw-ui https s3-ip
ms ms-drbd_s3 drbd_s3 \
meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
colocation col-s3_on_drbd inf: g-s3 ms-drbd_s3:Promoted
order o-drbd_before_fs Mandatory: ms-drbd_s3:promote g-s3:start
[...]
The g-s3 group ensures that the ext4 filesystem (fs_s3), s3gw container (s3gw), s3gw-ui container (s3gw-ui), nginx instance (https) and virtual IP (s3-ip) all run on the same node, and start one after another. The colocation and ordering constraints ensure that g-s3 runs on whichever node is currently the DRBD (ms-drbd_s3) primary.
The important pieces of glue here are:
The fs_s3 resource mounts /dev/drbd0 on /data
The s3gw resource passes -p 7480:7480 -v/data:/data to podman, so the container can write to /data on the host, and the S3 service is accessible via HTTP on port 7480.
The s3gw-ui resource passes -p 8080:8080 -e RGW_SERVICE_URL=https://s3gw.sleha.test to podman, so the UI is accessible via HTTP on port 8080, and it expects the S3 service to be externally available via https://s3gw.sleha.test.
nginx is configured to reverse proxy https://s3gw.sleha.test to http://localhost:7480, and https://s3gw-ui.sleha.test to http://localhost:8080.
I’ve got an entry in /etc/hosts to point s3gw.sleha.test and s3gw-ui.sleha.test at the virtual IP (192.168.100.50).
I’m using self-signed certificates (openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout cert.key -out cert.pem) for s3gw and s3gw-ui, so I had to go visit both https://s3gw.sleha.test and https://s3gw-ui.sleha.test in my browser and accept the SSL certificate before the UI would work.
The DRBD config, nginx config and SSL certificates and keys need to be present on all nodes. I used csync2 for this.
Here’s my /etc/nginx/nginx.conf. I’m not entirely convinced I’ve got everything 100% right here, but it seems to work (this is, incredibly, my first time doing anything with nginx, and my first time dealing with CORS):
Monitoring of processes inside containers is a bit sketchy. By default, it will run podman exec $CONTAINER /bin/true, but that really only proves that the container is alive. You can override that command with something else, but it’s apparently better to engineer your container to die quickly and well if something goes wrong.
So what was the end result? TL;DR: It pretty much All Just WorkedTM, which is exactly what you’d hope for when running a new application on a mature HA stack. I can use s3cmd to mess around with the S3 service, and use my web browser to play with the UI. Failover is nice and quick (think: a few seconds) if I kill a node. For the sake of convenience I did this experiment on a couple of VMs using the external/libvirt STONITH plugin, but I don’t expect a real deployment to be hugely different in behaviour. Also, I’d forgotten how good Pacemaker is at highlighting poorly behaved applications – prior to this experiment the s3gw-ui container didn’t stop well, but we weren’t aware of that until I tried a manual failover which took too long and resulted in an unexpected STONITH due to a stop timeout. Moritz has since fixed that.
One thing I tripped over when doing this deployment was the correct values to use for the access_key and secret_key of the default user when talking to the S3 service. These are actually settable for the s3gw container via the RGW_DEFAULT_USER_ACCESS_KEY and RGW_DEFAULT_USER_SECRET_KEY environment variables, but if left unset, they default to “test” and “test” respectively. The interesting bits of my s3cmd.cfg are thus:
access_key = test
secret_key = test
host_base = https://s3gw.sleha.test/
host_bucket = htts://s3gw.sleha.test/%(bucket)
In retrospect I probably should have added -e RGW_DEFAULT_USER_ACCESS_KEY=tserong -e RGW_DEFAULT_USER_SECRET_KEY=do_not_tell_anyone_this_is_your_password to the run_opts parameter of the s3gw resource in the Pacemaker config.
What is HCX? VMware HCX is an application mobility platform designed for simplifying application migration, workload rebalancing and business continuity across datacenters and clouds. VMware HCX was formerly known as Hybrid Cloud Extension and NSX Hybrid Connect.
GCVE HCX GCVE deploys the Enterprise version of HCX as part of the cost of the solution.
HCX Enterprise has the following benefits:
Hybrid Interconnect WAN Optimisation Bulk Migration, Live Migration and HCX Replication Assisted vMotion Cloud to cloud migration Disaster Protection KVM & Hyper-V to vSphere migrations Traffic Engineering Mobility Groups Mobility Optimised Networking Changeover scheduling Definitions Cold Migration
We have seen a lot of Google Cloud VMware Engine over the last few months and for the entire time we have used click-ops to provision new infrastructure, networks and VM’s. Now we are going to the next level and we will be using Terraform to manage our infrastructure as code so that it is version controlled and predictable.
Installing Terraform The first part of getting this working is installing Terraform on your local machine.
As described in some detail in my last post, we have a single 10kWh Redflow ZCell zinc bromine flow battery hooked up to our solar PV via Victron inverter/chargers. This gives us the ability to:
Store almost all the excess energy we generate locally for later use.
When the sun isn’t shining, grid charge the battery at off-peak times then draw it down at peak times to save on our electricity bill (peak grid power is slightly more than twice as expensive as off-peak grid power).
Opportunistically survive grid outages, provided they don’t happen at the wrong time (i.e. when the sun is down and the battery is at 0% state of charge).
By their nature, ZCell flow batteries needs to undergo a maintenance cycle at least every three days, where they are discharged completely for a few hours. That’s why the last point above reads “opportunistically survive grid outages”. With a single ZCell, we can’t use the “minimum state of charge” feature of the Victron kit to always keep some charge in the battery in case of outages, because doing so conflicts with the ZCell maintenance cycles. Once we eventually get a second battery, this problem will go away because the maintenance cycles automatically interleave. In the meantime though, as my project for Hack Week 21, I decided to see if I could somehow automate the Victron scheduled charge configuration based on the ZCell maintenance cycle timing, to always keep the battery as full as possible for as long as possible.
There are three goals somewhat in tension with each other here:
Keep the battery full, except during maintenance cycles.
Don’t let the battery get too full immediately before a maintenance cycle, lest the discharge take too long and maintenance still be active the following morning.
Don’t schedule charges during peak electricity times (we still want to draw the battery down then, to avoid using the expensive gold plated electrons the power company sends down the wire between 07:00-10:00 and 16:00-21:00).
Here’s the solution I came up with:
On non-maintenance cycle days, set two no-limit scheduled charges, one from 10:00 for 6 hours, the other from 21:00 for 10 hours. That means the battery will be charged from the grid and/or the sun continuously, except for peak electricity times, when it will be drawn down. Our loads aren’t high enough to completely deplete the battery during peak times, so there will always be some juice in case of a grid outage on non-maintenance cycle days.
On maintenance cycle days, set a 50% limit scheduled charge from 13:00 for 3 hours, so the battery won’t be too full before that evening’s maintenance cycle, which kicks in at sunset. The day after a maintenance cycle, set a no limit scheduled charge from 03:00 for 4 hours. At our site, maintenance has almost always finished before 03:00, so there’s no conflict here, and we still have time to get some charge into the battery to handle the next morning’s peak.
Now, how to automate that?
The ZCell Battery Management System (BMS) has a REST API which we can query to find out useful information about the battery. Unfortunately it won’t actually tell us for certain whether maintenance will be run on any given day, but we can get the maintenance time limit, and subtract from that the amount of time that’s passed since the last maintenance cycle. If the resultant figure is less than one day, we know that maintenance will happen today. It is possible for maintenance to happen at other times, e.g. I can force maintenance manually, and also it can happen more often than every three days if you mess with the allowed days setting in the BMS, so this solution arguably isn’t perfect, but I think it’s good enough under the circumstances, at least at our site.
The Victron Cerbo GX (the little box that controls everything) runs Linux, and you can easily get root on it, so it’s possible to write scripts that run locally there. Here’s what I ended up with:
One important point about installing things on the Cerbo GX, is that the root partition is overwritten during firmware updates, but there’s a separate data partition which is preserved. The root user’s home directory is symlinked to /data/home/root, so my script lives at /data/home/root/sched.py to ensure it remains present. Then we need to get it into /etc/crontab, which doesn’t survive firmware updates. This is done by adding a /data/rc.local script which the Cerbo GX runs on boot:
After a few days of testing and observation, I can confirm that it all works perfectly! At least, at our site, right now, with our current loads and daylight ours. The whole thing will want revisiting (or probably just turning off) as we get into summer, when we’ll be able to rely on significantly more sunlight to keep the battery full than we get now. I may well just go back to a single 03:00-for-four-hours grid charge then, once the days are nice and long. See how we go…
Picking up where we left off last month, let’s dive into disaster recovery and how to use Site Recovery Manager and Google Backup & Protect to DR into and within the cloud with GCVE.
But before we do, a quick advertisement:
If you are in Brisbane, Australia, I suggest coming to the awesome Google Infrastructure Group (GIG) which focuses on GCVE where on 04 July 2022 I will be presenting on Terraform in GCVE.
Let’s pick up where we left off from last months article and start setting up some of the features of GCVE, starting with Advanced Autoscaling.
What is Advanced Auto-Scaling? Advanced Autoscaling automatically expands or shrinks a private cloud based on CPU, memory and storage utilisation metrics.
GCVE monitors the cluster based on the metrics defined in the autoscale policy and decides to add or remove nodes automatically. Remember: GCVE is physical Dell Poweredge servers, not a container/VM running in Docker or on a hypervisor like VMware.
We’ve done this a number of times over the last decade, from OSDC to LCA. The idea is to provide a free psychologist or counsellor at an in-person conference. Attendees can do an anonymous booking by taking a stickynote (with the timeslot) from a signup sheet, and thus get a free appointment.
Many people find it difficult taking the first (very important) step towards getting professional help, and we’ve received good feedback that this approach indeed assists.
So far we’ve always focused on open source conferences. Now we’re moving into information security! First BrisSEC 2022 (Friday 29 April at the Hilton in Brisbane, QLD) and then AusCERT 2022 (10-13 May at the Star Hotel, Gold Coast QLD). The awesome and geek friendly Dr Carla Rogers will be at both events.
How does this get funded? Well, we’ve crowdfunded some, nudged sponsors, most mostly it gets picked up by the conference organisers (aka indirectly by the sponsors, mostly).
If you’re a conference organiser, or would like a particular upcoming conference to offer this service, do drop us a line and we’re happy to chase it up for you and help the organisers to make it happen. We know how to run that now.
In-person is best. But for virtual conferences, sure contact us as well.
The hack day didn’t go as well as I hoped, but didn’t go too badly. There was smaller attendance than hoped and the discussion was mostly about things other than FLOSS. But everyone who attended had fun and learned interesting things so generally I think it counts as a success. There was discussion on topics including military hardware, viruses (particularly Covid), rocketry, and literature. During the discussion one error in a Wikipedia page was discussed and hopefully we can get that fixed.
I think that everyone who attended will be interested in more such meetings. Overall I think this is a reasonable start to the Hack Day meetings, when I previously ran such meetings they often ended up being more social events than serious hacking events and that’s OK too.
One conclusion that we came to regarding meetings is that they should always be well announced in email and that the iCal file isn’t useful for everyone. Discussion continues on the best methods of announcing meetings but I anticipate that better email will get more attendance.
What is GCVE? Google Cloud VMware Engine, or GCVE, is a fully managed VMware hypervisor and associated management and networking components, (vSphere, NSX-T, vSAN and HCX) built on top of Google’s highly performant and scalable infrastructure with fully redundant and dedicated 100Gbps networking that provides 99.99% availability.
The solution is integrated into Google Cloud Platform, so businesses benefit from having full access to GCP services, native VPC networking, Cloud VPN or Interconnect as well as all the normal security features you expect from GCP.
The March 2022 meeting went reasonably well. Everyone seemed to have fun and learn useful things about computers. After 2 hours my Internet connection dropped out which stopped the people who were using VMs from doing the tutorial. Fortunately most people seemed ready for a break so we ended the meeting. The early and abrupt ending of the meeting was a disappointment but it wasn’t too bad, the meeting would probably only have gone for another half hour otherwise.
The BigBlueButton system was shown to be effective for training when one person got confused with the Debian package configuration options for Postfix and they were able to share the window with everyone else to get advice. I was also confused by that stage.
Future Meetings
The main feature of the meeting was training in setting up a mailserver with Postfix, here are the lecture notes for it [1]. The consensus at the end of the meeting was that people wanted more of that for the April meeting. So for the April meeting I will add to the Postfix Training to include SpamAssassin, SPF, DKIM, and DMARC. For the start of the next meeting instead of providing bare Debian installations for the VMs I’ll provide a basic Postfix/Dovecot setup so people can get straight into SpamAssassin etc.
For the May meeting training on SE Linux was requested.
Social Media
Towards the end of the meeting we discussed Matrix and federated social media. LUV has a Matrix server and I can give accounts to anyone who’s involved in FOSS in the Australia and New Zealand area. For Mastodon the NZOSS Mastodon server [2] seems like a good option. I have an account there to try Mastodon, my Mastodon address is @etbe@mastodon.nzoss.nz .
We are going to make Matrix a primary communication method for the Flounder group, the room is #flounder:luv.asn.au . My Matrix address is @etbe:luv.asn.au .
We also have a new URL for the blog and events. See the right sidebar for the link to the iCal file which can be connected to Google Calendar and most online calendaring systems.
We just had the first Flounder meeting which went well. Had some interesting discussion of storage technology, I learnt a few new things. Some people did the ZFS training and BTRFS training and we had lots of interesting discussion.
Andrew Pam gave a summary of new things in Linux and talked about the sites lwn.net, gamingonlinux.com, and cnx-software.com that he uses to find Linux news. One thing he talked about is the latest developments with SteamDeck which is driving Linux support in Steam games. The site protondb.com tracks Linux support in Steam games.
We had some discussion of BPF, for an introduction to that technology see the BPF lecture from LCA 2022.
Next Meeting
The next meeting (Saturday 5th of March 1PM Melbourne time) will focus on running your own mail server which is always of interest to people who are interested in system administration and which is probably of more interest than usual because of Google forcing companies with “a legacy G Suite subscription” to transition to a more expensive “Business family” offering.
I “recently” wrote about obtaining a new (to me, actually quite old) computer over in The Apple Power Macintosh 7200/120 PC Compatible (Part 1). This post is a bit of a detour, but may help others understand why some images they download from the internet don’t work.
Disk partitioning is (of course) a way to divide up a single disk into multiple volumes (partitions) for different uses. While the idea is similar, computer platforms over the ages have done this in a variety of different ways, with varying formats on disk, and varying limitations. The ones that you’re most likely to be familiar with are the MBR partitioning scheme (from the IBM PC), and the GPT partitioning scheme (common for UEFI systems such as the modern PC and Mac). One you’re less likely to be familiar with is the Apple Partition Map scheme.
The way all IBM PCs and compatibles worked from the introduction of MS-DOS 2.0 in 1983 until some time after 2005 was the Master Boot Record partitioning scheme. It was outrageously simple: of the first 512 byte sector of a disk, the first 446 bytes was for the bootstrapping code (the “boot sector”), the last 2 bytes were for the magic two bytes telling the BIOS this disk was bootable, and the other 64 bytes were four entries of 16 bytes, each describing a disk partition. The Wikipedia page is a good overview of what it all looks like. Since “four partitions should be enough for anybody” wasn’t going to last, DOS 3.2 introduced “extended partitions” which was just using one of those 4 partitions as another similar data structure that could point to more partitions.
In the 1980s (similar to today), the Macintosh was, of course, different. The Apple Partition Map is significantly more flexible than the MBR on PCs. For a start, you could have more than four partitions! You could actually have a lot more than four partitions, as the Apple Partition Map is a single 512-byte sector for each partition, and the partition map is itself a partition. Instead of being block 0 (like the MBR is), it actually starts at block 1, and is contiguous (The Driver Descriptor Record is what’s at block 0). So, once created, it’s hard to extend. Typically it’d be created as 64×512-byte entries, for 32kb… which turns out is actually about enough for anyone.
The Inside Macintosh reference on the SCSI Manager goes through more detail as to these structures. If you’re wondering what language all the coding examples are in, it’s Pascal – which was fairly popular for writing Macintosh applications in back in the day.
But the actual partition map isn’t the “interesting” part of all this (and yes, the quotation marks are significant here), because Macs are pretty darn finicky about what disks to boot off, which gets to be interesting if you’re trying to find a CD-ROM image on the internet from which to boot, and then use to install an Operating System from.
I never programmed a 1980s Macintosh actually in the 1980s. It was sometime in the early 1990s that I first experienced Microsoft Basic for the Macintosh. I’d previously (unknowingly at the time as it was branded Commodore) experienced Microsoft BASIC on the Commodore 16, Commodore 64, and even the Apple ][, but the Macintosh version was something else. It let you do some pretty neat things such as construct a GUI with largely the same amount of effort as it took to construct a Text based UI on the micros I was familiar with.
Okay, to be fair, I’d also dabbled in Microsoft QBasic that came bundled with MS-DOS of the era, which let you do a whole bunch of graphics – so you could theoretically construct a GUI with it. Something I did attempt to do. Programming on the Mac was so much easier to construct a GUI.
Of course, Microsoft Basic wasn’t the preferred way to program on the Macintosh. At that time it was largely Pascal, with C being something that also existed – but you were going to see Pascal in Inside Macintosh. It was probably somewhat fortuitous that I’d poked at Pascal a bit as something alternate to look at in the high school computing classes. I can only remember using TurboPascal on DOS systems and never actually writing Pascal on the Macintosh.
By the middle part of the 1990s though, I was firmly incompetently writing C on the Mac. No doubt the quality of my code increased after I’d done some university courses actually covering the language rather than the only practical way I had to attempt to write anything useful being looking at Inside Macintosh examples in Pascal and “C for Dummies” which was very not-Macintosh. Writing C on UNIX/Linux was a lot easier – everything was made for it, including Actual Documentation!
Anyway, in the early 2000s I ran MacOS X for a bit on my white iBook G3, and did a (very) small amount of any GUI / Project Builder (the precursor to Xcode) related development – instead largely focusing on command line / X11 things. The latest coolness being to use Objective-C to program applications (unless you were bringing over your Classic MacOS Carbon based application, then you could still write C). Enter some (incompetent) Objective-C coding!
Then Apple went to x86, so the hardware ceased being interesting, and I had no reason to poke at it even as a side effect of having hardware that could run the software stack. Enter a long-ass time of Debian, Ubuntu, and Fedora on laptops.
Come 2022 though, and (for reasons I should really write up), I’m poking at a Mac again and it’s now Swift as the preferred way to write apps. So, I’m (incompetently) hacking away at Swift code. I have to admit, it’s pretty nice. I’ve managed to be somewhat productive in a relative short amount of time, and all the affordances in the language gear towards the kind of safety that is a PITA when coding in C.
So this is my WIP utility to be able to import photos from a Shotwell database into the macOS Photos app:
There’s a lot of rough edges and unknowns left, including how to actually do the import (it looks like there’s going to be Swift code doing AppleScript things as the PhotoKit API is inadequate). But hey, some incompetent hacking in not too much time has a kind-of photo browser thing going on that feels pretty snappy.
Recently I read Michael Snoyman’s post on combining Axum, Hyper, Tonic and Tower. While his solution worked, it irked me – it seemed like there should be a much tighter solution possible.
I can deep dive into the code in a later post perhaps, but I think there are four points of difference. One, since the post was written Axum has started boxing its routes : so the enum dispatch approach taken, which delivers low overheads actually has no benefits today.
Two, while writing out the entire type by hand has some benefits, async code is much more pithy.
Thirdly, the code in the post is entirely generic, except the routing function itself.
And fourth, the outer Service<AddrStream> is an unnecessary layer to abstract over: given the similar constraints – the inner Service must take Request<..>, it is possible to just not use a couple of helpers and instead work directly with Service<Request...>.
So, onto a pithier version.
First, the app server code itself.
use std::{convert::Infallible, net::SocketAddr};
use axum::routing::get;
use hyper::{server::conn::AddrStream, service::make_service_fn};
use hyper::{Body, Request};
use tonic::async_trait;
use demo::echo_server::{Echo, EchoServer};
use demo::{EchoReply, EchoRequest};
struct MyEcho;
#[async_trait]
impl Echo for MyEcho {
async fn echo(
&self,
request: tonic::Request<EchoRequest>,
) -> Result<tonic::Response<EchoReply>, tonic::Status> {
Ok(tonic::Response::new(EchoReply {
message: format!("Echoing back: {}", request.get_ref().message),
}))
}
}
#[tokio::main]
async fn main() {
let addr = SocketAddr::from(([0, 0, 0, 0], 3000));
let axum_service = axum::Router::new().route("/", get(|| async { "Hello world!" }));
let grpc_service = tonic::transport::Server::builder()
.add_service(EchoServer::new(MyEcho))
.into_service();
let both_service =
demo_router::Router::new(axum_service, grpc_service, |req: &Request<Body>| {
Ok::<bool, Infallible>(
req.headers().get("content-type").map(|x| x.as_bytes())
== Some(b"application/grpc"),
)
});
let make_service = make_service_fn(move |_conn: &AddrStream| {
let both_service = both_service.clone();
async { Ok::<_, Infallible>(both_service) }
});
let server = hyper::Server::bind(&addr).serve(make_service);
if let Err(e) = server.await {
eprintln!("server error: {}", e);
}
}
Note the Router: it takes the two services and Fn to determine which to use on any given request. Then we just drop that composed service into make_service_fn and we’re done.
Next up we have the Router implementation. This is generic across any two Service<Request<...>> types as long as they are both Into<Bytes> for their Data, and Into<Box<dyn Error>> for errors.
Interesting things here – I use boxed_unsync to abstract over the body concrete type, and I implement the future using async code rather than as a separate struct. It becomes much smaller even after a few bits of extra type constraining.
One thing that flummoxed me for a little was the need to capture the future for the underlying response outside of the async block. Failing to do so provokes a 'static requirement which was tricky to debug. Fortunately there is a bug on making this easier to diagnose in rustc already. The underlying problem is that if you create the async block, and then dereference self, the type for impl of .first has to live an arbitrary time. Whereas by capturing the future immediately, only the impl of the future has to live an arbitrary time, and that doesn’t then require changing the signature of the function.
This is almost worth turning into a crate – I couldn’t see an existing one when I looked, though it does end up rather small – < 100 lines. What do you all think?
The first meeting will start at 1PM Australian Eastern time (Melbourne/Sydney) which is +1100 on Saturday the 5th of February.
I will start the video chat an hour early in case someone makes a timezone mistake and gets there an hour before it starts. If anyone else joins early we will have random chat until the start time (deliberately avoiding topics worthy of the main meeting). The link http://b.coker.com.au will redirect to the meeting URL on the day.
The first scheduled talk is a summary and discussion of free software related news. Anyone who knows of something new that excites them is welcome to speak about it.
The main event is discussion of storage technology and hands-on training on BTRFS and ZFS for those who are interested. Here are the ZFS training notes and here are the BTRFS training notes. Feel free to do the training exercises on your own VM before the meeting if you wish.
Then discussion of the future of the group and the use of FOSS social media. While social media is never going to be compulsory some people will want to use it to communicate and we could run some servers for software that is considered good (lots of server capacity is available).
Finally we have to plan future meetings and decide on which communication methods are desired.
The BBB instance to be used for the video conference is sponsored by NZOSS and Catalyst Cloud.
Since PM Scott Morrison did not announce the federal election date last week, it will now be held somewhere between March and May (see the post from ABC’s Antony Green for details). Various aspects of elections are covered in the Civics & Citizenship Australian Curriculum in Years 4, 5 and 6. Students are interested in […]
The main aim is to provide educational benefits to free software users via an online meeting that can’t be obtained by watching YouTube videos etc in a scope that is larger than one country. When the pandemic ends we will keep running this as there are benefits to be obtained from a meeting of a wide geographic scope that can’t be obtained by meetings in a single city. People from other countries are welcome to attend but they aren’t the focus of the meeting.
Until we get a better DNS name the address http://b.coker.com.au will redirect to the BBB instance used for online meetings (the meeting address isn’t yet setup so it redirects to the blog). The aim is that there will always be a short URL for the meeting so anyone who has one device lose contact can quickly type the URL into their backup device.
The first meeting will be on the 5th of Feb 2022 at 1PM Melbourne time +1100. When we get a proper domain I’ll publish a URL for an iCal file with entries for all meetings. I will also find some suitable way for meeting times to be localised (I’m sure there’s a WordPress plugin for that).
For the hands-on part of the meetings there will be virtual machine images you can download to run on your own system (tested with KVM, should work with other VM systems) and the possibility of logging in to a running VM. The demonstration VMs will have public IPv6 addresses and will also be available through different ports on a single IPv4 address, having IPv6 on your workstation will be convenient for you but you can survive without it.
Linux Australia has a list of LUGs in Australia, is there a similar list for NZ? One thing I’d like to see is a list of links for iCal files for all the meetings and also an iCal aggregator that for all iCal feeds of online meetings. I’ll host it myself if necessary, but it’s probably best to do it via Linux Australia (Linux Australasia?) if possible.
I’m attending the https://linux.conf.au/ conference online this weekend, which is always a good opportunity for some sideline hacking.
I found something boneheaded doing that today.
There have been a few times while inventing the OpenHMD Rift driver where I’ve noticed something strange and followed the thread until it made sense. Sometimes that leads to improvements in the driver, sometimes not.
In this case, I wanted to generate a graph of how long the computer vision processing takes – from the moment each camera frame is captured until poses are generated for each device.
To do that, I have a some logging branches that output JSON events to log files and I write scripts to process those. I used that data and produced:
Two things caught my eye in this graph. The first is the way the baseline latency (pink lines) increases from ~20ms to ~58ms. The 2nd is the quantisation effect, where pose latencies are clearly moving in discrete steps.
Neither of those should be happening.
Camera frames are being captured from the CV1 sensors every 19.2ms, and it takes that 17-18ms for them to be delivered across the USB. Depending on how many IR sources the cameras can see, figuring out the device poses can take a different amount of time, but the baseline should always hover around 17-18ms because the fast “device tracking locked” case take as little as 1ms.
Did you see me mention 19.2ms as the interframe period? Guess what the spacing on those quantisation levels are in the graph? I recognised it as implying that something in the processing is tied to frame timing when it should not be.
This 2nd graph helped me pinpoint what exactly was going on. This graph is cut from the part of the session where the latency has jumped up. What it shows is a ~1 frame delay between when the frame is received (frame-arrival-finish-local-ts) before the initial analysis even starts!
That could imply that the analysis thread is just busy processing the previous frame and doesn’t get start working on the new one yet – but the graph says that fast analysis is typically done in 1-10ms at most. It should rarely be busy when the next frame arrives.
This is where I found the bone headed code – a rookie mistake I wrote when putting in place the image analysis threads early on in the driver development and never noticed.
There are 3 threads involved:
USB service thread, reading video frame packets and assembling pixels in framebuffers
Fast analysis thread, that checks tracking lock is still acquired
Long analysis thread, which does brute-force pose searching to reacquire / match unknown IR sources to device LEDs
These 3 threads communicate using frame worker queues passing frames between each other. Each analysis thread does this pseudocode:
while driver_running:
Pop a frame from the queue
Process the frame
Sleep for new frame notification
The problem is in the 3rd line. If the driver is ever still processing the frame in line 2 when a new frame arrives – say because the computer got really busy – the thread sleeps anyway and won’t wake up until the next frame arrives. At that point, there’ll be 2 frames in the queue, but it only still processes one – so the analysis gains a 1 frame latency from that point on. If it happens a second time, it gets later by another frame! Any further and it starts reclaiming frames from the queues to keep the video capture thread fed – but it only reclaims one frame at a time, so the latency remains!
The fix is simple:
while driver_running:
Pop a frame
Process the frame
if queue_is_empty():
sleep for new frame notification
Doing that for both the fast and long analysis threads changed the profile of the pose latency graph completely.
This is a massive win! To be clear, this has been causing problems in the driver for at least 18 months but was never obvious from the logs alone. A single good graph is worth a thousand logs.
What does this mean in practice?
The way the fusion filter I’ve built works, in between pose updates from the cameras, the position and orientation of each device are predicted / updated using the accelerometer and gyro readings. Particularly for position, using the IMU for prediction drifts fairly quickly. The longer the driver spends ‘coasting’ on the IMU, the less accurate the position tracking is. So, the sooner the driver can get a correction from the camera to the fusion filter the less drift we’ll get – especially under fast motion. Particularly for the hand controllers that get waved around.
Poses are now being updated up to 40ms earlier and the baseline is consistent with the USB transfer delay.
You can also visibly see the effect of the JPEG decoding support I added over Christmas. The ‘red’ camera is directly connected to USB3, while the ‘khaki’ camera is feeding JPEG frames over USB2 that then need to be decoded, adding a few ms delay.
The latency reduction is nicely visible in the pose graphs, where the ‘drop shadow’ effect of pose updates tailing fusion predictions largely disappears and there are fewer large gaps in the pose observations when long analysis happens (visible as straight lines jumping from point to point in the trace):
Yes, the blog is still on. January 2004 I moved to WordPress, and it is still here January 2022. I didn’t write much last year (neither here, not experimenting with the Hey blog). I didn’t post anything to Instagram last year either from what I can tell, just a lot of stories.
August 16 2021, I realised I was 1,000 days till May 12 2024, which is when I become 40. As of today, that leads 850 days. Did I squander the last 150 days? I’m back to writing almost daily in the Hobonichi Techo (I think last year and the year before were mostly washouts; I barely scribbled anything offline).
I got a new Apple Watch Series 7 yesterday. I can say I used the Series 4 well (79% battery life), purchased in the UK when I broke my Series 0 in Edinburgh airport.
TripIt stats for last year claimed 95 days on the road. This is of course, a massive joke, but I’m glad I did get to visit London, Lisbon, New York, San Francisco, Los Angeles without issue. I spent a lot of time in Kuantan, a bunch of Langkawi trips, and also, I stayed for many months at the Grand Hyatt Kuala Lumpur during the May lockdowns (I practically stayed there all lockdown).
With 850 days to go till I’m 40, I have plenty I would like to achieve. I think I’ll write a lot more here. And elsewhere. Get back into the habit of doing. And publishing by learning and doing. No fear. Not that I wasn’t doing, but its time to be prolific with what’s been going on.
Once again time has passed, and another update on Oculus Rift support feels due! As always, it feels like I’ve been busy with work and not found enough time for Rift CV1 hacking. Nevertheless, looking back over the history since I last wrote, there’s quite a lot to tell!
In general, the controller tracking is now really good most of the time. Like, wildly-swing-your-arms-and-not-lose-track levels (most of the time). The problems I’m hunting now are intermittent and hard to identify in the moment while using the headset – hence my enthusiasm over the last updates for implementing stream recording and a simulation setup. I’ll get back to that.
Outlier Detection
Since I last wrote, the tracking improvements have mostly come from identifying and rejecting incorrect measurements. That is, if I have 2 sensors active and 1 sensor says the left controller is in one place, but the 2nd sensor says it’s somewhere else, we’ll reject one of those – choosing the pose that best matches what we already know about the controller. The last known position, the gravity direction the IMU is detecting, and the last known orientation. The tracker will now also reject observations for a time if (for example) the reported orientation is outside the range we expect. The IMU gyroscope can track the orientation of a device for quite a while, so can be relied on to identify strong pose priors once we’ve integrated a few camera observations to get the yaw correct.
It works really well, but I think improving this area is still where most future refinements will come. That and avoiding incorrect pose extractions in the first place.
The above plot is a sample of headset tracking, showing the extracted poses from the computer vision vs the pose priors / tracking from the Kalman filter. As you can see, there are excursions in both position and orientation detected from the video, but these are largely ignored by the filter, producing a steadier result.
This plot shows the left controller being tracked during a Beat Saber session. The controller tracking plot is quite different, because controllers move a lot more than the headset, and have fewer LEDs to track against. There are larger gaps here in the timeline while the vision re-acquires the device – and in those gaps you can see the Kalman filter interpolating using IMU input only (sometimes well, sometimes less so).
Improved Pose Priors
Another nice thing I did is changes in the way the search for a tracked device is made in a video frame. Before starting looking for a particular device it always now gets the latest estimate of the previous device position from the fusion filter. Previously, it would use the estimate of the device pose as it was when the camera exposure happened – but between then and the moment we start analysis more IMU observations and other camera observations might arrive and be integrated into the filter, which will have updated the estimate of where the device was in the frame.
This is the bit where I think the Kalman filter is particularly clever: Estimates of the device position at an earlier or later exposure can improve and refine the filter’s estimate of where the device was when the camera captured the frame we’re currently analysing! So clever. That mechanism (lagged state tracking) is what allows the filter to integrate past tracking observations once the analysis is done – so even if the video frame search take 150ms (for example), it will correct the filter’s estimate of where the device was 150ms in the past, which ripples through and corrects the estimate of where the device is now.
LED visibility model
To improve the identification of devices better, I measured the actual angle from which LEDs are visible (about 75 degrees off axis) and measured the size. The pose matching now has a better idea of which LEDs should be visible for a proposed orientation and what pixel size we expect them to have at a particular distance.
Better Smoothing
I fixed a bug in the output pose smoothing filter where it would glitch as you turned completely around and crossed the point where the angle jumps from +pi to -pi or vice versa.
Improved Display Distortion Correction
I got a wide-angle hi-res webcam and took photos of a checkerboard pattern through the lens of my headset, then used OpenCV and panotools to calculate new distortion and chromatic aberration parameters for the display. For me, this has greatly improved. I’m waiting to hear if that’s true for everyone, or if I’ve just fixed it for my headset.
Persistent Config Cache
Config blocks! A long time ago, I prototyped code to create a persistent OpenHMD configuration file store in ~/.config/openhmd. The rift-kalman-filter branch now uses that to store the configuration blocks that it reads from the controllers. The first time a controller is seen, it will load the JSON calibration block as before, but it will now store it in that directory – removing a multiple second radio read process on every subsequent startup.
Persistent Room Configuration
To go along with that, I have an experimental rift-room-config branch that creates a rift-room-config.json file and stores the camera positions after the first startup. I haven’t pushed that to the rift-kalman-filter branch yet, because I’m a bit worried it’ll cause surprising problems for people. If the initial estimate of the headset pose is wrong, the code will back-project the wrong positions for the cameras, which will get written to the file and cause every subsequent run of OpenHMD to generate bad tracking until the file is removed. The goal is to have a loop that monitors whether the camera positions seem stable based on the tracking reports, and to use averaging and resetting to correct them if not – or at least to warn the user that they should re-run some (non-existent) setup utility.
Video Capture + Processing
The final big ticket item was a rewrite of how the USB video frame capture thread collects pixels and passes them to the analysis threads. This now does less work in the USB thread, so misses fewer frames, and also I made it so that every frame is now searched for LEDs and blob identities tracked with motion vectors, even when no further analysis will be done on that frame. That means that when we’re running late, it better preserves LED blob identities until the analysis threads can catch up – increasing the chances of having known LEDs to directly find device positions and avoid searching. This rewrite also opened up a path to easily support JPEG decode – which is needed to support Rift Sensors connected on USB 2.0 ports.
Session Simulator
I mentioned the recording simulator continues to progress. Since the tracking problems are now getting really tricky to figure out, this tool is becoming increasingly important. So far, I have code in OpenHMD to record all video and tracking data to a .mkv file. Then, there’s a simulator tool that loads those recordings. Currently it is capable of extracting the data back out of the recording, parsing the JSON and decoding the video, and presenting it to a partially implemented simulator that then runs the same blob analysis and tracking OpenHMD does. The end goal is a Godot based visualiser for this simulation, and to be able to step back and forth through time examining what happened at critical moments so I can improve the tracking for those situations.
To make recordings, there’s the rift-debug-gstreamer-record branch of OpenHMD. If you have GStreamer and the right plugins (gst-plugins-good) installed, and you set env vars like this, each run of OpenHMD will generate a recording in the target directory (make sure the target dir exists):
The next things that are calling to me are to improve the room configuration estimation and storage as mentioned above – to detect when the poses a camera is reporting don’t make sense because it’s been bumped or moved.
I’d also like to add back in tracking of the LEDS on the back of the headset headband, to support 360 tracking. I disabled those because they cause me trouble – the headband is adjustable relative to the headset, so the LEDs don’t appear where the 3D model says they should be and that causes jitter and pose mismatches. They need special handling.
One last thing I’m finding exciting is a new person taking an interest in Rift S and starting to look at inside-out tracking for that. That’s just happened in the last few days, so not much to report yet – but I’ll be happy to have someone looking at that while I’m still busy over here in CV1 land!
As always, if you have any questions, comments or testing feedback – hit me up at thaytan@noraisin.net or on @thaytan Twitter/IRC.
Thank you to the kind people signed up as Github Sponsors for this project!
For a long time computer manufacturers have tried to differentiate themselves and their products from their competitors with fancy names with odd capitalisation and spelling. But as an author, using these names does a disservice to the reader: how are they to know that DEC is pronounced as if it was written Dec ("deck").
It's time we pushed back, and wrote for our readers, not for corporations.
It's time to use standard English rules for these Corporate Fancy Names. Proper names begin with a capital, unlike "ciscoSystems®" (so bad that Cisco itself moved away from it). Words are separated by spaces, so "Cisco Systems". Abbreviations and acronyms are written in lower case if they are pronounced as a word, in upper case if each letter is pronounced: so "ram" and "IBM®".
So from here on in I'll be using the following:
Face Book. Formerly, "Facebook®".
Junos. Formerly JUNOS®.
ram. Formerly RAM.
Pan OS. Formerly PAN-OS®.
Unix. Formerly UNIX®.
I'd encourage you to try this in your own writing. It does look odd for the first time, but the result is undeniably more readable. If we are not writing to be understood by our audience then we are nothing more than an unpaid member of some corporation's marketing team.
I gave the talk On The Use and Misuse of Decorators as part of PyConline AU 2021, the second in annoyingly long sequence of not-in-person PyCon AU events. Here’s some code samples that you might be interested in:
Simple @property implementation
This shows a demo of @property-style getters. Setters are left as an exercise :)
defdemo_property(f):f.is_a_property=TruereturnfclassHasProperties:def__getattribute__(self,name):ret=super().__getattribute__(name)ifhasattr(ret,"is_a_property"):returnret()else:returnretclassDemo(HasProperties):@demo_propertydefis_a_property(self):return"I'm a property"defis_a_function(self):return"I'm a function"a=Demo()print(a.is_a_function())print(a.is_a_property)
@run (The Scoped Block)
@run is a decorator that will run the body of the decorated function, and then store the result of that function in place of the function’s name. It makes it easier to assign the results of complex statements to a variable, and get the advantages of functions having less leaky scopes than if or loop blocks.
A while ago, I wrote a post about how to build and test my Oculus CV1 tracking code in SteamVR using the SteamVR-OpenHMD driver. I have updated those instructions and moved them to https://noraisin.net/diary/?page_id=1048 – so use those if you’d like to try things out.
The pandemic continues to sap my time for OpenHMD improvements. Since my last post, I have been working on various refinements. The biggest visible improvements are:
Adding velocity and acceleration API to OpenHMD.
Rewriting the pose transformation code that maps from the IMU-centric tracking space to the device pose needed by SteamVR / apps.
Adding velocity and acceleration reporting is needed in VR apps that support throwing things. It means that throwing objects and using gravity-grab to fetch objects works in Half-Life: Alyx, making it playable now.
The rewrite to the pose transformation code fixed problems where the rotation of controller models in VR didn’t match the rotation applied in the real world. Controllers would appear attached to the wrong part of the hand, and rotate around the wrong axis. Movements feel more natural now.
Ongoing work – record and replay
My focus going forward is on fixing glitches that are caused by tracking losses or outliers. Those problems happen when the computer vision code either fails to match what the cameras see to the device LED models, or when it matches incorrectly.
Tracking failure leads to the headset view or controllers ‘flying away’ suddenly. Incorrect matching leads to controllers jumping and jittering to the wrong pose, or swapping hands. Either condition is very annoying.
Unfortunately, as the tracking has improved the remaining problems get harder to understand and there is less low-hanging fruit for improvement. Further, when the computer vision runs at 52Hz, it’s impossible to diagnose the reasons for a glitch in real time.
I’ve built a branch of OpenHMD that uses GStreamer to record the CV1 camera video, plus IMU and tracking logs into a video file.
To go with those recordings, I’ve been working on a replay and simulation tool, that uses the Godot game engine to visualise the tracking session. The goal is to show, frame-by-frame, where OpenHMD thought the cameras, headset and controllers were at each point in the session, and to be able to step back and forth through the recording.
Right now, I’m working on the simulation portion of the replay, that will use the tracking logs to recreate all the poses.
GKE in Production - Part 2 This tutorial is part of a series I am creating on creating, running and managing Kubernetes on GCP the way I do in my day job. In this episode, we are covering how to setup a nginx ingress controller to handle incoming requests.
Note: There may be some things I have skimmed over, if so or you see a glaring hole in my configuration, please drop me a line via the contact page linked at the top of the site.
I’ve been asked more than once what it was like at the beginning of Ubuntu, before it was a company, when an email from someone I’d never heard of came into my mailbox.
We’re coming up on 20 years now since Ubuntu was founded, and I had cause to do some spelunking into IMAP archives recently… while there I took the opportunity to grab the very first email I received.
The Ubuntu long shot succeeded wildly. Of course, we liked to joke about how spammy those emails where: cold-calling a raft of Debian developers with job offers, some of them were closer to phishing attacks :). This very early one – I was the second employee (though I started at 4 days a week to transition my clients gradually) – was less so.
I think its interesting though to note how explicit a gamble this was framed as: a time limited experiment, funded for a year. As the company scaled this very rapidly became a hiring problem and the horizon had to be pushed out to 2 years to get folk to join.
And of course, while we started with arch in earnest, we rapidly hit significant usability problems, some of which were solvable with porcelain and shallow non-architectural changes, and we built initially patches, and then the bazaar VCS project to tackle those. But others were not: for instance, I recall exceeding the 32K hard link limit on ext3 due to a single long history during a VCS conversion. The sum of these challenges led us to create the bzr project, a ground up rethink of our version control needs, architecture, implementation and user-experience. While ultimately git has conquered all, bzr had – still has in fact – extremely loyal advocates, due to its laser sharp focus on usability.
Anyhow, here it is: one of the original no-name-here-yet, aka Ubuntu, introductory emails (with permission from Mark, of course). When I clicked through to the website Mark provided there was a link there to a fantastical website about a space tourist… not what I had expected to be reading in Adelaide during LCA 2004.
From: Mark Shuttleworth <xxx@xxx> To: Robert Collins <xxx@xxx> Date: Thu, 15 Jan 2004, 04:30
Tom Lord gave me your email address, I believe he’s already sent you the email that I sent him so I’m sure you have some background.
In short, I am going to fund some open source development for a year. This is part of a new project that I will be getting off the ground in the coming weeks. I don’t know where it will lead, it’s flying in the face of a stiff breeze but I think at the end of the day it will at least fund a few very good open source developers for a full year to work on the projects they like most.
One of the pieces of the puzzle is high end source code management. I’ll be looking to build an infrastructure that will manage source code for between 100 and 8000 open source projects (yes, there’s a big difference between the two, I don’t know at which end of the spectrum we will be at the end of the year but our infrastructure will have to at least be capable of scaling to the latter within two years) with upwards of 2000 developers, drawing code from a variety of sources, playing with it and spitting it out regularly in nice packages.
Arch and Subversion seem to be the two leading contenders for “next generation open source sccm”. I’d be interested in your thoughts on the two of them, and how they stack up. I’m looking to hire one person who will lead that part of the effort. They’ll work alone from home, and be responsible for two things. First, extending the tool (arch or svn) in ways that help the project. Such extensions will be released under an open source licence, and hopefully embraced by the tools maintainers and included in the mainline code for the tool. And second, they will be responsible for our large-scale implementation of SCCM, using that tool, and building the management scripts and other infrastructure to support such a large, and hopefully highly automated, set of repositories.
Would you be interested in this position? What attributes and experience do you think would make you a great person to have on the team? What would your salary expectation be, as a monthly figure, for a one year contract full time?
I’m currently on your continent, well, just off it. On Lizard Island, up North. Am headed today for Brisbane, then on the 17th to Launceston via Melbourne. If you happen to be on any of those stops, would you be interested in meeting up to discuss it further?
If you’re curious you can find out a bit more about me at www.markshuttleworth.com. This project is much lower key than some of what you’ll find there. It’s a very long shot indeed. But if at worst all that happens is a bunch of open source work gets funded at my expense I’ll feel it was money well spent.
Cheers, Mark
===== — “Good judgement comes from experience, and often experience comes from bad judgement” – Rita Mae Brown
I have always liked cryptography, and public-key cryptography in particularly. When Pretty Good Privacy (PGP) first came out in 1991, I not only started using it, also but looking at the documentation and the code to see how it worked. I created my own implementation in C using very small keys, just to better understand.
Cryptography has been running a race against both faster and cheaper computing power. And these days, with banking and most other aspects of our lives entirely relying on secure communications, it’s a very juicy target for bad actors.
About 5 years ago, the National (USA) Institute for Science and Technology (NIST) initiated a search for cryptographic algorithmic that should withstand a near-future world where quantum computers with a significant number of qubits are a reality. There have been a number of rounds, which mid 2020 saw round 3 and the finalists.
This submission caught my eye some time ago: Classic McEliece, and out of the four finalists it’s the only one that is not lattice-based [wikipedia link].
Tiny side-track, you may wonder where does the McEleice name come from? From mathematician Robert McEleice (1942-2019). McEleice developed his cryptosystem in 1978. So it’s not just named after him, he designed it. For various reasons that have nothing to do with the mathematical solidity of the ideas, it didn’t get used at the time. He’s done plenty cool other things, too. From his Caltech obituary:
He made fundamental contributions to the theory and design of channel codes for communication systems—including the interplanetary telecommunication systems that were used by the Voyager, Galileo, Mars Pathfinder, Cassini, and Mars Exploration Rover missions.
Back to lattices, there are both unknowns (aspects that have not been studied in exhaustive depth) and recent mathematical attacks, both of which create uncertainty – in the crypto sphere as well as for business and politics. Given how long it takes for crypto schemes to get widely adopted, the latter two are somewhat relevant, particularly since cyber security is a hot topic.
Lattices are definitely interesting, but given what we know so far, it is my feeling that systems based on lattices are more likely to be proven breakable than Classic McEleice, which come to this finalists’ table with 40+ years track record of in-depth analysis. Mind that all finalists are of course solid at this stage – but NIST’s thoughts on expected developments and breakthroughs is what is likely to decide the winner. NIST are not looking for shiny, they are looking for very very solid in all possible ways.
Prof Buchanan recently published implementations for the finalists, and did some benchmarks where we can directly compare them against each other.
We can see that Classic McEleice’s key generation is CPU intensive, but is that really a problem? The large size of its public key may be more of a factor (disadvantage), however the small ciphertext I think more than offsets that disadvantage.
As we’re nearing the end of the NIST process, in my opinion, fast encryption/decryption and small cyphertext, combined with the long track record of in-depth analysis, may still see Classic McEleice come out the winner.
GKE in Production - Part 1 This tutorial is part of a series I am creating on creating, running and managing Kubernetes on GCP the way I do in my day job.
Note: There may be some things I have skimmed over, if so or you see a glaring hole in my configuration, please drop me a line via the contact page linked at the top of the site.
What we will build In this first tutorial, we will be building a standard GKE cluster on Google Cloud Platform and deploying the hello world container to confirm everything is working.
Living in California, I’ve (sadly) grown accustomed to needing to keep track of our local air quality index (AQI) ratings, particularly as we live close to places where large wildfires happen every other year.
Last year, Josh and I bought a PurpleAir outdoor air quality meter, which has been great. We contribute our data to a collection of very local air quality meters, which is important, since the hilly nature of the North Bay means that the nearest government air quality ratings can be significantly different to what we experience here in Petaluma.
I recently went looking to pull my PurpleAir sensor data into my Home Assistant setup. Unfortunately, the PurpleAir API does not return the AQI metric for air quality, only the raw PM2.5/PM5/PM10 numbers. After some searching, I found a nice template sensor solution on the Home Assistant forums, which I’ve modernised by adding the AQI as a sub-sensor, and adding unique ID fields to each useful sensor, so that you can assign them to a location.
You’ll end up with sensors for raw PM2.5, the PM2.5 AQI value, the US EPA air quality category, air pressure, relative humidity and air pressure.
How to use this
First up, visit the PurpleAir Map, find the sensor you care about, click “get this widget�, and then “JSON�. That will give you the URL to set as the resource key in purpleair.yaml.
Adding the configuration
In HomeAssistant, add the following line to your configuration.yaml:
sensor:!includepurpleair.yaml
and then add the following contents to purpleair.yaml
-platform:restname:'PurpleAir'# Substitute in the URL of the sensor you care about. To find the URL, go# to purpleair.com/map, find your sensor, click on it, click on "Get This# Widget" then click on "JSON".resource:https://www.purpleair.com/json?key={KEY_GOES_HERE}&show={SENSOR_ID}# Only query once a minute to avoid rate limits:scan_interval:60# Set this sensor to be the AQI value.## Code translated from JavaScript found at:# https://docs.google.com/document/d/15ijz94dXJ-YAZLi9iZ_RaBwrZ4KtYeCy08goGBwnbCU/edit#value_template:>{{ value_json["results"][0]["Label"] }}unit_of_measurement:""# The value of the sensor can't be longer than 255 characters, but the# attributes can. Store away all the data for use by the templates below.json_attributes:-results-platform:templatesensors:purpleair_aqi:unique_id:'purpleair_SENSORID_aqi_pm25'friendly_name:'PurpleAirPM2.5AQI'value_template:>{% macro calcAQI(Cp, Ih, Il, BPh, BPl) -%}{{ (((Ih - Il)/(BPh - BPl)) * (Cp - BPl) + Il)|round|float }}{%- endmacro %}{% if (states('sensor.purpleair_pm25')|float) > 1000 %}invalid{% elif (states('sensor.purpleair_pm25')|float) > 350.5 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 500.0, 401.0, 500.0, 350.5) }}{% elif (states('sensor.purpleair_pm25')|float) > 250.5 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 400.0, 301.0, 350.4, 250.5) }}{% elif (states('sensor.purpleair_pm25')|float) > 150.5 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 300.0, 201.0, 250.4, 150.5) }}{% elif (states('sensor.purpleair_pm25')|float) > 55.5 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 200.0, 151.0, 150.4, 55.5) }}{% elif (states('sensor.purpleair_pm25')|float) > 35.5 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 150.0, 101.0, 55.4, 35.5) }}{% elif (states('sensor.purpleair_pm25')|float) > 12.1 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 100.0, 51.0, 35.4, 12.1) }}{% elif (states('sensor.purpleair_pm25')|float) >= 0.0 %}{{ calcAQI((states('sensor.purpleair_pm25')|float), 50.0, 0.0, 12.0, 0.0) }}{% else %}invalid{% endif %}unit_of_measurement:"bit"purpleair_description:unique_id:'purpleair_SENSORID_description'friendly_name:'PurpleAirAQIDescription'value_template:>{% if (states('sensor.purpleair_aqi')|float) >= 401.0 %}Hazardous{% elif (states('sensor.purpleair_aqi')|float) >= 301.0 %}Hazardous{% elif (states('sensor.purpleair_aqi')|float) >= 201.0 %}Very Unhealthy{% elif (states('sensor.purpleair_aqi')|float) >= 151.0 %}Unhealthy{% elif (states('sensor.purpleair_aqi')|float) >= 101.0 %}Unhealthy for Sensitive Groups{% elif (states('sensor.purpleair_aqi')|float) >= 51.0 %}Moderate{% elif (states('sensor.purpleair_aqi')|float) >= 0.0 %}Good{% else %}undefined{% endif %}entity_id:sensor.purpleairpurpleair_pm25:unique_id:'purpleair_SENSORID_pm25'friendly_name:'PurpleAirPM2.5'value_template:"{{state_attr('sensor.purpleair','results')[0]['PM2_5Value']}}"unit_of_measurement:"μg/m3"entity_id:sensor.purpleairpurpleair_temp:unique_id:'purpleair_SENSORID_temperature'friendly_name:'PurpleAirTemperature'value_template:"{{state_attr('sensor.purpleair','results')[0]['temp_f']}}"unit_of_measurement:"°F"entity_id:sensor.purpleairpurpleair_humidity:unique_id:'purpleair_SENSORID_humidity'friendly_name:'PurpleAirHumidity'value_template:"{{state_attr('sensor.purpleair','results')[0]['humidity']}}"unit_of_measurement:"%"entity_id:sensor.purpleairpurpleair_pressure:unique_id:'purpleair_SENSORID_pressure'friendly_name:'PurpleAirPressure'value_template:"{{state_attr('sensor.purpleair','results')[0]['pressure']}}"unit_of_measurement:"hPa"entity_id:sensor.purpleair
Quirks
I had difficulty getting the AQI to display as a numeric graph when I didn’t set a unit. I went with bit, and that worked just fine. 🤷�♂�
So, this idea has been brewing for a while now… try and watch all of Doctor Who. All of it. All 38 seasons. Today(ish), we started. First up, from 1963 (first aired not quite when intended due to the Kennedy assassination): An Unearthly Child. The first episode of the first serial.
A lot of iconic things are there from the start: the music, the Police Box, embarrassing moments of not quite remembering what time one is in, and normal humans accidentally finding their way into the TARDIS.
I first saw this way back when a child, where they were repeated on ABC TV in Australia for some anniversary of Doctor Who (I forget which one). Well, I saw all but the first episode as the train home was delayed and stopped outside Caulfield for no reason for ages. Some things never change.
Of course, being a show from the early 1960s, there’s some rougher spots. We’re not about to have the picture of diversity, and there’s going to be casual racism and sexism. What will be interesting is noticing these things today, and contrasting with my memory of them at the time (at least for episodes I’ve seen before), and what I know of the attitudes of the time.
“This year-ometer is not calculating properly” is a very 2020 line though (technically from the second episode).
It’s been a while since my last post about tracking support for the Oculus Rift in February. There’s been big improvements since then – working really well a lot of the time. It’s gone from “If I don’t make any sudden moves, I can finish an easy Beat Saber level” to “You can’t hide from me!” quality.
Equally, there are still enough glitches and corner cases that I think I’ll still be at this a while.
Here’s a video from 3 weeks ago of (not me) playing Beat Saber on Expert+ setting showing just how good things can be now:
Strap in. Here’s what I’ve worked on in the last 6 weeks:
Pose Matching improvements
Most of the biggest improvements have come from improving the computer vision algorithm that’s matching the observed LEDs (blobs) in the camera frames to the 3D models of the devices.
I split the brute-force search algorithm into 2 phases. It now does a first pass looking for ‘obvious’ matches. In that pass, it does a shallow graph search of blobs and their nearest few neighbours against LEDs and their nearest neighbours, looking for a match using a “Strong” match metric. A match is considered strong if expected LEDs match observed blobs to within 1.5 pixels.
Coupled with checks on the expected orientation (matching the Gravity vector detected by the IMU) and the pose prior (expected position and orientation are within predicted error bounds) this short-circuit on the search is hit a lot of the time, and often completes within 1 frame duration.
In the remaining tricky cases, where a deeper graph search is required in order to recover the pose, the initial search reduces the number of LEDs and blobs under consideration, speeding up the remaining search.
I also added an LED size model to the mix – for a candidate pose, it tries to work out how large (in pixels) each LED should appear, and use that as a bound on matching blobs to LEDs. This helps reduce mismatches as devices move further from the camera.
LED labelling
When a brute-force search for pose recovery completes, the system now knows the identity of various blobs in the camera image. One way it avoids a search next time is to transfer the labels into future camera observations using optical-flow tracking on the visible blobs.
The problem is that even sped-up the search can still take a few frame-durations to complete. Previously LED labels would be transferred from frame to frame as they arrived, but there’s now a unique ID associated with each blob that allows the labels to be transferred even several frames later once their identity is known.
IMU Gyro scale
One of the problems with reverse engineering is the guesswork around exactly what different values mean. I was looking into why the controller movement felt “swimmy” under fast motions, and one thing I found was that the interpretation of the gyroscope readings from the IMU was incorrect.
The touch controllers report IMU angular velocity readings directly as a 16-bit signed integer. Previously the code would take the reading and divide by 1024 and use the value as radians/second.
From teardowns of the controller, I know the IMU is an Invensense MPU-6500. From the datasheet, the reported value is actually in degrees per second and appears to be configured for the +/- 2000 °/s range. That yields a calculation of Gyro-rad/s = Gyro-°/s * (2000 / 32768) * (?/180) – or a divisor of 938.734.
The 1024 divisor was under-estimating rotation speed by about 10% – close enough to work until you start moving quickly.
Limited interpolation
If we don’t find a device in the camera views, the fusion filter predicts motion using the IMU readings – but that quickly becomes inaccurate. In the worst case, the controllers fly off into the distance. To avoid that, I added a limit of 500ms for ‘coasting’. If we haven’t recovered the device pose by then, the position is frozen in place and only rotation is updated until the cameras find it again.
Exponential filtering
I implemented a 1-Euro exponential smoothing filter on the output poses for each device. This is an idea from the Project Esky driver for Project North Star/Deck-X AR headsets, and almost completely eliminates jitter in the headset view and hand controllers shown to the user. The tradeoff is against introducing lag when the user moves quickly – but there are some tunables in the exponential filter to play with for minimising that. For now I’ve picked some values that seem to work reasonably.
Non-blocking radio
Communications with the touch controllers happens through USB radio command packets sent to the headset. The main use of radio commands in OpenHMD is to read the JSON configuration block for each controller that is programmed in at the factory. The configuration block provides the 3D model of LED positions as well as initial IMU bias values.
Unfortunately, reading the configuration block takes a couple of seconds on startup, and blocks everything while it’s happening. Oculus saw that problem and added a checksum in the controller firmware. You can read the checksum first and if it hasn’t changed use a local cache of the configuration block. Eventually, I’ll implement that caching mechanism for OpenHMD but in the meantime it still reads the configuration blocks on each startup.
As an interim improvement I rewrote the radio communication logic to use a state machine that is checked in the update loop – allowing radio communications to be interleaved without blocking the regularly processing of events. It still interferes a bit, but no longer causes a full multi-second stall as each hand controller turns on.
Haptic feedback
The hand controllers have haptic feedback ‘rumble’ motors that really add to the immersiveness of VR by letting you sense collisions with objects. Until now, OpenHMD hasn’t had any support for applications to trigger haptic events. I spent a bit of time looking at USB packet traces with Philipp Zabel and we figured out the radio commands to turn the rumble motors on and off.
In the Rift CV1, the haptic motors have a mode where you schedule feedback events into a ringbuffer – effectively they operate like a low frequency audio device. However, that mode was removed for the Rift S (and presumably in the Quest devices) – and deprecated for the CV1.
With that in mind, I aimed for implementing the unbuffered mode, with explicit ‘motor on + frequency + amplitude’ and ‘motor off’ commands sent as needed. Thanks to already having rewritten the radio communications to use a state machine, adding haptic commands was fairly easy.
I’d say the biggest problem right now is unexpected tracking loss and incorrect pose extractions when I’m not expecting them. Especially my right controller will suddenly glitch and start jumping around. Looking at a video of the debug feed, it’s not obvious why that’s happening:
To fix cases like those, I plan to add code to log the raw video feed and the IMU information together so that I can replay the video analysis frame-by-frame and investigate glitches systematically. Those recordings will also work as a regression suite to test future changes.
Sensor fusion efficiency
The Kalman filter I have implemented works really nicely – it does the latency compensation, predicts motion and extracts sensor biases all in one place… but it has a big downside of being quite expensive in CPU. The Unscented Kalman Filter CPU cost grows at O(n^3) with the size of the state, and the state in this case is 43 dimensional – 22 base dimensions, and 7 per latency-compensation slot. Running 1000 updates per second for the HMD and 500 for each of the hand controllers adds up quickly.
At some point, I want to find a better / cheaper approach to the problem that still provides low-latency motion predictions for the user while still providing the same benefits around latency compensation and bias extraction.
Lens Distortion
To generate a convincing illusion of objects at a distance in a headset that’s only a few centimetres deep, VR headsets use some interesting optics. The LCD/OLED panels displaying the output get distorted heavily before they hit the users eyes. What the software generates needs to compensate by applying the right inverse distortion to the output video.
Everyone that tests the CV1 notices that the distortion is not quite correct. As you look around, the world warps and shifts annoyingly. Sooner or later that needs fixing. That’s done by taking photos of calibration patterns through the headset lenses and generating a distortion model.
Camera / USB failures
The camera feeds are captured using a custom user-space UVC driver implementation that knows how to set up the special synchronisation settings of the CV1 and DK2 cameras, and then repeatedly schedules isochronous USB packet transfers to receive the video.
Occasionally, some people experience failure to re-schedule those transfers. The kernel rejects them with an out-of-memory error failing to set aside DMA memory (even though it may have been running fine for quite some time). It’s not clear why that happens – but the end result at the moment is that the USB traffic for that camera dies completely and there’ll be no more tracking from that camera until the application is restarted.
Often once it starts happening, it will keep happening until the PC is rebooted and the kernel memory state is reset.
Occluded cases
Tracking generally works well when the cameras get a clear shot of each device, but there are cases like sighting down the barrel of a gun where we expect that the user will line up the controllers in front of one another, and in front of the headset. In that case, even though we probably have a good idea where each device is, it can be hard to figure out which LEDs belong to which device.
If we already have a good tracking lock on the devices, I think it should be possible to keep tracking even down to 1 or 2 LEDs being visible – but the pose assessment code will have to be aware that’s what is happening.
Upstreaming
April 14th marks 2 years since I first branched off OpenHMD master to start working on CV1 tracking. How hard can it be, I thought? I’ll knock this over in a few months.
Since then I’ve accumulated over 300 commits on top of OpenHMD master that eventually all need upstreaming in some way.
One thing people have expressed as a prerequisite for upstreaming is to try and remove the OpenCV dependency. The tracking relies on OpenCV to do camera distortion calculations, and for their PnP implementation. It should be possible to reimplement both of those directly in OpenHMD with a bit of work – possibly using the fast LambdaTwist P3P algorithm that Philipp Zabel wrote, that I’m already using for pose extraction in the brute-force search.
Others
I’ve picked the top issues to highlight here. https://github.com/thaytan/OpenHMD/issues has a list of all the other things that are still on the radar for fixing eventually.
Other Headsets
At some point soon, I plan to put a pin in the CV1 tracking and look at adapting it to more recent inside-out headsets like the Rift S and WMR headsets. I implemented 3DOF support for the Rift S last year, but getting to full positional tracking for that and other inside-out headsets means implementing a SLAM/VIO tracking algorithm to track the headset position.
Once the headset is tracking, the code I’m developing here for CV1 to find and track controllers will hopefully transfer across – the difference with inside-out tracking is that the cameras move around with the headset. Finding the controllers in the actual video feed should work much the same.
Sponsorship
This development happens mostly in my spare time and partly as open source contribution time at work at Centricular. I am accepting funding through Github Sponsorships to help me spend more time on it – I’d really like to keep helping Linux have top-notch support for VR/AR applications. Big thanks to the people that have helped get this far.
Why that particular date? It’s Vincent van Gogh’s birthday (1853), and there is a fairly strong argument that the Dutch painter suffered from bipolar (among other things).
The image on the side is Vincent’s drawing “Worn Out” (from 1882), and it seems to capture the feeling rather well – whether (hypo)manic, depressed, or mixed. It’s exhausting.
Bipolar is complicated, often undiagnosed or misdiagnosed, and when only treated with anti-depressants, it can trigger the (hypo)mania – essentially dragging that person into that state near-permanently.
Have you heard of Bipolar II?
Hypo-mania is the “lesser” form of mania that distinguishes Bipolar I (the classic “manic depressive” syndrome) from Bipolar II. It’s “lesser” only in the sense that rather than someone going so hyper they may think they can fly (Bipolar I is often identified when someone in manic state gets admitted to hospital – good catch!) while with Bipolar II the hypo-mania may actually exhibit as anger. Anger in general, against nothing in particular but potentially everyone and everything around them. Or, if it’s a mixed episode, anger combined with strong negative thoughts. Either way, it does not look like classic mania. It is, however, exhausting and can be very debilitating.
Bipolar II people often present to a doctor while in depressed state, and GPs (not being psychiatrists) may not do a full diagnosis. Note that D.A.S. and similar test sheets are screening tools, they are not diagnostic. A proper diagnosis is more complex than filling in a form some questions (who would have thought!)
Call to action
If you have a diagnosis of depression, only from a GP, and are on medication for this, I would strongly recommend you also get a referral to a psychiatrist to confirm that diagnosis.
Our friends at the awesome Black Dog Institute have excellent information on bipolar, as well as a quick self-test – if that shows some likelihood of bipolar, go get that referral and follow up ASAP.
I will be writing more about the topic in the coming time.
This post documented an older method of building SteamVR-OpenHMD. I moved them to a page here. That version will be kept up to date for any future changes, so go there.
I’ve had a few people ask how to test my OpenHMD development branch of Rift CV1 positional tracking in SteamVR. Here’s what I do:
It is important to configure in release mode, as the kalman filtering code is generally too slow for real-time in debug mode (it has to run 2000 times per second)
Please note – only Rift sensors on USB 3.0 ports will work right now. Supporting cameras on USB 2.0 requires someone implementing JPEG format streaming and decoding.
It can be helpful to test OpenHMD is working by running the simple example. Check that it’s finding camera sensors at startup, and that the position seems to change when you move the headset:
Calibrate your expectations for how well tracking is working right now! Hint: It’s very experimental
Start SteamVR. Hopefully it should detect your headset and the light(s) on your Rift Sensor(s) should power on.
Meson
I prefer the Meson build system here. There’s also a cmake build for SteamVR-OpenHMD you can use instead, but I haven’t tested it in a while and it sometimes breaks as I work on my development branch.
I spent some time this weekend implementing a couple of my ideas for improving the way the tracking code in OpenHMD filters and rejects (or accepts) possible poses when trying to match visible LEDs to the 3D models for each device.
In general, the tracking proceeds in several steps (in parallel for each of the 3 devices being tracked):
Do a brute-force search to match LEDs to 3D models, then (if matched)
Assign labels to each LED blob in the video frame saying what LED they are.
Send an update to the fusion filter about the position / orientation of the device
Then, as each video frame arrives:
Use motion flow between video frames to track the movement of each visible LED
Use the IMU + vision fusion filter to predict the position/orientation (pose) of each device, and calculate which LEDs are expected to be visible and where.
Try and match up and refine the poses using the predicted pose prior and labelled LEDs. In the best case, the LEDs are exactly where the fusion predicts they’ll be. More often, the orientation is mostly correct, but the position has drifted and needs correcting. In the worst case, we send the frame back to step 1 and do a brute-force search to reacquire an object.
The goal is to always assign the correct LEDs to the correct device (so you don’t end up with the right controller in your left hand), and to avoid going back to the expensive brute-force search to re-acquire devices as much as possible
What I’ve been working on this week is steps 1 and 3 – initial acquisition of correct poses, and fast validation / refinement of the pose in each video frame, and I’ve implemented two new strategies for that.
Gravity Vector matching
The first new strategy is to reject candidate poses that don’t closely match the known direction of gravity for each device. I had a previous implementation of that idea which turned out to be wrong, so I’ve re-worked it and it helps a lot with device acquisition.
The IMU accelerometer and gyro can usually tell us which way up the device is (roll and pitch) but not which way they are facing (yaw). The measure for ‘known gravity’ comes from the fusion Kalman filter covariance matrix – how certain the filter is about the orientation of the device. If that variance is small this new strategy is used to reject possible poses that don’t have the same idea of gravity (while permitting rotations around the Y axis), with the filter variance as a tolerance.
Partial tracking matches
The 2nd strategy is based around tracking with fewer LED correspondences once a tracking lock is acquired. Initial acquisition of the device pose relies on some heuristics for how many LEDs must match the 3D model. The general heuristic threshold I settled on for now is that 2/3rds of the expected LEDs must be visible to acquire a cold lock.
With the new strategy, if the pose prior has a good idea where the device is and which way it’s facing, it allows matching on far fewer LED correspondences. The idea is to keep tracking a device even down to just a couple of LEDs, and hope that more become visible soon.
While this definitely seems to help, I think the approach can use more work.
Status
With these two new approaches, tracking is improved but still quite erratic. Tracking of the headset itself is quite good now and for me rarely loses tracking lock. The controllers are better, but have a tendency to “fly off my hands” unexpectedly, especially after fast motions.
I have ideas for more tracking heuristics to implement, and I expect a continuous cycle of refinement on the existing strategies and new ones for some time to come.
For now, here’s a video of me playing Beat Saber using tonight’s code. The video shows the debug stream that OpenHMD can generate via Pipewire, showing the camera feed plus overlays of device predictions, LED device assignments and tracked device positions. Red is the headset, Green is the right controller, Blue is the left controller.
Initial tracking is completely wrong – I see some things to fix there. When the controllers go offline due to inactivity, the code keeps trying to match LEDs to them for example, and then there are some things wrong with how it’s relabelling LEDs when they get incorrect assignments.
After that, there are periods of good tracking with random tracking losses on the controllers – those show the problem cases to concentrate on.
These lack of updates are also likely because I’ve been quite caught up with stuff.
Monday I had a steak from Bay Leaf Steakhouse for dinner. It was kind of weird eating it from packs, but then I’m reminded you could do this in economy class. Tuesday I wanted to attempt to go vegetarian and by the time I was done with a workout, the only place was a chap fan shop (Leong Heng) where I had a mixture of Chinese and Indian chap fan. The Indian stall is run by an ex-Hyatt staff member who immediately recognised me! Wednesday, Alice came to visit, so we got to Hanks, got some alcohol, and managed a smorgasbord of food from Pickers/Sate Zul/Lila Wadi. Night ended very late, and on Thursday, visited Hai Tian for their famous salted egg squid and prawns in a coconut shell. Friday was back to being normal, so I grabbed a pizza from Mint Pizza (this time I tried their Aussie variant). Saturday, today, I hit up Rasa Sayang for some matcha latte, but grabbed food from Classic Pilot Cafe, which Faeeza owns! It was the famous salted egg chicken, double portion, half rice.
As for workouts, I did sign up for Mantas but found it pretty hard to do, timezone wise. I did spend a lot of time jogging on the beach (this has been almost a daily affair). Monday I also did 2 MD workouts, Tuesday 1 MD workout, Wednesday half a MD workout, Thursday I did a Ping workout at Pwrhouse (so good!), Friday 1 MD workout, and Saturday an Audrey workout at Pwrhouse and 1 MD workout.
Wednesday I also found out that Rasmus passed away. Frankly, there are no words.
Thursday, my Raspberry Pi 400 arrived. I set it up in under ten minutes, connecting it to the TV here. It “just works”. I made a video, which I should probably figure out how to upload to YouTube after I stitch it together. I have to work on using it a lot more.
COVID-19 cases are through the roof in Malaysia. This weekend we’ve seen two days of case breaking records, with today being 5,728 (yesterday was something close). Nutty. Singapore suspended the reciprocal green lane (RGL) agreement with Malaysia for the next 3 months.
I’ve managed to finish Bridgerton. I like the score. Finding something on Netflix is proving to be more difficult, regardless of having a VPN. Honestly, this is why Cable TV wins… linear programming that you’re just fed.
Stock market wise, I’ve been following the GameStop short squeeze, and even funnier is the Top Glove one, that they’re trying to repeat in Malaysia. Bitcoin seems to be doing “reasonably well” and I have to say, I think people are starting to realise decentralised services have a future. How do we get there?
What an interesting week, I look forward to more productive time. I’m still writing in my Hobonichi Techo, so at least that’s where most personal stuff ends up, I guess?
I hit an important OpenHMD milestone tonight – I completed a Beat Saber level using my Oculus Rift CV1!
I’ve been continuing to work on integrating Kalman filtering into OpenHMD, and on improving the computer vision that matches and tracks device LEDs. While I suspect noone will be completing Expert levels just yet, it’s working well enough that I was able to play through a complete level of Beat Saber. For a long time this has been my mental benchmark for tracking performance, and I’m really happy
Check it out:
I should admit at this point that completing this level took me multiple attempts. The tracking still has quite a tendency to lose track of controllers, or to get them confused and swap hands suddenly.
I have a list of more things to work on. See you at the next update!
What an unplanned day. I woke up in time to do an MD workout, despite feeling a little sore. So maybe I was about 10 minutes late and I missed the first set, but his workouts are so long, and I think there were seven sets anyway. Had a good brunch shortly thereafter.
Did a bit of reading, and then I decided to do a beach boardwalk walk… turns out they were policing the place, and you can’t hit the boardwalk. But the beach is fair game? So I went back to the hotel, dropped off my slippers, and went for a beach jog. Pretty nutty.
Came back to read a little more and figured I might as well do another MD workout. Then I headed out for dinner, trying out a new place — Mint Pizza. Opened 20.12.2020, and they’re empty, and their pizza is actually pretty good. Lamb and BBQ chicken, they did half-and-half.
Twitter was discussing Raspberry Pi’s, and all I could see is a lot of misinformation, which is truly shocking. The irony is that open source has been running the Internet for so long, and progressive web apps have come such a long way…
Back in the day when I did OpenOffice.org or Linux training even, we always did say you should learn concepts and not tools. From the time we ran Linux installfests in the late-90s in Sunway Pyramid (back then, yes, Linux was hard, and you had winmodems), but I had forgotten that I even did stuff for school teachers and NGOs back in 2002… I won’t forget PC Gemilang either…
Anyway, I placed an order again for another Raspberry Pi 400. I am certain that most people talk so much crap, without realising that Malaysia isn’t a developed nation and most people can’t afford a Mac let alone a PC. Laptops aren’t cheap. And there are so many other issues…. Saying Windows is still required in 2021 is the nuttiest thing I’ve heard in a long time. Easy to tweet, much harder to think about TCO, and realise where in the journey Malaysia is.
Maybe the best thing was that Malaysian Twitter learned about technology. I doubt many realised the difference between a Pi board vs the 400, but hey, the fact that they talked about tech is still a win (misinformed, but a win).
Today is the first day that in the state of Pahang, we have to encounter what many Malaysians are referring to as the Movement Control Order 2.0 (MCO 2.0). I think everyone finally agrees with the terminology that this is a lockdown now, because I remember back in the day when I was calling it that, I’d definitely offend a handful of journalists.
This is one interesting change for me compared to when I last wrote Life with Rona — Day 56 of being indoors and not even leaving my household, in Kuala Lumpur. I am now not in the state, I am living in a hotel, and I am obviously moving around a little more since we have access to the beach.
KL/Selangor and several other states have already been under the MCO 2.0 since January 13 2021, and while it was supposed to end on January 26, it seems like they’ve extended and harmonised the dates for Peninsular Malaysia to end on February 4 2021. I guess everyone got the “good news” yesterday. The Prime Minister announced some kind of aid last week, but it is still mostly a joke.
Today was the 2nd day I woke up at around 2.30pm because I went to bed at around 8am. First day I had a 23.5 hour uptime, and the today was less brutal, but working from 1-8am with the PST timezone is pretty brutal. Consequently, I barely got too much done, and had one meal, vegetarian, two packs that included rice. I did get to walk by the beach (between Teluk Cempedak and Teluk Cempedak 2), did quite a bit of exercise there and I think even the monkeys are getting hungry… lots of stray cats and monkeys. Starbucks closes at 7pm, and I rocked up at 7.10pm (this was just like yesterday, when I arrived at 9.55pm and was told they wouldn’t grant me a coffee!).
While writing this entry, I did manage to get into a long video call with some friends and I guess it was good catching up with people in various states. It also is what prevented me from publishing this entry!
Day 2
I did wake up reasonable early today because I had pre-ordered room service to arrive at 9am. There is a fixed menu at the hotel for various cuisines (RM48/pax, thankfully gratis for me) and I told them I prefer not having to waste, so just give me what I want which is off menu items anyway. Roti telur double telur (yes, I know it is a roti jantan) with some banjir dhal and sambal and a bit of fruit on the side with two teh tariks. They delivered as requested. I did forget to ask for a jar of honey but that is OK, there is always tomorrow.
I spent most of the day vacillating, and wouldn’t consider it productive by any measure. Just chit chats and napping. It did rain today after a long time, so the day seemed fairly dreary.
When I finally did awaken from my nap, I went for a run on the beach. I did it barefoot. I have no idea if this is how it is supposed to be done, or if you are to run nearer the water or further up above, but I did move around between the two quite often. The beach is still pretty dead, but it is expected since no one is allowed to go unless you’re a hotel guest.
The hotel has closed 3/4 of their villages (blocks) and moved everyone to the village I’m staying in (for long stay guests…). I’m thankful I have a pretty large suite, it is a little over 980sqft, and the ample space, while smaller than my home, is still welcome.
Post beach run, I did a workout with MD via Instagram. It was strength/HIIT based, and I burnt a tonne, because he gave us one of his signature 1.5h classes. It was longer than the 80 minute class he normally charges RM50 for (I still think this is undervaluing his service, but he really does care and does it for the love of seeing his students grow!).
Post-workout I decided to head downtown to find some dinner. Everything at the Teluk Cemepdak block of shops was closed, so they’re not even bothered with doing takeaway. Sg. Lembing steakhouse seemed to have cars parked, Vanggey was empty (Crocodile Rock was open, can’t say if there was a crowd, because the shared parking lot was empty), there was a modest queue at Sate Zul, and further down, Lena was closed, Pickers was open for takeaway but looked pretty closed, Tjantek was open surprisingly, and then I thought I’d give Nusantara a try again, this time for food, but their chef had just gone home at about 8pm. Oops. So I drove to LAN burger, initially ordering just one chicken double special; however they looked like they could use the business so I added on a beef double special. They now accept Boost payments so have joined the e-wallet era. One less place to use cash, which is also why I really like Kuantan. On the drive back, Classic Pilot Cafe was also open and I guess I’ll be heading there too during this lockdown.
Came back to the room to finish both burgers in probably under 15 minutes. While watching the first episode of Bridgerton on Netflix. I’m not sure what really captivates, but I will continue on (I still haven’t finished the first episode). I need to figure out how to use the 2 TVs that I have in this room — HDMI cable? Apple TV? Not normally using a TV, all this is clearly more complex than I care to admit.
I soaked longer than expected, ended up a prune, but I’m sure it will give me good rest!
One thought to leave with:
“Learn to enjoy every minute of your life. Be happy now. Don’t wait for something outside of yourself to make you happy in the future.” — Earl Nightingale
In my experience, the C programming language is still hard to beat, even 50 years after it was first developed (and I feel the same way about UNIX). When it comes to general-purpose utility, low-level systems programming, performance, and portability (even to tiny embedded systems), I would choose C over most modern or fashionable alternatives. In some cases, it is almost the only choice.
Many developers believe that it is difficult to write secure and reliable software in C, due to its free pointers, the lack of enforced memory integrity, and the lack of automatic memory management; however in my opinion it is possible to overcome these risks with discipline and a more secure system of libraries constructed on top of C and libc. Daniel J. Bernstein and Wietse Venema are two developers who have been able to write highly secure, stable, reliable software in C.
My other favourite language is Python. Although Python has numerous desirable features, my favourite is the light-weight syntax: in Python, block structure is indicated by indentation, and braces and semicolons are not required. Apart from the pleasure and relief of reading and writing such light and clear code, which almost appears to be executable pseudo-code, there are many other benefits. In C or JavaScript, if you omit a trailing brace somewhere in the code, or insert an extra brace somewhere, the compiler may tell you that there is a syntax error at the end of the file. These errors can be annoying to track down, and cannot occur in Python. Python not only looks better, the clear syntax helps to avoid errors.
The obvious disadvantage of Python, and other dynamic interpreted languages, is that most programs run extremely slower than C programs. This limits the scope and generality of Python. No AAA or performance-oriented video game engines are programmed in Python. The language is not suitable for low-level systems programming, such as operating system development, device drivers, filesystems, performance-critical networking servers, or real-time systems.
C is a great all-purpose language, but the code is uglier than Python code. Once upon a time, when I was experimenting with the Plan 9 operating system (which is built on C, but lacks Python), I missed Python’s syntax, so I decided to do something about it and write a little preprocessor for C. This converts from a “Pythonesque” indented syntax to regular C with the braces and semicolons. Having forked a little dialect of my own, I continued from there adding other modules and features (which might have been a mistake, but it has been fun and rewarding).
At first I called this translator Brace, because it added in the braces for me. I now call the language CZ. It sounds like “C-easy”. Ease-of-use for developers (DX) is the primary goal. CZ has all of the features of C, and translates cleanly into C, which is then compiled to machine code as normal (using any C compiler; I didn’t write one); and so CZ has the same features and performance as C, but enjoys a more pleasing syntax.
CZ is now self-hosted, in that the translator is written in the language CZ. I confess that originally I wrote most of it in Perl; I’m proficient at Perl, but I consider it to be a fairly ugly language, and overly complicated.
I intend for CZ’s new syntax to be “optional”, ideally a developer will be able to choose to use the normal C syntax when editing CZ, if they prefer it. For this, I need a tool to convert C back to CZ, which I have not fully implemented yet. I am aware that, in addition to traditionalists, some vision-impaired developers prefer to use braces and semicolons, as screen readers might not clearly indicate indentation. A C to CZ translator would of course also be valuable when porting an existing C program to CZ.
CZ has a number of useful features that are not found in standard C, but I did not go so far as C++, which language has been described as “an octopus made by nailing extra legs onto a dog”. I do not consider C to be a dog, at least not in a negative sense; but I think that C++ is not an improvement over plain C. I am creating CZ because I think that it is possible to improve on C, without losing any of its advantages or making it too complex.
One of the most interesting features I added is a simple syntax for fast, light coroutines. I based this on Simon Tatham’s approach to Coroutines in C, which may seem hacky at first glance, but is very efficient and can work very well in practice. I implemented a very fast web server with very clean code using these coroutines. The cost of switching coroutines with this method is little more than the cost of a function call.
CZ has hygienic macros. The regular cpp (C preprocessor) macros are not hygenic and many people consider them hacky and unsafe to use. My CZ macros are safe, and somewhat more powerful than standard C macros. They can be used to neatly add new program control structures. I have plans to further develop the macro system in interesting ways.
I added automatic prototype and header generation, as I do not like having to repeat myself when copying prototypes to separate header files. I added support for the UNIX #! scripting syntax, and for cached executables, which means that CZ can be used like a scripting language without having to use a separate compile or make command, but the programs are only recompiled when something has been changed.
For CZ, I invented a neat approach to portability without conditional compilation directives. Platform-specific library fragments are automatically included from directories having the name of that platform or platform-category. This can work very well in practice, and helps to avoid the nightmare of conditional compilation, feature detection, and Autotools. Using this method, I was able easily to implement portable interfaces to features such as asynchronous IO multiplexing (aka select / poll).
The CZ library includes flexible error handling wrappers, inspired by W. Richard Stevens’ wrappers in his books on Unix Network Programming. If these wrappers are used, there is no need to check return values for error codes, and this makes the code much safer, as an error cannot accidentally be ignored.
CZ has several major faults, which I intend to correct at some point. Some of the syntax is poorly thought out, and I need to revisit it. I developed a fairly rich library to go with the language, including safer data structures, IO, networking, graphics, and sound. There are many nice features, but my CZ library is more prototype than a finished product, there are major omissions, and some features are misconceived or poorly implemented. The misfeatures should be weeded out for the time-being, or moved to an experimental section of the library.
I think that a good software library should come in two parts, the essential low-level APIs with the minimum necessary functionality, and a rich set of high-level convenience functions built on top of the minimal API. I need to clearly separate these two parts in order to avoid polluting the namespaces with all sorts of nonsense!
CZ is lacking a good modern system of symbol namespaces. I can look to Python for a great example. I need to maintain compatibility with C, and avoid ugly symbol encodings. I think I can come up with something that will alleviate the need to type anything like gtk_window_set_default_size, and yet maintain compatibility with the library in question. I want all the power of C, but it should be easy to use, even for children. It should be as easy as BASIC or Processing, a child should be able to write short graphical demos and the like, without stumbling over tricky syntax or obscure compile errors.
Here is an example of a simple CZ program which plots the Mandelbrot set fractal. I think that the program is fairly clear and easy to understand, although there is still some potential to improve and clarify the code.
#!/usr/local/bin/cz --
use b
use ccomplex
Main:
num outside = 16, ox = -0.5, oy = 0, r = 1.5
long i, max_i = 50, rb_i = 30
space()
uint32_t *px = pixel() # CONFIGURE!
num d = 2*r/h, x0 = ox-d*w_2, y0 = oy+d*h_2
for(y, 0, h):
cmplx c = x0 + (y0-d*y)*I
repeat(w):
cmplx w = c
for i=0; i < max_i && cabs(w) < outside; ++i
w = w*w + c
*px++ = i < max_i ? rainbow(i*359 / rb_i % 360) : black
c += d
I wrote a more elaborate variant of this program, which generates images like the one shown below. There are a few tricks used: continuous colouring, rainbow colours, and plotting the logarithm of the iteration count, which makes the plot appear less busy close to the black fractal proper. I sell some T-shirts and other products with these fractal designs online.
I am interested in graph programming, and have been for three decades since I was a teenager. By graph programming, I mean programming and modelling based on mathematical graphs or diagrams. I avoid the term visual programming, because there is no necessary reason that vision impaired folks could not use a graph programming language; a graph or diagram may be perceived, understood, and manipulated without having to see it.
Mathematics is something that naturally exists, outside time and independent of our universe. We humans discover mathematics, we do not invent or create it. One of my main ideas for graph programming is to represent a mathematical (or software) model in the simplest and most natural way, using relational operators. Elementary mathematics can be reduced to just a few such operators:
+
add, subtract, disjoint union, zero
×
multiply, divide, cartesian product, one
^
power, root, logarithm
◢
sin, cos, sin-1, cos-1, hypot, atan2
δ
differential, integral
a set of minimal relational operators for elementary math
I think that a language and notation based on these few operators (and similar) can be considerably simpler and more expressive than conventional math or programming languages.
CZ is for me a stepping-stone toward this goal of an expressive relational graph language. It is more pleasant for me to develop software tools in CZ than in C or another language.
My CZ project has been stalled for quite some time. I foolishly became discouraged after receiving some negative feedback. I now know that honest negative feedback should be valued as an opportunity to improve, and I intend to continue the project until it lacks glaring faults, and is useful for other people. If this project or this article interests you, please contact me and let me know. It is much more enjoyable to work on a project when other people are actively interested in it!
The uBITX uses an Arduino internally. This article describes how to update its software.
Required hardware
The connector on the back is a Mini-B USB connector, so you'll need a "Mini-B to A" USB cable. This is not the same cable as used with older Android smartphones. The Mini-B connector was used with a lot of cameras a decade ago.
You'll also need a computer. I use a laptop with Fedora Linux installed.
Required software for software development
In Fedora all the required software is installed with sudo dnf install arduino git. Add yourself to the users and lock groups with sudo usermod -a -G users,lock $USER (on Debian-style systems use sudo usermod -a -G dialout,lock $USER). You'll need to log out and log in again for that to have an effect (if you want to see which groups you are already in, then use the id command).
Run arduino as your ordinary non-root user to create the directories used by the Arduino IDE. You can quit the IDE once it starts.
Obtain the uBITX software
$ cd ~/Arduino
$ git clone https://github.com/afarhan/ubitxv6.git ubitx_v6.1_code
Connect the uBITX to your computer
Plug in the USB cable and turn on the radio. Running dmesg will show the Arduino appearing as a "USB serial" device:
usb 1-1: new full-speed USB device number 6 using xhci_hcd
usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-1: Product: USB Serial
usbcore: registered new interface driver ch341
usbserial: USB Serial support registered for ch341-uart
ch341 1-1:1.0: ch341-uart converter detected
usb 1-1: ch341-uart converter now attached to ttyUSB1
If you want more information about the USB device then use:
$ lsusb -d 1a86:7523
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics CH340 serial converter
In the last post I had started implementing an Unscented Kalman Filter for position and orientation tracking in OpenHMD. Over the Christmas break, I continued that work.
A Quick Recap
When reading below, keep in mind that the goal of the filtering code I’m writing is to combine 2 sources of information for tracking the headset and controllers.
The first piece of information is acceleration and rotation data from the IMU on each device, and the second is observations of the device position and orientation from 1 or more camera sensors.
The IMU motion data drifts quickly (at least for position tracking) and can’t tell which way the device is facing (yaw, but can detect gravity and get pitch/roll).
The camera observations can tell exactly where each device is, but arrive at a much lower rate (52Hz vs 500/1000Hz) and can take a long time to process (hundreds of milliseconds) to analyse to acquire or re-acquire a lock on the tracked device(s).
The goal is to acquire tracking lock, then use the motion data to predict the motion closely enough that we always hit the ‘fast path’ of vision analysis. The key here is closely enough – the more closely the filter can track and predict the motion of devices between camera frames, the better.
Integration in OpenHMD
When I wrote the last post, I had the filter running as a standalone application, processing motion trace data collected by instrumenting a running OpenHMD app and moving my headset and controllers around. That’s a really good way to work, because it lets me run modifications on the same data set and see what changed.
However, the motion traces were captured using the current fusion/prediction code, which frequently loses tracking lock when the devices move – leading to big gaps in the camera observations and more interpolation for the filter.
By integrating the Kalman filter into OpenHMD, the predictions are improved leading to generally much better results. Here’s one trace of me moving the headset around reasonably vigourously with no tracking loss at all.
If it worked this well all the time, I’d be ecstatic! The predicted position matched the observed position closely enough for every frame for the computer vision to match poses and track perfectly. Unfortunately, this doesn’t happen every time yet, and definitely not with the controllers – although I think the latter largely comes down to the current computer vision having more troubler matching controller poses. They have fewer LEDs to match against compared to the headset, and the LEDs are generally more side-on to a front-facing camera.
Taking a closer look at a portion of that trace, the drift between camera frames when the position is interpolated using the IMU readings is clear.
This is really good. Most of the time, the drift between frames is within 1-2mm. The computer vision can only match the pose of the devices to within a pixel or two – so the observed jitter can also come from the pose extraction, not the filtering.
The worst tracking is again on the Z axis – distance from the camera in this case. Again, that makes sense – with a single camera matching LED blobs, distance is the most uncertain part of the extracted pose.
Losing Track
The trace above is good – the computer vision spots the headset and then the filtering + computer vision track it at all times. That isn’t always the case – the prediction goes wrong, or the computer vision fails to match (it’s definitely still far from perfect). When that happens, it needs to do a full pose search to reacquire the device, and there’s a big gap until the next pose report is available.
That looks more like this
This trace has 2 kinds of errors – gaps in the observed position timeline during full pose searches and erroneous position reports where the computer vision matched things incorrectly.
Fixing the errors in position reports will require improving the computer vision algorithm and would fix most of the plot above. Outlier rejection is one approach to investigate on that front.
Latency Compensation
There is inherent delay involved in processing of the camera observations. Every 19.2ms, the headset emits a radio signal that triggers each camera to capture a frame. At the same time, the headset and controller IR LEDS light up brightly to create the light constellation being tracked. After the frame is captured, it is delivered over USB over the next 18ms or so and then submitted for vision analysis. In the fast case where we’re already tracking the device the computer vision is complete in a millisecond or so. In the slow case, it’s much longer.
Overall, that means that there’s at least a 20ms offset between when the devices are observed and when the position information is available for use. In the plot above, this delay is ignored and position reports are fed into the filter when they are available. In the worst case, that means the filter is being told where the headset was hundreds of milliseconds earlier.
To compensate for that delay, I implemented a mechanism in the filter where it keeps extra position and orientation entries in the state that can be used to retroactively apply the position observations.
The way that works is to make a prediction of the position and orientation of the device at the moment the camera frame is captured and copy that prediction into the extra state variable. After that, it continues integrating IMU data as it becomes available while keeping the auxilliary state constant.
When a the camera frame analysis is complete, that delayed measurement is matched against the stored position and orientation prediction in the state and the error used to correct the overall filter. The cool thing is that in the intervening time, the filter covariance matrix has been building up the right correction terms to adjust the current position and orientation.
Here’s a good example of the difference:
Notice how most of the disconnected segments have now slotted back into position in the timeline. The ones that haven’t can either be attributed to incorrect pose extraction in the compute vision, or to not having enough auxilliary state slots for all the concurrent frames.
At any given moment, there can be a camera frame being analysed, one arriving over USB, and one awaiting “long term” analysis. The filter needs to track an auxilliary state variable for each frame that we expect to get pose information from later, so I implemented a slot allocation system and multiple slots.
The downside is that each slot adds 6 variables (3 position and 3 orientation) to the covariance matrix on top of the 18 base variables. Because the covariance matrix is square, the size grows quadratically with new variables. 5 new slots means 30 new variables – leading to a 48 x 48 covariance matrix instead of 18 x 18. That is a 7-fold increase in the size of the matrix (48 x 48 = 2304 vs 18 x 18 = 324) and unfortunately about a 10x slow-down in the filter run-time.
At that point, even after some optimisation and vectorisation on the matrix operations, the filter can only run about 3x real-time, which is too slow. Using fewer slots is quicker, but allows for fewer outstanding frames. With 3 slots, the slow-down is only about 2x.
There are some other possible approaches to this problem:
Running the filtering delayed, only integrating IMU reports once the camera report is available. This has the disadvantage of not reporting the most up-to-date estimate of the user pose, which isn’t great for an interactive VR system.
Keeping around IMU reports and rewinding / replaying the filter for late camera observations. This limits the overall increase in filter CPU usage to double (since we at most replay every observation twice), but potentially with large bursts when hundreds of IMU readings need replaying.
It might be possible to only keep 2 “full” delayed measurement slots with both position and orientation, and to keep some position-only slots for others. The orientation of the headset tends to drift much more slowly than position does, so when there’s a big gap in the tracking it would be more important to be able to correct the position estimate. Orientation is likely to still be close to correct.
Further optimisation in the filter implementation. I was hoping to keep everything dependency-free, so the filter implementation uses my own naive 2D matrix code, which only implements the features needed for the filter. A more sophisticated matrix library might perform better – but it’s hard to say without doing some testing on that front.
Controllers
So far in this post, I’ve only talked about the headset tracking and not mentioned controllers. The controllers are considerably harder to track right now, but most of the blame for that is in the computer vision part. Each controller has fewer LEDs than the headset, fewer are visible at any given moment, and they often aren’t pointing at the camera front-on.
This screenshot is a prime example. The controller is the cluster of lights at the top of the image, and the headset is lower left. The computer vision has gotten confused and thinks the controller is the ring of random blue crosses near the headset. It corrected itself a moment later, but those false readings make life very hard for the filtering.
Here’s a typical example of the controller tracking right now. There are some very promising portions of good tracking, but they are interspersed with bursts of tracking losses, and wild drifting from the computer vision giving wrong poses – leading to the filter predicting incorrect acceleration and hence cascaded tracking losses. Particularly (again) on the Z axis.
Timing Improvements
One of the problems I was looking at in my last post is variability in the arrival timing of the various USB streams (Headset reports, Controller reports, camera frames). I improved things in OpenHMD on that front, to use timestamps from the devices everywhere (removing USB timing jitter from the inter-sample time).
There are still potential problems in when IMU reports from controllers get updated in the filters vs the camera frames. That can be on the order of 2-4ms jitter. Time will tell how big a problem that will be – after the other bigger tracking problems are resolved.
Sponsorships
All the work that I’m doing implementing this positional tracking is a combination of my free time, hours contributed by my employer Centricular and contributions from people via Github Sponsorships. If you’d like to help me spend more hours on this and fewer on other paying work, I appreciate any contributions immensely!
Next Steps
The next things on my todo list are:
Integrate the delayed-observation processing into OpenHMD (at the moment it is only in my standalone simulator).
Improve the filter code structure – this is my first kalman filter and there are some implementation decisions I’d like to revisit.
Publish the UKF branch for other people to try.
Circle back to the computer vision and look at ways to improve the pose extraction and better reject outlying / erroneous poses, especially for the controllers.
Think more about how to best handle / schedule analysis of frames from multiple cameras. At the moment each camera operates as a separate entity, capturing frames and analysing them in threads without considering what is happening in other cameras. That means any camera that can’t see a particular device starts doing full pose searches – which might be unnecessary if another camera still has a good view of the device. Coordinating those analyses across cameras could yield better CPU consumption, and let the filter retain fewer delayed observation slots.
Another year comes to a close, and this is the 4th year running I’m in Kuala Lumpur — 2017, 2018, 2019, and 2020… Wow. Maybe the biggest difference is that I’ve been in Malaysia for 306 days, thanks to the novel coronavirus. I have never spent this much time in Malaysia, in my entire life… I want to say KL, but I’ve managed to zip my way around to Kuantan (a lot), Penang, and Malacca. I can’t believe I flew back on February 29 2020 from Tokyo, and never got on a plane again! What a grounded globalist I’ve become.
My travel stats are of course, pretty dismal. 39 days out of the country. Apparently I did a total of 13 trips, 92 days of travel (I don’t know if all my local trips are counted frankly), 60,766km, 17 cities, and still 7 countries :) I don’t even want to compare to what it was like in 2019.
I ended that by saying, “I welcome 2020 with arms wide open.”. I’m not so sure how I feel about 2020. There is life beyond travel. COVID and our reaction to it, really worries me.
KL has some pretty good food. Kuantan has some pretty good people. While in KL, I visited a spin studio at least once per day. I did a total of 272 spin classes over 366 days! Not to forget there was 56 days of complete lockdown, and studios didn’t open till about maybe mid-June… Sure I did do some spin in London and Paris too, but the bulk of all this happened while I was here in KL.
I became reasonably friendlier, I became vulnerable, and like every time you do that, you’re chances of happiness and getting hurt probably straddle 50:50. Madonna – The Power of Good-bye can be apt.
This is not to say I didn’t enjoy 2020. Glass half full. I really did. Carpe diem. Simplicity is best. If you can follow KISS principles in engineering, why would you pour your entire thought process out and overwhelm the other party?
Anyway, I still look forward to 2021, with wide open arms, and while I really do think the COVID mess isn’t going away and things are going to be worse for many, I will still be focused on the most positive aspects of 2021. And I’ll work on being my old self again ;-)
I also ended the year with a haircut (number 1/0.5 on the sides) on Monday 28 December 2020. Somewhat of an experiment (does CoQ10 help speed up hair growth?) but also somewhat of a reaction to saying goodbye to December 2020.
udev can be used to block a USB device (or even an entire class of devices, such as USB storage). Add a file /etc/udev/rules.d/99-local-blacklist.rules containing:
While I hope to update this site again soon, here’s a photo I captured over the weekend in my back yard. The red flowering plant is attracting wattlebirds and honey-eaters. This wattlebird stayed still long enough for me to take this shot. After a little bit of editing, I think it has turned out rather well.
Photo taken with: Canon 7D Mark II & Canon 55-250mm lens.
Edited in Lightroom and Photoshop (to remove a sun glare spot off the eye).
Digital TV uses MPEG Transport Stream, which is a container for video designed for lossy transmission, such as radio. To save CPU cycles, Personal Video Records often save the MPEG-TS stream directly to disk. The more usual MPEG is technically MPEG Program Stream, which is designed for lossless transmission, such as storage on a disk.
Since these are a container formats, it should be possible to losslessly and quickly re-code from MPEG-TS to MPEG-PS.
I gave the talk Practicality Beats Purity: The Zen of Python’s Escape Hatch as part of PyConline AU 2020, the very online replacement for PyCon AU this year. In that talk, I included a few interesting links code samples which you may be interested in:
__NOT_A_MATCHER__=object()__MATCHER_SORT_KEY__=0defswitch(cls):inst=cls()methods=[]forattrindir(inst):method=getattr(inst,attr)matcher=getattr(method,"__matcher__",__NOT_A_MATCHER__)ifmatcher==__NOT_A_MATCHER__:continuemethods.append(method)methods.sort(key=lambdai:i.__matcher_sort_key__)formethodinmethods:matches=method.__matcher__()ifmatches:returnmethod()raiseValueError(f"No matcher matches value {test_value}")defcase(matcher):def__decorator__(f):global__MATCHER_SORT_KEY__f.__matcher__=matcherf.__matcher_sort_key__=__MATCHER_SORT_KEY____MATCHER_SORT_KEY__+=1returnfreturn__decorator__if__name__=="__main__":foriinrange(100):@switchclassFizzBuzz:@case(lambda:i%15==0)deffizzbuzz(self):return"fizzbuzz"@case(lambda:i%3==0)deffizz(self):return"fizz"@case(lambda:i%5==0)defbuzz(self):return"buzz"@case(lambda:True)defdefault(self):return"-"print(f"{i}{FizzBuzz}")
fuck grey text on white backgrounds
fuck grey text on black backgrounds
fuck thin, spindly fonts
fuck 10px text
fuck any size of anything in px
fuck font-weight 300
fuck unreadable web pages
fuck themes that implement this unreadable idiocy
fuck sites that don’t work without javascript
fuck reactjs and everything like it
thank fuck for Stylus. and uBlock Origin. and uMatrix.
Earlier today I launched this site. It is the result of a lot of work over the past few weeks. It began as an idea to publicise some of my photos, and morphed into the site you see now, including a store and blog that I’ve named “Photekgraddft”.
In the weirdly named blog, I want to talk about photography, the stories behind some of my more interesting shots, the gear and software I use, my technology career, my recent ADHD diagnosis and many other things.
This scares me quite a lot. I’ve never really put myself out onto the internet before. If you Google me, you’re not going to find anything much. Google Images has no photos of me. I’ve always liked it that way. Until now.
ADHD’ers are sometimes known for “oversharing”, one of the side-effects of the inability to regulate emotions well. I’ve always been the opposite, hiding, because I knew I was different, but didn’t understand why.
The combination of the COVID-19 pandemic and my recent ADHD diagnosis have given me a different perspective. I now know why I hid. And now I want to engage, and be engaged, in the world.
If I can be a force for positive change, around people’s knowledge and opinion of ADHD, then I will.
If talking about Business Analysis (my day job), and sharing my ideas for optimising organisations helps anyone at all, then I will.
If I can show my photos and brighten someone’s day by allowing them to enjoy a sunset, or a flying bird, then I will.
And if anyone buys any of my photos, then I will be shocked!
So welcome to my little vanity project. I hope it can be something positive, for me, if for noone else in this new, odd world in which we now find ourselves living together.