Re: Call for nominations: Developer Membership Board
On Wed, Mar 09, 2022 at 02:43:40AM +, Seth Arnold wrote: > I've been having this thought a lot the last few years. My response here should in no way be read as suggesting Robie is personally contributing to an excess of bureaucracy in Ubuntu. To the contrary, I've always appreciated that Robie eagerly reaches out to start conversations to reach a consensus. This is strictly a lament that I don't think the structures we've got are responsive to the needs of today. We've got a lot of roles to fill and everyone in the project is stretched too thin to take on additional responsibilities. Thanks signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Tue, Mar 08, 2022 at 10:37:07AM -0500, Dan Streetman wrote: > In any case, all this formality really is exhausting and I don't care > to pursue it, since you seem to be saying that I can't call for a DMB I've been having this thought a lot the last few years. A lot of the Ubuntu structures feel like they may have had a place in the early days, when there were thousands of enthusiasts all contributing at once and trying to coordinate how they were going to do all that. Now it feels like we've got the ossified remains of a lot of committees and teams and boards and I just don't know how much of it is still relevant to the Ubuntu of today. Every piece serves a role so it's not like I can just point to any one specific thing and say we ought to scrap it, but I remember watching what felt like dozens of DMB meetings where not enough members showed up, not enough members voted, and the poor applicants could go weeks or months (or more?) without an answer. That kills enthusiasm. I'm sorry that I don't have a solution to recommend but I think I'd like to suggest that we try stepping back from bureaucracy when opportunities arise. Thanks signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Revisiting default initramfs compression
On Thu, 9 Dec 2021 at 06:13, Julian Andres Klode wrote: > Hi all, > > some time ago, the default compressor for initramfs was changed > from lz4 -9 to zstd -19. This caused significant problems: > Exactly three months later... we still haven't taken any action on this. Time to do something! I have a few questions below but tl;dr: unless there are immediate objections, I'm going to make a change to initramfs-tools to allow the compression level to be configured and set the default to 12 for zstd. - it is very slow > - it uses a lot of memory > > The former is a problem for everyone, the latter means that > zstd just crashes on a Pi Zero. > > This is an analysis of what we have in terms of time spent, > memory spent, and file size achieved, and where we can > go from here. > > # Comparison of different compression levels > > ## Desktop (ThinkPad T480s, jammy) > > levelusertime elapsed memory fileSize > lz4 9.65s11.09s12M 64M > -1 5.69s 6.99s24M 57M > -6 12.59s 8.58s99M 47M > -1219.85s10.82s 249M 41M > -1971.29s26.95s 519M 35M > > -> I believe that somewhere around -12 is a decent >compromise between size and speed. > I would agree that it's certainly better than -19. > ## Pi 4 (arm64, focal) > > Times have been measured for mkinitramfs only. A full > update-initramfs call spends much more time copying > some firmware bits to boot partition with flash-kernel > > levelusertime elapsed memory fileSize > lz421.10s64.85s21M 29M > -1 13.73s44.55s21M 27M > -6 26.07s49.09s91M 24M > -1248.18s54.67s 203M 22M > -19 130.07s92.80s 350M 20M > > -> 6 is essentially free if the Pi 4 is idle. Nice. > -> -6 is still 20% of total RAM of a Pi 0 > Are people really going to run an arm64 userland on a Pi 0? Any "real" solution for pi 0 has to involve doing at least the bulk of the compression not on the pi, there's no real way around that. Which is something we should do, but realistically it's not happening for jammy. > -> There's no meaningful difference between -6 and -12 >in terms of time elapsed. -6 uses 116% CPU, -12 uses >145% CPU. > > ## Adaptive compression > > zstd also supports adaptive compression, compressing as hard as > it can while not impacting I/O speed. So hardware with slow I/O > like a Pi would compress harder to avoid idling. > > This is somewhat suboptimal with recent update-initramfs though, > as it first writes the cpio archive to the disk and then compresses > it rather than doing it in a pipe where that would be more > meaningful. > > Question: Does zstd --adapt adapt to memory available? > While attractive, this does feel a bit risky. We want to be able to make reasonable predictions about the size of the initrd. > # Way(s) forward > > To remedy the issue the proposal is to build with > > - zstd -1 on hardware with 512 MB or less memory > - zstd between -1 and -19 on other hardware > - zstd -19 during image building > I think this broadly makes sense. I'll notice that currently initramfs-tools doesn't allow tuning the compression level at all :/ Probably fairly routine to add support for that though. > Finding the right level between -1 and -19 is hard. The more > cores you have, the less penalty you pay for higher level. > You suggested -12 above. How about we try that to start with? Do you have an idea how to detect "512 MB or less memory"? > Going for adaptive compression would remove the guess work, but > will result in larger images on faster machines. Maybe that's > fine, though - they probably have more space on /boot anyway? > > If we want to aim for 5% of total memory, we should probably > aim for something like: > > -1 on <= 512MB > -6 on <= 2 GB (or --adapt=min=1,max=6) > -12 on the rest (or --adapt=min=12) > > It's clear that in all cases, zstd -1 is at least better than the > lz4 -9 we used before; both in terms of space used, and time spent. > Yeah that's interesting. > # Concerns > > Lowering the compression level will reduce the boot speed by fractions > of a second on hardware with fast I/O. > Well speaking selfishly, the mean "number of boots per mkinitramfs call" for me is about 1... Cheers, mwh -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
PSA: server move for changelogs.ubuntu.com
I wanted to let everyone know that Canonical has switched that the servers which provide changelogs.ubuntu.com to a new setup. While there has been testing of the changelogs and metarelease files on the new servers its possible somebody somewhere may encounter an issue. If you do please let me know or file an RT. Cheers, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Tue, Mar 8, 2022 at 9:20 AM Robie Basak wrote: > > On Tue, Mar 08, 2022 at 08:56:23AM -0500, Dan Streetman wrote: > > I would like to officially call for a DMB vote on extending DMB > > eligibility to members of the ~ubuntu-sru-developers team. > > Previous discussion and decision here: > https://lists.ubuntu.com/archives/technical-board/2020-January/002464.html > > It's been pointed out recently that it's the TB that runs the DMB > election, even if the administrative work has been delegated to the DMB > (and then to me). > > I concluded the previous discussion on the basis of having found > consensus within the DMB (you weren't on the DMB at the time) and on the > basis of no objection from the TB, who were copied in to the thread. > > If you want the eligibility criteria changed contrary to that previous > discussion and decision, I think it'd need to be a TB policy decision Well, that seems a whole lot like it's simply your opinion. In any case, all this formality really is exhausting and I don't care to pursue it, since you seem to be saying that I can't call for a DMB vote on this, even though the previous decision was decided entirely by DMB members. > since it'd be contrary to the opinion of a bunch of people in that > thread (and therefore there wouldn't be consensus, unless their > positions have changed or you persuade them otherwise). You can take it > to the TB mailing list and/or add the item to the TB agenda here: > > https://wiki.ubuntu.com/TechnicalBoardAgenda > > Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Tue, Mar 08, 2022 at 08:56:23AM -0500, Dan Streetman wrote: > I would like to officially call for a DMB vote on extending DMB > eligibility to members of the ~ubuntu-sru-developers team. Previous discussion and decision here: https://lists.ubuntu.com/archives/technical-board/2020-January/002464.html It's been pointed out recently that it's the TB that runs the DMB election, even if the administrative work has been delegated to the DMB (and then to me). I concluded the previous discussion on the basis of having found consensus within the DMB (you weren't on the DMB at the time) and on the basis of no objection from the TB, who were copied in to the thread. If you want the eligibility criteria changed contrary to that previous discussion and decision, I think it'd need to be a TB policy decision since it'd be contrary to the opinion of a bunch of people in that thread (and therefore there wouldn't be consensus, unless their positions have changed or you persuade them otherwise). You can take it to the TB mailing list and/or add the item to the TB agenda here: https://wiki.ubuntu.com/TechnicalBoardAgenda Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Tue, Mar 8, 2022 at 8:52 AM Robie Basak wrote: > > On Tue, Mar 01, 2022 at 03:51:22PM +, Robie Basak wrote: > > Three members - Simon Quigley, Eric Desrochers and Rafael David Tinoco - > > have recently vacated their seats on the DMB. Subsequently, this email > > is a call for nominations to fill their vacated seats. > > We don't yet have enough nominations to fill the seats that are up for > election. In recent years the DMB has routinely been short-staffed, > blocking us from being able to appoint more Ubuntu developers. > > If you are a core dev or MOTU, please consider spending one hour every > other Monday to help others join us by nominating yourself for a seat on > the DMB[1]. I would like to officially call for a DMB vote on extending DMB eligibility to members of the ~ubuntu-sru-developers team. > > Thanks, > > Robie > > [1] > https://lists.ubuntu.com/archives/ubuntu-devel-announce/2022-March/001305.html > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Tue, Mar 01, 2022 at 03:51:22PM +, Robie Basak wrote: > Three members - Simon Quigley, Eric Desrochers and Rafael David Tinoco - > have recently vacated their seats on the DMB. Subsequently, this email > is a call for nominations to fill their vacated seats. We don't yet have enough nominations to fill the seats that are up for election. In recent years the DMB has routinely been short-staffed, blocking us from being able to appoint more Ubuntu developers. If you are a core dev or MOTU, please consider spending one hour every other Monday to help others join us by nominating yourself for a seat on the DMB[1]. Thanks, Robie [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2022-March/001305.html signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
