l1k

This is using Thunderbolt networking as transport, which incurs a bit of overhead.

But starting with the upcoming Linux v7.2, there's a new feature called USB4STREAM to use raw Thunderbolt packets as transport with minimum overhead and a super simple user interface:

https://lore.kernel.org/r/20260511102744.1867485-1-mika.west...

Release of v7.2-rc1 is predicted for Jul 5, that's when this will first be available as a tarball. Until then you have to clone from thunderbolt.git/next:

https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thun...

Or alternatively linux-next:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

Press coverage:

https://www.phoronix.com/news/Intel-Linux-USB4STREAM

Fun fact (or not so fun if you're a subscriber):

Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now.

https://lore.kernel.org/all/CAGg4U=GNtCObd_Nbm_1Rr5FEvPb69Yz...

As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.

the kernel's implementation of RSA isn't hardened against timing attacks

Cloudflare is using custom BoringSSL-based crypto code in the kernel:

https://lore.kernel.org/all/CALrw=nEyTeP=6QcdEvaeMLZEq_pYB9W...

It does enable address space separation of secret keys from user space, which some people love:

https://blog.cloudflare.com/the-linux-kernel-key-retention-s...

https://www.youtube.com/watch?v=7djRRjxaCKk

https://www.youtube.com/watch?v=lvZaDE578yc

So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space.

Disclosure: I'm co-maintaining crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.

NTB = Non-Transparent Bridge

DW = DesignWare

Some of the sites that went online around 1994 are still there:

https://north.pole.org/

https://town.hall.org/

I believe Carl Malamud (Internet Multicasting Service) was behind these.

The audio files are in Sun Audio format, which all browsers supported natively back then. Chromium apparently no longer does, requires saving and opening in VLC.

"They Were There"

https://www.youtube.com/watch?v=MmVCePfMXAU

If you need a lot of RAM, usually you need to buy servers with multiple CPUs to which you can attach the memory. Because the amount of DRAM you can attach to one CPU is limited.

If you don't have the need for all the extra CPUs, just being able to attach more memory to a single CPU through CXL may be cheaper.

The original Raspberry Pi SoC (BCM2835) is ARMv6 with VFP2 Hard Float support.

Debian's "arm" architecture is ARMv7 with VFP3. It doesn't support BCM2835.

Debian's "armel" architecture is ARMv4. It doesn't use BCM2835 to its full potential.

So the BCM2835 is awkwardly positioned in-between Debian's two stock ARM 32-bit architectures, which motivated the decision to recompile all packages for a BCM2835-specific "armhf" distribution.

In a sense, it's a historic artifact.

The point here is likely to pull the rug out from under scalpers' feet.

With the Raspberry Pi 5 out in two weeks, all the held-back inventory of older models will be dumped, prices will plummet, availability will become a non-issue.

In that sense it's a wise move.

A lot of RISC CPU arches which were popular in the 1990's declined because their promulgators stopped investments and bet on switching to IA64 instead. Around the year 2000, VLIW was seen as the future and all the CISC and RISC architectures were considered obsolete.

That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium.

The PCI resource allocation code is fairly intricate and everyone is scared that changing it may cause regressions. Sergei's patch set is quite intrusive and it would be necessary to somehow break it up into smaller pieces that are slowly fed into mainline over several release cycles, always watching out for regression reports. So, the problem is known, but the engineers working on PCI code in the kernel are given higher priority stuff to work on by their employers, hence the issue hasn't gotten the attention it deserves.

Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.

You'd be surprised. Here's an article I wrote on the modernization of PCIe hotplug in Linux:

https://lwn.net/Articles/767885/

Thunderbolt devices appear in the OS as a PCIe switch, so you need two additional bus numbers (one for the Switch Upstream Port and one for the Switch Downstream Port). If the device is hotplugged to a port which has run out of bus numbers, you'll get this error message.

Mika Westerberg is constantly fine-tuning the allocation of PCI resources in the Linux kernel to avoid such scenarios. Some recent patches:

https://lore.kernel.org/linux-pci/20220905080232.36087-1-mik...

https://lore.kernel.org/linux-pci/20221130112221.66612-1-mik...

On macOS, it's possible to pause the PCI bus, reallocate resources and unpause the bus:

https://developer.apple.com/library/archive/documentation/Ha... (search for "Supporting PCIe Pause")

We don't have that on Linux unfortunately, so we depend on getting the initial resource allocation right.

Sergei Miroshnichenko has worked on such a reallocation feature for Linux but it hasn't been accepted into mainline yet and he hasn't posted a new version of his patches for almost two years, so the effort seems stalled:

https://lore.kernel.org/linux-pci/20201218174011.340514-1-s....

Filed chapter 11 twice.

Bad management made the wrong bet, thought Itanium and Windows would take over the world.

But what really broke all UNIX workstation manufacturers' backs was the unwillingness to cannibalize their products with affordable machines. SGI workstations were not affordable to students, so they got x86 machines instead and installed Linux. Google was built with x86-based Linux boxes because that's what the founders were using and could afford. UNIX workstation manufacturers lost an entire generation of young engineers that way. Apple eventually offered what they should have: Sleek, affordable machines with a rock-solid UNIX underneath a polished UI.

There's a series currently under discussion which failed CI:

https://lore.kernel.org/intel-gfx/20211214140301.520464-1-bi...

Plus 13 patches over the past years (not counting merges and SPDX commits):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Unfortunately, a lot of the PREEMPT_RT patches follow the "disable stuff for now, fix up for real later" anti-pattern. :-(

Case in point:

https://lore.kernel.org/intel-gfx/YgqmfKhwU5spS069@linutroni...

This was the first time that I was aware of Apple had shipped a little Endian processor.

FWIW, the LaserWriter 16/600 PS (introduced 1994) uses an Intel 80168 as I/O processor for AppleTalk serving etc.

So Apple did develop for and ship little endian CPUs way before the iPod.

A heartfelt thank you Cameron, TenFourFox has kept my Pismo 7410/550 alive and useful for another ten years after Camino's sad demise. I've gotten so used to the regular TenFourFox updates that I already feel withdrawal symptoms now. It's always been mindboggling to me that you've done all this almost single-handedly.

Wayne Goodrich was fired by Apple shortly after Steve's death and subsequently sued the company:

https://www.latimes.com/business/la-xpm-2012-aug-21-la-fi-tn...

That is a fantastic showcase how to respond to negative criticism in a friendly, constructive and polite manner. Good work, Jason.

XDC 2018 - Lyude Paul & Alyssa Rosenzweig - Introducing Panfrost

https://www.youtube.com/watch?v=qtt2Y7XZS3k

I've you want to learn even more, take a look at Documentation/memory-barriers.txt in the Linux kernel source tree:

https://www.kernel.org/doc/html/latest/staging/index.html#me...

This outcome was anticipated much earlier in a 2006 interview with Mike Pinkerton (ex-Mozilla, now Tech lead for Chrome on Mac & iOS):

"And then, kind of, they lucked into Firefox. I mean, seriously, they got really lucky that Firefox — that Ben was able to execute so successfully, because I have no idea what would have happened to the Foundation without Firefox. It probably would have just blown up and you know, dried up and blown away. [...] And so they kind of transitioned from that to, “Well, okay, now we’re a corporation and we’ve got our big ticket item, and we’ve got to make sure as many people buy it as possible. And you know, and how do we continue to — how do we continue to ensure that revenue coming in?” You know, so they transitioned more from “Wow, we’ve got this great thing, let’s share it with the world!” To, “Well, we’ve got this great thing, we’d better keep making money off of it.” And I think a lot of those decisions have sort of tainted where the project was going. Bringing in — you know, they’ve got all this money, so now they bring in all of these marketing and manager people who haven’t been part of the community, who don’t understand why Firefox is successful, because they didn’t see what it was. They didn’t grow up through that failure to see why it’s a success and now they’re making the decisions to continue the success."

http://mozillamemory.org/detailview.php?id=7277

Download the raw patch from lore.kernel.org, apply it with "git am", fix up the commit message with "git commit --amend", add your "Signed-off-by" below the existing one, submit with "git-send-email" or "git format-patch" + "msmtp".

That way the commit author remains the same because "git format-patch" includes a "From:" line in the message body which "git am" will interpret as the commit author when the maintainer applies the patch.

Your Signed-off-by is necessary to keep the DCO chain intact: https://www.kernel.org/doc/html/latest/process/submitting-pa...

However, that is now done: https://lore.kernel.org/netdev/086b426f44bc24360cc89476fe18d...

Thank you for the report.

The second flight of this mission is currently ongoing:

https://www.flightradar24.com/DADLR/2491326d

Thirty years ago, in the Hunt for Red October, a software to identify seismic events was used to predict movement of a man-made submarine:

https://www.youtube.com/watch?v=y7g6dKncO-I

Thanks for the awesome suggestions.

The video port coming out of the Raspberry Pi SoC is HDMI, hence the choice of the connector. We've put the connector on the top of all of our products to lessen the chances of the cable accidentally coming lose. The top and bottom of the case is primarily used for vents. We'd have to make them smaller to fit a VGA or DVI connector there and that might negatively impact heat dissipation. That said, I agree that HDMI is not as rugged. A particular problem we've encountered are cheap cables which connect the shield to ground.

As for flashing the products, there's a micro USB port on the front plate which allows flashing the eMMC from an attached laptop or PC. It's also possible to mount the eMMC to retrieve logfiles from the machine that way. When the machine is booted, it senses whether bus power is provided on the micro USB port. If so, the USB port on the Raspberry Pi SoC is switched to gadget mode instead of host mode. You then need to run a little program called rpiboot on the attached laptop which downloads a firmware to the Raspberry Pi to turn it into a USB Mass Storage Device. Afterwards the eMMC pops up on the attached laptop as an external drive:

https://www.raspberrypi.org/documentation/hardware/computemo...

It would in principle be possible to build small gadgets which users plug into the micro USB port and which automatically flash the attached Raspberry Pi without the need for a laptop.

Another possibility would be to split the eMMC into multiple partitions, one containing the regular OS and the other to store an update image. The system would initially boot into a RAM disk, determine whether an update image is present, extract that over the regular OS partition and reboot. The update image could be deployed via ssh.

A lot of our customers have a background in automation and are used to Windows on their desktop PC, with little prior Linux experience. Shipping a desktop by default is intended to make their life easier.

Since the image is based on Raspbian, updates are installed via apt-get as usual. There are some deb packages of our own pre-installed. Updates for those are made available via our apt repository at packages.revolutionpi.de.

You mean the watchdog integrated into the BCM2835? That's a good question, we haven't tested that yet, but I've added it to the todo list now.

One particular product in the Revolution Pi lineup called "Connect" has an additional hardware watchdog which is also capable of resetting attached devices via a relay. That one works even when the BCM2835 has locked up completely. However, the CPU needs to have cooled down a bit to reboot successfully.