101–110 of 134 posts
Earlier quoted context omitted.
I remember I had some idea for (GNU) grep, but I couldn't even build the damn thing. It's autotools hell.
Your distro should do this for you! Apt-source or pkgbuild will do fine, you don't need Nix or Gentoo to have a ready-to-go script for building your own version of some pre-packaged tool.
Earlier quoted context omitted.
Gentoo doesn't do this crap every 3 weeks, come on. I agree in the sense that I didn't want to have this choice thrust upon me, much like many other choices, but Gentoo has always been good about supporting different choices. My system is still systemd-free, for instance, and I'm rocking MATE. I read the news item, upgraded my profile to the non-merged next version now that I have to make a choice of merged or not, a…
They broke dracut roughly a month ago... A week before that, they upgraded python without bumping all the python packages (kicad comes to mind, edit: ansible deps are frequently broken). In March, profile 23 wants you to remove your CHOST, which sounds like a good way to break systems, thankfully you can ignore them and keep it set. Back in February they broke something tied to wine/mono/dotnet without testing it. Ba…
Python I'll give you, I forgot about 3.12 becoming the default this month, I have an explicit version set in a package.use file that I'll change when I'm ready because I've been burned before. Part of this I blame on Python; overall I've been pretty happy with python on gentoo though, it still lets me have python 2 around for some things. On a Mint laptop I had to install tauthon outside of its package manager.
I read the dracut news item, determined there were no actions required for me (zfs-kmod has the initframfs flag on), and nothing broke. Rereading it again, yeah, it's kind of a sucky change in defaults, but it's clear in what people who might be affected should do.
The profile 23 upgrade is part of the same split/merged usr upgrade, it's clear about the potential scenarios to be worried about (CHOST not being one for most users, a newer gentoo system never set it in the make.conf and my old one's had it commented out for however long.) Note that you could always ignore the profile update for about a year, it's not something that has to be dealt with right away.
For the initramfs thing, it's important to note that it's only required if you have / and /usr on separate filesystems. My old box has them on one filesystem and even after moving it to the un-merged profile 23 I still don't use an initramfs for it. There was originally a news item in 2013, referenced by the item in January of this year, about having them on separate filesystems being unsupported without initramfs. I think 11 years for end-users that could have been impacted by this to deal with it is more than reasonable.
Glancing through the news list, the one on 2024-02-01 about grub updates resulted in a broken boot for me, I think I should have just ignored it. The item last December about CUPS didn't break anything but I can see how it easily could if ignored. I'm still annoyed that they've dropped layman but layman still works as-is. Overall, I do think things have been somewhat less stable in the last 4 years. Even just on news items (that could have impacted my old box, anyway) there's been 49 since 2020, while in the 10 years of April '09 to 2019 there were 81, though 2023 only had 3 items.
There is of course some fighting, and sometimes some turbulent periods of more frequent fighting, but it's still not every few weeks or even months and a lot of the time the fight is yours to accept/decline at your choosing.
Aren't the Rust binaries significantly larger? Wouldn't that be a problem for embedded system and containers? I'm also sceptical to the whole idea. There are tons of more interesting problems to solve than replacing an stable solution with a new one just because you don't like GPL.
> There are tons of more interesting problems to solve than replacing an stable solution with a new one just because you don't like GPL. I think the argument is usually memory safety rather than licensing.
This is after all cp and ls we are talking about. For me personally compatibility would be a much bigger issue
Earlier quoted context omitted.
They might as well rename it C:/Linux/System32 while they're at it. The separate paths were originally done for reasons but since you can't install a mainstream distro with Linux is becoming less and less like UNIX every day.
> The separate paths were originally done for reasons These reasons were not originally philosophical in nature: http://lists.busybox.net/pipermail/busybox/2010-December/074... IMO, keeping /usr/bin and /usr/local/bin separate from /bin doesn’t serve any useful purpose except historical continuity. You can’t really get rid of those paths without breaking things (e.g. since /usr/bin/env is usually hardcoded in shebang…
I use it all the time for custom scripts/programs I don't want the package manager to interfere with.
https://unix.stackexchange.com/questions/4186/what-is-usr-lo...
Earlier quoted context omitted.
The thing is, I don't really want to do a clause-by-clause, point/counterpoint "Chapter And Verse Citations" argument.[1] It's why I focus on the goals - they're clear and well-understood. And, to be clear, I was mostly on the fence about this (my open-source projects tend to be a mix of BSD/MIT and GPL) since around 1995. For my FLOSS experiments/projects, I'd pick a license based on the goal of the project: Popular…
> Compare with Linux, which was adopted extensively by corporations, and forced to give back. I don't think Linux's success has as much to do with license as it has to do with Linus Torvalds. Very few developers can work on one project for 30 years straight making respectable engineering decisions for the entire run. And even fewer delegate well. Both of which Linus seems to have managed. If anything, corporations se…
Well, yes, that's my point: It didn't get the best hardware support by allowing vendors to close of every single driver.[1]
It's collected the best hardware support because those hardware manufacturers who write drivers contributed those drivers back to mainline, hence the reason for Linux's dominance over the competing FLOSS OSes.
Compare to the BSDs, who collected NO hardware support from Apple.
> I can only say that the folks I've worked with don't bat an eye at MIT or BSD or Apache licensed dependencies, but know to ask about the GPL and avoid.
Maybe they ask, and maybe they avoid. My experience with those (very rare) clients who avoid is that they want to take a 99.99% complete solution, add their 0.01% contribution, and lock the resulting product up.
> I think one has to be careful about grand narratives. They often leave out crucial details while painting a version of things as we want them to have happened, as opposed to the messy haphazard way things tend to happen. Hindsight is 20:20, but rose colored glasses can still throw it off.
I agree, but note that I did not come to this opinion quickly nor rashly. It was carefully considered, while taking into account the behaviour of corporations and communities over the history of my involvement as a professional developer (i.e. mid-90s).
IOW, this is not an opinion that I have held for 30 years, it's an opinion that I have formed after watching the industry for 29 years. It'd be quite hard to claim that my opinion is an uninformed or rose-tinted one.
[1] Nvidia shows that, with enough effort, vendors could have closed off the drivers anyway. But there's less friction in simply throwing the driver to the community and letting it get maintained, as opposed to writing shims and binary blobs which the vendor still has to maintain.
Earlier quoted context omitted.
> It's arguable that macOS going Unix had a halo effect that did more for Linux and open source than if they stayed on a completely propietary stack. But that's not relevant to the parent's point, which is "If all open source, such as Linux, was BSD licensed, then only proprietary unixes would be common", which I happen to agree with. Linux would have been further behind because all the proprietary unixes could take…
>and all those thousands of full-time employees working on Linux would have created value for the shareholders of their employers, not value for the Linux users (like they currently do now) But aren't the biggest Linux users companies? They use Linux for their data centers, for the mobile phones they sell.
> But aren't the biggest Linux users companies? They use Linux for their data centers, for the mobile phones they sell.
Yes, and? I am not seeing the point you are trying to make ... those "biggest Linux users companies" are making large contributions to Linux. That is, in fact, the point of the GPL - that they make their contributions to all linux users, not just to their shareholders.
Earlier quoted context omitted.
> The separate paths were originally done for reasons These reasons were not originally philosophical in nature: http://lists.busybox.net/pipermail/busybox/2010-December/074... IMO, keeping /usr/bin and /usr/local/bin separate from /bin doesn’t serve any useful purpose except historical continuity. You can’t really get rid of those paths without breaking things (e.g. since /usr/bin/env is usually hardcoded in shebang…
> > The separate paths were originally done for reasons > > These reasons were not originally philosophical in nature: http://lists.busybox.net/pipermail/busybox/2010-December/074... > > IMO, keeping /usr/bin and /usr/local/bin separate from /bin doesn’t serve any useful purpose except historical continuity. You can’t really get rid of those paths without breaking things (e.g. since /usr/bin/env is usually hardcoded…
Earlier quoted context omitted.
tell that to ie playstation users that basically use bsd and cannot use the computation of their device for nothing that sony does not permit. very freedom
Xbox, Nintendo's various consoles, and Sony's are all DRM'd to hell and back. If BSD wasn't available under terms Sony liked, they'd be using QNX or something more obscure and just as inaccessible to their users. For better or worse, all the big console manufacturers see their ability to lock down their platform as vital to their development and business strategies. Vital to their ability to charge $60 for a few giga…
That's the point: if they don't want to contribute their changes back, they should spend their own money writing their own software.
Right now, they'd take thousands of hours of effort from the community, add a few hundred of their own and then close off the product from the very community that they so willingly took this charity from. Yay BSD license!
If they had to use QNX or similar, they'd pay to do it. If they had to use GPL, they'd pay to close off their changes, which would be great for funding more free software.
> For better or worse, all the big console manufacturers see their ability to lock down their platform as vital to their development and business strategies. Vital to their ability to charge $60 for a few gigabytes of 1s and 0s.
Well that's why I divided the licenses into "pro-user" and "pro-corporate". The BSDs are pro-corporate.
Earlier quoted context omitted.
> Compare with Linux, which was adopted extensively by corporations, and forced to give back. I don't think Linux's success has as much to do with license as it has to do with Linus Torvalds. Very few developers can work on one project for 30 years straight making respectable engineering decisions for the entire run. And even fewer delegate well. Both of which Linus seems to have managed. If anything, corporations se…
> If anything, corporations seem to use Linux despite the GPL, because it has collected the best hardware support of any of the Free / Libre OS options. Well, yes, that's my point: It didn't get the best hardware support by allowing vendors to close of every single driver.[1] It's collected the best hardware support because those hardware manufacturers who write drivers contributed those drivers back to mainline, hen…
Linux's wealth of open source drivers seem to come almost exclusively from it's community, instead. Which, but for a Finnish university student, could have just as easily coalesced around FreeBSD.
Earlier quoted context omitted.
Xbox, Nintendo's various consoles, and Sony's are all DRM'd to hell and back. If BSD wasn't available under terms Sony liked, they'd be using QNX or something more obscure and just as inaccessible to their users. For better or worse, all the big console manufacturers see their ability to lock down their platform as vital to their development and business strategies. Vital to their ability to charge $60 for a few giga…
> If BSD wasn't available under terms Sony liked, they'd be using QNX or something more obscure and just as inaccessible to their users. That's the point: if they don't want to contribute their changes back, they should spend their own money writing their own software. Right now, they'd take thousands of hours of effort from the community, add a few hundred of their own and then close off the product from the very co…
Last I checked there were about a thousand open source OSes. Hundreds under BSD-like licenses. Here's a partial list: https://en.wikipedia.org/wiki/List_of_BSD_operating_systems
It sounds like you're advocating for wiping them all from history and outlawing everything but GPL licensed code, which just isn't possible, nor desirable. Sorry?