Posts
1542
Following
216
Followers
1958
Director of Linux Foundation IT. Currently in charge of kernel.org infra.

This account is for Linux/Kernel/FOSS topics in general: #linux, #kernel, #foss, #git, #sysadmin, #infrastructure.

For my personal account, please follow @monsieuricon@castoranxieux.ca.

Montréal, Québec, Canada 🇨🇦🇺🇦
Anyone else has `alias ungz=gunzip`?
7
3
14
The first of each month works as a regular reminder of how many mailman-2 servers there still are out there.
1
13
28
Did you ever wonder how those kernel releases make it to a mirror near you? Wonder no more, I've documented the process of delivering the latest set of stable kernels.

https://youtu.be/_MnZdrBJOwI?si=kfzFgfjr_yi8F4md
1
3
11
Oh no.
21
85
183
Edited 1 year ago
Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:

- The kernel security team does not have any "early notice"
announcement list for security fixes for anyone, as that would only
make things more insecure for everyone.

- The kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

- You HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random
patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system,
and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss
it with them as to how they achieve this result as this is what you
are paying for. If you aren't paying for it, just use Debian, they
know what they are doing and track the stable kernels and have a
larger installed base than any other Linux distro. For embedded,
use Yocto, they track the stable releases, or keep your own
buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before
putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about
1.5mil lines of code, embedded runs about 3.5mil lines of code, your
mileage will vary). If you can't test releases before moving them
into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a
future problem as future problems, when found, will be fixed then.

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...
11
228
247
PSA: don't get COVID. It sucks.
4
11
26
Dear Qatar Airlines. Everything was great, but providing "Avengers: Infinity Wars" without "Avengers: Endgame" in your entertainment options is just _mean_.
1
0
5
On the upside, COVID 19 tests still work. On the downside -- everything else. :(
2
2
7
De retour à Montréal!

I need a nap and a long break from air travel.
0
0
5
What are you doing, frog, are you nuts? Get inside. Turn on the AC. Take a cold bath.
1
1
8
Looks like I get to spend a day in Doha because they overbooked our flight to Montreal. No big, I've never actually been to the middle east.
0
0
0
✈️ ALA > DOH > YUL

I spent a great week in Almaty visiting my KZ cousins and meeting up with my parents. Now it's time to head back.
0
0
2
Hopping on an airplane to go home soon. Here are some horses from a walk earlier.

Any guesses where I have been?
3
0
5
echo "canyon"
0
0
11
Yakkity-yak.
3
1
10
I am currently away from my office.
2
0
32
Me: orders a delivery once while visiting Portugal in 2019
Routinely, for the next 4 years: "Atualização dos termos e condições"
0
0
7
Nobody expects the speculative execution.
6
66
104
Ask fedi: replicating large file collections over slow links
Show content
I have a server "primary-na" with 50TB of arbitrary content in /srv, mostly in millions of small files, many of them identical hardlinks. I have 3 other servers across the world (copy-na, copy-eu, copy-ap) where I want to have the exact replica of primary-na's /srv. These replicas may be occasionally unavailable for hours on end, or they may be occasionally slow or under high load. The content on them may also occasionally bitrot and must be identified and healed.

I've researched this multiple times over the last few years, but I've still not found a solution that would beat "just run rsync over it when something changes on replica-na." It's simple and effective, but obviously super inefficient and IO-heavy on both ends.

Any suggestions on how you would do it?
12
4
5
Show older