SELECT DISTINCT
count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;
).
After a third of my DPL term (OMG), we've made significant progress,
reducing the amount in question (369 packages) by nearly half. I'm
pleased with the support from the DDs who moved their packages to Salsa.
Some packages were transferred as part of the Bug of the Day initiative
(see below).
Bug of the Day
As announced in my 'Bits from the DPL' talk at DebConf, I started
an initiative called Bug of the Day. The goal is to train newcomers
in bug triaging by enabling them to tackle small, self-contained QA
tasks. We have consistently identified target packages and resolved at
least one bug per day, often addressing multiple bugs in a single
package.
In several cases, we followed the Package Salvaging procedure outlined
in the Developers Reference. Most instances were either welcomed by
the maintainer or did not elicit a response. Unfortunately, there was
one exception where the recipient of the Package Salvage bug expressed
significant dissatisfaction. The takeaway is to balance formal
procedures with consideration for the recipient s perspective.
I'm pleased to confirm that the Matrix channel has seen an increase
in active contributors. This aligns with my hope that our efforts would
attract individuals interested in QA work. I m particularly pleased
that, within just one month, we have had help with both fixing bugs and
improving the code that aids in bug selection.
As I aim to introduce newcomers to various teams within Debian, I also
take the opportunity to learn about each team's specific policies
myself. I rely on team members' assistance to adapt to these policies. I
find that gaining this practical insight into team dynamics is an
effective way to understand the different teams within Debian as DPL.
Another finding from this initiative, which aligns with my goal as DPL,
is that many of the packages we addressed are already on Salsa but have
not been uploaded, meaning their VCS fields are not published. This
suggests that maintainers are generally open to managing their packages
on Salsa. For packages that were not yet on Salsa, the move was
generally welcomed.
Publicity team wants you
The publicity team has decided to resume regular meetings to coordinate
their efforts. Given my high regard for their work, I plan to attend
their meetings as frequently as possible, which I began doing with the
first IRC meeting.
During discussions with some team members, I learned that the team could
use additional help. If anyone interested in supporting Debian with
non-packaging tasks reads this, please consider introducing yourself to
debian-publicity@lists.debian.org. Note that this is a publicly archived
mailing list, so it's not the best place for sharing private
information.
Kind regards
Andreas.
/healthz
HTTP endpoint, which more accurately reflected the health of each k8s apiserver.Publisher: | Ballantine Books |
Copyright: | 2009 |
ISBN: | 0-553-59217-3 |
Format: | Mass market |
Pages: | 438 |
Publisher: | DAW |
Copyright: | November 2022 |
ISBN: | 0-7564-1543-8 |
Format: | Kindle |
Pages: | 676 |
The problem here is with Open Source Software.I want to say not only is that view so myopic that it pushes towards the incorrect, but also it blinds us to more serious problems. Now, I don t pretend that there are no problems in the FLOSS community. There have been various pieces written about what this issue says about the FLOSS community (usually without actionable solutions). I m not here to say those pieces are wrong. Just that there s a bigger picture. So with this xz issue, it may well be a state actor (aka spy ) that added this malicious code to xz. We also know that proprietary software and systems can be vulnerable. For instance, a Twitter whistleblower revealed that Twitter employed Indian and Chinese spies, some knowingly. A recent report pointed to security lapses at Microsoft, including preventable lapses in security. According to the Wikipedia article on the SolarWinds attack, it was facilitated by various kinds of carelessness, including passwords being posted to Github and weak default passwords. They directly distributed malware-infested updates, encouraged customers to disable anti-malware tools when installing SolarWinds products, and so forth. It would be naive indeed to assume that there aren t black hat actors among the legions of programmers employed by companies that outsource work to low-cost countries some of which have challenges with bribery. So, given all this, we can t really say the problem is Open Source. Maybe it s more broad:
The problem here is with software.Maybe that inches us closer, but is it really accurate? We have all heard of Boeing s recent issues, which seem to have some element of root causes in corporate carelessness, cost-cutting, and outsourcing. That sounds rather similar to the SolarWinds issue, doesn t it?
Well then, the problem is capitalism.Maybe it has a role to play, but isn t it a little too easy to just say capitalism and throw up our hands helplessly, just as some do with FLOSS as at the start of this article? After all, capitalism also brought us plenty of products of very high quality over the years. When we can point to successful, non-careless products and I own some of them (for instance, my Framework laptop). We clearly haven t reached the root cause yet. And besides, what would you replace it with? All the major alternatives that have been tried have even stronger downsides. Maybe you replace it with better regulated capitalism , but that s still capitalism.
Then the problem must be with consumers.As this argument would go, it s consumers buying patterns that drive problems. Buyers individual and corporate seek flashy features and low cost, prizing those over quality and security. No doubt this is true in a lot of cases. Maybe greed or status-conscious societies foster it: Temu promises people to shop like a billionaire , and unloads on them cheap junk, which all but guarantees that shipments from Temu containing products made with forced labor are entering the United States on a regular basis . But consumers are also people, and some fraction of them are quite capable of writing fantastic software, and in fact, do so. So what we need is some way to seize control. Some way to do what is right, despite the pressures of consumers or corporations. Ah yes, dear reader, you have been slogging through all these paragraphs and now realize I have been leading you to this:
Then the solution is Open Source.Indeed. Faults and all, FLOSS is the most successful movement I know where people are bringing us back to the commons: working and volunteering for the common good, unleashing a thousand creative variants on a theme, iterating in every direction imaginable. We have FLOSS being vital parts of everything from $30 Raspberry Pis to space missions. It is bringing education and communication to impoverished parts of the world. It lets everyone write and release software. And, unlike the SolarWinds and Twitter issues, it exposes both clever solutions and security flaws to the world. If an authentication process in Windows got slower, we would all shrug and mutter Microsoft under our breath. Because, really, what else can we do? We have no agency with Windows. If an authentication process in Linux gets slower, anybody that s interested anybody at all can dive in and ask why and trace it down to root causes. Some look at this and say FLOSS is responsible for this mess. I look at it and say, this would be so much worse if it wasn t FLOSS and experience backs me up on this. FLOSS doesn t prevent security issues itself. What it does do is give capabilities to us all. The ability to investigate. Ability to fix. Yes, even the ability to break and its cousin, the power to learn. And, most rewarding, the ability to contribute.
Series: | Discworld #34 |
Publisher: | Harper |
Copyright: | October 2005 |
Printing: | November 2014 |
ISBN: | 0-06-233498-0 |
Format: | Mass market |
Pages: | 434 |
Photo by Pixabay |
Given a typical install of 3 generic kernel ABIs in the default configuration on a regular-sized VM (2 CPU cores 8GB of RAM) the following metrics are achieved in Ubuntu 23.10 versus Ubuntu 22.04 LTS:
2x less disk space used (1,417MB vs 2,940MB, including initrd)
3x less peak RAM usage for the initrd boot (68MB vs 204MB)
0.5x increase in download size (949MB vs 600MB)
2.5x faster initrd generation (4.5s vs 11.3s)
approximately the same total time (103s vs 98s, hardware dependent)
For minimal cloud images that do not install either linux-firmware or modules extra the numbers are:
1.3x less disk space used (548MB vs 742MB)
2.2x less peak RAM usage for initrd boot (27MB vs 62MB)
0.4x increase in download size (207MB vs 146MB)
Hopefully, the compromise of download size, relative to the disk space & initrd savings is a win for the majority of platforms and use cases. For users on extremely expensive and metered connections, the likely best saving is to receive air-gapped updates or skip updates.
This was achieved by precompressing kernel modules & firmware files with the maximum level of Zstd compression at package build time; making actual .deb files uncompressed; assembling the initrd using split cpio archives - uncompressed for the pre-compressed files, whilst compressing only the userspace portions of the initrd; enabling in-kernel module decompression support with matching kmod; fixing bugs in all of the above, and landing all of these things in time for the feature freeze. Whilst leveraging the experience and some of the design choices implementations we have already been shipping on Ubuntu Core. Some of these changes are backported to Jammy, but only enough to support smooth upgrades to Mantic and later. Complete gains are only possible to experience on Mantic and later.
The discovered bugs in kernel module loading code likely affect systems that use LoadPin LSM with kernel space module uncompression as used on ChromeOS systems. Hopefully, Kees Cook or other ChromeOS developers pick up the kernel fixes from the stable trees. Or you know, just use Ubuntu kernels as they do get fixes and features like these first.
The team that designed and delivered these changes is large: Benjamin Drung, Andrea Righi, Juerg Haefliger, Julian Andres Klode, Steve Langasek, Michael Hudson-Doyle, Robert Kratky, Adrien Nader, Tim Gardner, Roxana Nicolescu - and myself Dimitri John Ledkov ensuring the most optimal solution is implemented, everything lands on time, and even implementing portions of the final solution.
Hi, It's me, I am a Staff Engineer at Canonical and we are hiring https://canonical.com/careers.
Lots of additional technical details and benchmarks on a huge range of diverse hardware and architectures, and bikeshedding all the things below:
release
elements that reference downloadable data without an artifact
block, which has not been supported for a while. For all of these, I checked to remove only things that had close to no users and that were a significant maintenance burden. So as a rule of thumb: If your XML validated with no warnings with the 0.16.x branch of AppStream, it will still be 100% valid with the 1.0 release.
Another notable change is that the generated output of AppStream 1.0 will always be 1.0 compliant, you can not make it generate data for versions below that (this greatly reduced the maintenance cost of the project).
developer_name
tag. With AppStream 1.0, this is changed a bit. There is now a developer
tag with a name
child (that can be translated unless the translate="no"
attribute is set on it). This allows future extensibility, and also allows to set a machine-readable id
attribute in the developer
element. This permits software centers to group software by developer easier, without having to use heuristics. If we decide to extend the developer information per-app in future, this is also now possible. Do not worry though the developer_name
tag is also still read, so there is no high pressure to update. The old 0.16.x stable series also has this feature backported, so it can be available everywhere. Check out the developer tag specification for more details.
scale
attribute, to indicate an (integer) scaling factor to apply. This feature was a breaking change and therefore we could not have it for the longest time, but it is now available. Please wait a bit for AppStream 1.0 to become deployed more widespread though, as using it with older AppStream versions may lead to issues in some cases. Check out the screenshots tag specification for more details.
environment
attribute on the respective screenshot
tag. This was also a breaking change, so use it carefully for now! If projects want to, they can use this feature to supply dedicated screenshots depending on the environment the application page is displayed in. Check out the screenshots tag specification for more details.
references
tag, you can associate the AppStream component with a DOI (Digital object identifier) or provide a link to a CFF file to provide citation information. It also allows to link to other scientific registries. Check out the references tag specification for more details.
appstreamcli
utility also has much improved support for relation checks, and I wrote about these changes in a previous post. Check it out!
With these changes, I hope this feature will be used much more, and beyond just drivers and firmware.
Series: | Chilling Effect #1 |
Publisher: | Harper Voyager |
Copyright: | September 2019 |
Printing: | 2020 |
ISBN: | 0-06-287724-0 |
Format: | Kindle |
Pages: | 420 |
IOPS | Bandwidth | |
4k random writes | 19.3k | 75.6 MiB/s |
4k random reads | 36.1k | 141 MiB/s |
Sequential writes | 2300 MiB/s | |
Sequential reads | 3800 MiB/s |
IOPS | Bandwidth | |
4k random writes | 16k | ? |
4k random reads | 90k | ? |
Sequential writes | 280 MiB/s | |
Sequential reads | 560 MiB/s |
IOPS | Bandwidth | |
4k random writes | 430 | 1.7 MiB/s |
4k random reads | 8006 | 32 MiB/s |
Sequential writes | 311 MiB/s | |
Sequential reads | 566 MiB/s |
Next.