Rewriting essential Linux packages in Rust
lwn.net
lwn.net
I wonder, to what extent is the Linux Rust effort "generously subsidized" by corporations?
> He is thinking about ""what we are going to leave to the next generation"". Developers starting out don't want to use COBOL, Fortran, or C, he said. They want to work with fancy stuff like Rust, Swift, Go, or Kotlin.
Oh, think about the children! The wolf in sheep's clothing.
Almost wonder when spyware will be added and restrictive DRM.
Yes, some people do believe liberal licenses are free-er. Corporations certainly like the freedom to not contribute back.
Corporations do not like the GPL on its merits, but it's also worth remembering that the GPL is also not that popular compared to MIT among developers. Developers have not been choosing the GPL for new projects.
See: https://github.blog/open-source/open-source-license-usage-on...
Why?
But let's assume you're correct. What better metric do we have about which license OSS projects are using?
And who cares about those ad-hoc metrics? GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. That alone is a good metric. Blender and OBS are also heavy hitters. It is easy to take these things for granted, and anyone seeking to rewrite GPL software under a liberal licence (whether it is in Rust is irrelevant) would benefit from reading a little history.
I don't disagree, but you're missing the point which is -- the reason why the GPL is not popular is not only because corporations disfavor it, it's because devs disfavor it too. You might ask yourself, "Why?"
> Blender and OBS are also heavy hitters.
And so is Firefox which is MPL2, etc. If your point is -- OSS can't be successful (or successful and copyleft) without the GPL, then you're obviously wrong.
> It is easy to take these things for granted, and anyone seeking to rewrite GPL software under a liberal licence (whether it is in Rust is irrelevant) would benefit from reading a little history.
Is this meant to be maximally patronizing? I am old enough and I was there. It is also fair to see the world differently than you do, and to appreciate different things (as others do and will do.) Some may say, "More than 25 years have passed since the Halloween documents and I am no longer on a jihad."
What I am saying is not that the GPL is not good, only that the GPL isn't the highest good, and more important than the GPL (or the MIT license for that matter) is my freedom to reimplement any software in whatever language and under whatever license I choose.
If you don't get it, then, it's not for you.
The reality -- the project became a way for new Rust devs to get their first Github commit. It became popular. MIT/Apache 2 is the default for new Rust projects.
But I think you need to also consider the downside risk. Because I don't see one. uutils are valuable only because they exactly replicate the GNU version. You'll always have GNU!
I would hazard that extent is strictly less than Linux itself.
It’s been my daily driver for 20 years. That it has an open license is a good thing.
Don't get me wrong, I very much like FreeBSD, but I believe a liberal licence on critical infrastructure like an OS is detrimental. Of course, FreeBSD folks will argue the opposite.
Which will happen with these tools, anyway.
IOW, this is de-facto closed source distribution.
What happens when a company decides to add their own secret sauce and release that version only, or what happens tons of slightly incompatible, closed source variants pop-up, what happens upstream decides to not release future versions' source code.
We have seen it all, and we'll see all of them again.
But what has once been licensed under a permissive license, will remain free forever.
Only the changes will be affected.
No! Sublicensing simply means that there can be a chain of licensing, e.g. author —— Linux distribution —— end user. Not that the middleman can change the license.
(It's actually irrelevant in Germany, because consensus in our legal community seems to be that there is a direct licensing relationship between author and end user, even if they don't know each other and never interact)
If I own the code, I can redistribute that code under a non-GPL license any time I want to (or not release changes at all). The GPL license that I grant to you on my code only affects what YOU can do with it. Consider the common practice of dual-licensed GPL code (a very common strategy for FOSS libraries to extort license fees).
And yes, an MIT license permits sub-licensing. Which is a good thing. (So does GPL). Maybe that word doesn't mean what you think it means. Perhaps you meant re-licensing.
> What happens when a company decides to add their own secret sauce
Then you use the old code without the secret sauce.
> what happens tons of slightly incompatible, closed source variants pop-up,
The same thing that happens when tons of slightly incompatible GPL-licensed variants pop up.
> What happens when upstream decides not to release future version's source code.
GPL does't help with that either.
> We have seen it all
To be perfectly honest, coming to Linux world, I find the various creative strategies to extort license fees for GPL code to be extremely distasteful. Off the top of my head: Juce: three dozen dual-GPL- and GPL-incompatible (not-for commercial use without paid license) libraries and tools with no upfront documentation on which libraries and tools are distributed under which license. You have to download them one by one to find out which license they are distributed under. Ubuntu: withholds (currently) 21 security fixes unless you pay for a license! Reaper, which is GPL-licensed, but demands that you purchase a license when you run it; sources are available but are impossible to build. GPL libraries that require use of non-GPL services in the cloud. Seems much more like a dystopia to me.
All I want is for people to be able to use my code. For whatever. And I am grateful to those who have provide code that I use under equally generous terms. And not at all impressed by somebody who added four hundred lines of code to a huge MIT-licensed library, and licensed them under a GPL license. (It took me less time to rewrite from scratch than I spent trying to get a fix pulled into the GPL project).
There's a term for that: Embrace-Extend-Extinguish
Because "monies".
What would motivate a company to fork and keep private changes to a core GNU utility like chmod?
They don't need to make extensive changes. Pull the latest, patch, compile, burn to FW. TaDa!
IOW, TiVoization 2.0. GPL2 makes it very hard already, but GPL3 makes it impossible.
With permissive licenses, it's very possible.
Maybe ask these folks: https://www.busybox.net/license.html
Even people who nominally agree with the concept of Free Software might not want to be forced to use GPL. The freedom to choose how to license one's work is also an important freedom, after all. GPL can be confusing, so you can't fault anyone from not wanting to use it even if they agree with the spirit of the license.
(For the record, I use GPL on some of my projects. I don't hate it, but I also like to use MIT on some projects, too.)
A ton of commercial services and products somehow use Linux, the poster child of GPL2, while also running tons of their proprietary code. Python is GPL, and it's all over the place in the computing world.
If you just want to take some code someone else wrote, for free, and alter and meld it into your commercial product, well, yes, GPL does not allow that. I don't think it's a huge impediment for legitimate use.
I'd say that all open-source approaches have their own use cases. Certain things are easier to release under BSD / MIT license, some makes sense to release under GPL, some have to resort to AGPL, to the detriment of commercial adoption. A dual restrictive open-source + paid commercial license can be the best in many cases.
Doesn't GPL do that better by mandating that changes must be accessible to the public? Like, if an employee worked out some patch, it would be a violation of the license to not make it accessible to the public.
1. Code copyright has devalued a lot in general, as you can code significantly faster with LLMs and use them to launder GPL'd code into whatever you want.
2. Big tech seems to be getting away with most other forms of abuses these days, GPL wouldn't really stop them from doing anything important.
To the extent that code is being devalued, I would say that these LLMs are a benefit to open source overall, as devaluing of code also reduces the opportunity cost of open sourcing software. They also somewhat level the playing field between single-contributor open source projects and companies with teams of developers, because an individual is almost always limited by the rate at which he/she can write or architecture code, whereas teams have significant non-code overheads (meetings, reviews, bureaucracy).
I see no real evidence this is the case. Can you provide examples?
For instance -- do you see many Linux clones right now? Ask yourself: why might you not? Perhaps it's because it's almost impossible for an AI to rewrite Linux.
GNU and Linux are the engine that powers practically every form of online harm.
The best licenses are BSD and MIT and others of that sort; they have no naive pretense of not helping corporations: everyone can do almost whatever they want, be they a large business or an individual. These licenses also don't encourage unlevel playing fields where the copyright proprietor enjoys dominance in the ecosystem.
For instance, if you are licensee under the BSD2, the only thing you cannot do, in comparison with the copyright holder, is remove copyright notices from the documentation or other materials accompanying the compiled code. This is really a minor thing which only stands in the way of those who want to be outright plagiarists.
With the GPL, it's extremely important to be the copyright holder, so that you can litigate. That's why the Free Software Foundation and GNU Project require copyright assignment for all non-trivial contributions to every project. If your program is a patchwork of files, each copyright someone else, you can't litigate infringement cases easily.
The project owner ALWAYS has dominance in the ecosystem. At least with GPL the owner is protected from someone else scooping up the project to make a closed version. How would you feel if you made an awesome open project only for someone to copy it and close the source, make minor changes, and sell it without even giving you the changes? That crap is not possible with GPL.
For instance, Facebook is closed, in spite of running on a mountain of GPLed stuff.
A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the correct toolchain to reproduce the build without a signature.
I would almost go as far as to say that, in this day and age, someone ripping off free source code in order to create a nice, local-only application, is practically a hero. :)
In a MIT only world, you would have no source of anything. So not only you can’t build a signature-free version of the kernel for educational purposes, you can’t even have it.
This is a corporation paradise.
Open source licenses are characterized by the fact that you don't have to read them, let alone agree with them, merely in order to obtain the software and use it. These licenses "kick in" when you redistribute.
The AGPL can only be litigated as a closed license; i.e. the argument being that if the defendant does not use the program in accordance with the license, their copy is infringing, the same like a cracked version of Photoshop. Whether you are allowed to have a copy or not depends on how you are using it.
A successful AGPL litigation would mainly succeed in proving to the world that the license is nonfree, which would be evident from the arguments that would necessarily have to be used, and the reasoning necessarily expressed in the verdict.
You may dislike that particular family of licenses, but it doesn’t allow you to give false information about it. Maybe it’s not intentional, so you need to refresh your understanding. We’re humans, and our brains are not tapes. Knowledge distorts. I experience the same.
GPL says something simple: “Modified the code? Share it. Oh, BTW, you can’t change the license.” The rest is legalese.
https://www.gnu.org/philosophy/free-sw.html
"The freedom to run the program as you wish, for any purpose (freedom 0)."
If you modified the software, there are restrictions on running it; you cannot run the program as you wish, for any purpose.
It looks like an open and shut case to me. The place where the AGPL comes from doesn't meet the free software definition coming from the same place.
It might meet your personal definition of what is free, but that doesn't fix the above hypocrisy.
It allows certain combined works to be redistributed whose redistribution would be forbidden by the GPL, like proprietary, closed-source programs dynamically linked to a LGPLed library.
Given a GPLed library, you can make such a combined work anyway, and use it; but you may not redistribute it.
The LGPL is more free than the GPL, whereas the AGPL is nonfree.
In 2016, the Cygwin project LGPLed its libraries (DLLs). That was great news; that meant I could bundle a BSD-licensed program without having to put a GPL license on the combined work as a whole and cast doubts about how it could be used (since it is a programming language implementation, needing to be redistributed by downstream developers).
I immediately started working on a fork of the Cygwin DLL that would enable it to serve as a more native-looking run-time for Windows applications. I could build the program on Cygwin (and make a regular Cygwin package), but also ship exactly the same executable as a Windows application by bundling it with the modified cygwin1.dll.
The LGPL is good.
In computer science, there is the question whether P =? NP.
Likewise, we have the question GPL =? LGPL; would the GPL's unreasonable exclusion of dynamic linking hold up in court, or would it fall, reducing GPL to LGPL?
I'm of the opinion that everything library-like should use the LGPL rather than the GPL (if it must use some kind of GPL). The LGPL is what the GPL should be (if it legally isn't already anyway).
The LGPL is better for promoting free software. If some developer has a choice between a proprietary library and a free one, it's counterproductive to slap a GPL on the free one to steer them to the other one.
Obviously, the LGPL is used for platform libraries like Glibc, based on similar reasoning, which is probably also why Cygwin sobered up and switched to LGPL. Because banishing proprietary programs from linking to the libraries that comprise free platforms would be counterproductive. You just lose user base and mind share.
It would behoove you to check the license in order to confirm that whoever gave it to you had the right to do so.
Beyond confirming that you have a legit copy, you don't have to be concerned with the license at all, if you're not redistributing anything.
The vendors of proprietary software and their lawyers dreamed up this idea that a license can lapse based on the user's non-redistributing uses of the work. For instance, if the user reverse-engineers the binary code to understand how it works, then they become unlicensed, the idea then being that they are perpetrating copyright infringement by continuing to have a copy.
The AGPL falls into this category.
The restriction itself does not come from copyright law; copyright law doesn't say things like that allowing network users to interact with a software program is an infringing activity, or that reading the work to understand it is infringing activity.
https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St...
Certainly if you privately modify it is going to be unlikely for someone to find out you did that, but that doesn't make it any less illegal.
You're not breaking the law if you scribble notes in the margin of a textbook; that's just crazy. Even if you pass that on to a friend, for that matter.
Anyway, if a license tries to rely on such draconian doctrines to prevent uses, it's obviously not a free license.
Kind of like how cops in some places in America can evidently arrest someone for DUI if that person merely walks to their car with their car keys, intending to sleep inside until sober.
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017... Behan-Webster-1.pdf
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
This is exactly what AGPL is for. Of course, AGPL is too overbearing for most projects, and only makes sense for SaaS.
>A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the correct toolchain to reproduce the build without a signature.
This is a problem indeed (that most people have forgotten about, due to the shim code that people use to load other operating systems like Linux). It may become a problem in the future so we need to stay vigilant and never support products that lock the bootloader. Unfortunately most phones do that. Phones are a rats nest of proprietary software and hardware and we need more development of open technology in that space.
Nobody cares if you take some open source server software, and run version that you modified with your own cool features, without sharing the source code, and this is something you're entitled to under the FSF's Freedom Zero.
Among the social harms of SaaSS, this is not on the radar; and obsession with it shows either that the FSF are out of touch, or that they think that any action is better than inaction, so that if they take a swing at the problem with the wrong tool (copyright licensing) they look like they gave it a good college try.
The problem of SaaSS is people being locked to a service because that's where their data is siloed. This harm can be perpetrated with completely unmodified software you can download yourself. Running your own copy does nothing to solve the problem; your copy is not where the data is, where the other users are.
left-pad II, coming soon to a Linux distro near you
(An interesting thing to consider: the worst "supply-chain" type attack in recent memory is probably xz, which has a much more traditional maintenance, development, and distribution model than the median Rust package does. I don't think Rust's ecosystem is even remotely immune to the risk of malicious packages, but I imagine the kinds of dependencies that exist in the current coreutils are much more appealing to a high-sophistication attacker because of their relative lack of publicity/transparency.)
Instead, what's left over is a bunch of random junk that saves developers 20-30 minutes of typing and Stack Overflow research. "Here's a small package to automate the creation of a zip file with this format and add a manifest file to it", stuff like that.
And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it. The "code quality" calculus tends to invert very rapidly when you have that kind of ratio.
Does that really matter? The compiler only includes the stuff you actually use anyways.
Goodness, no. The compiler can elide unreferenced symbols, that's not at all the same thing as "stuff you actually use". Just build a static glibc binary someday around "int main(void) { return 0; }" for a reference as to just how much stuff can get sucked in even if you think you aren't using it.
In fact "unexpectedly included feature" was part of the xz-utils attack last year! The backdoor leveraged the fact that the openssh daemon linked against libsystemd for authentication, which links against liblzma (for some reason, I don't know why), despite xz not being required for anything in the ssh protocol. Boom.
And in that case, the two dependencies (systemd and xz-utils) were inarguably in the "complicated" category that apps can't be expected to reimplment. Think how much more complicated this gets if every bit of junk logic becomes a "dependency".
People need to be thinking about this as a problem!
The simple truth is that in "modern" package systems optimized around Reuse-Uber-Alles principles, the ability of J. Random Attacker to "get code into" a downstream app is much, much higher than it was in the days of coarse-grained projects. We need to start dealing with that as a problem to be solved and not excused away.
Could anyone expand on this? I could imagine tools... better static analysis, maybe? being able to help. But I'd really want to see details. Both to see if it really helps, and because if there is tooling to help then I want to know so I can adopt it!
Mostly, I am tired of tools requiring root access, or a block device, to function, even in read only mode.
If you have a file on disk (eg: a VM's disk) mdadm will refuse to show metadata, requiring root to do so.
If that's an artificial limitation, surely it should be easy to fix?
> "I'm going to state the obvious, that Rust is very good for security, for parallelism, for performance".
> The idea to replace GNU coreutils with Rust versions was not about security, though, because the GNU versions were already quite secure. "They did an amazing job. They almost don't have any security issues in their code base." And it's not about the licensing, he said. "I'm not interested in that debate."
> One of the reasons that Ledru liked Rust for this project, he said, is that it's very portable. He is "almost certain" that code he writes in Rust is going to work well on everything from Android to Windows.
> Ledru cited laziness as another reason for using Rust. "So if there is a crate or library doing that work, I'm going to use it. I'm not going to implement it [myself]." There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take". There is more and more tooling around to help mitigate the risk, he said.
People who keep promote this fraud are fraudsters too
I wonder if Linux is re-written i rust will it too remove GPL as a factor ?
Again due to the license choice I tend to believe this can be seen as a way to move Linux to a Microsoft Type Windows System.
I would've preferred projects like these to be GPL licensed too, but as the author writes in the comments (https://lwn.net/Articles/1009647/): what's the real-world impact of this specific project being MIT?
Commercial UNIX systems are pretty much dead, and I doubt the ones that still want to ship customised versions of these tools will respect the GPLv3 licence. I believe copyleft is essential for things like kernels, but for userspace tooling where plenty of alternatives exist, I don't think it's as important.
There are plenty of permissively licensed projects that have been around for decades. Copyleft licenses don't provide much additional protection. They impose a requirement on people that modify the software to provide those modifications under the same license. That's about it. Imposing that requirement is important to some people but not really that essential for the long term health of open source projects.
If you want to create a fork of OpenBSD kernel and call it DrEvilBSD and release it under the 100% proprietary DrEvil License 1.0, you can do that of course. The license allows you to do that. You are required to preserve the license and copyright notice, of course. For copyleft proponents, this is a wrong that needs to be corrected and they'll use big words like theft and stealing. For permissive software people this is a feature, not a bug. Do whatever you want with the software. These are both valid points of view to hold.
In practice, long lived OSS projects get more protection from the fact that they have a large amount of copyright holders (everybody that ever contributed to the code) which makes any form of re-licensing impractical. The Linux kernel will never re-license. Nor will the OpenBSD kernel. It would take the permission of many thousands/tens of thousands of developers; or their surviving relatives (quite a few are no longer alive). Not going to happen.
Anyway, the MIT license is a perfectly good license. It's widely used, well understood, easy to understand, etc. It has been around for decades. Countless of OSS projects use it. Perfectly fine choice if your goal is to facilitate others to use your software in whatever way works for them. Whether that's bundling into some proprietary firmware or distributing it in some OSS linux distribution. Giving users of the software that freedom is a fine choice.
And kind of important for operating systems. Unless your goal is to keep it out of the hands of companies that sell products to customers based on these operating systems. Which might be why there aren't many AGPL or GPLv3 licensed operating systems.
For a project like this coreutils rewrite, the MIT license makes sense. It maximizes usability across diverse systems Linux, BSD, proprietary UNIX, Windows, etc. without imposing restrictions. That’s likely an intentional choice to ensure broad adoption. There's no good reason to restrict that. Probably the developers want to see this go wherever it can go.
No reason it must? AFAIK all Rust for Linux code is GPL2. For example see: https://github.com/torvalds/linux/blob/master/rust/kernel/al...
If some was or were to be licensed as MIT code, there is also plenty of dual licensed code in the Linux kernel.
The amount of complexity, even with pretty high-level Rust std, is still super high. So rewriting them in Rust is no small feat.
For the file-system management ones: I appreciate the value of everyone knowing these tools, but they do have some terrible defaults, and I wish there was an alternative between using a GUI/TUI file manager and carefully not stabbing myself in the foot. That's why I started building human-utils (alas it's very much unfinished).
install -d -m 755 somedir
That's not obvious.
> He is "almost certain" that code he writes in Rust is going to work well on everything from Android to Windows.
I'd think the problem with security in code is cocky developers who believe that some part of the environment is magical and can save them from themselves.
> Ledru cited laziness as another reason for using Rust. "So if there is a crate or library doing that work, I'm going to use it. I'm not going to implement it [myself]."
Precisely. Where does this "certainty" come from then?
> He is thinking about "what we are going to leave to the next generation".
At this rate, a complete and total mess, of two slightly incompatible libraries neither of which have any significant features which differentiate it from the other, save for in the imagination of the developers themselves.
> He is thinking about "what we are going to leave to the next generation".
A history lesson in software licensing, maybe? Certainly not one he bothered to learn himself, lol.
There was a book called "Dr. Dobb's C-tools", which had the commented source code of a C compiler, assembler, linker and std library, and it greatly benefitted me to go beyond K&R's book towards understand the idioms of C programing.
What relevance does that have tho?
> Coreutils are not part of the linux project in the first place, and uutils does not aim to be merged into GNU coreutils.
I think he having fun with you bro.
AFAIK, no. Linux chooses to support platforms from which we haven't seen new releases in decades, like DEC Alpha. Although in recent years, Linux has dumped support for many older platforms including IA-64.
But my guess is GNU coreutils also doesn't support all Linux targets. I mean this in two ways -- 1) AFAIK coreutils does not expressly support each and every Linux platform, and 2) whether something builds is not the measure of whether there is platform support.
That is -- Linux may support some weirdo MIPs variant and 68K (which has Tier 3 Rust support), but what's your guess that your GNU coreutils support, even busybox support, for these platforms is top tier? You may be guaranteed that your weirdo arch has a C compiler, but what's the likelihood all the GNU tests passed on this arch? That each and every utility even runs on this arch?
https://github.com/coreutils/coreutils/blob/master/README-in...
contains notes on compiling for IRIX, HPUX, AIX, and OSF/1. So no, I would bet that it very much does run anywhere Linux runs, and a lot of places it doesn't.
Again, how well tested do you imagine the OSF/1 target is? Do you imagine each merge pops off a CI test for that platform? My guess is -- it's been a long time since anyone connected with the GNU coreutils project built for that platform.
See the reply from estebank to me, below:
> Platform support goes beyond "does a compiler happen to produce a binary".
pkgin install coreutils
And I'm saying -- yes, if "Does it compile?" portability is a value that you care about, the GNU version is probably your version. But what if the Q is (as it was): "Is Rust (llvm?) supported on all platforms Linux targets?"
Then -- I think you need to dig more carefully into what you mean by "support" of non-standard platforms, and why it might be important to you. Would say -- we can move our entire stack to an emulated PDP-11 because Linux and GNU coreutils seem to compile? My guess is no. For lots of reasons, but one reason is "It compiles"/"Seems to work" is not a good measure of support.
https://github.com/eza-community/eza (modern ls replacement)
https://github.com/BurntSushi/erd (modern tree replacement)
https://github.com/sharkdp/bat (modern cat(1) replacement)
my .zshrc for every system now uses these as drop in replacements
This looks really cool, though. I might try using this as an `ls` replacement, too, just because of how it shows the recursive directory size like `du`. I've always wished windows explorer did that (do any linux gui file managers?)
So changing to the new thing invalidates all that existing value.
That’s not argument to never do anything new, but it’s an argument why for your UNIX-like OS should ship the standard boring thing instead of the shiny new thing in the base install.
Example: https://github.com/mpv-player/mpv/commit/1e70e82baa91
Anyway, I don't see any of that as a reason for not having ripgrep installed everywhere by default and as an argument for not using it.
I wish C didn’t have strtok, but it’s too late.
For example, on Archlinux, `base` (the minimal set of packages to install) includes `systemd`. `systemd` isn't POSIX.
Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default.
I'm just tired of people hiding behind POSIX compliance. One wonders how many of your invocations of grep are not POSIX compliant. (A strict POSIX grep is laughably minimal. To the point that not even minimal implementations of coreutils, like busybox, don't stick to the strict set prescribed by POSIX.) I'm not even aware of any grep implementation that doesn't implement something beyond what POSIX requires.
Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.
grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run.
Why should ripgrep be on base and what kind of overhead are we adding to install?
> how many of your invocations of grep are not POSIX compliant.
It would be a different argument if ripgrep was compliant with extensions, like gnugrep, but being a completely separate tool with a similar name, it doesn’t fill the same role.
I like it and install it when I need it.
You did not mention a word about scripting.
> But that's not what you originally said.
It is. The reason ripgrep should not be in base is because it’s not posix compliant.
> You did not mention a word about scripting.
WTF. Literally right there in my first comment:
> Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.
I hate to say, "please re-read my original comment," but I think it might actually apply in your case.
In regards to ripgrep
> that is clearly not a sufficient criteria to exclude something from `base`. You need something else
The burden is on you to demonstrate why it should be included absent of a standard, not me to show why it should be excluded. Base maintenance work is a scarce resource.
Your only argument so far has been that posix compliance doesn’t matter.
This interaction is actually souring me on the project.
> Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default.
...
> This interaction is actually souring me.
You and me both. Maybe you could try actually reading my comments. I feel like I'm talking to an AI that has been trained to be maximally annoying through gaslighting.
So unless you can demonstrate that you're a real person (like my profile does), you're now on my ignore list.
We tried it in a commercially project because some hyperiders in the team wanted to do so. The truth is, a thing that would be developed in C++ in 1.5 month wasn't done in 6 months caused by things like 'All our developers are newbies in the language, no one really can do meaningful reviews, tons of dependencies(often one dependency in different versions), no good way to integrate cargo in our existing build flow and the lack of fun during programming.'
When you don't start a complete new project with bloody newbies, Rust is not a good choice.
It just really really sucks that people are thereby allocating a ton of effort into reimplementing these tools--putting good effort behind a project that even has a good reason to exist (memory safety), even if (as I'll poke at later in this comment) that apparently is explicitly not the reason they are working on this (which shocked me)--with the goal of being "bug for bug compatible" with the upstream copies from the GNU Foundation while carefully ignoring the #1 most important integration (as this affects how the software fits into the whole) test: "is this software 'free' as in freedom?".
Of course, they claim that this is some kind of unproductive waste of time "debate", as if the license is the least important part of the software and doesn't matter, and I think some people want to take this narrative. Regardless, whether or not we agree with this--a position that feels a lot like "politics don't matter and are a waste of time, so stop voicing your concerns"--that's not what's going on here: if you look a bit deeper, this project actually cares deeply about its license, and is going out of its way to choose the license it is using, ignore complaints, and avoid ending up GPL.
https://www.youtube.com/watch?v=5qTyyMyU2hQ
In an interview with FOSS Weekly, Sylvestre Ledru (the main developer, who curiously has a background working on Debian and Firefox, before ending up getting seduced by the clang/LLVM ecosystem), firmly states "it is not about security", focusing only on an interest in learning himself how the full stack of tools function and preparing for a future where new developers don't actually know enough C to contribute; this might seem to fit into the earlier narrative that the license doesn't really matter, which he later restates himself "I don't care that much, as long as it is OSI compliant".
This topic comes up multiple times later in the interview, and Steven sticks to his framing that he doesn't care about the license, that this debate is a waste of time, and that he tries to avoid discussing it as it is "more philosophical than technical". Of course, this isn't preventing him from discussing it ;P... this is clearly a big issue that people have with this project, it is one that comes up in most discussions of the project, and--if it really didn't matter, and it really weren't a big deal--you would thereby expect that he'd just change it, to avoid having to discuss it again...
...only, in this interview--in no small part from the interviewer slowly leaking part of their pre-interview discussion to cause the topic to keep coming back up--we learn just how much this developer does seem to care about the license, as, to keep it all as MIT, he's having to avoid looking at the original implementation, in an attempt to avoid accidentally letting his code get infected by GPL, to support some users of the project who actively choose to use this reimplementation to avoid GPL compliance (the example we are given--by the interviewer outing it, not him--is "car manufacturers").
As someone who works in security but finds it demoralizing how often security is used as an excuse for what ends up being an effort to lock users out of a platform due to what is merely some supposedly-accidental property of the effort--including one time I was in a hearing with the US Copyright Office, sitting next to a rep from General Motors who was there to argue that we shouldn't be allowed to jailbreak a "portable all-purpose mobile computing device" because that might include a car (lol)--I found this back/forth in the comments forum on the website for this interview worth reading:
https://hackaday.com/2024/07/17/floss-weekly-episode-792-rus...
<AgainAgain> the goal is to “rewrite it in x” is to move everything to permissive liscenses. then lock future changes away. just like every thing else “security” is used as pretext.
<Jonathan Bennett> We chatted a bit about exactly that. They make no claim that this effort is for security, and freely admitted that some of their users are doing so precisely because it’s MIT and not GPL. So… Yes, but actually no.
<Thovte> That sounds like yes, but actually, yes. No?