Remote

Sebastian Dröge 🍵

@slomo@toot.cat

mastodon 4.8.0-alpha.3+glitch.9f145e9a5

Free software developer at Centricular, working on #GStreamer, #Rust, #GNOME and various other projects.

Likes tea, cycling, hiking, scuba diving and photography.

he/him — en/de/el(ελ), ja(日本語) in progress

1092 Followers

838 Following

22 Posts

Joined April 05, 2017

Blog:

https://coaxion.net/blog

Website:

https://coaxion.net

Work:

https://www.centricular.com

Sebastian Dröge 🍵 @slomo@toot.cat

· 7mo ago

Question for y'all who are using claude or similar: why do you put `Co-authored-by: Claude` etc. into commit messages?

You already pay that company money, and in addition you do free advertisement for them?

Should I also start adding `Co-authored-by: neovim`, "proudly written with the help of rust-analyzer", etc. to my commit messages, and if not why is that different?

Or is that a way to deflect responsibility? "Look, claude wrote that, it's not my fault if the code is wrong"?

Or are you trying to say that part of the copyright of the commit is owned by claude? And if so, what do you mean with that? It's Anthropic's now, or do you believe non-persons can legally own something?

Only replies about this aspect please. I'm not interested in hearing your opinion about how claude is the future of programming or how AI is the worst. There are already enough discussions about that, we don't have to start yet another one.

26

18

16

1

Sebastian Dröge 🍵 @slomo@toot.cat

· 5mo ago

Replying to

@raphadue@fosstodon.org @centricular@floss.social gst-rtsp-server in RECORD mode you mean? That would be an easy change but it wasn't on my list yet. I try to not change anything in gst-rtsp-server if I can avoid it :) Want to give it a try and send an MR? In theory should be just a matter of changing the element name string.

2

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 5mo ago

Replying to

@zeenix @pid_eins Most CVEs are completely uninteresting though, and also the CVE ratings are imaginary numbers that have little to do with reality. I think what Lennart refers to here is issues with actual bad impact, and many memory safety issues are clearly not that unless you're a security researcher.

2

3

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 7mo ago

Replying to

@wouter@pleroma.debian.social The Linux kernel policy seems require it for "science reasons": ... proper attribution helps track the evolving role of AI in the development process. That seems not very useful like this though. For that purpose you probably want to also document *how* it was used exactly. Also I don't think it would be a valid reason to require it because the quality might not be great. If that was the reason then the only consequence of that should be to simply say that it's forbidden / discouraged to use.

1

1

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 38mo ago

Replying to

@lkanies@hachyderm.io They are. The correct way to transliterate ö to plain Latin characters is via oe, but outside Germany almost nobody knows that and assumes the dots can simply be omitted instead 🙂 Plain o is also accepted (e.g. in documents) but not "correct". Fun fact, here in Greece I'm with five different names in the systems because everything has it's own silly rules and technical restrictions: Dröge, Droege, Droge, Ντρέγκε (correct transliteration to Greek) and Ntregke (Greek transliterated to Latin characters again) 🙃

5

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 38mo ago

Replying to

@lkanies@hachyderm.io I hope they never write anything about me 🙃 Without the umlaut my last name means 'drug' in German and I'm sure they won't manage the correct transliteration with 'ö' changed to 'oe'

5

2

1

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Thanks for the concrete example. If do_expensive_thing() has no observable side effects in this context (i.e. nothing but its return value), then a compiler could still do that. If it has observable side effects then I would argue that allowing the compiler to reorder randomly is a worse outcome than specifying an order. Apart from reproduceability of the the side effects in different environments and with different compilers / compiler flags, you probably don't want the runtime of your application to depend on such a brittle optimization. But I can see that someone else might have a different opinion on that. I hope I don't have to ever deal with bugs in their code though 😅

1

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@bugaevc@floss.social @saagar@federated.saagarjha.com See e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa44e230278a181a3e0444b970fb6d72 , which is a naive implementation of the original code in Rust and does not compile. The "trick" here is that you can only have one mutable reference to the reader or multiple immutable ones. Which is broken here. There are cases where you rely on the order but this rule is not broken, notably when using implicitly shared global state like stdout. But it at least covers all (?) cases where mutability is explicitly modeled: you simply can't have one argument affect any of the others. I should add that using the arguments in the other order actually works (because of left-to-right evaluation), but that's not the original code and IMHO also a language design mistake.

play.rust-lang.org

1

0

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Yes, also why it's not as easy as it seems to design a programming language without footguns (to be clear, Rust also has its own set of those), and you have to be very careful with adding features at a later time as the interaction between them can be confusing, or adding one harmless feature makes it impossible to add another one in the future.

1

0

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@xakon@ieji.de Both were x86-64 and it seems to be the same for all targets for the given compiler. Just guessing, but the reason for this is probably that gcc was historically first used widely on ancient x86 with stack-based argument passing, and changing that now doesn't have much advantage but has the chance of breaking someone's code in a hard to debug way.

0

1

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Oh sorry, I wrote runtime and meant to write behaviour.

0

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 5mo ago

Replying to

@zeenix @pid_eins And how many of those 70% of the issues were actual problems more severe than crashing the application? Sure it's great to get rid of these 70% and be able to focus on the others, but that's no excuse to ignore the remaining 30%. Filesystem handling issues like these OTOH have a good chance of leading to severe data loss or privilege escalation.

0

0

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@LeDuc@epicure.social Yes, historically all these things are explainable and it's hard to change nowadays without potentially causing even more breakage. The conclusion would be that it's time (or was long ago) to retire C.

0

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Right, so why not a) specify it (so at least the order of the side-effects that don't affect each other is not random), and b) disallow code where the order actually matters (side effects of one part of the expression affecting another one)? For optimizations, I'm still waiting for an example where this actually allows any kind of useful optimization that is not possible otherwise. If you have one, please let me know 🙂 That both gcc and clang rely on one fixed order seems like a hint that there is actually not much opportunity for using this for optimizations.

0

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Why would you want to keep the order unspecified though? But as I mentioned elsewhere, the code in question wouldn't compile at all with Rust for other reasons. Not just a warning.

0

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Sure, there are always ways of doing something wrong so why even bother preventing some of them 🤔

0

2

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@saagar@federated.saagarjha.com Are you aware of an example (sorry!) where such an optimization is allowed to change the order of observable side effects (leaving aside UB)? I'm fine with such optimizations and also wrote code that relies on them for performance, but at least if they don't trigger the local, observeable behaviour of the code would not change apart from being slower.

0

3

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 5mo ago

Replying to

@adingbatponder@fosstodon.org @centricular@floss.social Which part specifically? Happy to explain that in more detail, but you probably already know what UDP is good for, for example 🙂

0

0

0

0

Sebastian Dröge 🍵 @slomo@toot.cat

· 43mo ago

Replying to

@ovrim@wien.rocks Yeah I'm aware of the first part. For the second part, do you have an example where it actually allows the optimizer specifically to do a better job? Also note that gcc and clang both seem to guarantee left-to-right or right-to-left, so there doesn't seem to be much opportunity for optimizations lost in practice at least.

0

0

0

0