benou

Tbh I am using /e/OS as my daily driver and I fully agree, it just works. Bonus points for the Nextcloud integration which I can tie to my self-hosted Nextcloud instance.

I do not understand all the negativity, I think it is a solid alternative in the ecosystem, and choice is a good thing.

Anyone can propose a devroom for FOSDEM, I hope you'll do it next year :)

What is the FOSDEM community's answer to the real concerns that these changes pose ? Let's hand solder raspberry pis ! let's self host LLMS from 2 years ago on FreeBSD ! Look, i can run wasn linux on this risc-v cpu !

Maybe, just maybe, they're having fun? FOSS is not only about corporate open-source, but also genuine curiosity. Both can have their place.

no wonder that nobody younger than 40 was attending the conference. The next generation is doing something else and rightly so.

I saw a lot of students at FOSDEM, attending, presenting and helping the at organization.

My experience was good: on my way in Paris -> Brussels arrived 10min early, and on my way out Brussels -> Paris I had ~15min delay (apparently because Police had to board the train before Brussels).

I'm self-hosting for 17 years and counting.

In my opinion, the pragmatic solution I use is:

1) use a specialized distribution (I use yunohost but there are others). This makes configuring SPF, DKIM, TLS and more a breeze

2) use a reputable relay to send your emails (I use OVH but again there are plenty of other choices)

Of course it means you are not "pure" because emails you send will go trough a 3rd party (the relay) but it solved the delivery issue entirely for me, so that I can continue to benefit from all the other benefits of self-hosting.

Yep, AI scrapers have been breaking our open-source project gerrit instance hosted at Linux Network Foundation.

Why this is the case while web-crawlers have been scrapping the web for the last 30 years is a mystery to me. This should be a solved problem. But it looks like this field is full of wrongly behaving companies with complete disregards toward common goods.

Here is an example of preparing a debian ARM image on x86 with debootstrap, qemu and chroot:

  ~# sudo apt install qemu-user-static debootstrap
  ~# mkdir /tmp/arm
  ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian
  ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/
  ~# chroot /tmp/arm   # from that point, you're running ARM!
  ~# /debootstrap/debootstrap --second-stage

I still use my Thinkpad x61 as my daily driver (typing on it right now) and I don't feel most of the "severe limitations" you are listing. I think some are wrong (eg. I use Dual-band AC wifi and BT4.0 wifi card in mine, and have a 2.5" SATA-II (3Gbps) SSD), and others are not limitation for my use. I won't recommend it to everyone, mind you, but for my use it is perfect.

and for those wondering, looks like it is called "dom.private-attribution.submission.enabled"

Atari ST serie was very popular in Europe, more popular than Mac or Amiga at the time I believe.

In a similar vein, the "Confrérie des Charitables de Saint-Éloi" was founded in Béthune (France) in 1188 during a plague epidemy and is still active today.

Edit: spelling

VPP dev here. Yes, we had support for OpenSuse and RHEL/CentOS in the past, but distro support vanished. We're a small team so we need to focus (note: for OpenSuse it's still maintained by a volunteer, just not in CI/CD), but we're open :) FreeBSD fundation decided it was important for them and we're happy to help!

VPP dev here. Our perf tests for Intel run in CSIT lab consistently shows a perf benefit of 10%-20% since Haswell I believe, so in our typical VPP deployment we usually map 2 VPP workers (dataplane threads) to both hyperthreads of the same physical core. But that's for VPP, your mileage may vary depending of your workload (eg. FreeBSD kernel stack).

My guess is kernel needs to know the current directory of a process so that when said process tries to open a file without an absolute path (eg. just "file.txt" and not "/tmp/file.txt"), it can open "$CWD/file.txt".

This must be tracked by kernel, because not all syscalls go through libc, you can issue the open syscall directly from a process.

There might be other reasons, but I'd bet it's the main one.

Also, the claims they make in the paper is inaccurate relative to VPP: they claim VPP uses "overlay/convert" method, which is true for DPDK drivers, but we also maintain native drivers for NIC we care about (eg. Intel's) - especially because going through the "overlay/convert" method is costly at high-packet rate.

IOW, one of their strong claim is that PacketMill is innovative because it avoids copying/converting uneeded metadata, but VPP is already doing that since years.

Finally, their claim to break the 100Gbps on single core @2.3GHz is cute, but again I'm afraid they're late to the party. They claim 12-13Mpps per core for 64-bytes packets for example but VPP can achieve 20+Mpps per core already for L3 forwarding (routing).

Again, benchmarking is hard, but I keep reading there claims over and over in academic papers when they're factually wrong for area I know about. I can only imagine what is happening for area I don't know :(

The approach is interesting but I'm afraid that the benchmarking is bogus, as it's usually the case is in this kind of papers.

Part of the problem I think is that they have to compare to other existing solutions (click, VPP etc) otherwise everybody will ask, but at the same time it is very difficult to do a fair comparison.

I'm a VPP developer hence I'm both biased and a knowledge-domain expert, but focusing on what I know, which is VPP: figure 11b, they compare VPP to PacketMill for some L2 patch workload. They claim their approach is fare because they use automated tooling to benchmark, good and we also do for VPP, but our results don't necessarily match theirs - and, surprisingly, our results are higher than what they claim for VPP.

PacketMill paper figure 11b for VPP for L2 patch for 64-bytes packets at 1.2GHz using DPDK MLX5 driver [1]: ~5Gbps

VPP for similar configuration [2]: ~7.5Gbps (already a 50% error margin?)

VPP using a more optimized NIC driver (native AVF vs DPDK MLX5) [3]: ~18Gbps (almost 2x what they seem to claim for PacketMill...)

All this to say comparing different solutions is terribly hard, and I'm not sure of the value of this kind of benchmarks.

For VPP we built CSIT [4] which is opensource under the Linux Foundation Networking to automate tests in the same environments, to compare between VPP and DPDK between releases and platforms.

[1] https://packetmill.io/docs/packetmill-asplos21.pdf

[2] http://csit.fd.io/report/#eNp1kd0OwiAMhZ8Gb0zN6MRdeaHuPQxidS...

[3] http://csit.fd.io/report/#eNp1kd0OgjAMhZ9m3pgaVkS88ULlPcwcVU...

[4] http://csit.fd.io/

Most packets follows the same nodes in the graph. You have some divergence (eg. ARP packets vs IP packets to forward), but the bulk of the traffic does not. So typically the initial batch of packets might be split in 2 with a small "control plane traffic" batch (eg. ARP) and a big "dataplane traffic" batch (IP packets to forward). You'll not do much SIMD on the small controlplane batch which is branchy anyway, but you do on the big dataplane batch, which is the bulk of the traffic.

And VPP is targeting high-end system and uses plenty of AVX512 (we demonstrated 1TBps of IPsec traffic on Intel Icelake for example). It's just very scalable to both small and big systems.

Batching packets bring several benefits:

  - amortizing cache misses are you mentioned

  - better use of out-of-order, superscalar processors: by processing multiple independent packets in parallel, the processor can fill more execution units

  - enable the use of vector instructions (SSE/AVX, VMX etc): again, processing multiple independent packets in parallel means you can leverage SIMD. SIMD instructions are used pervasively in VPP

Not that surprising, given this was already extensively documented in the 2000's (so already widely known by then) with iSCSI and such, see https://www.rfc-editor.org/rfc/rfc3385 for example.

Looking at RFC1812, Martian packets [1] seems to be reserved addresses only.

What you're talking about is referred to as source address validation [2] also known as strict reverse path forwarding (RPF) [3].

[1] https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.7

[2] https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.8

[3] https://datatracker.ietf.org/doc/html/rfc3704#section-2.2

Looks like it's the more expensive (and more capable) MeteoBridge from the same company: https://www.meteobridge.com/wiki/index.php/Home not Meteostick.

Monitoring weather data at home is a cool project! I have a Davis station installed on a pole above my roof and it is interesting to see the difference between feelings and measures (esp. wind gust and rain rate).

Anyway, to collect weather data from Davis station, I highly recommend https://www.smartbedded.com/wiki/index.php/Meteostick

It is very simple to use and works really well - it is also supported by WeeWX through an out-of-tree driver, but is easy to setup. It also allows you to keep your console in your living room while you collect data in your basement.

I'm using a similar setup but with a Davis Vantage Vue weather station [1], a Meteostick USB receiver [2] and WeeWX weather software [3]! It is pretty cool to be able to compare your feelings vs the hard facts (eg. I found it very hard to evaluate wind speed).

[1] https://www.davisinstruments.com/pages/vantage-vue [2] https://www.smartbedded.com/wiki/index.php/Meteostick [3] https://weewx.com/

I highly recommend yunohost. I am using it since a few years, after a lot of years of maintaining my own "classic" mail + web server by hand [1].

I deploy it in an unprivileged LXC container [2] and went through several upgrades already. It really worked great for me.

[1] https://benou.fr/www/ben/14-years-of-self-hosting.html [2] https://github.com/bganne/yunohost

I thought it was going to be about NIC descriptors [1]. I think we can say that descriptors is not very descriptive without context...

[1] https://stackoverflow.com/questions/36625892/descriptor-conc...

According to Wikipedia https://en.wikipedia.org/wiki/Goat

The goat or domestic goat (Capra hircus) is a domesticated species of goat-antelope typically kept as livestock. It was domesticated from the wild goat (C. aegagrus) of Southwest Asia and Eastern Europe. The goat is a member of the animal family Bovidae and the tribe Caprini, meaning it is closely related to the sheep.

I could not find any RSS feed on their website though

I love hiking into remote areas, including "bear country". I have seen black bears and grizzly bears while hiking.

You do not need assault rifles, this sounds silly and over the top. You just need to be aware of your surroundings, follow the rules and have a bear spray : https://www.nps.gov/subjects/bears/safety.htm

Very good idea!

And I love bloom filter too (and their more modern successor cuckoo filter) but I'd challenge the usecase you mention though: 1 million IPv4 is 4MB, and 16MB for IPv6. That's tiny, you're better off using some kind of hashtable, unless you have a fast and small memory, and then a slow and big memory (say embedded processor with small CPU cache and some DRAM).

Bloom filters are useful when your working set cannot fit in your fast memory, to allow you to go to the slow memory only for a small number of requests.

I was going to mention it too! The really cool thing about reservoir sampling is that it can be done "online" (ie process input incrementally) which makes it super useful when you want to compute statistical properties of something in the field without blowing up your cpu and memory.

For example, let's say I have a server serving queries. I want to measure min/max/avg/stdev/99p you name it. You can do it cheaply with reservoir sampling, without having to save all data points.