I do not share your view of old timey sales pitch, at least for the talk about systemd nspawn OCI container support.
If anything, that talk was a tad low effort, with even dismissive answers — "Yes" and "No?" as full answers to audience questions, with no follow up?! Still very informative though!
The Varlink talk really was very salesy for a Fosdem presentation. Shouldn't be long until the recording becomes available, feel free to tell me I was wrong after watching it.
It's mainly re-hashed. I think I've seen the same talk twice before? At least once.
It's a very "I've made a cool thing. This is what I think is cool about it" type of talk. Which I don't think is uncommon for FOSDEM.
Maybe a bit uncommon for a higher profile figure like Lennart.
> It's mainly re-hashed. I think I've seen the same talk twice before? At least once.
He held a similar talk at All Systems Go I think (I missed the talk here at FOSDEM).
> It's a very "I've made a cool thing. This is what I think is cool about it" type of talk.
Varlink isn't something he just made up, he mearly "adopted it" (started making use of it). It existed before, but I don't know anything that really made use of it before.
The official-looking website at https://varlink.org doesn't give any information about who the authors are, as far as I can tell, but the screenshots show the username "kay". There's a git repo for libvarlink [1] where the first commits (from 2017) are by Kay Sievers, who is one of the systemd developers.
An announcement post [2] from later in 2017, by Harald Hoyer, says that the varlink protocol was created by Kay Sievers and Lars Karlitski in "our team", presumably referring to the systemd team.
So the systemd developers "adopted" their own thing from themselves?
While I guess you aren't wrong, I also wouldn't say you are entirely correct that Kay is a systemd developer. He use to work on udev, but hasn't been active in any meaningful way on it for 2 years before varlinks release[1]. For what it was made I can't really say, but Lennart hadn't start integrating Varlink until a while after its release (I think I remember it being like 2021 or so when he started making use of it, after another check it seems the start of varlink stuff in systemd was 2019[2]).
Kay Sievers' Wikipedia page cites a blog post by Lennart Poettering [1] which says that systemd was designed in "close cooperation" with Kay Sievers and that Harald Hoyer was also involved, so it seems pretty clear that he's on the team that develops systemd, the team that Harald Hoyer referred to as "our team". All three of them gave a talk [2] together in 2013 about what they were developing.
If Lennart Poettering "adopted" varlink, he seems to have done so from members of his own team ("our team") who created varlink and who are also fellow co-creators of systemd.
My only disappointment with this year's geopolitcs-enhanced (always a welcome addition to tech by the way, as tech is ultimately steered by politics!) FOSDEM is a great underrepresentation of mainland China, and more generally the whole Global South. It is sad to see this omission in a time when the EU's free movement needs more like minded allies than ever. And what can be more free than that untethered by the chains of empire.
Sure, there was some mention of Brazil in some talks. And yes, a couple of China specific speakers etc, but in my view this is almost cancelled by the inclusion of topics about taiwan. Similarly the China focused talks mention "specific risks" stemming ostensibly from a differing system of governance.
Almost as if corporate sponsorships induce self censorships which limit true organizing effort.
FOSDEM is the Free Open Source Developers European Meetup. It's expected that people from China don't like traveling a long way to Europe. They have other FOS conferences in China.
Corporate sponsorships enabling "self-censorship"? That's rich from someone whitewashing authoritarianism. If FOSDEM underrepresented China, good - tech thrives without Beijing's chains. Bring real open-source contributions next time, not propaganda.
I am in the same boat. There is an about:config flag to revert the behavior and use old menus.
I am not sure whether the new mac-native context menus even have a notion of access keys, so I am not hopeful for a fix.
Do any informed US readers here know what are the implications of the FAA ADS-B privacy ICAO address program[0]? Will this reduce the possibility for hobbyists to have oversight over such flight operations?
Last week, I tried this on an AMD 3400g (Vega 11 amdgpu) with that specific environment variable and my results were:
- vainfo told me it (VA-API) can decode vp9 and h264 among others
- mpv plays vp9 and h264 using vaapi
- firefox log mentions using VA-API in h264 playback but in vp9 nothing related is printed
Maybe firefox whitelisted only h264 for hw decode?
Depends on what "not worth it" means really. Even though gestures minus interactivity is far from how "proper" gestures feel, I'd rather have something rather than nothing (for example, it is still more convenient to 3-finger swipe to switch virtual desktop than a keyboard shortcut or clicking a button).
Ok, I admit that "not worth it" is better rephrased as "not the end goal". If the end goal is interactive gestures, one-off discrete gestures are welcome as an intermediate step or halfway solution.
Ideally the input framework would know if the streamed gesture was consumed real-time, and if not (e.g. no support for such interactice gesture in some program), the one-off event is issued.
This reminds me of current xorg libinput two finger scrolling / wheel event. Xinput2 is the relevant keyword but I am not sure exactly how it all fits in, only what I can observe:
- applications that don't know about multi finger scroll/pan listen for and accept classic mouse4 / mouse5 events and interpret them to scroll in steps if relevant. As an example, xev x event testing uility is not xinput2 aware AFAIK nor are classic x or older gtk programs
- applications can be xinput2-aware (e.g. eog Eye of Gnome image viewer, but maybe also any non-ancient gtk3 application as well), in which case they can scroll more directly (pixel-smooth) and with appropriate acceleration / smoothing / inertia (gtk-specific ?). In firefox there's an env var like MOZ_USE_XINPUT2 which tells firefox it can do this smoother wheel handling, not sure if it's required or automatic these days.
To test received events including xinput2, there is utility xinput --test-xi2
As a closing anecdote, there's an interesting interaction bug I have experienced with xfce where both xfwm will react to Super+scroll (compositor-level full screen zoom), and the application under the mouse pointer will also react to the scroll up/down. I have not deciphered the interactions here but it depends on app under mouse cursor...
reply