Re-Cap: AOSCC 2018

Even though we didn't have the fortune to meet each other in person like we did last year, AOSCC 2018 has been productive and a whole heap of fun. While there's obviously no picture of the event this time, we do have a full log of the sessions over the two weeks for your reference.

This year's conference was constituted by a series of topic, with 14 topics discussed across 16 sessions over the span of two weekends. The purpose of this news post is to provide a summary of decisions made and changes planned for the coming year - so you'll know what to expect. There are lots of things to talk about so... Let's dive in.

Codename and Wallpaper

Friends of our community never disappoints in terms of creativity and sense of humour... And this year is no exception. Out of 40 nominated codenames, the community voted "Fsck" to be the codename of AOSC OS Core 6. Fsck, file system consistency check, or an elegant rendition of a widely used profanity - like how Fsck was originally called...

*Dennis Ritchie: “So fsck was originally called something else”*
*Question: “What was it called?”*
*Dennis Ritchie: "Well, the second letter was different"*

This year's default wallpaper was made by Tianhao Chai with Blender - titled "Campanula".

"Campanula" also comes in two variants, one with an alternative layout, and another rendered in a "neon light" style. All these wallpapers could be downloaded here.

We have also received 39 wallpaper submissions from our community members, currently available for download here

AOSC OS Core 6

AOSC OS will continue to evolve around a Core, and with Core 6, we expect to make some major changes in terms of version updates and build configurations.

• Version updates, for example, GCC 8.2, and GNU C Library 2.28, etc.
• GCC will (finally) update to the new stdc++ ABI, no longer using the aging GCC 4 compatibility ABI.
• For AMD64, the default -mtune= parametre will now point to sandybridge instead of core2, which should marginally improve binary performance on newer AMD64 devices.

AOSC OS Core 6 will come as a part of the next wave of major updates, expected in December.

Changes to AOSC OS Updates and Branches

Two of the most notable changes planned are the switch to a seasonal update model, and the introduction of a third system update branch/channel. Allow me to break it down a little bit...

Seasonal Update Model

This change originated largely originated from the time and scheduling trouble we have had since the last summer's switch to monthly update cycles - as there's simply too little time for us to make it happen (and too little of us, mind you), and we did not have a concrete policy on feature planning and freezing periods.

With this new update model, the change is not limited to (obviously) switching to a seasonal schedule to provide stable updates. With this new model, extensive changes are made to how AOSC OS is maintained and updated - known patch releases (typically, z in a x.y.z version format) will be provided for "stable" channel users, a month-long freezing period will be set in place for the "testing" channel, a strategy to align update cycles with upstream LTS branch updates is also introduced.

The "stable" channel will also become our focus of maintenance, which we find a bit "left behind" and starved of updates. While this tend not to break things - since security updates were practically the only updates pushed to this channel - the channel also suffered from lack of backported bugfix due to the aforementioned time and scheduling issues. A good example of this issue is best demonstrated in this severely delayed update cycle, where on the "stable" channel a graphical bug that prevented transparency to be displayed on Plasma panels on deviced with Intel GMA/Core Graphics - while this was addressed when libGLVND was introduced in the "testing" channel, though for the extensive changes required to introduce this library and the fact that we did not have enough time to investigate for a more minimalistic approach to fix this issue, this "fix" was then never backported to the "stable" channel.

Users of the "testing" channel can also expect more stability in the future, as updates will go through a process of automatic testing and auditing before landing in this channel. This will be discussed in the section below.

Introducing... The "Explosive" Channel

This update channel is intended as a "No Man's Land", where immediate version updates are uploaded, and tested automatically, before landing in the "testing" channel.

The "explosive" channel is also introduced to aid in feature freezing and release scheduling, as freezing for users of both channels will no longer hinder package updates - to reduce time waste, which could in turn hinder updates for the next cycle.

The branch is also limited to the amd64 port of AOSC OS - due to computational limitations, we chose not to build any "explosive" updates on the other ports, they will in turn receive updates merged from the "explosive" branch, while build fixes for these ports will be merged back to "explosive".

Again, this channel is not intended to be used by anyone - not even the developers themselves. If you feel obliged to update with this channel, you are on your own.

Security Updates

On the question of security updates, we are looking to expand user notifications beyond GitHub issues and our [email protected] mailing list. In the future, security advisories will be posted as a brief list here on the Portal.

We are also seeking help on security vulnerable discovery, reporting, fixing, and testing - please do contact us at #aosc or at our Telegram group if you are interested.

Implementing AOSC OS Optimisation Overlays

This change was first discussed at AOSCC 2017 but was unfortunately never materialised, though overlay support has already been implemented in Autobuild3 and apt-gen-list.

We will implement two overlays in the coming year - in the form of an extra repository:

• AMD64 AVX2+ Overlay, for AVX2-enabled (Advanced Vector Extensions 2) devices, where most devices with Intel Haswell (4th Generation Core) processors or newer, and all AMD Ryzen are supported.
• PowerPC 32-bit Big Endian G4+ Overlay, intended for PowerPC-based Apple Macintosh computers with a G4 processor or newer - where AltiVec is available.

Both overlays aimed to produce higher performance binaries with optimisations for these newer, vector-based instruction sets (or SIMD) - this can provide performance uplift in certain applications, as benchmarked by Phoronix in the case of AVX2 in 2013.

However, these optimisations may come with a price of higher power consumption and heat output - as briefly described in this Super User Post. In our current plan, users will be made aware if an overlay repository is available for their device(s), though it will not be enabled by default automatically. We plan to conduct more up-to-date performance, power consumption, and thermal testings in the future.

LiveKit, RescueKit, and System Releases

One of the longest running discussion among the AOSC OS users and developers has been the introduction of Live media and a system installer. For system installation and configuration, LiveKit will be similar to GParted Live - a lightweight toolkit environment.

An installation program is also planned, inspired by the Which Wich order form - a single-page installation configurator. More details will come once the implementation process begins.

RescueKit takes on roughly the same idea, though it is assembled as a RAM disk image that is bootable right from the GRUB menu - where users could boot into to repair their AOSC OS installation. Additionally, users will be able to package a backup of their current system as a system tarball, which could be in turn installed by the system installer, as discussed above.

In the question of system releases, we plan on maintaining a seasonal update cycle, much like the aforementioned seasonal update model - with additional system releases made available in case of major security vulnerabilities.

AOSC Bazaar

In the coming months, a community-wide platform for goods and devices exchange will be implemented to provide friends in and around the community with community goods such as the legendary (?) AOSCC sticker packs and other souvenirs.

Community developers could also request for compiling/testing/... devices on this platform, which will be provided by community members or other developers as a donation.

What's More?

This has already been quite a long news post, so it might not be in the interest of information and transparency to keep extending this post. Here is a brief (and incomplete) list of things we've discussed and decided upon, in no particular order...

• AOSC OS packaging repository (aosc-os-abbs and aosc-os-core) will begin to enforce source checksum, link accessibility, secure connections (HTTPS replacing HTTP and FTP, as much as possible).
• Old forks found in our GitHub organisation will be cleaned up and archived.
• AOSC OS's KDE/Plasma variant will switch to the Arc KDE theme and a suitable icon theme.
• Introduction of package variants for different system configurations.
• Packages for legacy ports (specified as ARMv7, armel; and PowerPC 32-bit Big Endian, powerpc) will have minimalised configurations to remove features unsuitable or unapplicable to their performance and platform support.

AOSCC 2019?

With the lessons learned from AOSCC 2018, we will no longer hold community-wide poll on next year's meeting location unless anyone could secure a venue before hand. Therefore, next year's meeting location is not yet known, and hopefully we will get some choices in the near future.

Conclusion

And with such, the re-cap of AOSCC 2018 is now complete, AOSCC 2018 had been quite a productive conference and will surely point a clearer direction for our community projects in the coming year. Look forward to see you again in AOSCC 2019!

— Mingcong Bai