Search results

However you go about this path, in the context of a third party port - should you decide to proprietarize any part of it; you lose the benefit of garnering contributions from the community. No one is going to work on third party proprietary software for free. So if that is your objective; forget...

"Those who do not understand Unix are condemned to reinvent it, poorly" - Henry Spencer Rust for Linux (*ahem* GNU/Linux) is the second edition of the above quote.

I'll raise you one. https://www.phoronix.com/news/Alex-Gaynor-Rust-Maintainer

Nobody is making a serious push for Rust in base. No-one. Only a couple committers are making (weak and unconvincing) arguments for Rust in userland based rewrites. Even the case for that pointless. FreeBSD has already made this mistake before importing Perl in base and it ended badly. Most of...

Except these aren't important issues. These discussions were nonexistent until the Linux community decided to adopt Rust in their mainline tree. Linux migrants flock to the FreeBSD forums thinking it's going to adopt whatever new shiny-ness the Linux community is experimenting with. FreeBSD...

*accessibility

How exactly? Explicit documentation from Chinese SoC manufactures is a pipe dream; which is a deal breaker. Also, who's to say they're even honest with what their documentation describes? Instead of hardware specs, try selecting a manufacture you can trust, and one with better transparency of...

What the f**k are you talking about? Seriously, all of this nonsensical, mental masturbating needs to stop. FreeBSD isn't going to be rewritten in Rust, ever. Better yet, go read the objections from Poul-Henning Kamp on the mailing list and let his insights educate you. And who gives a flying...

It's a compelling board on paper spec-wise; although i'm skeptical of having chinese chips on my network (allwinner, rockchip, mediatek, cix, etc.) The lack of documentation doesn't help either. I'd shoot for Raspberry, SolidRun, ODroid, etc. stuff instead. (broadcom, qualcomm, amlogic, nxp, etc.)

Not so much the numbers, but recent controversy and the reputation around the platform. It just doesn't make for a good user experience for game users/devs. That's on top of the DRM nonsense that it's plagued with. I'm not sure if you're aware of recent news, but here's a few examples...

The idea here is to provide an autonomous distribution utility that's not entirely anchored to the system and/or the main ports tree. This frees up the ports committers from doing the heavy lifting; as I imaging this sort of thing would evolve and change rapidly. A community led effort with a...

I wasn't clear enough in my OP. I was thinking something along the lines of ravenports; something that's not entirely anchored to the system and can be distributed separately. A community led effort. The Linux developer community ruined Linux; not gamers.

From what I'm reading lately; the current gaming landscape is not looking too good. Windows 11 is a s**t show, next gen consoles aren't looking too promising, Steam is on a steady downhill (i've never really been a fan of steam anyway..), and as much as I love Apple Silicon - it doesn't provide...

It's inherently better than any other option. Because the ports framework is being managed by those providing an operating system. Who knows the intricacies of a platform software runs on better than the ones developing it. There's less risk involved trusting them. "Ports" is also a framework...

There's something to be said about all of these language package managers; doesn't make sense to me. I'd wager there'd be less incentive for these should the Linux community have uniformity on the matter. Long Live C and Ports.

muh security

My point is that the cost of compartmentalizing an existing C/C++ codebase (or parts of it) in capability mode is far less economically taxing than rewriting swaths of drivers/applications in a completely foreign (and arguably unnecessary) language. Some changes even consisting of only several...

With the supposed purpose of Rust people keep regurgitating; Capsicum/CHERI has already addressed these issues years ago. They simply could've taken the code and made use of it; instead of rewriting entire software ecosystems that work. Pure NIH circus behavior. I don't see why Rust exists...

That's objectively false. And it's not a matter of opinion. The question posed was to determine if GPU vendors willing to rewrite their entire stacks in Rust. Which I highly doubt. Should the Linux kernel devs try to shoehorn Rust into an existing C world for GPUs; they'll just move onto the...

I like how people just casually glanced over these comments. This is a potential serious issue that will need to be addressed at some point. How are we going to deal with this? Also, has anyone even assessed whether GPU vendors even want to work with Rust for their hardware? I recall a time...