Just to add a non-problematic experience report to the mix: I've been using 6.10 for months on two AMD machines with different hardware (one with a 7840U and one with a 5700XT) without any issues whatsoever.
On Linux, "net.ipv4.ping_group_range" is typically used to allow unprivileged users to do ICMP echo requests. Setting the setuid bit or granting a capability are both very old ways of doing this.
ping_group_range (two integers; default: see below; since Linux 2.6.39)
Range of the group IDs (minimum and maximum group IDs,
inclusive) that are allowed to create ICMP Echo sockets.
>>The default is "1 0", which means no group is allowed to
create ICMP Echo sockets.<<
This would seem to indicate this isn't being used -- at least on Ubuntu? What am I missing?
This requires a more comprehensive redesign of the build process. Most Linux distributions also run the tests of the project they're building as part of the build process.
Profile guided optimization is, unfortunately, wildly powerful. And it has a hard requirement that a casual link exists from test data (or production data!) to the build process.
Really? Is the new implementation of the sync server finally stable? For years we've been stuck between the old Python 2 implementation and the new incomplete Rust implementation.
I remember there being talks of a complete rewrite of Newpipe. Did anything come of that? I'm a happy user, so I don't really have an opinion on whether it should happen or not.
Schabi here:
The team wants to start the rewrite in 2024 after 0.26.0 got released. The reson for the rewrite: Codebase got hard to maintin so we need to refactor. Also android changed the UI style and the UI frameworks a lot. We want to stay up to date with that.
Yes. Contributors are abaoloutly welcome, and Jetpack and Kotlin is exactly what we are looking for. However we need to prepare and sort out things before we can start. Stay put and follow our blog to find out when we begin: https://newpipe.net/blog
I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time.
In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
> I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time.
Eh, they had a pain-point, built a tool to alleviate it, and shared it. I suppose the less tone-deaf alternatives are "keep feeling the pain (by not building it)" or "let everybody else keep feeling the pain (by not sharing it)." I can't complain too much with that.
> In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime.
I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
In our opinion, flakes are the future of Nix and we're doing the hard work of using them extensively everywhere we can. While we do that, we fix bugs and papercuts along the way. I don't think flakes _can_ meaningfully stabilize without people pushing them to their boundaries and then addressing the problems that come up.
In other words, yes: we are doubling down because we don't see a future of Nix where flakes or something like them aren't central.
you guys seem very <ahem>, determined, to do things your way. I'm kinda new to the whole nix community and it just feels like you guys are a bull in a china shop. Maybe that's what it needs. Strong, opinionated, decisive, leadership. Dunno. All I can say is I hope, I _really_ hope, that you guys don't become, basically, Nix's "google". Defacto owning it to all of our costly detriment over time. It's why I'm tempted, despite their polish, to stay away from your products for the time being.
My feeling is we’ve been careful and considered about what we build and why, though I understand some folks don’t like what we’ve made. That’s their right, just like it is our right to build things we think are important and add value to the Nix community. We’re not in charge of the Nix project: Nix has its own governance and processes that we also engage with.
Most of our tools are open source, totally free, and don’t depend on us as a company continuing to exist. In many cases I hope the Nix project wants to adopt and take over some of our work — like the installer.
Our goal is to make Nix as good as possible, and do it together. In the meantime, it’s okay to not use our tools :)
I share your frustration about the Nvidia situation. However, if you want to run a certain operating system and have a good experience, you need to buy hardware that's well-supported on that operating system. It's as simple as that. This is a little like buying an M1 Mac and complaining that Linux doesn't run well on it.
