

Kerneld…I shudder at the thought.
Kerneld…I shudder at the thought.
Also it’s running locally. I think the biggest problem with AI is the data harvesting and this is just not that
Ah, I wasn’t aware they were using existing projects. I hadn’t done a lot of research and was under the impression they were building utilities.
This isn’t a rust issue…this is a canonical using a less than ideal license issue on their rust code.
Just to play devil’s advocate. Until rust gets a production ready GCC backend or LLVM gets more esoteric HW support there are probably some platforms that cannot run rust. That being said… realistically I think by the time rust becomes a large enough part of the kernel for it to matter the issue will have been sorted out as there are already 2 GCC implementations of rust in development…
I’m not sure if that’s true. The mint team has their X-Apps project which is designed to be a cross DE GTK app initiative. Having written GTK software I also haven’t found many pain points myself. Most of the problems with gnome seem to be the gnome team and not the surrounding projects.
That’s true but knowing gnome they’ll abandon evince development. So while you can still use evince it likely won’t be maintained or bug fixed.
Or just use NAT64? That’s the conventional way to do this. Yes a VPN works but it’s a tunnel, NAT64 just maps the entire IPv4 internet into v6 space and clients just use native v6 to get out. It’s easy to setup on a VPS and there are even public instances. https://nat64.net/
Yeah I understand that. And as I noted with the exception of firmware which almost universally requires running very out of date hardware I do the same. I’d like to get there with my phone but I haven’t managed it yet. I have written off firmware being FOSS because as mentioned. You almost always need very old hardware for that outside of embedded devices. And if you go down the firmware rabbit hole you probably have to draw the line somewhere. Platform firmware is the one everyone focuses on but what about GPU or NIC firmware? What about microcode or firmware embedded in the IME or PSP? Yes you can sometimes neuter the IME but that doesn’t apply to all CPUs. It’s just an unwinnable rabbit hole without going to a fully open computing platform.
Router yes, actually router is running coreboot and tiano core with OpenWRT. Does still have proprietary microcode though, and WiFi firmware. All my WAPs also run OpenWRT. I don’t have a modem, I have fiber. The ONT is probably running something proprietary but as far as I’m concerned that’s ISP equipment, not mine. Phone…not quite. I tried…it is running an AOSP rom…but going to a full Linux phone never quite worked out. That being said I was originally referring to my laptop and desktop which make use of no proprietary software or drivers. I do go FOSS to the extreme as much as possible. I just haven’t figured out the phone. I did try going f-droid only for a while but it made basic tasks on my phone substantially more difficult.
It’s funny seeing blogs about this because I live with 100% FOSS, minus firmware
I wonder if they’ve fixed their IPv6 stack, last I tried Haiku I couldn’t get it connected to the internet because it was so broken. I should try again since they seem to have done some networking fixes.
In contrast to most people here who talk about solutions to this problem with tooling often used for batch deployment what I’ll say is just my opinion on the matter. Outside of OEM or fleet deployments the advantages of nix just aren’t that apparent. You feel like your system was a house of cards but I’ve personally never felt that way and I suspect neither have most other users. Every OS to ever exist more or less behaves in a similar way, i.e. it’s mutable, so most users have only ever known this behavior. Installing software and then having to configure it in a software specific way is the norm across all existing computer platforms for all of time and for most situations it’s worked well enough. It isn’t nearly broken or painful enough for most people to care. Honestly if nix was the norm for Linux it might even scare away windows or Mac users looking to move. Linux is already a learning curve and completely changing the software installation and management paradigm(beyond using a package manager which can conveniently be explained like an app store) would not help the situation.
The problem with that thought is the lower level bits are very *nix but all the higher level bits like the GUI and other surrounding APIs are all heavily Objective-C/NextStep based and aren’t really all that unixy. We do have GNUStep as a base to use for that to an extent but I really don’t think the unix parts of Mac, are that helpful to porting complex user facing GUI programs.
People say this but I’m not sure I believe that. Keep in mind Google is the only android OEM that allows you to do a bootloader unlock and root without an exploit, it’s officially supported as a developer configuration.
Tbh I’m not an apple person either. The comment about macOS being on 26 caught my eye and I went and did some research.
Darling is a cool project but I think the reason it hasn’t taken off is because there isn’t a lot of software people both want to use on Linux and software that isn’t already covered by wine. You need an overlap between those 2 and that’s a small market
I do find it funny how android is Linux yet their Linux feature is a VM
Looks like they’re jumping from 15 to 26, in fact they’re doing the same thing for iOS, jumping from 18 to 26 for the next release. Looks like they’re synchronizing all their OS version numbers using the year they’ll be primarily used(i.e. 2026) from what I can find.
The reason for initramfs is because if you build your block or filesystem drivers as modules the kernel can’t boot without loading the modules and can’t load the modules without said modules and therefore causing a chicken and egg problem. Reading a folder without all necessary boot drivers just isn’t possible. That’s why the bootloader is responsible for loading initramfs into system memory, the kernel can read it with 0 drivers required. Getting rid of it can be done but ALL of your boot drivers need to be statically linked into the kernel image so that the kernel doesn’t need any modules to get the rootfs mounted. Ironically EFI can be used to obsolete initramfs in theory since the kernel can read data from the ESP without any drivers being required so putting modules in a folder on the ESP would work for EFI enabled systems