how do i get plasma to do screensharing here?

and more importantly using pipewire instead of pulseaudio

oh it works on firefox, but not on a linuxulator app like Discord

hm, mesa errors on linuxulator, p.swee.codes/swee/8ada4dfe54a248d2a244ffbd651c4f1a

sorry i cant help you swee

What’s the simplest way to get my install to be able to resolve .local names? Avahi looks lijenit pulls in dbus, which seems like a lot for this.

Hello. Does anyone know of any C (or C++, but for the sake of god, no rust/go/js with npm/yarn stuff, etc) RDAP client that would help me when `whois` fails?

Not a freebsd user (yet), but perhaps someone using freebsd knows of something

codegirl: freshports.org/dns/rdap (which is golang) or freshports.org/net/rdapper (looks like perl)

codegirl:

oops

Thanks a lot, gedge

I just did this: ls -d /usr/ports/*/*rdap*

there may be better ways :)

Do you think perl would be a risk for the same kind of issue that JS&npm, rust&cargo, etc would suffer? I mean, supply chain attacks and such?

That's a hard question to answer, because the answer is (always) "yes, there's a risk for [insert language here]"

But, using an O/S package (whether it's perl/go/js/rust/...) probably reduces your exposure. Though, not entirely.

the Perl equivalent to JS/NPM and Rust/Cargo would be Perl/CPAN

anth: you probably want mdns in nsswitch.conf via dns/nss_mdns port

codegirl: every language has a supply chain issue when third-party libraries are being used in the development process. I don't think there is a "language ecosystem" around assembler, but I could be wrong on that. Outside of that, most languages have an ecosystem around them and hence they have a supply chain problem. my humble opinion.

mns, indeed, I think you're right, maybe I should think why I feel safer with standard shared libraries on a unix system

Maybe I'm departing from broken assumptions

codegirl, I think standard shared libraries to me means /lib/* /usr/lib/* which are part of base and the people who can commit there are a smallish known set of historically good people. Then layered on are /usr/local/lib/* libraries coming in through ports and those have supply chain possible problems.

shared libraries don't do anything to help against supply chain attacks

But hopefully if something has come through ports I am hoping that someone would notice a problem. Though that is not guarenteed.

In this case a supply chain attack would be someone puts something bad in libxz(sp?) and it gets into the ports tree and installed everywhere compromising anything that uses a standard compressor. Oh, that's already somewhat almost happened did happen in some systems.

Indeed, I'm aware of the xz issue, but...

That was exploiting other weaknesses in other systems that we thankfully avoided by being better but it illustrates the potential for things coming through ports.

well, what helps for stuff that is part of base is the slower release cycle and more reviews, but that doesn't make immune against supply chain attacks

When you compare how many times shared libraries (the most actively maintained and with more eyes on it), it's a rare event that something like what happened to xz happens to, say, curl

I mean, of course it's not immune, but it's quite rare that someone is able to put a malicious code inside some library that gets to do that and it goes all the way unnotice, while on stuff like rust's cargo it's quite easy

Perhaps the release cycle speed is indeed something to be valued here

But I think the complexity net of interdependance is also a possible weakness on the models used by rust and other languages

Release cycle speed is definitely a factor. Slower releases give time for reviews to happen. Fast churning releases are impractical to review because tomorrow the code is completely different anyway.

This is why I'm following stabilization week for Current Again

codegirl, Thanks for no supporting rustcancer.

why rust in FreeBSD or any BSD for that matter is a bad thing?

mikulvoid: because only few ppl can code in Rust, nobody kwows Rust en mass as C. Rust is very complex language comparing to C.

what language would you like to see in BSD?

How's about the principles, philosophy, and ideology of a language, e.g.: <felipec.wordpress.com/2025/02/13/rust-not-for-linux> ?

Now, Git has a dependency on Rust. :-) or :-(

In BSD, I'd like to see C, Pascal, perhaps Hare, Seed7...

sounds like the guy just doesnt like rust

no good technical arguments in there

C is widely spoken, everyone can join the development, report bugs, provide support. Rust is not. Rust is a barrier.

The appeal to popularty is a false argument: C was no popular when it was first created. Languages are born, flourish, and die.

checkpoint, I am glad you did not bring Python in. Lua, Perl, and Tcl are all better, IMHO.

ant-x: C was and is very popular since 70th. it is very easy to learn, it's easy to read and understand code in C. It's being taught in universities. Rust is much more sophisticate, it's even more complex than C++ I think, noone teaches Rust.

I was shocked to learn that Universities start teaching not pure computer-science but whatever is trendy in the corporate culture :-(

ant-x: maybe because corporations fund them ? depends on univesity though. Where I studdied back in 90th they still teach Pascal.

Back in the 90-ies yes. But now?

They may be attracting studient by teaching the trenty sh&t.

trendy sh&t is vibe coding, it does not require teaching :)

Vibe coding in Rust :-)

what's puzzle me most is that in many unis nowadays there are some tutors/teachers who require extensive use of LLMs, same time there are those who strictly oppose that. Poor students fail to carve their learning curve.

ant-x: Vibe coding in Rust - that's what Canonical is doing right now.

My colleagues think those encouraging the use the Aritficial Idiot are clever and progressvie...

What's Canonical?

What Canon allows vibe codeing instead of celebrating human excellence?

ant-x: the Ubuntu developers, AFAIK.

A modern pun: "My C is Rusty".

Yikes... AI-cancer is permeating even free software...

By the way, I don't know much C beyond C'89.

ant-x: c89 is pretty much sufficient to understand BSD kernel code

I am not tryting to do that.

ant-x: maybe you are not just ready for that, morally. :)

OT: Does anyone know whether alloca() is required to present in the standard library by all C standards?

May be...

* to be present in

ant-x: I don't think alloca() is in C standard, it's a compiler's feature (sub rsp, XXX)

Non-standard, unlike VLAs in a later standard. Thanks. I wonder why alloca is still available in GCC with -std=c89 . Not very strict, perhaps.

ant-x: "man alloca" says: The alloca() function appeared in Version 7 AT&T UNIX/32V. Basicall it's pre '89.

gcc --std=c89 enables those standard features but doesn't disable non-standard features.