Accepted stands for FOSDEM 2024 https://fosdem.org/2024/news/2023-11-20-accepted-stands-fosdem-2024/

Any embedded Linux software engineers looking for a well paid job?

Louis Rossmann is hiring.

#Linux #TexasInstruments #EmbeddedLinux #Programmers #Engineers #Work

Putting software in containers is cruel and unnatural.

Programs should be allowed to roam and graze freely on computer systems. Forcibly isolating and constraining them will lead only undue suffering.

Use of technologies such as Docker in systems administration must be ended immediately, there is no ethical justification for inflicting trauma like this in an enlightened society.

In this "free range software manifesto" I will -

Well, TIL that b4 shazam has some other handy flags like -H and I can use that instead of make a branch, apply, merge, drop in cover letter.

CFP for the containers devroom at #fosdem2024 is now out!
https://discuss.linuxcontainers.org/t/fosdem-2024-containers-devroom-call-for-papers/18253

With the HDR OLED Steam Deck announced today, it's the ideal time to check out a recent blog post (and the linked XDC talk) on exposing AMD color management features to Linux userspace from my @igalia colleague @melissa https://melissawen.github.io/blog/2023/11/07/amd-steamdeck-colors-p2

Linaro successfully enables upstream Linux support for the Qualcomm Snapdragon 8 Gen 3 Mobile Platform - the latest addition to the Snapdragon family.
Learn more about:
- Effortless upstream Linux integration
- Powerful performance optimization
- Running AOSP with Mainline
- Continued collaboration
Read the Blog Post Here https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-3-mobile-platform/
#Qualcomm #LinuxSupport #Snapdragon #Technology #Innovation"

A talk for fresh Kernel Maintainers and anyone looking to optimize their workflow @linuxplumbersconf with @krzk
1. Get improvements to email workflow: b4, useful simple hooks for verifying commits (because checkpatch is not enough).
2. Get yourself in linux-next and get tested by community Continuous Integration/Testing.
3. Add yourself to kernel.org keyring, sign your tags and pushes (for transparency log).
4. Dump the mailing lists: use lei and lore
https://lpc.events/event/17/contributions/1498/

We'll be holding a BBB Training session for remote presenters and attendees on Thursday (8 November) at:

7am PST, 10am EST, 3pm UTC, 4pm CET, 8:30pm IST, 12am Friday JST

This will be recorded so that you can watch it later.

This session is highly recommend for those that are presenting remotely

To join, you will need to log in to: https://meet.lpc.events

After logging in, to join the meeting, click the Hackroom entry in the leftnav then select the join button of Hackroom 1.

My k230 just got here, sounds like nobody has upstream running yet?

"We are happy to tell you that we accept your proposal "RISC-V devroom" as a devroom at FOSDEM." Woop, woop! @fosdem

The secret to conferences (but you did not hear this from me) is not attending the sessions

Failing is OK. We can learn a lot when we fail. https://inbox.sourceware.org/libc-alpha/cf4a8045-c824-6f1c-ffd1-e433aa45ef2c@redhat.com/T/#u

Just sent a large number of patches to support the Qcom Snapdragon 8 Gen 3 in mainline #Linux :-)
=> https://lore.kernel.org/all/?q=sm8650

PSA: we have seen the vague viral reports alleging a Signal 0-day vulnerability.

After responsible investigation *we have no evidence that suggests this vulnerability is real* nor has any additional info been shared via our official reporting channels.

I had an amazing time last week at @KernelRecipes 10th edition. This marked my fifth year speaking at the most unique Linux kernel conference in the world. I'm thrilled to have been a part of this incredible event for half of its life so far. Thank you folks!🐧🙂

Trimmed diffstat of v6.6-rc1 pull request ARM SoC changes from @arnd - the most active platforms for v6.6:

18.9% arch/arm64/boot/dts/qcom/
0.6% arch/arm/boot/dts/qcom/
1.0% drivers/soc/qcom/
...
9.6% arch/arm64/boot/dts/freescale/
3.6% arch/arm/boot/dts/nxp/imx/
0.7% arch/arm/boot/dts/nxp/ls/
0.9% arch/arm/boot/dts/nxp/mxs/
...
8.1% arch/arm/boot/dts/aspeed/
...
8.2% arch/arm64/boot/dts/ti/
0.5% arch/arm/boot/dts/ti/
...
6.6% arch/arm64/boot/dts/nvidia/
...
6.3% arch/arm64/boot/dts/rockchip/

Way to go Qualcomm SoC community!
Source: https://lore.kernel.org/all/4f60d13e-f060-491a-88c7-6f25323a48f8@app.fastmail.com/

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...

PSA: don't get COVID. It sucks.