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 :(