@navi Yeah… also gonna have to switch my router to a non-linux, thankfully that should be technically doable but I hate the idea of having to re-do all the config.
@lanodan @navi My router has been on linux 5.10 since forever and I'm not changing it. (I had to pin to 5.10 because for some reason later versions mess up the regulatory country of my wifi card and it's impossible to make it work. I'm not experienced enough at debugging kernel drivers to fully dive in and understand what's going on.)
@ska @navi I could consider doing that but it makes me rather uneasy, like if rewriting the config would be free (and is close enough to feature-parity) I'd possibly even consider 9front.
Which incidentally would probably make it much easier to see why a breakage happened from one version to another.
Which incidentally would probably make it much easier to see why a breakage happened from one version to another.
@navi what hapoen?
@mirabilos https://social.coop/@cwebber/117134650112102361
specially this bit:
> I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust...
specially this bit:
> I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust...
@navi ugh. But that will also end up in LTS kernels 🤮
@mirabilos @navi Plus well… not really sure I'd place much trust in the quality of LTS kernels
@lanodan @mirabilos my idea is just that it'd slow down the rate that shit gets to me
failing to see any alternative except just not updating the kernel at all anymore
failing to see any alternative except just not updating the kernel at all anymore
@navi @mirabilos Yeah, for me LTS will be the interim/temporary solution while moving stuff to other operating systems (that's going to be a pain but at least my own software is portable… because I already had to switch OS).
@lanodan @mirabilos i don't have a viable alternative yet, specially considering openrc asw
closest would be hurd but it's obv. not nearly functional for all i do
closest would be hurd but it's obv. not nearly functional for all i do
@lanodan @mirabilos i might end up writing my own toy kernel into usability before another viable os shows up i think
@navi @mirabilos Yeah, ability to slap OpenRC on say NetBSD would be nice.
And Hurd is one I could *maybe* consider supporting but not using, got too many annoyances with GNU at this point and could entirely see it falling into the slop.
One that would be ironic is illumos getting a good anti-AI policy, as then it would be going back to a system I left, but well it's a rather corpo-friendly system (although has historical beef against Oracle) so I don't have much hopes.
And Hurd is one I could *maybe* consider supporting but not using, got too many annoyances with GNU at this point and could entirely see it falling into the slop.
One that would be ironic is illumos getting a good anti-AI policy, as then it would be going back to a system I left, but well it's a rather corpo-friendly system (although has historical beef against Oracle) so I don't have much hopes.
@lanodan @mirabilos technically you can, we do support freebsd, dragonflybsd, and netbsd, iirc
but i don't think anyone's actually running those atm, so it would be a lot of work to go against the base system... which is the major issue with all those battery-included kernel-os systems
but i don't think anyone's actually running those atm, so it would be a lot of work to go against the base system... which is the major issue with all those battery-included kernel-os systems
@SRAZKVT @navi I think even in theory I wouldn't, I hate having to reboot over and over, so for me to write drivers they would have to either be in userspace or just the basic core you can easily test in a VM.
And then there's dealing with all the half-broken stuff hardware vendors sells where you need to add quirks to your drivers.
And then there's dealing with all the half-broken stuff hardware vendors sells where you need to add quirks to your drivers.
@SRAZKVT @lanodan
i don't even know if the forcing corps to opensource is really an actually useful thing, as we see by android phones being forced to run highly outdated kernel versions because the vendor only ever wrote drivers in this one tree, and didn't want to upstream
the reason corps upstream drivers over letting them rot in a private fork, imo, is because they learnt that by doing that they offload a lot of labor maintaining it
i don't even know if the forcing corps to opensource is really an actually useful thing, as we see by android phones being forced to run highly outdated kernel versions because the vendor only ever wrote drivers in this one tree, and didn't want to upstream
the reason corps upstream drivers over letting them rot in a private fork, imo, is because they learnt that by doing that they offload a lot of labor maintaining it
@xarvos @navi @SRAZKVT I found the ~source on e621 but sadly my computer needs to prove humanity to access it. (And source did have the gnome logo)
screen.png
screen.png
@mirabilos @navi Tribblix could be neat but well… waiting for AI policy in place before I consider it as a possibility.
After all it's github-hosted.
After all it's github-hosted.