Rewriting the GNU Coreutils in Rust
| LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
As movement toward memory-safe languages, and Rust in particular, continues to grow, it is worth looking at one of the larger scale efforts to port C code that has existed for decades to Rust. The uutils project aims to rewrite all of the individual utilities included in the GNU Coreutils project in Rust. Originally created by Jordi Boggiano in 2013, the project aims to provide drop-in replacements for the Coreutils programs, adding the data-race protection and memory safety that Rust provides.
Many readers will be familiar with the Coreutils project. It includes the basic file, process, and text manipulation programs that are expected to exist on every GNU-based operating system. The Coreutils project was created to consolidate three sets of tools that were previously offered separately, Fileutils, Textutils, and Shellutils, along with some other miscellaneous utilities. Many of the programs that are included in the project, such as rm, du, ls, and cat, have been around for multiple decades and, though other implementations exist, these utilities are not available for platforms like Windows in their original form.
Collectively, the Coreutils programs are seen as low-hanging fruit where a working Rust-based version can be produced in a reasonable amount of time. The requirements for each utility are clear and many of the them are conceptually straightforward, although that's not to suggest that the work is easy. While a lot of progress has been made to get uutils into a usable state, it will take some time for it to reach the stability and maturity of Coreutils.
The use of Rust for this project will help to speed this process along since a huge swathe of possible memory errors and other undefined behavior is eliminated entirely. It also opens the door to the use of efficient, race-free multithreading which has the potential to speed up some of the programs under certain conditions. The uutils rewrite also provides an opportunity to not just reimplement Coreutils but to also enhance the functionality of some of the utilities to yield a better user experience, while maintaining compatibility with the GNU versions. For example, feature requests that have long been rejected in the Coreutils project, like adding a progress bar option for utilities like mv and cp, are currently being entertained in this Rust rewrite.
What has been done so far
On the project's GitHub page, a table can be found with the utilities divided into three columns: "Done", "Semi-Done", and "To-Do". At the time of this writing, only 23 of the 106 utilities being worked on are not yet in the "Done" column, with 16 of them marked as "Semi-Done" and seven under the "To-Do" column. The utilities under "To-Do" have either not been worked on at all or are currently undergoing their initial implementation (like with pr and chcon). Those in the "Semi-Done" column are missing options that have not yet been implemented, or their behavior is slightly different from their GNU counterparts in certain situations. For example:
- tail does not support the -F or --retry flags.
- more fails when input is piped to it as in "cat foo.txt | more".
- install is missing both the -b and --backup flags.
- Several utilities do not support non-UTF-8 arguments, although this is largely being mitigated by migrating from getopts to clap for command-line argument parsing.
It is important to keep in mind that just because a program is marked as "Done" doesn't mean that all of the tests are passing or that the utility is as performant or memory-efficient as the GNU version. For example, there are open issues to improve the performance of factor (roughly 5x slower) and sort (between 1.5x to 6x slower). In some other cases, the uutils versions are faster than their GNU equivalents. An example is the cp utility in which a measurable performance improvement has been reported, primarily due to the use of the sendfile() and copy_file_range() system calls, which are not being used in the GNU version despite several proposals to do so.
At the moment, only 142 of 624 tests in the Coreutils test suite are passing compared to around 546 tests passing with the GNU version. However, it should be noted that many of the errors are due to differences in the output of the commands.
A separate table also exists to show all of the platforms and architectures that the uutils project currently supports. The major operating systems (Linux, macOS, and Windows) are well accounted for across various architectures although quite a few utilities are currently not building on Windows. FreeBSD, NetBSD, and Android also compile most binaries except for a handful of utilities including chroot, uptime, uname, stat, who, and others. The rows for Redox OS, Solaris, WebAssembly, and Fuchsia are currently all blank, which reflects the lower priority assigned to those platforms at the moment.
The uutils project, currently at version 0.0.6, has already been packaged in the repositories for various Linux distributions and packaging systems. Notably, Sylvestre Ledru, a director at Mozilla and prolific contributor to the Debian and Ubuntu projects, has led the way in getting the project packaged for Debian as an alternative to the GNU Coreutils. Its current state is deemed good enough to get a system with GNOME up and running, install a thousand of the most popular Debian packages, and to build Firefox, the Linux kernel, and LLVM/Clang. Additionally, uutils is present in the repositories for Arch Linux (Community), Homebrew for macOS, and the Exherbo Linux distribution.
Licensing
An important aspect of the uutils project to be aware of is its licensing. All of the utilities in the project are licensed under the permissive MIT License, instead of the GPLv3 license of GNU Coreutils. This potentially makes it more attractive for use in places where software licensed with GPLv3 is not adopted due to its restrictions on Tivoization among other things. The decision to use the MIT License is not without its critics; some who commented in a GitHub issue about the choice would rather see a copyleft license applied to a project of this sort.
The main criticism echoes arguments over FOSS licensing in the past: a non-copyleft license is harmful to the freedoms of end users since it allows a person or organization to incorporate any part of the project into a device or in the distribution of other software without providing the source code so it is impossible to study, change, or improve it. There is also a concern that the license choice is being made to maximize Rust usage without regard for other effects; replacing GPL-licensed tools with alternatives under a more-permissive license is seen by some as a step backward.
Contributing to uutils
The best way to follow the development of the uutils project is through its GitHub repository and official Discord server. Details on how to get started contributing to the project can be found in a document that is included in the repository.
A lot of work remains to be done to get uutils into a production-ready state. The project has been positioned as a good way get into Rust development and there is a list of issues for newcomers as a place to begin. The current focus of the project appears to be full compatibility with the GNU Coreutils and improving the test coverage before tackling other problems. Things like removing unnecessary dependencies, improving performance, and decreasing memory use are better suited to being addressed after the compatibility issues have been ironed out.
| Index entries for this article | |
|---|---|
| GuestArticles | Isaiah, Ayooluwa |
(Log in to post comments)
Rewriting the GNU Coreutils in Rust
Posted Jun 8, 2021 22:58 UTC (Tue) by Sesse (subscriber, #53779) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 8, 2021 23:41 UTC (Tue) by tux3 (subscriber, #101245) [Link]
Now that languages like Rust are making thread-safety practically the default, it is getting a bit silly to iterate over items with only one core while the other 7 or 15 watch.
Legacy tools are being very innefficient with both, currently. Even git is criminally underthreaded and often blocking on serial I/O.
Though that is slowly being improved, the software has not kept up with the silicon, and that is because the abstractions we had made it too hard.
Hail the new languages and the bloated libraries like Tokio. They compile to megabytes of statically linked copies, but boy is it nice to have a modern and fast runtime underneath instead of all the barely-reentrant-half-the-time and definitely blocking POSIX legacy!
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 3:25 UTC (Wed) by notriddle (subscriber, #130608) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 6:19 UTC (Wed) by LtWorf (subscriber, #124958) [Link]
You can use several threads but they are blocking each other out to access the same hardware resource, and remember that switching thread is not cheap at all, so in the end you are likely to end up with a multicore version of ls that is also way slower and has much much more complex code that is also more error prone.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 7:01 UTC (Wed) by mokki (subscriber, #33200) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 7:17 UTC (Wed) by warrax (subscriber, #103205) [Link]
This isn't really true in this day and age. It used to be quite expensive, but that's no longer the case (in the common case). Of course it's still more expensive than not doing it (assuming that you cannot do anything productive with that parallelism), but that's neither here nor there.
Anyway, the point of io_uring is avoiding traversing the userland<->kernel boundary unless absolutely required because *THAT* is expensive.
More generally, I'd also challenge your assertion that accessing the hardware in a multithreaded fashion doesn't have gains. Sure, it might not do much for spinning rust, but SSDs can certainly handle multiple non-interfering I/O operations.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 7:21 UTC (Wed) by warrax (subscriber, #103205) [Link]
Note also that parallelizing I/O can actually also help with the latency incurred between userland and the actual device latency. The more commands you can queue ahead of time, the more commands the device can go through in a rapid fire fashion -- even in the case where no actual parallel fetching/writing can happen on the device itself.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 16:24 UTC (Wed) by Wol (subscriber, #4433) [Link]
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:55 UTC (Thu) by farnz (subscriber, #17727) [Link]
Not just the kernel - all modern storage devices also reorder requests to minimise the overall time.
Every level in the stack below the application benefits from having deep queues; the only reason to not issue all the I/O you can at once is that you might not be able to handle the responses as fast as they come in. Otherwise, you might as well queue up as much I/O as you can keep track of; the kernel will do its re-ordering, and the device can reorder anything from 31 commands upwards to maximise throughput.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 8:06 UTC (Wed) by Sesse (subscriber, #53779) [Link]
That is certainly a part of the point, but not the entire point. Probably more important than that is to be able to do issue many I/Os in parallel, ie., it finally gives Linux usable, performant async I/O. This is required if you want to drive modern SSDs fast, but also for many small files on a HDD. When I implemented io_uring support in plocate, that was the big killer; being able to issue 256 stat()s at once and watch the kernel reorder them into one big head sweep, as opposed to jittering back and forth over the disk. (You'll see a similar thing when ls-ing or cp-ing many (small) files.) Syscall overhead didn't play into it at all; in fact, nearly all the gains were realized in the prototype implementation where I called io_uring_enter() once for every stat, ie., no reduction in syscall overhead at all.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 22:59 UTC (Thu) by warrax (subscriber, #103205) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 9:44 UTC (Wed) by eru (subscriber, #2753) [Link]
it is getting a bit silly to iterate over items with only one core while the other 7 or 15 watch.
Only if that program is the only process running! Especially with utilities like this, you may not assume you have the whole CPU to yourself. Sometimes it is true, usually not.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 10:18 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 10:31 UTC (Wed) by matthias (subscriber, #94967) [Link]
And of course, high nice values are for background tasks where the user is not waiting for the output. If I run a core utility from the shell, I want to have the result now and I do not care whether a background task has to wait.
Rewriting the GNU Coreutils in Rust
Posted Jun 20, 2021 14:35 UTC (Sun) by roblucid (guest, #48964) [Link]
If there's multiple io commands in flight, waiting a little to process one of them won't hurt.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 18:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 20:17 UTC (Wed) by Wol (subscriber, #4433) [Link]
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 6:59 UTC (Thu) by jem (subscriber, #24231) [Link]
Also, what default Application Programming Interface is this changing?
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 23:02 UTC (Thu) by warrax (subscriber, #103205) [Link]
I'm obviously just nitpicking, but Rust "only" guarantees freedom from *data* races.
Rust lacunae
Posted Jun 11, 2021 1:44 UTC (Fri) by ncm (guest, #165) [Link]
Similarly, Rust does not trap integer overflows (except in signed types in non-release builds, i.e. unit tests), so does not prevent such bugs. Complacency around bugs the Rust compiler permits is encouraged by neglect as part of the Holy Mission to drive Rust into universal enterprise use. ("Rewrite It in Rust" has lately been repudiated as official policy of Rust advocacy, for reasons, but uutils seems to have missed the memo.)
When bugs do trap, such as array indexing errors, the resulting panic cannot be presumed to clean up properly before exiting. This sort of thing is hard to get right, and only comes with maturity. Coreutils probably still have bugs of their own, but they are manifestly bugs we have found we can live with.
All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite, at much less risk of introducing new bugs, and without abandoning those targets LLVM poorly serves. No Holy Mission drives such activity, so we see it happen with resounding success in Gcc and Gdb, but not yet in less active projects, or in more hidebound ones like PosgreSQL, SQLite, Git, Systemd, the BSDs, or Linux.
There is more than one way to get memory safety without compromising performance. Rust offers one way. Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another. As such libraries are needed anyway, the cost is small. In effect, one places the trust in such libraries that Rust users place in their compiler and in audited "unsafe" blocks in their corresponding libraries.
It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason; but they can anyway be redeemed starting with a 1-line change to their build script.
Rust lacunae
Posted Jun 11, 2021 2:14 UTC (Fri) by rodgerd (guest, #58896) [Link]
Rust lacunae
Posted Jun 11, 2021 2:51 UTC (Fri) by ncm (guest, #165) [Link]
Unfortunate choices are unfortunate, including choices that generate unnecessary extra work; but as none of them make extra work for me, I happily coexist. You?
Rust lacunae
Posted Jun 11, 2021 2:26 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Or they found the Rust benefits worth it regardless of advocacy. Your scorn is unwarranted.
Rust lacunae
Posted Jun 11, 2021 3:05 UTC (Fri) by ncm (guest, #165) [Link]
Rust is manifestly a better language than C for any use where it works at all. But it is not the only, and often enough not the wisest choice. Everyone chooses for their own reasons, and wisdom may come too late, but late is better than never.
Rust lacunae
Posted Jun 11, 2021 4:47 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
I wasn't the only who read it that way. Couple of examples:
"Complacency around bugs the Rust compiler permits is encouraged by neglect as part of the Holy Mission to drive Rust into universal enterprise use"
Sounds like a conspiracy with no evidence cited.
"No Holy Mission drives such activity"
Sounds scornful to me. If you didn't intend to be read that way, you should rephrase these.
Rust lacunae
Posted Jun 11, 2021 10:13 UTC (Fri) by khim (subscriber, #9252) [Link]
> But it is not the only, and often enough not the wisest choice.Sadly today they are precisely one language suitable for writing safe low-level code. Well… one and half, essentially: Rust and “GCC's C with set of flags Linus insisted on being added to GCC”. C++ is flat-out unsuitable.
And as you readily admit Rust is the best of these.
Rust lacunae
Posted Jun 12, 2021 13:50 UTC (Sat) by BirAdam (guest, #132170) [Link]
Did everyone suddenly forget about Ada and it’s sinking Spark? These two have been in use in mission critical work for decades.
Ada for the win
Posted Jun 21, 2021 22:04 UTC (Mon) by rc_rocks (guest, #152877) [Link]
Rust lacunae
Posted Jun 12, 2021 22:52 UTC (Sat) by ncm (guest, #165) [Link]
Rust lacunae
Posted Jun 12, 2021 23:22 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Rust lacunae
Posted Jun 11, 2021 4:19 UTC (Fri) by marcH (subscriber, #57642) [Link]
Great plan on paper. The reasons why this does not work in practice are well known and have been detailed in about every single article about Rust.
- While much safer than C, even the "most modern" C++ is not as safe as Rust [1]
- Different C++ programmers seem to have different opinions about "modernity" (and everything C++?) "There is more than one way to do it", famous last words.
- Similarly, there is no simple tool or set of rules to detect unsafe/old C and tell when such a safety effort is "done". With Rust you know that safety is done when it compiles and all the unsafe blocks have been very carefully review. In C/C++ there is instead a patchwork of external checkers [2] with varying and overlapping coverage, rules and false positives.
- For the above reasons, safety regressions are easy even after you think you're done.
Last but not least:
- It's not fun, so no one is doing it.
The problem with safety and security is that they depend on "the weakest link". So incremental approaches that don't tell you when the job is done are flawed by design.
[1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
[2] ... that everyone should absolutely use despite their limitations
> Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another. As such libraries are needed anyway, the cost is small.
Modularity and code re-use in C are indeed a joke, unlike safety this is a very good reason to switch to C++; no "weakest link" problem with modularity and immediate benefits. I bet there are other very good reasons to switch to C++; but not safety. Sorry.
Rust lacunae
Posted Jun 11, 2021 9:52 UTC (Fri) by james (subscriber, #1325) [Link]
When bugs do trap, such as array indexing errors, the resulting panic cannot be presumed to clean up properly before exiting.OK, I'm curious: what sort of clean up would be reasonable for a coreutils utility beyond just dying?
Rust lacunae
Posted Jun 11, 2021 14:24 UTC (Fri) by zlynx (guest, #2285) [Link]
Of course, if the cleanup is truly important than you cannot implement cleanup using exceptions, panics, or error return codes. There is just no way to be sure that the process isn't killed, so for thorough, reliable cleanup it needs to fork() and have the parent wait for successful completion. If the child fails the parent can clean up. That works for OOM Kill, segmentation fault, illegal instruction and other failures.
Rust lacunae
Posted Jun 13, 2021 13:52 UTC (Sun) by jezuch (subscriber, #52988) [Link]
I myself would be completely satisfied if mv did not clean up completely after it was killed by an unmaskable signal. After all, it seemed like this was the intent of the killer!
Rust lacunae
Posted Jun 13, 2021 14:14 UTC (Sun) by james (subscriber, #1325) [Link]
If anything goes wrong it is nice if mv deletes any temporary copy it had made in the process of moving a file across filesystems.I've no idea if any version of mv actually does this, but I understand it's possible to open an un-named, unlinked temporary file and write to it, then when you've finished create a link to the file (meaning it has a name and isn't temporary any more), fsync as necessary, and then delete the original file. If the program crashes before the file is linked, then Linux will automatically delete it.
Once the file is linked, you've got a full copy where you want it. Deleting that copy is not obviously the right thing. Deleting the original copy is, but the program crashed when it tried to do that.
Rust lacunae
Posted Jun 11, 2021 10:08 UTC (Fri) by khim (subscriber, #9252) [Link]
> All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite, at much less risk of introducing new bugs, and without abandoning those targets LLVM poorly serves.Unfortunately the time have come to accept that C and especially C++ are not languages you can use to write bug-free programs. Even if your code is bug-free today it wouldn't be bug-free tomorrow. Modern compilers insist that code compiler with --std=c89 or --std=c++98 should obey rules introduced in 2023 (sic! they use not yet developed and not yet approved rules from not yet existing standard to compile code written decades ago — look here for details). With C you can piggyback on the Linux need to actually produce reliable code and the fact that Linus keeps one (just one) C compiler in a state where it can actually be used for that. With C++ that's just plain out impossible.
Rust is built on the same unstable foundation, but, fortunately, this quicksand is only for the unsafe part of the language, safe mode (the default mode) is supposed to not have any undefined behaviors which compiler couldn't detect. This make it actually suitable for reliable software.
> No Holy Mission drives such activity, so we see it happen with resounding success in Gcc and Gdb, but not yet in less active projects, or in more hidebound ones like PosgreSQL, SQLite, Git, Systemd, the BSDs, or Linux.Linux already contemplates Rust, too.
> Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another.Modern C++ is unsitable. You can't write safe software using it. Simply because you never know how and when code style would be retroactive changed. Google writes such code in C++, but it's special: they “own” both sides of the equation and thus can actually change code-which-was-safe-but-is-now-unsafe when they are changing the compiler. Most C++ developers don't have such luxury. And since Linux doesn't use C++ they couldn't rely on Linus, too.
> Rust users place in their compiler and in audited "unsafe" blocks in their corresponding libraries.Rust tries to make sure that code written according to the rules of the book is not only safe today but would stay safe tomorrow. That's big practical difference. The fact that this promise doesn't cover unsafe code is quite unfortunate, but typical rust project doesn't include a lot of unsafe code thus there are at least some hope. No such hope with C++, sadly.
> It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reasonC++ maybe more convenient and sometimes even offer faster code (with the use of rvalue-references and other such things) but they also make it more bug-prone. Time have come to start thinking about abandoning it. And Rust is the only viable alternative.
And I say that as someone who likes C++ and hates Rust syntax. Bug I guess I would have to accept it.
Rust lacunae
Posted Jun 12, 2021 9:29 UTC (Sat) by ncm (guest, #165) [Link]
Thus, every tiny increment in safety of C++ code being written, from any cause, whether via compiler improvements, language evolution, standard library improvements, third-party library improvements, new libraries released, or developer education, *each* have overwhelmingly more real-world impact than the entire output of the entire Rust ecosystem, from language spec through to "hello world" beginner. All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.
Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better, and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.
You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself. In another decade, you will likely have discovered some other enthusiasm of likely similar real-world impact.
I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.
Rust lacunae
Posted Jun 12, 2021 10:33 UTC (Sat) by khim (subscriber, #9252) [Link]
> Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust.Sure. And they would be buggy and there would be lots of CVEs and data loss. That's fine: if safety is not your goal, data loss is accetable and only performance matters to you then C++ is fine choice.
“Unsuitable for any purpose” is definition from some “better world” position. Where people are more honest and care about security and not just about security certificates. We don't live in that world, sadly.
Thus, every tiny increment in safety of C++ code being written, from any cause, whether via compiler improvements, language evolution, standard library improvements, third-party library improvements, new libraries released, or developer education, *each* have overwhelmingly more real-world impact than the entire output of the entire Rust ecosystem, from language spec through to "hello world" beginner.Indeed. Only you misrepresent direction. Today programs written in C++ code are worse from security perspective than it was yesterday and tomorrow they would be even less safe. Just look on number of CVEs in Chrome, e.g. Yes, 2020 had less vulnerabilities than 2019 — but that's mostly because COVID-19 made development slower. And 2021 is shaping to beat record of 2019, so…
Also note how DoS vulnerabilities have disappeared. That's good, right? C++ is doing great, right? Nope: it just means that there are so many other, more serious, vulnerabilities that DoS ones are no longer even worth reporting.
> All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.Indeed. Pain accumulates slowly but steadily. And even Google and Microsoft are thinking about abandoning ship (and before you misinterpret me: no, they are not ready to embrace Rust, Google have just only added it to Android… even the decision whether to drop C++ or not is not yet finalized… but discussions are underway).
> Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better,That I agree with.
> and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.That I couldn't agree with, sorry. While C++ can be improved it's actually less secure than C code. Simply because language is just so complex and insecure. And most mitigations techniques (sanitizers, static analysis, etc) improve safety of both C and C++ thus C stays ahead.
Heck, if you compare C and C++ standard you will find out that C have (and always had) four nicely-prepared lists in it's annex: unspecified behavior list, undefined behavior list, implementation-defined behavior list and locale specific behavior list.
With C++… after 36 years of developers we only have proposal… and it doesn't even includes such lists, it just says that it would be nice to, you know, have an actual list of rules for the programmer to follow somewhere.
That's not security, that's a joke.
> You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself.Only time will tell. Rust was added to Android only just one year ago. And only couple of small subsystems were implemented in Rust. Microsoft joined the Rust Foundation and actually supports development in Rust, but is not yet ready to drop C++.
But the fact that these companies with billions of investment in C++ tools, lots of in-house expertise and their own compilers (clang's C++ is basically Google work at this point, Apple never was all that interested in C++ and other contributors do even less) are even contemplating switch says you something about C++ safely, I'm afraid.
Yes, it's true: we don't yet know if Rust would be able to replace C++ or not. But the fact remains: it's the only relatively popular language that can do that. C#, Go or Java are all very nice languages but they couldn't be used as low-level system languages. Rust can be used for that.
And it's more secure than C, unlike C++, which is less secure, so why would you advocate switching to C++?
Rust eliminates certain classes of bugs entirely (not all of them, of course, you can write buggy code in any language) while C++ warmly embraces latter choice in the infamous “Hoare dilemma” (There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies).
Thus if you need security you go with Rust. If you only need security certificates then C++ is better for now. But why would anyone want a security certificate for coreutils replacement?
Rust lacunae
Posted Jun 12, 2021 23:51 UTC (Sat) by ncm (guest, #165) [Link]
It doesn't matter what you agree or don't agree with; nobody asks you.
Instead, they continue to choose to use C++ because it works, is fully mature, yet is on a cycle of continuous improvement. It reliably brings in billions of dollars, quarter after quarter, for myriad serious users. They invest in continuous improvement by sending literally hundreds of representatives to ISO Standard meetings three times a year, more at each meeting than at any prior, to help prepare the next Standard. Each Standard published on a reliable 3-year schedule has had as much work than the sum total ever devoted to Rust.
I have spent strictly more time in the past decade filing bug reports against compilers than I have in chasing down memory errors in my C++ code. So, whatever Rust has to offer in avoiding memory errors is of no practical value to me or people who code like me: we don't make memory errors. Overwhelmingly more of us are coding C++ than have ever even heard of Rust. More pick up coding C++ anew each month than the total who have ever so much as compiled hello.rs.
You can pretend all you like that C++ code is less secure than C, or that it is getting less secure, or that Google et al. are preparing to drop it, but it is your fantasy. Your need to invent falsehoods to promote your case only shows you have no case, and that people have been correct to ignore you.
Rust lacunae
Posted Jun 13, 2021 7:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
We already know whether Rust will displace C++. It will. Any plans you have that depend on not displacing C++ have already failed, right out of the gate.
It doesn't matter what you agree or don't agree with; nobody asks you.
Rust lacunae
Posted Jun 13, 2021 8:43 UTC (Sun) by farnz (subscriber, #17727) [Link]
In at least one large engineering organisation I'm aware of, Rust is displacing C++ in internal tooling, and there are people looking at using it in customer-facing code because the internal tooling that's written in Rust has the performance characteristics of tooling written in C++, but with many fewer bugs, and all of those bugs being either non-security or in the FFI layer to existing C++ libraries that are being reused.
I would not bet on Rust displacing C++ in the next 5 years; I also wouldn't bet on C++ retaining dominance in the next 20, because the Rust ownership and borrowing model is the killer feature over C++17 (the current internal standard for C++ in that organisation). And the problem with the ownership model is that it needs full ecosystem buy-in to be useful - everything has to respect it in order for it to give benefits - which means that a C++23 with a Rust ownership model will take decades to upgrade existing C++ code to the point where it's useful.
With Rust, because there's a clear FFI boundary (e.g. using the CXX crate), you get tooling assistance in enforcing the model at that boundary, and with experience, it becomes clear when a bug is in the FFI layer or C++ code, and when it's in Rust.
Rust lacunae
Posted Jun 13, 2021 18:30 UTC (Sun) by Wol (subscriber, #4433) [Link]
> I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.
You only observe and report reality? Like the future? Well they do say prediction is always difficult, especially if it's about the future.
It won't take much, and you could suddenly find all those thousands of pages you describe are legacy. There's probably *still* more Cobol than C++ in regular production use, but nobody hears about it because it's all in maintenance mode. What will you say if that description becomes true of C++ in the next decade?
Cheers,
Wol
Rust lacunae
Posted Jun 28, 2021 13:38 UTC (Mon) by immibis (subscriber, #105511) [Link]
This was true of every now-dead language, at some point.
Rust lacunae
Posted Jun 11, 2021 11:19 UTC (Fri) by daniels (subscriber, #16193) [Link]
Wayland literally predates Rust, so sadly that wasn't an option.
The core library is quite tiny though, and its primary role in life is to act as a mediator between UNIX sockets (raw bytes) and an FFI bridge (C base types) to whichever language clients or servers are written in. Maybe C++ has matured a bit since Wayland's inception, but at the time C++ interfacing with itself might as well have been an FFI given how difficult it was. Either way, the code in between the sockets and the FFI is so thin that you'd probably increase the code complexity and error factor by converting it to C++.
I get frustrated at C when working on Weston because it's so unhelpful. But C++ doesn't help me with that, because remembering what the name of my type isn't my problem, nor is more ergonomic list/array iteration (because everyone augments the laughably-inadequate C standard library with their own anyway). Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.
Rust lacunae
Posted Jun 11, 2021 12:02 UTC (Fri) by khim (subscriber, #9252) [Link]
> Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.Indeed. Rust is so nice (except for syntax which I still hate) that I fear for the Mozilla a lot nowadays. Because most (if not all) really popular languages which were developed in companies either belong to companies are no longer are relevant in the software field (like AT&T with C) or extinct (like Sun with C++ and Java, like Netscape with JavaScript, etc).
Rust was separated from Mozilla, though, let's hope it would save Mozilla from that fate.
Rust lacunae
Posted Jun 14, 2021 16:45 UTC (Mon) by anton (subscriber, #25547) [Link]
Not sure why you mention Sun for C++. Bjarne Stroustroup worked at AT&T Bell Labs from 1979 to 2002.
Rust lacunae
Posted Jun 14, 2021 16:49 UTC (Mon) by khim (subscriber, #9252) [Link]
Memory wart, sorry. So both C and C++ were by AT&T and Java was by Sun.
Thanks for the correction, but it still doesn't bode well for Mozilla.
Except Rust is now separated from it thus there are hope.
Rust lacunae
Posted Jun 12, 2021 8:00 UTC (Sat) by ncm (guest, #165) [Link]
When you show you need to rely on falsehoods to make your case, you reveal you have no case.
Rust lacunae
Posted Jun 13, 2021 14:10 UTC (Sun) by jezuch (subscriber, #52988) [Link]
Um, excuse me? C++'s type system is based on misunderstanding of object orientedness (which in C++, and just about any other "OO" language, is just an extension of structural programming and a far cry from Simula's design, which we're only now rediscovering). Rust's type system is based on algebraic types, in the ML tradition (not as pure as in Haskell, but still). Traits are first-class citizen in Rust, while in C++ they're a design pattern at best, and everything is centered on classes. Completely different paradigms.
BTW, I know that my interpretation of history of programming language design is un-orthodox, no need to point it out ;)
Rust lacunae
Posted Jun 13, 2021 18:38 UTC (Sun) by zlynx (guest, #2285) [Link]
But no, it was not a "misunderstanding." I think C++ design is probably one of the best compromises possible between efficient machine code and OO. And of course we must remember it stayed compatible with C.
"Pure" object oriented languages are just disgustingly inefficient. Java succeeds because of the immense work put into its JVM and JIT compiling. Python and Ruby show off what happens when everything is an object.
Anyone can look and see that C++ is used where speed matters.
Also it is very funny that you use Simula of all languages as an example of object oriented. Smalltalk was the pure object oriented language. Simula was a mashup of Algol and OO juist as C++ is a mix of C and OO. Simula doesn't contain even half of what became Object Oriented in Smalltalk.
Rust lacunae
Posted Jun 14, 2021 12:28 UTC (Mon) by jezuch (subscriber, #52988) [Link]
The claim was that Rust bases its type system on C++ and is far behind it. My point was that Rust, while syntactically in the C family, explicitly breaks away from its type system. And is more powerful thanks to a conscious design and not being a heap of ad-hoc.
Rust lacunae
Posted Jun 13, 2021 19:28 UTC (Sun) by ncm (guest, #165) [Link]
Language purity is a farce. C++ was never promoted as an "object-oriented language". It has always been a language that provides support for an object-oriented style as one among many, and supports promiscuous mixing of styles for anyone not stupidly wedged into just one.
Most of its type operations are inspired by ML, as in Haskell. Algebraic types are just types. There is no paradigm. Paradigms are a farce too.
Rust lacunae
Posted Jun 13, 2021 14:13 UTC (Sun) by jezuch (subscriber, #52988) [Link]
Oh, and I believe that Rust's type system is way more powerful than C++'s, which is a complete mess. So the catch-up goes the other way.
Rust lacunae
Posted Jun 13, 2021 15:02 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
Rust lacunae
Posted Jun 13, 2021 21:54 UTC (Sun) by khim (subscriber, #9252) [Link]
Type system of C++ is built like everything else in that language: 100 stories tall skyscraper with the foundation of quicksand. Yes, I know why, but the fact that size > -1 is always false if size is unsigned with no warnings or errors caused far more real-world problems than anything related to issues with references. The fact that uint32_t, uint64_t and size_t are not distinct is seriously problematic, too.
Rust have a pretty decent type system. Not perfect but pretty good. Type system of C++ is collection of footguns. Yes, you can make your program misbehave in so many interesting ways… but does anyone finds it fun to explore all these ways when they are debugging something?
Back then when C++ at least tried to be compatible with old versions it sounded justified at least, but now, when new versions of C abd C++ are designed to add new and exciting bugs into programs which were perfectly safe yesterday that “compatibility!” excuse just doesn't sound convincing. At least Linus works as good enough brake for that activity in “Kernel C”. But nobody does the same with C++.
At least safe Rust doesn't try to pretend that someone may write code in 1990 which obeys rules which are not yet finalized yet in 2021. Unsafe Rust, sadly, inherits that issue because of it's LLVM foundation, but in typical program there are limited amount of unsafe rust code.
Rust lacunae
Posted Jun 24, 2021 15:24 UTC (Thu) by nye (guest, #51576) [Link]
>size > -1 is always false if size is unsigned with no warnings
$ clang++ -Weverything /tmp/test.cpp
/tmp/test.cpp:4:14: warning: result of comparison 'unsigned int' > 4294967295 is always false [-Wtautological-type-limit-compare]
if (size > -1) {
~~~~ ^ ~~
/tmp/test.cpp:4:16: warning: implicit conversion changes signedness: 'int' to 'unsigned int' [-Wsign-conversion]
if (size > -1) {
~ ^~
Even if you don't like using -Weverything because you don't want to opt in to newly added warnings, I do think that -Wsign-conversion is something that should always be turned on for code under active development. If you have substantial legacy codebase then you will doubtless need to add a lot of explicit casts to silence false positives, but, well, that's what you asked for.
Rust lacunae
Posted Jun 13, 2021 19:35 UTC (Sun) by ncm (guest, #165) [Link]
Or, you can look at the actual proposals to strengthen Rust's type system to be able to express more of what can now be expressed in C++ and Haskell but not in Rust.
Rust lacunae
Posted Jun 14, 2021 12:22 UTC (Mon) by jezuch (subscriber, #52988) [Link]
[1] https://sdleffler.github.io/RustTypeSystemTuringComplete/
Rust lacunae
Posted Jun 11, 2021 12:14 UTC (Fri) by roc (subscriber, #30627) [Link]
> the resulting panic cannot be presumed to clean up properly before exiting. This sort of thing is hard to get right, and only comes with maturity.
GNU coreutils can't even be bothered handling SIGPIPE when stdout is a closed pipe. "Graceful exit" is not their forté.
OTOH, in Rust RAII is *the* way to clean up resources, and panics run those drop handlers, so Rust panics generally clean up after themselves quite well.
Rust lacunae
Posted Jun 11, 2021 13:48 UTC (Fri) by Sesse (subscriber, #53779) [Link]
Rust lacunae
Posted Jun 11, 2021 14:06 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
https://security.googleblog.com/2021/05/integrating-rust-...
Rust lacunae
Posted Jun 11, 2021 14:15 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
https://security.googleblog.com/2021/04/rust-in-linux-ker...
Rust lacunae
Posted Jun 11, 2021 14:18 UTC (Fri) by Sesse (subscriber, #53779) [Link]
Rust lacunae
Posted Jun 11, 2021 14:27 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Which media? Also, integrating Rust into Linux kernel and Android isn't exactly what I would consider small-scale.
Rust lacunae
Posted Jun 11, 2021 14:33 UTC (Fri) by Sesse (subscriber, #53779) [Link]
Google's scale is staggering. Around 100B of lines of C++ by now (I don't have updated numbers). In comparison, the Linux kernel with its ~30M LOC is a drop in the ocean; assigning one or two engineers onto looking at the prospect of maybe writing device drivers in Rust one day, even more so.
Rust lacunae
Posted Jun 11, 2021 15:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
- Rust isn't used anywhere at Google. <shown uses>
- Oh, it's being looked at for Linux drivers, that's meaningless at the scale of Google.
As if on day 1 there has to be millions of lines of code for it to be meaningful. There is massive momentum for these kinds of things and it takes time. Google having their pet language probably has way more buy-in from management and whatnot, so that specific comparison isn't really useful in my mind.
Rust lacunae
Posted Jun 11, 2021 18:08 UTC (Fri) by Sesse (subscriber, #53779) [Link]
Rust lacunae
Posted Jun 11, 2021 17:08 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Too vague. Which article(s) are you referring to?
> Google's scale is staggering.
Yes and the fact that they have shown significant interest and movement towards integrating Rust into projects with massive user bases like Linux and Android is yet another evidence of growing large scale adoption by multiple companies across many different industries. This is the only realistic way you are ever going to see adoption of any new(er) language. It won't be massive code dumps of millions of lines of code one fine day.
Rust lacunae
Posted Jun 12, 2021 9:39 UTC (Sat) by ncm (guest, #165) [Link]
Rust lacunae
Posted Jun 12, 2021 10:19 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Calling all the existing adoption and momentum from several major players as zero evidence or fooling around is pretty dismissive. This isn't remotely comparable to Forth or Haskell. We are talking about code in production from Mozilla, npm, discord, dropbox, cloudfare and so on. I can't think of any other language comparable to C or C++ that has gotten this level of traction in this timeframe. Feel free to continue overlooking this and we will find out even more conclusively in a few years.
Rust lacunae
Posted Jun 13, 2021 18:47 UTC (Sun) by ncm (guest, #165) [Link]
Rust lacunae
Posted Jun 13, 2021 19:11 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
I just don't agree with your opinion. There is no confusion around that.
Rust lacunae
Posted Jun 13, 2021 20:07 UTC (Sun) by ncm (guest, #165) [Link]
Your relationship with truth is duly noted. I will not need any further information.
Rust lacunae
Posted Jun 13, 2021 20:14 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
That's not accurate. My comments weren't limited to Google.
Rust lacunae
Posted Jun 13, 2021 20:36 UTC (Sun) by nix (subscriber, #2304) [Link]
Rust lacunae
Posted Jun 12, 2021 23:24 UTC (Sat) by khim (subscriber, #9252) [Link]
Rust lacunae
Posted Jun 15, 2021 19:43 UTC (Tue) by Wol (subscriber, #4433) [Link]
And of course, Forth also has the reputation of producing executables that are smaller than well-written assembler :-)
Writing a KLOC and more program in Forth would probably be a bit of a nightmare.
Cheers,
Wol
Rust lacunae
Posted Jun 13, 2021 7:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I don't work in Amazon, but I've heard from my friends there that Rust in practice turns out to be a more productive language than C++ and much easier to pick up. One major advantage is that you don't have to learn the particular subset of C++ and its libraries that is in use in your new workplace.
Rust lacunae
Posted Jun 11, 2021 19:51 UTC (Fri) by notriddle (subscriber, #130608) [Link]
except in signed types in non-release buildsIn non-release builds, unsigned integer overflow also traps. There is no difference between signed and unsigned integer overflow in Rust.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 13:15 UTC (Thu) by moltonel (guest, #45207) [Link]
Assigning priorities should be done at the system and kernel level, not at the process level. It's nice to have `-jN` style options with a "-j$(nproc)" default, but they remain a bit of a kludge. Instead we have nice, cgroups, etc. It'd be great if something like Apple's grand central dispatch became ubiquitous on Linux.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 15:07 UTC (Thu) by Sesse (subscriber, #53779) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 20, 2021 14:31 UTC (Sun) by roblucid (guest, #48964) [Link]
If you're using a good asynchronous implementation even less so, as you're giving the freedom to the disk to reorder fetches.
Copying and moving data on disks wasn't CPU bound even with relatively weak uni-processors.
In the article it mentioned performance gains due to using zero copy calls rather than the threading.
Rewriting the GNU Coreutils in Rust
Posted Jun 20, 2021 22:51 UTC (Sun) by zlynx (guest, #2285) [Link]
The new game consoles are using tricks to transfer data directly from NVMe to the GPU. Because the CPU is slow, busy and doesn't need to be involved.
Anyway, to repeat myself, storage and network IO is rapidly catching up in speed as CPU speed stalls out in favor of multiple cores.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 0:02 UTC (Wed) by wahern (subscriber, #37304) [Link]
You can also use sendfile to copy files from disk to socket and vice-versa. With kernel-based TLS (aka kTLS) you can do this on TLS-encrypted TCP sockets.
I suppose somebody will at some point add a sendfile operation to io_uring, though that wouldn't necessarily buy you performance, just user space convenience.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 2:30 UTC (Wed) by Paf (subscriber, #91811) [Link]
Send file is very often *not* faster than read and write because many file system implementations use a 64KB pipe, generating 64 KB I/Os. It’s often much better to do larger I/O from user space, even on SSDs.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 3:46 UTC (Wed) by NYKevin (subscriber, #129325) [Link]
Would it be legal/advisable for sendfile to actually be implemented by doing that (with write, not fwrite), in cases where the file to read is mmap'able? Or does that break some sort of "don't alloc buffers in userspace without userspace explicitly asking for it" rule? I can't imagine that any reasonable implementation of malloc would care, but I'm sure there's some ridiculous use case where you go trawling through /proc/self/maps and do something clever with it.
Alternative #2: What if you could mmap file A, somehow tell the kernel that "this mmap now belongs to file B," and then unmap it? I'm guessing that you can't do the second step, though. AFAIK, there's currently no such thing as filesystem-to-memory-to-filesystem COW, so you'd have to fault everything into memory, at which point this is clearly a terrible idea (for large files, anyway).
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:51 UTC (Wed) by Paf (subscriber, #91811) [Link]
You can do things like mmap in the kernel; in general you can kind of do ... whatever. But a lot of it is ugly or weird (using syscall type functionality within the kernel is prone to weird reentrancy issues), or requires allocating big blobs of memory in the kernel.
Things like COW for page cache memory would be ... weird. It gets in to areas I’m not familiar with, but I would think faulting, etc, might be a problem.
(Also, I misremembered above - send file is *always* via a pipe.)
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:58 UTC (Wed) by Sesse (subscriber, #53779) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 8:39 UTC (Wed) by LtWorf (subscriber, #124958) [Link]
Refreshing
Posted Jun 9, 2021 6:21 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
– grep - https://github.com/BurntSushi/ripgrep
– find - https://github.com/sharkdp/fd
– cat - https://github.com/sharkdp/bat
– ls - https://the.exa.website/
The syntax is a bit different than originals and not all features are present, but the change was worth it. Those new, “modern” utils are pleasure to use and are fast. Incidentally or not, they all are written in Rust.
I'm looking forward to coreutils rewrite. Using all the Linux kernel features and all the CPU cores would be nice. It's 2021, we do not need code to support AIX from the '80s of the last century.
Refreshing
Posted Jun 9, 2021 13:18 UTC (Wed) by taladar (subscriber, #68407) [Link]
Refreshing
Posted Jun 9, 2021 13:35 UTC (Wed) by nix (subscriber, #2304) [Link]
(a lot of the other tools above are really good. In particular rg is amazingly fast for even ridiculously complex regexes.)
Refreshing
Posted Jun 9, 2021 20:51 UTC (Wed) by khim (subscriber, #9252) [Link]
You have made me really curious.Specifically that:
> nearly-unreadable ultra-low-contrast dark blue on black
And of course what I have find is something which is really well-readable and nice looking. While yellow used for README.md and Makefile is a bit hard for me to read (but not hard enough to declare them not usable).
Finding good colors is hard. People are different and significant percentage of males have issues there. Thus I'm not sure “oh, default colors don't look nice to me — means the whole project is unsuitable for everyone” is a good attitude.
> but the whole point of exa is to make better decisions by defaultBut what is “better decisions by default”? We may aim to create better peception for the majority of people (the ones with no defects) or we may try to make sure our color scheme is poor-but-acceptable for most people (including the ones with vision defects). My guess would be that ls and axe aim for the 1st (which makes sense for highly-configurable tool) while web sites are usually designed for the 2nd.
This creates strange dilemma: colors which are best for actual program are not best for the website dedicated to that program… so what should be done about that? Should the website use some non-standard palette to make it acceptable for the majority or use the actual default colors program uses? I don't think these are easy decisions and I don't think exa is big enough project to afford market research…
Refreshing
Posted Jun 10, 2021 1:07 UTC (Thu) by kschendel (subscriber, #20465) [Link]
So I guess I have no objection to the (rather peculiar IMO) colors shown on the exa website as long as I can turn it all off and just see black and white.
Refreshing
Posted Jun 10, 2021 2:00 UTC (Thu) by NYKevin (subscriber, #129325) [Link]
Refreshing
Posted Jun 24, 2021 12:53 UTC (Thu) by immibis (subscriber, #105511) [Link]
Surely "dumb" means "I can't do anything other than printing characters - not even clearing the screen"?
Refreshing
Posted Jun 10, 2021 11:26 UTC (Thu) by jengelh (subscriber, #33263) [Link]
Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit[1].
No, it's not that hard:
As an application developer, firstly, make colors the user's business and emit as few as possible by default. My recommendation is to do with just {default_fg, fg_hue1_shade1, fg_hue1_shade} and {default_bg}. Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.
[1] https://paste.opensuse.org/view/raw/21792273 (mcedit with 7+ colors, 11+ shades, not all pictured / background never counted)
[2] https://paste.opensuse.org/view/raw/73371546 (2c3s)
Refreshing
Posted Jun 10, 2021 12:07 UTC (Thu) by khim (subscriber, #9252) [Link]
> Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit.Surely you jest? I'm using mcedit more often than not because I like how it colors things. There are many things I don't like about mcedit (e.g. I really hate that a single long line can slow down it immensely), but colors? Mcedit is one if the best examples IMO. At least for me.
> As an application developer, firstly, make colors the user's business and emit as few as possible by default.Nope. That's 2nd step. You have omitted extremely important 1st step: accept that you are not developing program which you would like to use in it's default configuration and create program for “someone else”. Maybe even conduct some kind of “UI research” (like GNOME guys did before they developed GNOME 3).
Unfortunately, considering the end result of GNOME3 redesign, I couldn't say that's the road to success.
And if you skip that 1st step and create something which you, personally, would like to use… is that really such an awful sin? Git was created that way, after all. And it's wildly more successful than GNOME3.
> Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.Indeed. It makes it possible to do something which I never need or want. But why should developer value that ability higher than the ability to do what they need or want?
You somehow skipped that part entirely.
P.S. And I'm all too ready to admit that my tastes may be “wrong”. Perhaps lasting impression of Norton Commander and Turbo Pascal have left it's mark, who knows. But when I hear “color support is not hard, you just need to avoid this <link to something I like> and do this <link to something I hate>” then only reaction it may evict in me is “who died and make your god?” and/or “why should I create the program which you would like and not I would like?” People are different. Deal with this.
Refreshing
Posted Jun 9, 2021 21:07 UTC (Wed) by pizza (subscriber, #46) [Link]
"readability" depends on your terminal colors -- if you have a light/white background (which is the "modern" default) then dark blue is a very legible color. But yellow (which is great on a dark background) is equally illegible on a light background.
So while desktop environments make it pretty easy to switch between light/dark themes, there isn't really a sane mechanism to pass that theme-derived information to terminal-based applications.
Refreshing
Posted Jun 9, 2021 23:15 UTC (Wed) by Sesse (subscriber, #53779) [Link]
Refreshing
Posted Jun 10, 2021 14:38 UTC (Thu) by nix (subscriber, #2304) [Link]
Of course it does, which is why any program with colour worth its salt provides at least two defaults, for light and dark background. But... exa has a dark background *on its website*, and then uses colours on it which are only suitable for a light-backgrounded terminal (and I'm not sure they're even suitable for that). It's like it's trying to make sure it's looking as bad as possible to potential new users. Weird.
Refreshing
Posted Jun 10, 2021 17:51 UTC (Thu) by zdzichu (subscriber, #17118) [Link]
I'm not sure why it's not good for you? Maybe your display isn't accurately color-corrected? Have you loaded proper ICC profile? Maybe you have a display with a strange gamma curve, like MacBook? Who knows?
Anyway, people tend to either select suitable color-set for their terminal emulators, or tweak the colors which they don't see clearly to be in better shade.
Exa is not ideal, not because of colors. For example, exa omits directory size, which is very useful information on CephFS. But I like it more than GNU “ls”, still.
Refreshing
Posted Jun 10, 2021 20:54 UTC (Thu) by nix (subscriber, #2304) [Link]
When the colours are a stated benefit of the tool, and the choice on the website seem that bad, I think it's justified. (Also: colours really do matter, at least to people who have working vision that's good enough that they can benefit at all. Obviously the colourblind, people with tunnel vision or people who are actually blind are rightly going to think this is not a discussion that could affect them!)
> I'm not sure why it's not good for you? Maybe your display isn't accurately color-corrected? Have you loaded proper ICC profile?
Are you joking? To a first approximation nobody who isn't involved in graphic design will have done that. It takes special hardware and I don't have it (yes, it's not very expensive hardware, but it's also more or less useless unless you're a graphic designer).
Dark blue on black is almost guaranteed to be hard to read right back to the days of the oldest colour-capable DEC terminals (GNU ls's default colours make this mistake too, in case you think I'm letting it off too lightly, and portage, oh boy). Yellow on white likewise. Obviously exa lets you change these, but these seem to me to be examples of just plain bad defaults which have *always* been bad even though everyone always picks them for their new tool: but nonetheless I have no idea why anyone would think this is a good choice of colours to put on a website, unless perhaps they *are* using amazing colour-corrected Retina displays rather than the years-old random Samsungish LCDs which most people not using Macs are more likely to have. My vision is quite poor and my glasses don't make blue or red particularly good colour choices in any case, because of strong dispersion even with extremely expensive lenses -- but dispersion isn't the problem here. Can *anyone* read dark blue on black easily? (Maybe you have the brightness jacked way up? Surely not, everything else would be painfully bright.)
... hm, maybe it's just that newer LCDs have a wider colour gamut than older LCDs (which should lead to dark blue being further separated from black), and both my LCD screens *are* quite old random Samsungs. It's hard for me to say: I've hardly seen any newer LCDs... colour correction seems unlikely to fix *that*. I'd need a new set of displays, at a cost of several hundred quid, so that people with terrible colour choices can inflict a bit less pain on me :P
Hm maybe I *should* replace my monitors. Last time I looked monitors wider than 19" with VESA mount brackets were for whatever reason almost unobtainable... but that drought appears to have passed, and it was in any case years ago. Of course none of them are going to say what their colour gamut is, and shopping for monitors is a headache-inducing nightmare in any case. Argh.
Refreshing
Posted Jun 10, 2021 20:56 UTC (Thu) by mpr22 (subscriber, #60784) [Link]
It's tolerable on PC native romfont displays, but a big part of that is that standard PC romfonts have two-pixel vertical strokes.
Refreshing
Posted Jun 11, 2021 10:53 UTC (Fri) by flussence (subscriber, #85566) [Link]
I can save you the expense: on my Dell Ultrasharp (older model, but still well beyond sRGB) the colour choices we're complaining about here are still barely legible. And yes, it does have the correct magic bytes loaded in colord!
Maybe it's readable at 100% brightness but nobody wants to stare into a lightbulb, and this thing's old enough that getting there takes a few minutes now...
Refreshing
Posted Jun 13, 2021 20:39 UTC (Sun) by nix (subscriber, #2304) [Link]
Let no-one say LWN comment threads are not valuable! :)
Refreshing
Posted Jun 11, 2021 12:19 UTC (Fri) by khim (subscriber, #9252) [Link]
> Obviously the colourblind, people with tunnel vision or people who are actually blind are rightly going to think this is not a discussion that could affect them!That's funny because I was the only guy in our class who never had any vision problems. Never needed glasses neither for reading nor for driving, passed all these medical color-tests with flying colors, etc.
> Dark blue on black is almost guaranteed to be hard to read right back to the days of the oldest colour-capable DEC terminalsWhat about blue on blue (like immensely popular in xUSSR Norton Commander? I still use that scheme (because it's a default in Midnight Commander) and like it.
> Can *anyone* read dark blue on black easily?Yes. Me. Dark blue is perfectly fine. Novadays I have slight trouble reading bright yellow or bright blue on black. But dark ones are perfectly fine.
> ... hm, maybe it's just that newer LCDs have a wider colour gamut than older LCDs (which should lead to dark blue being further separated from black), and both my LCD screens *are* quite old random Samsungs.Maybe, but that's irrelevant. I liked blue on blue back when I used ViewSonic PT810 and I like this setting now.
Refreshing
Posted Jun 10, 2021 11:41 UTC (Thu) by flussence (subscriber, #85566) [Link]
I go out of my way to change it in every terminal emulator I use, because otherwise large parts of the OS are unusable (Gentoo's package manager and surrounding tooling is an accessibility disaster that frequently uses blue and yellow text colour to convey *information* - there's no escape even if you try to use a light terminal).
Refreshing
Posted Jun 9, 2021 22:45 UTC (Wed) by rodgerd (guest, #58896) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 6:23 UTC (Wed) by sylvestre (subscriber, #57054) [Link]
I started to focus a bit more on the GNU compat lately and create this project https://github.com/uutils/coreutils-tracking to keep of the Rust/coreutils vs GNU/coreutils evolution of the testsuite:
Image: https://raw.githubusercontent.com/uutils/coreutils-tracki...
And document how to run the testsuite locally:
https://github.com/uutils/coreutils#comparing-with-gnu
Making progress!
I will try to publish a blog post to share updates.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 7:20 UTC (Wed) by eru (subscriber, #2753) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 8:08 UTC (Wed) by Sesse (subscriber, #53779) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 10:07 UTC (Wed) by eru (subscriber, #2753) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:23 UTC (Wed) by wahern (subscriber, #37304) [Link]
That sounds very nice from the standpoint of interactive use. But for non-interactive scripting such behaviors violate numerous best practices, and are neither particularly convenient, consistent, nor safe. This is a common story for tools like ripgrep.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:28 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Why is this a problem? It is a easy toggle to turn on/off
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 23:12 UTC (Fri) by jccleaver (subscriber, #127418) [Link]
Because a system administrator may spend lots of time iterating between executing command lines, writing those command lines into a shell script, and debugging said command lines.
Predictability is vitally important, especially if it's 3am and I'm trying to figure out why this shell script that had been working suddenly breaks in the script but works fine when executed by hand.
There's a reason code deltas for interactive operation were few and far between, and mostly invisible (eg, stripping color). When the utility didn't handle it, "standard" shell aliases (eg, "rm -i") could do the trick. Plenty of utilities in the last decade seem to think that I *always* want a huge, complex TUI for getting data, or think it knows better about how I want my output presented.
I have high confidence that grep in an interactive shell and grep in a shell script will do essentially the same thing (except for things that apply to all scripting, like proper handling of globs). I have little confidence a "modern" grep replacement won't have some weird hacky behavior that was put in because it looks cool and will cost me an hour of hair-pulling early in the am trying to track it down.
Rewriting the GNU Coreutils in Rust
Posted Jun 12, 2021 3:17 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
I suspect from your response that you haven't used rg.
I have written plenty of scripts using both grep and occasionally rg as part of my work and I consider either behavior very much predictable and documented. If anything grep behavior is slightly less predictable when switching between say a laptop running Mac and a server running Linux because of the variations between grep.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:22 UTC (Wed) by taladar (subscriber, #68407) [Link]
More readable documentation and --help output might certainly be welcome, as might be some optional verbose/debug flags that give more readable error messages that explain why something isn't working.
On the other hand if we are talking about making things incompatible for scripting use I would certainly agree that that is the wrong type of "enhancement".
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 14:24 UTC (Wed) by mbunkus (subscriber, #87248) [Link]
This is a different goal than rewriting programs or collections such as Coreutils.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 13:50 UTC (Thu) by moltonel (guest, #45207) [Link]
In my youthful days I'd read all the coreutils changelogs and get excited about new features. Yesterday's bells are today's must-have. A lot of the entries in http://www.gnu.org/software/coreutils/rejected_requests.html look really reasonable and useful to me.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 19:33 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]
I disagree mildly. It's vital that a replacement for something important like coreutils be 100% compatible, but that should be limited to doing the same things when given commands that are valid for the old version. They should be free to add new features as long as they are only accessed in a way that wouldn't happen with the old software, e.g. by using currently unused command line switches. But new features should take a back seat to getting compatibility complete.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 9:42 UTC (Fri) by james (subscriber, #1325) [Link]
I disagree mildly.So do I!
It's vital that a replacement for something important like coreutils be 100% compatible...Not that coreutils was ever 100% compatible unless POSIXLY_CORRECT was set. I see no reason why a reimplementation shouldn't be afforded the same luxury (GNULY_CORRECT?) if they identified unfortunate edge behaviour.
Having said that, the original Unix utilities were written by competent hackers. The GNU reimplementations were also written by competent hackers. There can't be many places where existing behaviour could be improved, but not in a backwards-compatible way, and where the compatibility break would be worth it.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 7:38 UTC (Wed) by epa (subscriber, #39769) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 23:17 UTC (Wed) by Sesse (subscriber, #53779) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 23:19 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 5:34 UTC (Thu) by epa (subscriber, #39769) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 7:50 UTC (Thu) by Sesse (subscriber, #53779) [Link]
Say that you have some long-running computation that you want to be able to abort cleanly. Now further assume that your thread is stuck in a syscall; say either waiting for a write to file on NFS, or waiting for data from socket. Let's say a recvfrom(). You trap SIGINT, and in your handler, you set a “please shut down” flag. (You can't do much else in a signal handler!) Now, if this didn't abort your recvfrom() with an EINTR, how would you ever get to actually check that flag and shut down?
Rewriting the GNU Coreutils in Rust
Posted Jun 15, 2021 12:44 UTC (Tue) by epa (subscriber, #39769) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 15, 2021 19:02 UTC (Tue) by nix (subscriber, #2304) [Link]
Many, perhaps most of the commands in coreutils are or can operate as filters. These can be arbitrarily long-lived and spend nearly all their time blocked on I/O.
Rewriting the GNU Coreutils in Rust
Posted Jun 16, 2021 5:03 UTC (Wed) by epa (subscriber, #39769) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 16, 2021 14:46 UTC (Wed) by nix (subscriber, #2304) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 15:45 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
That's not good in a system's language. You want to get the errors as they occur. Now, the stdlib can provide combinators to say "restart on EINTR" around these calls to abstract at least that away, but Sesse's point is that you can't just hide it away in all cases.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 20:09 UTC (Fri) by notriddle (subscriber, #130608) [Link]
That's what it does.
In the documentation for Write, it says that the regular write call can return Interrupted. The wrapper that automatically retries is called write_all.
Rewriting the GNU Coreutils in Rust
Posted Jun 14, 2021 8:04 UTC (Mon) by ceplm (subscriber, #41334) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 14, 2021 8:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Rewriting small pieces of it one-by-one is perfectly fine. It's exactly the small gradual refactoring that we need.
For perspective, coreutils is around 70k lines of code in C. This is not a huge project by any means.
Rewriting the GNU Coreutils in Rust
Posted Jun 15, 2021 8:57 UTC (Tue) by epa (subscriber, #39769) [Link]
I agree with Joel's points, and you don't want to ditch battle-hardened code, but if the hardening was only added for running on AIX 0.9 in mixed-endian EBCDIC configuration, you can drop it as long as you explicitly drop support for that platform. A new implementation with narrower goals doesn't have to be a drop-in replacement for the old version in all cases. And there are times when rewriting is worthwhile; the GNU tools themselves are from-scratch rewrites of classic Unix utilities, and quite apart from licensing they fixed lots of technical problems like fixed line width.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 12:44 UTC (Wed) by karim (subscriber, #114) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:00 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Not quite. This is an alternative from scratch implementation. The biggest motivation I would imagine is the rapid adoption of Rust and willingness to adopt new features and taking advantage of new capability in the Linux kernel. GPL has been falling out of favor for many of these new projects for other reasons and that is not a new trend
https://redmonk.com/sogrady/2017/01/13/the-state-of-open-...
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:01 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
What stops anyone from making non-GPL copies of GPL software (besides the "don't look at the implementation" general copyright considerations)? Is there something special about GPL software that means no one can have a valid reason to not use it and instead require something permissive?
> At some point in the future TBD will the GNU project be seen as an intermediate transition point where it'll have fuelled "open source" but will itself have become obsolete?
Note that I'm not thrilled about the GPL becoming less prevalent overall, but this sentiment seems kind of misguided. If GNU wants to stay relevant, it's not going to do that my resting on its laurels. Clang showed that to GCC at least.
Big business isn't helping this situation, but sitting on the sidelines and pouting "why does no one want to use me?" isn't a compelling reason to use that software.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 23:22 UTC (Wed) by rodgerd (guest, #58896) [Link]
In 2021 the FSF have decided that their guiding light is a guy who needs assistants to book travel so he doesn't have to use JavaScript and browses the web via email. The FSF endorses a hardware strategy that valorises leaving your hardware with known-insecure firmware installed because installing security updates from the vendor is "unfree" and bad.
The FSF have chosen to become irrelevant to how people want to live their lives and interact with technology in favor of a weird, insecure, retrocomputing experience, rather than providing meaningful free alternatives. It's no wonder that people are interpeting this is damage and working around it. It's unfortunate that this has tainted people's impression of the GPL; I'm very keen on the share-and-share-alike philosophy that rests at its core. But it's become tainted by the FSF's disinterest in learning what humans want to do, in preference for hectoring developers and users alike.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 0:38 UTC (Thu) by pizza (subscriber, #46) [Link]
> The FSF have chosen to become irrelevant to how people want to live their lives and interact with technology in favor of a weird, insecure, retrocomputing experience
In other words, you're saying the world changed, but the FSF did not?
(The FSF was never particularly aligned with how "people want[ed] to live their lives and interact with technology". They've been pushing against the grain from the very beginning!)
> rather than providing meaningful free alternatives
Sure, the FSF, with its couple-hundred-thousand/year budget and one full-time employee, is somehow supposed to out-produce Google, Microsoft, Apple, Amazon, Facebook, Netflix, etc etc combined. Plus a couple dozen data centers. Gotcha.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 2:11 UTC (Thu) by NYKevin (subscriber, #129325) [Link]
If the FSF wants to fritter away its goodwill on irrelevant work that few people care for, well, it's their organization to run as they see fit. But IMHO it's unwise to play such dangerous games with the GPLv4 (or GPLvN+1) relicensing rights. If they continue on their current path, they will eventually run out of mindshare, donations, and ultimately cash reserves, and GPLv4 will get auctioned off to the highest bidder. That will be interesting to watch, but I sincerely hope it doesn't happen for a long time.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 3:02 UTC (Thu) by pizza (subscriber, #46) [Link]
And that's fine; Good riddance.
The FSF, GNU, and copyleft in general are slowly reverting back to what it was before the big venture-capital dotcom bubble; ie folks writing software on a volunteer basis for largely ideological reasons. As long as there are folks who believe in those principles, it will continue. If not, then, well, nope.
Speaking of capitalism, at the end of the day, what the average user calls "software" (or "app") is actually a "service". You can't compete with services by providing software.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 1:58 UTC (Thu) by flussence (subscriber, #85566) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 13:24 UTC (Wed) by IanKelling (subscriber, #89418) [Link]
distros? I say: first of all, GNU/Linux generally embraces copyleft to
protect your freedom and BSD doesn't. BSD distros also do some things
different, but I think the copyleft issue is more important. For some
reasons I think that, see
https://www.gnu.org/philosophy/why-copyleft.en.html.
> The Coreutils project was created to consolidate three sets of tools
> that were previously offered separately...
I think a better, more accurate summary is that coreutils was created
because the programs in it were essential for the goal of developing a
free software operating system protected by copyleft that could
replace Unix and do all that Unix could do.
> The uutils project aims to rewrite all of the individual utilities
> included in the GNU Coreutils project in Rust.
Again, I think a better summary is that uutils aims to replace GNU
coreutils and remove it's copyleft protections. They also try to make
some technical improvements by using rust instead of C. FSF enforces the
GPL on GNU coreutils, bringing and protecting freedoms for software
users. uutils aims to end that work.
The uutils maintainers do not want it framed this way, they seem to
highlight rust and treat the license as an unimportant footnote. The
authors of this article thankfully brought up the issue, but still in a
secondary way. I understand that some people don't care much about
copyleft or software freedom. I want to convince them that they should
care. I hope someone forks uutils and makes new contributions under
GPLv3+, which then applies to the entire program when users receive
it. Then I hope the maintainers of that fork work with a nonprofit like
FSF or Software Freedom Conservancy to enforce the license, because the
copyright holders have the exclusive right of enforcement and they
probably won't have as much dedication to doing it as those nonprofits
(especially after they die, since copyright lasts far beyond most
people's deaths). And because those nonprofits will enforce them in
community oriented ways that prioritize users' freedom
( https://www.fsf.org/licensing/enforcement-principles ).
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:00 UTC (Wed) by micka (subscriber, #38720) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:41 UTC (Wed) by khim (subscriber, #9252) [Link]
That's normal reaction from someone who belongs to “free software” camp. That was discussed for many years (e.g. see this thread).
The fact that free software movement is dying makes them really bitter. But somehow they still don't understand that if people don't accept their ideals then it's highly unlikely that they would try to support them.
For some reason they act like a truly religious person: not trying to understand why other people may not share their belief but just assume they are not supporting it just because they haven't achieved “the enlightenment” yet.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 22:06 UTC (Wed) by pizza (subscriber, #46) [Link]
Is it really dying, though? It was never "popular" to begin with, with its proponents always looked upon with derision.
In absolute terms, it's probably larger than ever. But as a portion of "the market" it's shrunk considerably.
But I suspect the bitterness is more due to this whole situation pretty much playing out as predicted. We're seeing the beginnings of the second round of BSD wars, only this time fueled by Apache-licensed stuff instead, and of course, users will be screwed over left and right in even greater numbers.
Time will tell. *shrug*
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:10 UTC (Thu) by khim (subscriber, #9252) [Link]
> It was never "popular" to begin with, with its proponents always looked upon with derision.True, but these proponents were able to coopt people with a different mindset. The ones who later have formed the “open source” movement.
There was some friction between these two groups, but Linus is still considering adoption of GPL as one of the best decisions he ever did in development of Linux.
Today… these people are leaving. GCC team haven't divorced FSF yes, but this is, surely, step in that direction.
> We're seeing the beginnings of the second round of BSD wars, only this time fueled by Apache-licensed stuff instead, and of course, users will be screwed over left and right in even greater numbers.Maybe. This wouldn't happen any time soon, though.
> Time will tell. *shrug*Sure. But only our descendants will be able to tell. When was TiVo made? 22 years ago? That's almost quarter-century. The promised doom haven't materialized yet.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:06 UTC (Sun) by nix (subscriber, #2304) [Link]
That doesn't mean the toolchain hackers aren't free software people any more. It's still GPL-licensed and will remain so. Being in favour of free software and wanting to give RMS sole unquestioned authority over your project are *not* the same thing. I wish people would stop assuming they were.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:41 UTC (Sun) by pizza (subscriber, #46) [Link]
On the contrary; it's come to pass many times over, now affecting the overwhelming majority of computing devices sold.
Oh, and heavy equipment. Farmers shouldn't have to commit felonies just to get their equipment working again:
https://www.vice.com/en/article/v7m8mx/john-deere-promise...
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:58 UTC (Sun) by khim (subscriber, #9252) [Link]
> On the contrary; it's come to pass many times over, now affecting the overwhelming majority of computing devices sold.I think you are mixing two very tangentially related issues:
- Tivoisation/lockdown — which predates FSF and GNU and is wasn't ever a problem in BSD wars.
- Balcanization — creation of incompatible software platforms which makes life of software developers miserable
Lockdown is happening, of course, as I have said it was a thing half-century ago and even before. Industry always wanted that, that's why we have these fancy screwdriver bits, e.g.
But balcanization… not sure where one can see it today. What makes all these numerous proprietary works of LLVM any different from proprietary forks of GCC which were supplied (and still are supplied) in various projects? Yes, technically speaking I can look on the code of TI-GCC or GPC and try to backport fixes from GCC12… but practically speaking it wouldn't much easier than attempting to replicate work embedded in these LLVM forks.
Rewriting the GNU Coreutils in Rust
Posted Jun 28, 2021 14:01 UTC (Mon) by immibis (subscriber, #105511) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 22:40 UTC (Wed) by rodgerd (guest, #58896) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 0:05 UTC (Thu) by Wol (subscriber, #4433) [Link]
(The Japanese High Command in WW2 for those who don't recognise the quote.)
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:13 UTC (Wed) by khim (subscriber, #9252) [Link]
Unfortunately that ship have sailed. When GPLv3 was made I, too, hoped it would protect user's freedom better.
Instead the opposite happened. Industry have spoken and said “no” to GPLv3 and “big no” to AGPL.
The only real good thing GPLv3 did was mending the bridge between GPLv2+ and Apache license (it was never 100% clear if such combination was legal before introduction of GPLv3). All other consequences are negative. Apple bought llvm and created clang to make sure it wouldn't need to touch GPLv3, Google embraced that works and did a lot to make sure GPLv3 and even GPLv2+ (except for kernel) wouldn't be part of Android and so on.
In the end GPLv3 impact was profoundly negative: apparently GPLv2 was causing just enough pain to industry adopters to make it good for users yet still acceptable to the industry. GPLv3 has passed that threshold. In theory it provides benefits to users. In practice is just makes their life harder because they have to deal with unreliable MTP instead of reliable CIFS, e.g.
Can you even name one popular project which was started as GPLv3 one (and not relicensed from GPLv2+)? > I hope someone forks uutils and makes new contributions under GPLv3+, which then applies to the entire program when users receive it.
Why would anyone make fork which noone very few would ever want?
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:51 UTC (Wed) by pizza (subscriber, #46) [Link]
> Instead the opposite happened. Industry have spoken and said “no” to GPLv3 and “big no” to AGPL.
A license can't protect users' freedoms if code authors choose to not use it. Which only tells you those authors don't actually prioritize "protecting users' freedoms"
Meanwhile. The "industry" always hated copyleft, and I think what we are seeing today would have happened even if the GPLv3 had never come to be.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 9:39 UTC (Thu) by khim (subscriber, #9252) [Link]
> The "industry" always hated copyleft, and I think what we are seeing today would have happened even if the GPLv3 had never come to be.I'm not so sure. Industry always hated copyleft, true, but not enough to actually dedicate substantial resources to it's eradication. Apple have chosen to open up Objective C instead of asking some other company for the base C compiler (and there were many such companies back then). Everyone who was using Linux was using bunch of GNU software, too (that's, ironically, why term GNU/Linux haven't gotten traction and was considered superfluous for many years).
This all have changed when discussions about tivoization and, more importantly, talks about changes to GPL to prevent that have started.
Grudging agreement between “free software” movement and industry was broken and “war” have started. Maybe that war was inevitable, who knows? But even if it were, ultimately, inevitable, GPLv3 provoked it early and thus made “free software” position worse instead of making it better.
> A license can't protect users' freedoms if code authors choose to not use it. Which only tells you those authors don't actually prioritize "protecting users' freedoms"True. But before GPLv3 lots of people (“open source” camp, people who don't try to eliminate proprietary software) who don't really care about user's freedom and only want tit-for-tat (as Linus likes to put it) have chosen GPL anyway. Which “free software” can then portray as their victory and, more importantly, can use to get some freedom for users.
Today… these people usually pick APL or MIT license because they expect that this would just attract more potential contributors that way and would make proprietary forks unsuccessful. This is somewhat risky ploy, but, after GPLv3 fiasco and industry rejection of it… more-or-less inevitable.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 10:46 UTC (Thu) by pizza (subscriber, #46) [Link]
I believe that GPL enforcement efforts poisoned the well far more than GPLv3 ever did. All companies ever cared about was money, and GPL enforcement changed "I get to use this for free" into "we have to actually pay attention to what we're using in our products", which required changes to how they did business.
Mind you, supply chain management is critically important (though "the industry persists in trying to bury their head in the sand and ignore this) and GPL compliance is downright cheap, especially when compared to most regulations that a typical company has to deal with. But it was the publicity around that (minimal) GPL enforcement that seeded the general industry rejection.
(And I say that as someone who is firmly in the "GPLv3 is better than v2" and "we need _more_ enforcement" camps)
> Today… these people usually pick APL or MIT license because they expect that this would just attract more potential contributors that way and would make proprietary forks unsuccessful.
Those that _contribute_ determine the direction software takes, and "the industry" massively out-contributes the "free software" crowd, so it's no surprise those contributions reflect the priorities (including the ethics) of "the industry"
> This is somewhat risky ploy, but, after GPLv3 fiasco and industry rejection of it… more-or-less inevitable.
Equally inevitable is the failure of that ploy, because it does nothing to prevent the a bigger fish from taking your software and completely proprietizing it (making it more attractive to users by out-contributing you) or wrapping/bundling it as a service and completely undercutting your ability to monitize your own software.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 12:30 UTC (Thu) by khim (subscriber, #9252) [Link]
> Equally inevitable is the failure of that ploy, because it does nothing to prevent the a bigger fish from taking your software and completely proprietizing it (making it more attractive to users by out-contributing you) or wrapping/bundling it as a service and completely undercutting your ability to monitize your own software.If it's as inevitable as you say then why there are so many projects which don't support that fate and so few popular GPLv3 projects?
Actually you answered that question.
> Those that _contribute_ determine the direction software takes, and "the industry" massively out-contributes the "free software" crowd, so it's no surprise those contributions reflect the priorities (including the ethics) of "the industry"Indeed — that's why you can pick APL/MIT and face the problems you outlined above. Risky and uncertain choice, yes. Or you may pick GPLv3 and guarantee the failure.
IanKelling class for GPLv3+ fork of uutils. Basically do what you say industry does to APL/MIT-licensed projects. But have any such GPLv3 fork succeeded? Ever? I'm not saying it's impossible, I'm really genuinely curious.
Because for now it looks as if choice of GPLv3 doesn't doom the project, but certainly hurts and if any GPLv3 ever succeeds it's because it's not just better than alternatives but better enough to overcome GPLv3 stigma.
GPLv3 fork of any permissively-licensed project can show that it's not true and we can learn on it's example about how GPLv3-software can win. But to do that we need at least one example of such a project.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:08 UTC (Thu) by pizza (subscriber, #46) [Link]
The only way a "GPL fork" of a permissively-licensed project will be "successful" (in terms of mindshare, marketshare, whatever) is if the GPL-proponents out-contribute the others, producing something that is "better enough". Which is bloody unlikely when you're a handful of part-time volunteers up against teams that are funded by industry consortia.
BTW, you seem to define "success" as "the industry widely adopts it". I *do not care* what "the industry" wants (which is "everything, for nothing"). Instead, I care about (1) the software meeting my own personal needs, and (2) the other users of my software.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:45 UTC (Thu) by khim (subscriber, #9252) [Link]
> Instead, I care about (1) the software meeting my own personal needs, and (2) the other users of my software.Do you? How does GPL (any version) helps with either (1) or (2)?
I don't see how GPL can help either (1) or (2) if industry rejects your software.
If industry accepts that software than (and only than) license starts to matter.
> Which is bloody unlikely when you're a handful of part-time volunteers up against teams that are funded by industry consortia.Then why the hell do you insist on putting yourself in that position?
Back in XX century FSF (and GNU project) worked with the industry. GNU tools were “unofficial standard” on many OSes (and FSF's FTP even carried binaries for popular OSes like Solaris) even if definitely mostly helps the ones who adopted free software because of convenience and not because of their belief in “free software”. Heck, back then, back in XX century Stallman wrote If you want to accomplish something in the world, idealism is not enough—you need to choose a method that works to achieve the goal. In other words, you need to be “pragmatic.”
And back then copyleft worked. The biggest achievements which Stallman lists in his essay are few cases where someone made a piece of software because copyleft forced them to do that.
After GPLv3 fiasco… that stopped happening. Instead of releasing things under GPLv3… people started releasing stuff under permissive licenses or, alternatively, stopped using GPLed programs as basis for development and don't release anything at all.
And instead of trying to be pragmatic and adjusting their stance “free software” camp doubled-down on their idealism and is now quickly driving themselves into irrelevance.
That's sad to observe, but… if these people want to fight… against the whole industry… well… that's their choice, in the end.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 15:47 UTC (Thu) by pizza (subscriber, #46) [Link]
"Industry" has failed me (and the users in my little niche) many times over. WTF would I give a damn what they want?
If I released my code under permissive terms, I'd be effectively paying them to screw me over again. That'll sure show them!
> And instead of trying to be pragmatic and adjusting their stance “free software” camp doubled-down on their idealism and is now quickly driving themselves into irrelevance.
There is no compromise with someone who doesn't believe you have the right to exist. Keep that in mind when you talk about compromising ideals.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 16:33 UTC (Thu) by khim (subscriber, #9252) [Link]
> There is no compromise with someone who doesn't believe you have the right to exist. Keep that in mind when you talk about compromising ideals.That lines highlights the issue with the GPLv3 and the reason why it shouldn't be used much better than anything else.
The truth is different: extinction is much worse than even the “compromise with someone who doesn't believe you have the right to exist”.
But in the end, as I have said, it's your choice: if “free software” camp want to become just an article in Wikipedia about yet another group which no longer exist… who am I to judge them?
> "Industry" has failed me (and the users in my little niche) many times over. WTF would I give a damn what they want?Care to write an article which explains how “industry” have failed you, and, more importantly, how you are thriving now without them?
I'm sure people on LWN would appreciate it. As cautionary tale if not anything else.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 17:18 UTC (Thu) by pizza (subscriber, #46) [Link]
The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances. "user empowerment" as embodied in the "Four Freedoms" is in direct conflict to this.
But your takeaway is that the GPLv3 is the problem, rather than the ones seeking to repress users? WTF?
> Care to write an article which explains how “industry” have failed you, and, more importantly, how you are thriving now without them?
Printers. I've said here in the past that I've been threatened with lawsuits by companies that were actively distributing (if not outright using) my code -- Code that I only wrote because they refused to support Linux users.
Meanwhile, the actual "need" that got me into this area to begin with was a brand-new printer with memory card slots that couldn't handle abitrary jpegs... and also violated the flow control portions of the USB printer class specification.
And yes, by any objective standard, I'm thriving. My personal printing needs are well met these days, and I've been able to leverage this work into a (very) modest consulting business that pays for more creative-outlet-type devices (most recent one was a laser engraver that runs GPLv3-licensed GRBL).
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 21:04 UTC (Thu) by khim (subscriber, #9252) [Link]
> The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances. "user empowerment" as embodied in the "Four Freedoms" is in direct conflict to this.… because that's the only thing that you can actually make and sell. It's not as if there are no attempts to create other types of devices — people are just not buying these.
> But your takeaway is that the GPLv3 is the problem, rather than the ones seeking to repress users? WTF?GPLv3 is a problem because it's expressly designed to make sure code released under that license wouldn't reach actual users and would forever stay irrelevant.
Yes, it was brave attempt to change the industry rules… and it failed. Time to move on.
> And yes, by any objective standard, I'm thriving. My personal printing needs are well met these days, and I've been able to leverage this work into a (very) modest consulting business that pays for more creative-outlet-type devices (most recent one was a laser engraver that runs GPLv3-licensed GRBL).Interesting. This means that while industry-at-large changed and now using GPLv3 for something like uutils just means that nobody would bother to even look on your creation… yet at the same time certain niche markets appeared where GPLv3 is not considered large enough liability to try such software.
This certainly is an interesting example and article may show how more such niches can be found (or made?). That would mean that “free software” may still be relevant to some people beyond core “die-hard believers”. And certain types of software may actually exist as genuine “free software” because of that.
I wasn't aware such niches remained. All the software I develop and use is either:
- Used by billions of people — and then, of course, GPLv3 is just flat out unacceptable, or
- is niche enough that you can't make a business out of it — and then GPLv3 is irrelevant since there are noone who would misappropriate it in the first place (since there are no money in it)
If you may show where “free software” can be actually useful then it would be 100 times more important than whining about the desire of uutils makers to create something that people would actually use.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 0:39 UTC (Fri) by pizza (subscriber, #46) [Link]
Of course there are other types of devices, and real people do buy them. There is a considerable middle ground between "tens of millions of units shipped in a quarter" and "nothing".
> GPLv3 is a problem because it's expressly designed to make sure code released under that license wouldn't reach actual users and would forever stay irrelevant.
[citation needed]
> If you may show where “free software” can be actually useful then it would be 100 times more important than whining about the desire of uutils makers to create something that people would actually use.
"free software" isn't inherently useful, except in an abstract educational sense. But "useful software" is made more so by being "free".
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 8:24 UTC (Fri) by marcH (subscriber, #57642) [Link]
Yes and the resources to pay engineers and develop software are a direct function of that volume.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 8:26 UTC (Fri) by marcH (subscriber, #57642) [Link]
> [citation needed]
Let's quote you then:
> The entire purpose of the "tech industry" these days is to sell advertising (and/or access to "content") on locked-down appliances.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 10:37 UTC (Fri) by pizza (subscriber, #46) [Link]
And do I really have to point out that the software world is *much much much* bigger than the "tech industry"?
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 11:53 UTC (Fri) by khim (subscriber, #9252) [Link]
> I'd think such an absolute declaration as to the intents of the GPLv3 would be trivial to cite, as the whole drafting process was quite publicThe whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell.
But it was really quite naive to expect such an outcome in a world where the same hardware is sold to a different users at “differentiated prices”. Think Intel's CPUs or compare prices of TI-NSpire and TI-NSpire CAS (not only they have identical hardware, their sales rely on the inability of the buyer to tinker with their software… they are not doing all that good of a job ensuring that, actually, since they only need to claim that it's impossible to change the software, they don't need to make it actually impossible — but that stil absolutely precludes use of GPLv3 software).
FSF hoped to, basically, change the business models of many different industries, laws (that's very explicitly written there, look on section #3), the style in which governments operate — with very limited reward: the ability to use some software for free. No wonder the attempt backfired.
It was a gamble: we may change the rules under which the whole world operates or we would be kicked out of mainstream and relegated to tiny, insignificant niches. But GCC looked so entrenched, Linux was so popular… the die was cast. “Free software” lost.
> And do I really have to point out that the software world is *much much much* bigger than the "tech industry"?Indeed. And since software replaces hardware more and more it becomes more and more important for the developers of hardware to stop unauthorized modifications. For market compliance and other reasons.
Indeed, that was pointed out to FSF many, many times during the GPLv3 drafting. And it was altered to accommodate some such uses (look for distinctions WRT to “User Product”, e.g. — it's there specifically to allow producers of industrial devices not intended to be used by “Joe Average” to be able to delived locked-down hardware to their customers who very expressly don't want the ability to change the code on a device with associated liability). But it was very obvious even back then that such cases would become more widespread, not less (heck, look on #3 “Protecting Users' Legal Rights From Anti-Circumvention Law” again).
In a world where problems in software may lead to, at most, some papers being incorrectly printed GPLv3 may have been acceptable (yet, ironically enough, it was also not needed in such a world). In a world where software drives literally everything… it's unusable and ensures that end-users would never see your software.
Relying on software to fix hardware bugs is the norm novadays and it's much, much, MUCH simpler to rely on the locked down, signed, firmware instead on some nebulous schemes which may detect and alter modification of core system library (like libstdc++) and save the hardware anyway.
It's certainly nice that some niche industries may still afford to use GPLv3 and I really would be glad to read your article about that (no sarcasm here) but GPLv3 was expressly designed to make sure software under said license wouldn't be acceptable for many, many, MANY industries and thus would never reach the end users.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 12:15 UTC (Fri) by pizza (subscriber, #46) [Link]
This may have been the end result, but it is was not the "Expressly designed intent", as you yourself said in the very first sentence of your reply:
> The whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell.
(though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than not)
Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 12:36 UTC (Fri) by khim (subscriber, #9252) [Link]
> though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than notLocked-down devices predate not just GPLv3, not just the whole GNU project. They go back to early days of the IT industry. IBM sold features which would be unlocked (by installation of some SMS cards) back in 1950th, TROS modules in 1960th and so on.
Yes, it was relatively easy to circumvent these limitations (compared to RSA signature in modern devices) but that's not something people invented just to make FSF angry at them.
GPLv3 needs entirely new scheme, though: the one where you can change part of your base system software but not the whole thing.
That is certainly harder to achieve than full lock down of the whole thing.
> Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).
How is that substantially different from Apache license? It also includes the patent grant. And is loved by the industry.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 12:49 UTC (Fri) by pizza (subscriber, #46) [Link]
For the "tech industry" as a whole, the "user" is not the "customer" -- as in, those _using_ the product/device/whatever are not the same parties who actually fork over money. In those scenarios (and other business models where hardware is sold at a loss and made up for on the back end), locked-down devices are economically advantageous.
For everything else, barring legal/regulatory anti-tamper requirements (which are actually quite rare), there simply isn't an economic incentive/advantage to lock the hardware down; indeed it doing so can actually place you at a competitive disadvantage (because it both raises your costs and _reduces_ end-user functionality/utility)
In my two decades of experience in this field, the general concept of copyleft as a whole is the problem -- businesses simply don't want to have to comply with source distribution requirements and the risk that their "secret sauce" is forced into the open due to viral GPL contamination. Nevermind that having the processes to maintain/track the "software supply chain" is a practical necessity (ie _not_ having it can be a massive liability even without copyleft/GPL)
Once they accept the practical realities of having some GPL software (ie providing corresponding source code and keeping their proprietary stuff, if any, properly segregated), GPLv2 vs GPLv3 vs MPL vs SCCL or whatever is largely irrelevant... unless you have patents you're trying to protect/enforce, and the GPLv3's explicit patent license can possibly render your business' entire patent portfolio effectively useless for anything other than purely defensive means. That scares the bejeebus out of the suits, so the edict comes down that GPLv3 is bad, along with the funding to avoid its use, even to the point of wholesale development of in-house replacements.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 12:57 UTC (Fri) by khim (subscriber, #9252) [Link]
You still haven't explained what makes explicit patent grant in GPLv3 worse than no less explicit patent grant of APL. And APL is certainly warmly embraced by the industry.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 14:17 UTC (Fri) by pizza (subscriber, #46) [Link]
ASLv2's patent clauses kick in only for _contributions_ to the software (ie "by contributing, you're granting a license for all patents you have that relate to the software") , but GPLv3's patent clauses go considerably further, applying even if you merely redistribute unmodified 3rd party software covered by a patent you hold or have licensed.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 15:42 UTC (Fri) by marcH (subscriber, #57642) [Link]
macOS has been stuck to the last GPLv2 version of bash for years, now switching to zsh. Same for other software on macOS.
Same timing all across the industry, what a coincidence!
Rewriting the GNU Coreutils in Rust
Posted Jun 28, 2021 14:09 UTC (Mon) by immibis (subscriber, #105511) [Link]
> That lines highlights the issue with the GPLv3 and the reason why it shouldn't be used much better than anything else.
Pardon? What about the GPLv3 doesn't give people the right to exist?
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 5:05 UTC (Fri) by NYKevin (subscriber, #129325) [Link]
The people who care about monetization were never using permissive licenses, are not now using GPLv3, and increasingly they're not even using AGPL. Instead, they're inventing their own proprietary fake-open-source licenses such as the SSPL or Commons Clause. As it turns out, "take somebody else's open source software and host it for a small fee" is an increasingly viable business model, and the Four Freedoms (particularly freedom 0) were specifically designed to allow people to do that sort of thing.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 6:20 UTC (Fri) by joib (subscriber, #8541) [Link]
Some are, typically those using an 'open core' business model.
> As it turns out, "take somebody else's open source software and host it for a small fee" is an increasingly viable business model, and the Four Freedoms (particularly freedom 0) were specifically designed to allow people to do that sort of thing.
Sure. Software where only the copyright holder is allowed to monetize it is quite clearly not free, as freedom from the tyranny of the copyright holder is one of the core ideas behind both free software and open source. That being said, if an oligopolistic megacorporation uses their superior economy of scale to crush anyone else, including the original creators, from hosting an open source app that's a problem too. I don't know what 'the solution' to this would look like, though it seems the lack of success of AGPL would suggest that increasingly stringent copyleft isn't it.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 19:57 UTC (Thu) by Hobart (subscriber, #59974) [Link]
https://web.archive.org/web/20160106033123/https://tech-i...
> At that time, I envisaged the legal ramifications like some others who have recently posted on this list, so I did not see a basis for saying they could not do this.
> But at the same time, I realized that it would not bode well for the GNU project if such a thing were permitted. So I responded, "I will have to check with our lawyer."
> It's a good thing I did, because when I checked, I found that there was a basis for objecting to this plan. Such .o files would have implied the presence of the GNU compiler, linked with them. They would be, in effect, a way of distributing a larger program which implicitly includes the GNU compiler; as such, it must follow the terms on the GNU compiler.
> I told NeXT this, and NeXT decided there was no alternative to making the Objective C front end free software. So now it is available to all of us as a part of GCC.
Characterizations elsewhere in this thread of people who want their time & code to be "share and share alike" peppered with canards about religion are inflammatory.
If Apple is benevolent and sharing of their source code, it would be nice of them to open the NetBSD-based Time Capsule code for to save customers who shelled out hundreds from owning bricks. Here's a Guardian story on that one. https://www.theguardian.com/news/datablog/2010/jul/14/app...
🎵Join us now and share the software🎶
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 20:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yet they decided to just open the source and keep gcc, because it wasn't really a big deal for them.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:13 UTC (Sun) by nix (subscriber, #2304) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:29 UTC (Sun) by khim (subscriber, #9252) [Link]
At least half-dozen compilers existed back then: Aztec C, Lattice C, Megamax C, and others. Year 1983 article name Nine C Compilers for the IBM PC speaks for itself (and note that back then GCC had no support for x86 which means there were more compilers than these nine).
If Jobs really wanted to avoid publishing Objective C changes he could have easily done that. But apparently for him it wasn't a big deal. This changed with GPLv3: suddenly the deal was altered enough that it have become a big deal for Apple.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 2:25 UTC (Fri) by ncm (guest, #165) [Link]
Probably more important is that Gcc utterly nuked the whole compiler industry, and probably even killed Ada as a viable industrial language (even though GNU Ada eventually came out). Linux similarly nuked the OS business, causing a massive collapse and consolidation.
When you look around for relevance of GNU-licensed and other Free software, look at companies that collapsed or never came into existence. Everything else is a rounding error. New GPLed software is a good way to eliminate an industry sector that might otherwise be dictating terms to you.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 15:17 UTC (Fri) by joib (subscriber, #8541) [Link]
To the extent the Apple ecosystem hasn't yet switched over to Swift, I believe it's still used there.
But apart from GNUStep which is quite niche, I don't think it has ever been much used in the FOSS world.
> Probably more important is that Gcc utterly nuked the whole compiler industry
Playing the devils advocate, AFAIU people used gcc mostly because it was free as in beer, and good enough (heck, in many cases better than the proprietary alternatives). Had it been available via a permissive license, the end result would have been the same. Sure, someone could try to build a proprietary compiler business on top of 'permissive gcc', but the same problem would remain: why would anyone go through the hassle of paying for it if gcc is good enough and free?
> Linux similarly nuked the OS business
Again, we don't have alternative universes to run experiments on, but one could argue that Linux success instead of, say, FreeBSD, was more due to lucky timing (the BSD's being caught up in lawsuits during the critical early years etc.), and a better more scalable development model.
(All this being said, I do think copyleft offers at least some protection against 'proprietarization' (not so much of for SaaS as we've seen in recent years), and I think it's a shame it's become so shunned in recent years.)
Rewriting the GNU Coreutils in Rust
Posted Jun 12, 2021 8:20 UTC (Sat) by ncm (guest, #165) [Link]
Had Gcc not been copyleft, we would have seen identically the same balkanization in compilers, with each ISA's owner fielding its own proprietary, binary-only Gcc variant.
What we got instead was that to field a new ISA without providing Gcc patches would be instant death. That x86 in the end wiped out all but ARM *anyway* is a whole other story, one that might yet get a new chapter on RISC-V. (I am ready for Risc-6 already, taking RISC-V and walking back its less fortunate choices.)
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 8:36 UTC (Sun) by joib (subscriber, #8541) [Link]
It was a different world back then, and further doesn't prove that the superior development model of Linux rather than the license, or uncertainty due to the lawsuits, was the key factor.
> Had Gcc not been copyleft, we would have seen identically the same balkanization in compilers, with each ISA's owner fielding its own proprietary, binary-only Gcc variant.
> What we got instead was that to field a new ISA without providing Gcc patches would be instant death. That x86 in the end wiped out all but ARM *anyway* is a whole other story,
And today LLVM is roughly on par with GCC, and the feared for balkanization hasn't happened. There are some proprietary forks of LLVM, but largely nobody cares about those. Any architecture that wants to be taken seriously needs to have both GCC and LLVM support.
> (I am ready for Risc-6 already, taking RISC-V and walking back its less fortunate choices.)
As far as ISA's go, I think aarch64 is pretty nice. You just have to go convince ARM to 'open source' it. :)
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 13:13 UTC (Sun) by pizza (subscriber, #46) [Link]
Nobody cares, except, of course, for those who have to actually _use_ those forks.
A few years ago I actually had five different LLVM-based compilers installed onto my $dayjob workstation. Only one had source provided, the rest were proprietary, and as such I was entirely dependent on the vendor to fix bugs and otherwise provide updates that the Distro-supplied one received on a routine basis.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 16:25 UTC (Sun) by ncm (guest, #165) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 22:24 UTC (Sun) by nix (subscriber, #2304) [Link]
Well, also what we got was that ISA vendors tended to fob off the job of producing a compiler on a convenient consultancy that wouldn't compete with them, i.e., Cygnus. These days, well, RH ate Cygnus and IBM ate RH and I'm not sure (even if the toolchain division was still doing that sort of heavy embedded work) that embedded vendors would be as happy that IBM wouldn't compete with them as they were that Cygnus wouldn't.
Rewriting the GNU Coreutils in Rust
Posted Jun 21, 2023 6:19 UTC (Wed) by ceplm (subscriber, #41334) [Link]
I was not thinking about FreeBSD, where it is quite certainly true, but more like a sad death of Plan 9. It seems to me that ESR is (again) wrong in claiming that
>> The long view of history may tell a different story, but in 2003 it looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor.
I think it is not enough acknowledged how much exactly licensing issues and the entry cost damaged Plan 9. With the advent of both FreeBSD and Linux, there was just no reason to bother with the proprietary OS at all. Engineering decisions could cause for Plan9 to be just small community somewhere in the corner in the style of FreeBSD, Haiku, or even Hurd, which could survive and carry on the system to be a good citizen of the 21st century (not of 1980s as it is now), but because of it has been opened only when it was completely dead (April 2002), it never happened, and we have now 10 (according to Wikipedia) forks none of them compelling enough to push other ones to merge.
There is no GPLv3 fiasco
Posted Jun 28, 2021 14:07 UTC (Mon) by immibis (subscriber, #105511) [Link]
Merely not using copyleft licenses is hardly "dedicating substantial resources to its eradication". Industry has never and will never use copyleft licenses except in rare cases where it's to their advantage. Nothing has changed except public opinion of the GPL, and that new opinion has no grounding in reality.There is no "GPLv3 fiasco". What is this "GPLv3 fiasco" you speak of? I have never seen a "fiasco", only a smear campaign, from companies that would like to Tivoize, and from "useful idiots" who repeat and amplify the arguments of those companies.
Industry rejected GPLv3, yes. Industry also rejected GPLv2 until they realized they could Tivoize. Industry likes BSD/MIT because it lets them have what they want and give nothing in return. It's not smart to avoid GPLv3 just because "industry doesn't like it". Them not liking it is kinda the point.
There is no GPLv3 fiasco
Posted Jun 28, 2021 17:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
The fact that there is hardly any successful widely used GPLv3 projects.
There is no GPLv3 fiasco
Posted Jun 28, 2021 18:34 UTC (Mon) by mpr22 (subscriber, #60784) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 23:57 UTC (Wed) by pabs (subscriber, #43278) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 9:17 UTC (Thu) by Wol (subscriber, #4433) [Link]
That's the big worry for me about Fuschia, linux quite specifically implements POSIX, and my experience leads me to believe a lot of the things I don't like about linux are posix-fossilized design decisions. If Fuschia breaks away from that, it could leave linux behind (which is a good thing), but it could leave Linus behind, and that most definitely is a BAD thing.
The point behind Open Source is that "proprietary friction" pushes software writers into collaboration, and linux is successful because of that, not because of copyleft.
But the problem with much software is that the community of users, and the community of developers, is such that the Open Source "friction" doesn't exist. Users can't share development because users don't know how to develop. But copyleft doesn't wrok very well in this scenario, either, because it makes it hard for developers to monetise their work ...
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 10:13 UTC (Thu) by khim (subscriber, #9252) [Link]
> If Fuschia breaks away from that, it could leave linux behind (which is a good thing), but it could leave Linus behind, and that most definitely is a BAD thing.For better or for worse, but that's not in a cards. Fuschia have to run Android apps well and for that it needs POSIX.
Sure, it may try to create a sandboxed “jail” for these apps, but then the outcome would be like with MacOS: everyone would just write apps for that “jail” and “native Fuschia” would be irrelevant.
> The point behind Open Source is that "proprietary friction" pushes software writers into collaboration, and linux is successful because of that, not because of copyleft.Copyleft certainly helped. Lots of stuff in Linux was started as someone's proprietary work and then shared and merged. BSDs are losing such contributions every year (when SONY takes FreeBSD for PlayStation and adds some interesting features to it… what does FreeBSD receives back? nothing, obviously). This made big difference.
But that only worked when copyleft was mild enough for the companies to adopt that software in the first place. When GPLv3 “crossed the pain threshold” companies just stopped using such software so there are no advancements to share back.
> But copyleft doesn't wrok very well in this scenario, either, because it makes it hard for developers to monetise their work ...Indeed. But that's what GPLv3, ultimately, did. GPLv2 was mild enough that companies adopted GPLv2-licensed programs and then developers got some money. This doesn't often happen with GPLv3: companies prefer to adopt technically inferior alternative rather than deal with GPLv3. Developers are observing that and stop developing GPLv3 software. And then there are no copyleft software at all.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 20:33 UTC (Fri) by notriddle (subscriber, #130608) [Link]
Fuchsia isn't POSIX-compliant. <a href="https://fuchsia.dev/fuchsia-src/concepts/system/libc?hl=en">It does not have signals, and it does not support forking</a>.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 9:57 UTC (Thu) by khim (subscriber, #9252) [Link]
More correct phrasing would be: Google is trying to replace Linux. And failing.
Industry is just not interested in that and even Google itself spends more resources advancing Linux than developing it's supposed replacement.
And I suspect this is because of Linus adamant position “Linux is purely about tit-for-tat, we don't want to turn it into weapon of mass opinion”.
Note how easy was it for the industry to arrange replacements for GPLv3 pieces (GCC was replaced with clang, Samba abandoned entirely and instead phones are using MTP which is awful from the user's perspective, but doesn't need to put GPLv3 software in the image and so on), while GPLv2 projects are stubbornly clinging and refusing to die en masse. Although there are some limited success like when BlueZ was kicked out from Android, but smaller things (like FLAC library, e.g.) are still there.
Basically position of the industry WRT GPLv2 was “we would gladly use an alternative with more permissive license if someone else would develop it — but wouldn't spend resources themselves” but GPLv3 causes entirely different reaction “we would's use that software and would develop an alternative if needed”.
This made “free software” position much, much, MUCH weaker.
Rewriting the GNU Coreutils in Rust
Posted Jun 28, 2021 14:14 UTC (Mon) by immibis (subscriber, #105511) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 22:27 UTC (Wed) by IanKelling (subscriber, #89418) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 7:04 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
https://www.gnu.org/software/coreutils/faq/coreutils-faq.... says:
"In 2003 these three packages of fileutils, shellutils, and textutils were combined into the current coreutils package. This greatly simplified the maintenance and management of this project."
which doesn't make it sound ideological at all.
> I think a better summary is that uutils aims to replace GNU coreutils and remove it's copyleft protections.
What evidence do you have to support that claim? Why is the idea that a set of people have decided to write Rust replacements for some tooling and have chosen to use the license prevalent in that community implausible? Or, to reframe the scenario: why has the FSF failed to convince the Rust (and many other) communities that strong copyleft is a core part of free software? The majority of Rust developers I know are strongly anti-corporate, so simply ascribing it to Rust's initial backing doesn't make sense here. What are the FSF's plans for demonstrating the benefits of copyleft, other than berating volunteer developers for not using the FSF's preferred license?
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 16:29 UTC (Wed) by andrewsh (subscriber, #71043) [Link]
This concept document describes why and how we at Apertis came to a conclusion that we’re going to switch to uutils as our coreutils implementation. The work is currently in progress to integrate it into the target images.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 18:41 UTC (Wed) by IanKelling (subscriber, #89418) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 20:22 UTC (Wed) by Wol (subscriber, #4433) [Link]
Not because they are physically or legally blocked from changing it, but because they precisely are USERS, they do not possess the ABILITY to modify and update the source and code.
This is where the Free Software philosophy falls down - all too often the end user cares nothing for the freedoms because they do not have the ability to avail themselves of them.
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 20:50 UTC (Wed) by pizza (subscriber, #46) [Link]
There's a big difference, legally as well as morally, between "not having the skills to do X" vs "actively prevented from doing X by a third party (and usually enforced by the government)"
"Tivoized" refers to the latter only.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:53 UTC (Wed) by khim (subscriber, #9252) [Link]
That's true but in reality anti-tivoization clause takes important features from users (the ability to watch video on Netflix, the ability to play games they like, the ability to work with work documents on their own device and so on) in exchange for the nebulous freedoms which they couldn't use anyway.
Only true “free software” believers may think they can convince “Joe Average” that it's good trade-off.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 22:17 UTC (Wed) by pizza (subscriber, #46) [Link]
Yep, "the industry" is downright user-hostile, seeing them only as eyeballs to monetize.
But speaking personally, if "the industry" wants to do that, they can write their own code instead of using mine.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 0:01 UTC (Thu) by Wol (subscriber, #4433) [Link]
Emphasizing the anti-tivoisation features of GPL3 will simply alienate them. And actually, most Android phones are not, I believe, tivo-ised even though the GPL2 permits it. Yes, it's a bugger to get round the tivoisation feature, but you can. By Design.
Thing is, this really is a feature, not an anti-feature, because it enhances security.
And given the environment I work/think in, much as I like the idea of copyleft, in practice the GPL does not "work as designed". It relies on the concept of "derivative work", and in a world of byte-code, with no concept of linking, there is no *practical* difference between GPL and LGPL.
Cheers,
Wol
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 0:46 UTC (Thu) by pizza (subscriber, #46) [Link]
... so you're saying that folks that don't write software don't get to chose how their software gets used?
When "Joe Average User" gets fed up with getting trampled on, stuff will start changing. As an example of this, farmers are driving the "right to repair" movement.
(Another example -- the entire "maker" community. They're largely about "empowering users" too, only it tends to get expressed in non-software manners)
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 8:09 UTC (Thu) by joib (subscriber, #8541) [Link]
Issues of how people go about their digital lives, and to which extent they are themselves in control of it ("digital sovereignty" if you will) are certainly increasingly important. We have $multibillion corporate empires encouraging and monetizing online bigotry and hatred, influencing democracy in a very negative way, and may even be implicated in genocides (Myanmar). The free software movement could be a powerful public voice in all this. But no, instead it's retreating into the "by and for unix geeks stuck in 1990" world, rendering itself irrelevant.
> As an example of this, farmers are driving the "right to repair" movement.
Indeed; "farmers", "right to repair movement". Where is the free software movement in all this? Sitting far away in a corner lamenting the existence of permissively licensed projects like uutils or LLVM and hoping they fail.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 10:25 UTC (Thu) by pizza (subscriber, #46) [Link]
What, exactly, are they supposed to be doing? Again, they have a shoestring budget and are up against companies who spend more than that every month on office supplies for their PR department. And do you honestly believe governments who think nothing of shooting their own people care what some foreign geeks think?
> Indeed; "farmers", "right to repair movement". Where is the free software movement in all this? Sitting far away in a corner lamenting the existence of permissively licensed projects like uutils or LLVM and hoping they fail.
The Free Software has been there all along, with formal organizations issuing press releases and filing occasional court briefs in support of the farmers. y'know, being an advocate like they've always been, with volunteers writing software to help solve problems they personally care about. That is literally all they can do, write software and be an advocate -- because that's all the legal regime allows -- anything more (such as developing alternatives) requires breaking DRM, which even talking about is enough to expose you to ruinous fines and jail time in most (if not all) developed countries.
The the FSF (and the greater Free Software movement) is not a corporation capable of imposing top-down direction onto a massive army of employees (and another army of lobbyists to bribe politicians) but that's what it's up against.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:24 UTC (Thu) by joib (subscriber, #8541) [Link]
True. It's not an easy or guaranteed win. But if your compare to, say, the abolitionists or suffragettes back in the day, they didn't have any money compared to the moneyed interests they were up against either. But they won, because they had morality and ethics on their side, and were able to leverage that into mass movements that supported their causes. I hope the free software movement could do the same in helping (not saying the free software movement must do this alone!) rein in the excesses of surveillance capitalism. But a narrow focus on copyleft won't achieve that, as most people who aren't software developers won't even understand what they're talking about, much less understand why it would matter and why they should care.
Freedom for people matter. Freedom for software doesn't, per se, except as a means to an end.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 3:19 UTC (Thu) by pabs (subscriber, #43278) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 3:46 UTC (Thu) by pizza (subscriber, #46) [Link]
(See https://www.gnu.org/licenses/rms-why-gplv3.en.html starting with the 6th paragraph )
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 4:24 UTC (Thu) by pabs (subscriber, #43278) [Link]
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/
https://sfconservancy.org/copyleft-compliance/
https://events19.linuxfoundation.org/wp-content/uploads/2...
OTOH, they (and it seems RMS) believe that both the GPLv3 and GPLv2 permit what Tivo did. Some quotes from the PDF:
Ironically, even if Linux were GPLv3, Tivo’s method of crypto-lock-down would likely comply with GPLv3.
bkuhn checked this with RMS: even he agrees this mechanism complies with GPLv3.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 18:43 UTC (Fri) by IanKelling (subscriber, #89418) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 7:03 UTC (Thu) by matthias (subscriber, #94967) [Link]
Yes, it does. But it seems that it does not require that the scripts still work on the device:
> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
No word saying that the scripts still have to work on the distributed device. Maybe it is enough if the scripts work for an empty device prior to software installation. This of course does not help the end user as there is virtually no possibility to get hands on such a device.
Therefore, the GPL3 is more specific in this regard. But still, it seems perfectly ok, if any proprietary software on the device stops working in the moment you exercise your rights to install modified versions of the GPL software, which will render many devices useless.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 1:41 UTC (Fri) by gdt (subscriber, #6284) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 11:47 UTC (Thu) by geert (subscriber, #98403) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 2:34 UTC (Fri) by ncm (guest, #165) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 7:50 UTC (Fri) by geert (subscriber, #98403) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 5:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
It's hard to summon righteous rage when you're talking about how you can't get into a TV HDMI stick ($50 cost) to install your own Linux there. Why bother, when a RaspberryPi costs $30 and comes with helpful manuals and a developer community?
I guess people were worried about tivoization earlier when most people had one multi-$$$ computer.
Rewriting the GNU Coreutils in Rust
Posted Jun 12, 2021 6:35 UTC (Sat) by pabs (subscriber, #43278) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 15, 2021 23:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Tractors are a more interesting case, because their tivoization is actually ALLOWED by the GPLv3. I'm not joking, it only applies to:
> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
And tractors are an interesting case in general, because John Deere is not the only manufacturer. People can buy tractors without any sort of lockdown just fine. However, John Deere's tractors are desirable exactly because they have very helpful software, even though it locks out third-party repairs.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 17:17 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 18:52 UTC (Wed) by jezuch (subscriber, #52988) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 2:00 UTC (Thu) by karkhaz (subscriber, #99844) [Link]
> KLEE found ten unique bugs in COREUTILS (usually memory error crashes). Figure 7 gives the commandlines used to trigger them. The first three errors existed since at least 1992, so should theoretically crash any COREUTILS distribution up to 6.10
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 9:22 UTC (Thu) by helge.bahmann (subscriber, #56804) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 18:09 UTC (Wed) by ccchips (subscriber, #3222) [Link]
berminghamc@Nuc1:~/Rust$ ls -l
total 3316
-rwxrwxr-x 1 berminghamc berminghamc 16696 Jun 9 13:05 hello
-rw-rw-r-- 1 berminghamc berminghamc 114 Jun 8 23:47 Hello.c
-rwxrwxr-x 1 berminghamc berminghamc 3364408 Jun 9 13:05 Hello_Rust
-rw-rw-r-- 1 berminghamc berminghamc 512 Jun 8 21:08 Hello_Rust.rs
berminghamc@Nuc1:~/Rust$
would an actual, properly-vetted C utility have as much space usage in C as in Rust?
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 20:06 UTC (Wed) by ballombe (subscriber, #9523) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 8:33 UTC (Fri) by gspr (subscriber, #91542) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 9:44 UTC (Fri) by farnz (subscriber, #17727) [Link]
There's some talk, but no efforts that I know of - see this blog entry on how Swift achieves dynamic linking when Rust doesn't that explains one route that could be taken to dynamic linking in Rust without losing too much of the Rust benefits.
Ultimately, though, we're at the "needs an innovation" stage - dynamic linking is built around the idea that compilation takes a single independent unit of source and turns it into complete object code with unresolved symbols. Linking then resolves all the symbols to get an executable binary. In that model, dynamic linking is a big win; there's a clear divide between the single units of source and the symbol resolution.
Modern languages (C++, Rust, Swift, Go and others) are not as amenable to this model; units of source code are not independent any more, because the use of generics and vtables both mean that inlining and specialisation of the inlined code is a huge win and thus we want to either have huge units of source (entire programs, say), or we want the link phase to do significant compilation effort, possibly changing the units that it has on disk.
Note that Rust is, in a very technical and useless sense, dynamically linked on Linux; while all the Rust code forms a single object, that object is dynamically linked with the C code it depends on at runtime, including the VDSO and libc. It's just that what we want is to somehow get the shared code between two Rust objects into a Rust shared object that's reused at runtime, and this is a deeply challenging problem to get right, especially in a language that aims to have cheap abstractions like Vec<_> working well.
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 10:22 UTC (Fri) by gspr (subscriber, #91542) [Link]
I agree with the points you bring up, and recognize them as real and significant hurdles. I am not a computer scientist, but it does seem at least plausible to me that, as you suggest, innovation can potentially occur that works around the hurdles.
Regarding your point about Rust dynamically linking to C/other libraries: Yes, absolutely. And this is a huge selling point of Rust for me. I had Rust-Rust dynamic linking in mind though.
Rewriting the GNU Coreutils in Rust
Posted Jun 12, 2021 23:49 UTC (Sat) by khim (subscriber, #9252) [Link]
The biggest problem with dynamic linking IMO is just the fact that people don't bother to create a stable ABIs. Not even with C libraries.
And if you do want to create such an ABI you can as well go and create C ABI for two Rust modules.
This being said it would be interesting to develop some kind of tool to make it possible to load plugins into programs (but then… maybe these should go into separate processes anyway?).
Anyway: ABI stability and dynamic linking should be considered one problem, not two. Because ABI-unstable dynamic libraries create more problems than they solve from my observation.
If you have two versions of boost deeply embedded into two separate libraries then they can work fine, if both link boost dynamically then this become a problem.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 8:21 UTC (Sun) by farnz (subscriber, #17727) [Link]
However, in C-land (which works well with the FORTRAN compile first, then link model), an ABI-unstable dynamic library still appears to work OK; as long as you don't accidentally remove or break an exported symbol, you get the disk space and memory savings of dynamic linking, and you get an apparent ability to rebuild the shared object with newer (bug fixed) code and swap it in for the old version.
There are still two orthogonal reasons for dynamic linking:
- To have code that's used in many binaries exist once on the system, saving disk space and memory via CoW.
- To allow you to replace a shared object with a newer version in order to improve performance and fix bugs present in the older version.
Without an explicitly stable ABI, you can't reliably get #2 - at any time, a surprise ABI change can mean that the two shared objects are no longer equivalent from the perspective of your existing binaries. But you still get #1 - less memory used by running programs because the shared code is all in shared objects that are CoW and read-only.
Getting the first just requires the tooling to support it, and is a matter of coming up with a workable design for doing #1 without compromising on modern features like generics. Getting the second also needs developer buy-in; no amount of tooling helps if you keep a symbol unchanged, but completely alter its semantics. And the first is a requirement for the second; I can't build a stable dynamic link ABI if the tooling won't let me build a dynamic library.
Rewriting the GNU Coreutils in Rust
Posted Jun 13, 2021 9:38 UTC (Sun) by khim (subscriber, #9252) [Link]
If you don't have stable ABIs then savings from COW rarely materialize. Simply because different programs end up with different DSOs anyway.
Sure, if may still get that benefit for OS-supplied programs, but in todays' world where even low-end system gave gigabytes of RAM it's not very important.
And where it is important (embedded, e.g.) you would get bigger savings if you would just combine multiple binaries into one. Bosubox was written in C yet it's usually compiled as one binary anyway.
Thus solving dynamic linking problem without solving ABI stability problem incurs high costs yet doesn't buy you much.
And the fact that you can't solve stability ABI without developer's buy-in makes the issues easier to handle different issues, too.
Think Windows, platform with most third-party plugins implemented as dynamic libraries (Android and iOS have more apps today, but very-very few of them use or support third-party plugins): global variables can not be shared, there are no common libc (thus you need to keep track of different versions of malloc/free) and so on.
Similarly in Rust: if we don't plan to make the ability to build any module as share library the goal then we can significantly simplify that task and from practical POV there would be little difference.
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 20:25 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Maybe? There isn't enough details here to understand what you did
You might want to look at https://github.com/johnthagen/min-sized-rust to be aware of the details that affect binary size
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 21:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
> cyberax@CybMac:/tmp$ rustc -O hello1.rs
> cyberax@CybMac:/tmp$ strip hello1 ; ls -la hello1
> -rwxr-xr-x 1 cyberax wheel 295880 9 июн 14:32 hello1
You can further reduce the size by using dynamic runtime:
> cyberax@CybMac:/tmp$ rustc -C prefer-dynamic -O hello1.rs
> cyberax@CybMac:/tmp$ ls -la hello1
> -rwxr-xr-x 1 cyberax wheel 50184 9 июн 14:29 hello1
In practice, if you are using a multicall binary then it would be BETTER to use the statically linked binary. This way the kernel will only need to cache this one binary and it will load much faster (no linking needed). This is especially helpful for scripts that invoke a lot of utilities.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 2:56 UTC (Thu) by ccchips (subscriber, #3222) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 9, 2021 23:06 UTC (Wed) by rodgerd (guest, #58896) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 2:03 UTC (Thu) by flussence (subscriber, #85566) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 1:07 UTC (Thu) by xinitrc (subscriber, #126452) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 14:06 UTC (Thu) by mw_skieske (guest, #144003) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 4:31 UTC (Thu) by sjj (subscriber, #2020) [Link]
I have nothing against adding new options. Go for it, that’s how gnu won. Some people in these discussions always act like this kind of new thing is something being forced on them. Lighten up, it’s the way of the world.
I would prefer GPL of some version, but those who write the code, get to choose the license.
Also, thanks to the writer, this was nicely done and informative.
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 7:26 UTC (Thu) by areilly (subscriber, #87829) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 10, 2021 9:24 UTC (Thu) by danielthompson (subscriber, #97243) [Link]
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 2:23 UTC (Fri) by sjj (subscriber, #2020) [Link]
The decision to use the MIT License is not without its critics
Posted Jun 10, 2021 12:49 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Sooner or later the "freedom" to brand this and seal it away will be abused by somebody and a Free Software fork will occur to preserve the code and continue developing. Many of those involved will be astonished. How could this entirely predictable event occur? Surely by choosing not to believe in something they can make it disappear, can't they?
Rewriting code in Rust is worthwhile and I've been doing some of that. Replacing GPL'd code with MIT code just saves up pain for later, and I assume that this will be among many "I told you so" stories in the future.
The decision to use the MIT License is not without its critics
Posted Jun 10, 2021 14:04 UTC (Thu) by Wol (subscriber, #4433) [Link]
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 11, 2021 12:25 UTC (Fri) by daniels (subscriber, #16193) [Link]
The decision to use the MIT License is not without its critics
Posted Jun 12, 2021 15:41 UTC (Sat) by flussence (subscriber, #85566) [Link]
XFree86 had them (their website pretends they're the only game in town to this day), anyone who's been a reader here long enough remembers OpenOffice *definitely* had one, and in coreutils' case the FSF has a wannabe BSA Auditor loose on the internet trying to shut down the competition through concern trolling.
The decision to use the MIT License is not without its critics
Posted Jun 12, 2021 15:07 UTC (Sat) by BirAdam (guest, #132170) [Link]
The decision to use the MIT License is not without its critics
Posted Jun 12, 2021 21:06 UTC (Sat) by Wol (subscriber, #4433) [Link]
But the EFFECT of that, seeing as it works with dynamic linking by the user at runtime, and subroutines are all independent modules, is that the GPL, in practice, is little different from Mozilla.
The only thing I would really do that's a bit different, is to stick a notice in the COPYING file that says "by distributing this software you agree that it is maths, a big number, software "per se", and as such that you agree it falls foul of the legal bars to being patentable subject matter".
So basically, anybody who distributes it is blocked from suing anyone else on patent grounds for using it.
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 12, 2021 23:30 UTC (Sat) by khim (subscriber, #9252) [Link]
<p>I don't object to that desire but why not use GPLv3 then? It looks as if you would get all the problems of using GPLv3 without any advantages which is a bit of a strange choice.</p>
The decision to use the MIT License is not without its critics
Posted Jun 13, 2021 22:11 UTC (Sun) by Wol (subscriber, #4433) [Link]
But my version simply says "if you distribute this program, you can't sue the users with patents". It makes no statement as to whether the patents are valid, it doesn't grant any patent licences to anyone, it places (almost) no restrictions on who you can sue with them. It just says "you agree that this object is not patentable subject matter".
And like I said, chances are if I was going down the "patent licence" route, I'd choose the MPL not the GPL, because IN PRACTICE the two would be pretty indistinguishable.
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 13, 2021 22:42 UTC (Sun) by khim (subscriber, #9252) [Link]
> It makes no statement as to whether the patents are validReally? You basically say “software is a math, it couldn't be patented”, ask distributor to agree to that statement (WRT your program only, but what precisely makes it special?) and then expect that anyone who have any patents would just be happy to distribute it?
I don't really understand where such naivety may come from.
> It just says "you agree that this object is not patentable subject matter".Which makes their whole patent portfolio much weaker (if not pointless). Because after they agreed to that they would have to explain what makes your software special and different from all other software. That's not an easy thing to do, especially if you need to convince not patent attorney but layman (which maybe needed in court).
And some think GPLv3 patent grant is too broad.
> And like I said, chances are if I was going down the "patent licence" route, I'd choose the MPL not the GPL, because IN PRACTICE the two would be pretty indistinguishable.True. They both, at least, don't include any funny language which may be interpreted as a declaration to nullify other, unrelated, patents.
The decision to use the MIT License is not without its critics
Posted Jun 14, 2021 8:07 UTC (Mon) by Wol (subscriber, #4433) [Link]
> Really? You basically say “software is a math, it couldn't be patented”, ask distributor to agree to that statement (WRT your program only, but what precisely makes it special?) and then expect that anyone who have any patents would just be happy to distribute it?
It's a special case :-) But basically, I just see it as stating the LEGAL reality that software IS unpatentable. Yes I know there are plenty of people tring to do an end-run round SCOTUS and the EPO treaty, but this would be my little contribution to the battle.
> I don't really understand where such naivety may come from.
Lawyers love arguing things. Judges rule as minimally as they can. Dragging this into a case about different software is quite likely to be thrown out as irrelevant, and if it's a case over this software, well, I doubt anyone would get themselves into a court case over it.
Maybe I just haven't been around big corporate lawyers enough ... :-)
> > And like I said, chances are if I was going down the "patent licence" route, I'd choose the MPL not the GPL, because IN PRACTICE the two would be pretty indistinguishable.
> True. They both, at least, don't include any funny language which may be interpreted as a declaration to nullify other, unrelated, patents.
And, in my case, as copyright licences, as I said they're pretty indistinguishable.
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 14, 2021 9:06 UTC (Mon) by khim (subscriber, #9252) [Link]
> Dragging this into a case about different software is quite likely to be thrown out as irrelevant.How would that be irrelevant? If the company distributes your software and then tries to sue someone… how would that work? You can't simultaneously claim you believe software is just a math and then turn around and try to claim that it's patented. It's bad faith as minimum.
> Maybe I just haven't been around big corporate lawyers enough ... :-)Or read enough news. When Oracle sued Google over Java copyright infringement was nine lines. And while, eventually, billions Oracle tried to get were never awarded… the case went to SCOTUS.
You forget (or misunderstand) what's the work of lawers actually is.
Their work is not to make sure you wouldn't be sued. That's impossible: is US, at least, anyone may sue anyone else for any reason.
Their work is not even to ensure you win. You are correct: there are many defenses which may ensure that court would (after few rounds of appeal) decide in your favor.
Works of lawers is to make court battles cost-effective! Otherwise why would they even get paid in the first place?
And your little stunt is bad as they come: some kind of unique (and very broad) patent statement they have to deal with in court. Sounds convincing to layman (at least to some laymans) and is not obvious why it should be ignored. Better to avoid that if at all possible…
> Lawyers love arguing things.Only when they are paid to do that. In case of licenses they prefer to reuse analysis which was already done. They may not like GPLv3 but they know it. They discussed it with colleagues, they, most likely, already have a guideline and so on.
Your little stunt? They would ask for significant sum before they would be even ready to declare it safe or not safe! And in most companies this sum immediately becomes “price of that software” and often means that you can't use it. It becomes too expensive.
The decision to use the MIT License is not without its critics
Posted Jun 15, 2021 20:31 UTC (Tue) by Wol (subscriber, #4433) [Link]
You forget I'm not an American.
> Their work is not to make sure you wouldn't be sued. That's impossible: is US, at least, anyone may sue anyone else for any reason.
Same here. Difference is, trying to sue your opponent into bankruptcy (popular with deep-pocketed Americans) is likely to end with you suing *yourself* into bankruptcy.
> Their work is not even to ensure you win. You are correct: there are many defenses which may ensure that court would (after few rounds of appeal) decide in your favor.
Or after just one round?
> Works of lawers is to make court battles cost-effective! Otherwise why would they even get paid in the first place?
Well, in America "cost effective" usually means "make the opponent lose worse", even if they are in the right. As I said, that's likely to prove seriously masochistic over here :-)
If I were a software distributor, and had no intention of using software patents offensively, there's a pretty easy defence over here.
If you sue me and claim that this means I agree software patents are invalid so I can't countersue, I promptly move for summary dismissal because you also agree that software patents are invalid, oh and can I also have you pay my court costs because you're suing me with patents you've just admitted are invalid therefore if it's not malicious it's negligent thank you very much.
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 15, 2021 21:25 UTC (Tue) by khim (subscriber, #9252) [Link]
> If you sue me and claim that this means I agree software patents are invalid so I can't countersue, I promptly move for summary dismissal because you also agree that software patents are invalid, oh and can I also have you pay my court costs because you're suing me with patents you've just admitted are invalid therefore if it's not malicious it's negligent thank you very much.I think you have lost the forest for the trees. The distributor of your software agreed that software is a math and lost a chance to use software patents for a countersuit. His opponent haven't agreed to anything. Thus distributor couldn't use patents offensively, but is still under threat of patent lawsuits from others.
So yes, you have just gave the distributor another incentive not to touch your program.
Have you ever looked on any patent battles which were exposed on LWN? Why do you think patent lawsuits are usually settled instead of patents being invalidated? The answer is simple: because it's almost impossible to invalidate a patent! Once it's granted it's considered valid and you would need to, basically, go to the supreme court before you get invalidation will all rounds of appeals.
What happens instead is, usually, countersuit. And the best way to do it is to use your own patents. You don't claim that patent which was used to sue you is invalid. Instead you find some other patent which belongs to someone who you don't think would sue you and show it. Ideally an expired one. And claim that since that patent is also valid your software is not infringing.
Like: patent troll says that his innovation covers all the ways of drawing lines on a computer screen. You find a patent which explains how to draw lines using pixels and say to judge: “yes, plaintiff made great discovery and found a way to draw lines on a screen… that's certainly great and innovative achievement, but certain ways of doing that were known before — and here is patent that proves it”. And that's it.
Judge is happy because s/he doesn't need to pass through 10 layers of appeals, you are happy because you proved that you can draw lines on a screen… and even patent troll is happy because s/he can go and sue some other people because patent used for that is still valid (even if a bit damaged). And if he would agree to stop patent lawsuit and grant you license instead… then it's not even the least bit damaged! Without court decision it's not precedent!
This is the most cost-effective way of dealing with patents. And your “simple” clause makes it much, much harder (if not impossible) to use. Because now distributor have to somehow defend itself without bringing counterpatents to the table.
> Well, in America "cost effective" usually means "make the opponent lose worse", even if they are in the right. As I said, that's likely to prove seriously masochistic over here :-)Maybe, but as long as you have to deal with US (and it's still one of the most lucrative markets) you have to deal with patents. Simply because you declared that software is not patentable doesn't mean patent trolls would agree.
Same here. Difference is, trying to sue your opponent into bankruptcy (popular with deep-pocketed Americans) is likely to end with you suing *yourself* into bankruptcy.Oh, don't worry, that art would come to other parts of the world, surely. It's not even that hard: just sell your patent portfolio to dozen of pure trolls which can be bankrupted safely and see how many rounds of litigation the target firm would sustain.
You don't even need to actually coordinate lawsuits (and be accused of doing shady acts), just sell hundred patents to hundred patent trolls with list of companies which are infringing and make sure your target is there in top10.
The decision to use the MIT License is not without its critics
Posted Jun 16, 2021 8:53 UTC (Wed) by Wol (subscriber, #4433) [Link]
> I think you have lost the forest for the trees. The distributor of your software agreed that software is a math and lost a chance to use software patents for a countersuit. His opponent haven't agreed to anything. Thus distributor couldn't use patents offensively, but is still under threat of patent lawsuits from others.
You seem to be ordering me to give a damn.
Guess what, I DON'T.
> What happens instead is, usually, countersuit. And the best way to do it is to use your own patents. You don't claim that patent which was used to sue you is invalid. Instead you find some other patent which belongs to someone who you don't think would sue you and show it. Ideally an expired one. And claim that since that patent is also valid your software is not infringing.
Which is EXACTLY what I'd do. I'd let *them* claim my patent is invalid "because it's maths".
And because over here, the civil courts are courts of JUSTICE, I'd say to the Judge "please rule that software is maths, pretty please". Bang goes their case. And because we don't have the idiocy of doing ALL the discovery, THEN ALL the arguments, this would probably all be dealt with in summary judgement at the start of the case.
> Maybe, but as long as you have to deal with US (and it's still one of the most lucrative markets) you have to deal with patents. Simply because you declared that software is not patentable doesn't mean patent trolls would agree.
And if I don't give a damn? Plus, how long is it going to be the most lucrative? President Trump did a LOT of damage trade-wise to the US. China is growing rapidly in importance. Europe has been really spooked and will be seriously concerned about standing on its own two feet. India is a big and lucrative market.
America has been isolationist for most of its history. I think it's very soon going to find that Trump's mis-steps are going to haunt it and drive it back into isolation. On a personal level, the less I have to do with the US the better, and I think many Americans would be surprised how widespread that sentiment is. (Individual Americans, on the other hand, are nice. Including a lot of my relatives :-) But that's pretty normal for any country :-)
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 16, 2021 9:51 UTC (Wed) by khim (subscriber, #9252) [Link]
> Which is EXACTLY what I'd do. I'd let *them* claim my patent is invalid "because it's maths".Why would they do that? They would be happy to add slander to your case. Because they still think that patents are valid and now you, too, agreed with that and that explicitly contradicts your previous steps (when you agreed to accept that code falls foul of the legal bars to being patentable subject matter). Court would need to decide what kind of outcome is actually valid (as usual: after years of appeals) but since harm is mounting (distribution software without license is big no-no) then can we have that travesty stopped?
Cease the distribution of that software and then we can continue. And that (preliminary injunction with the decision to stop distribution) may actually happen pretty quickly (few months).
> And because over here, the civil courts are courts of JUSTICE, I'd say to the Judge "please rule that software is maths, pretty please"What law would give judge the right to say that? Courts may be “courts of justice” in the country where you live but they still can not invent rules on the fly, they have to follow law. That's the whole point of separation of power. Judges may think that software is math, it's their right, but as long as it's not part of some law they can not use that for court proceedings. The privilege of turning such beliefs into something you can use in court belongs to legislature branch, not judiciary.
Only high, final, courts in some countries have the right to “bridge the gap” and then, only in rare cases where one needs to “harmonize the law”, anyway.
> Bang goes their case.Lol. I think you have never been in court. Not even as witness. “Bang goes their case” is almost never the case. And when you try to bring facts not explicitly mentioned in any law (as you repeatedly have tried to do in your mental exercises) appeals and repeated hearings may take years.
> And if I don't give a damn?That's your right, of course. But as one of my friends likes to say “why would you pick such an extravagant way of self-mutilation?”
If you want to make sure others wouldn't use and/or distribute your software… you can just write so. No need to elaborate complex schemes which would lead to the same thing in the name of “fight against the software patents”.
> I think it's very soon going to find that Trump's mis-steps are going to haunt it and drive it back into isolation.Possible. This would plunge the Europe into chaos, though, which may render question of software patents moot point because noone discusses software patents in Somali: they have more acute, more pressing, needs.
Do you really plan to release software with the goal of it only be usable after collapse of Western Civilization? That's a bit crazy.
> China is growing rapidly in importance. India is a big and lucrative market.Indeed, China is growing and India may become more important with time, too. But they also fill patents like crazy. Including software ones. Do you really think they are doing this because they plan to continue to believe that software is a math and can not be patented?
Newcomers always try to somehow ignore patents. Incumbents always [try] to use them to protect itself. US was pretty negligent WRT copyrights and patents while it was growing in power. It only started to vigorously assert them when it couldn't grow.
If and when Europe would start failing (and without US backing it's inevitable) — it would double-down on software patents, don't worry. Same with China and India: if China would feel threatened — software patents would ineveitably become valid.
> Individual Americans, on the other hand, are nice.Indeed. But individual Americans like individual Germans, individual Russians or, heck, even individual Iranians, never decide how laws of their country would be shaped. You need a political movement for that, not an obscure line in the license for the obscure software.
The decision to use the MIT License is not without its critics
Posted Jun 16, 2021 8:58 UTC (Wed) by Wol (subscriber, #4433) [Link]
> Oh, don't worry, that art would come to other parts of the world, surely. It's not even that hard: just sell your patent portfolio to dozen of pure trolls which can be bankrupted safely and see how many rounds of litigation the target firm would sustain.
Unless it wouldn't ...
> You don't even need to actually coordinate lawsuits (and be accused of doing shady acts), just sell hundred patents to hundred patent trolls with list of companies which are infringing and make sure your target is there in top10.
And I wouldn't bother suing the patent troll for costs. At the slightest HINT of what you suggest, I'd go for the troll's directors and sue THEM. PERSONALLY.
Yup, it might prove expensive defending the first couple of lawsuits. But I doubt I'd have many trolls willing to put their personal wealth on the line ...
(I think "piercing the veil" with a patent troll company wouldn't be that hard.)
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 16, 2021 10:05 UTC (Wed) by khim (subscriber, #9252) [Link]
> And I wouldn't bother suing the patent troll for costs. At the slightest HINT of what you suggest, I'd go for the troll's directors and sue THEM. PERSONALLY.So you would sue someone who's work is, quite literally, to be sued? Big deal.
The actual guys behind the whole thing would laugh all the way to bank.
> (I think "piercing the veil" with a patent troll company wouldn't be that hard.)Have you ever tried to do this? Sigh. I wish you will read the The Little Golden Calf. Then you would know who Sitz-Chairman Funt is. Actual wikiquote may just be enough:
Sitz-Chairman (зиц-председатель, zits-predsedatel), a strawman chairman. The Horns and Hoofs was headed by Sitz-Chairman Funt. The title is a bilingual Russian-Yiddish pun. The Yiddish word "sitzen" means "to sit", which in Russian connotes "doing time". Also "Sitz" has legal meanings similar to the English "seat". The sole function of a Sitz-Chairman was to do prison time when (not "if"!) the time comes (Compare Sitz-redakteur, a person hired by a 19th century German newspaper for the same purpose).
Note the last phrase. It all was invented in good old Europe and, don't worry, it will be back sooner or later.
The decision to use the MIT License is not without its critics
Posted Jun 14, 2021 17:19 UTC (Mon) by ceplm (subscriber, #41334) [Link]
Well, it doesn't make any sense to me. Why the plus? Either you are against GPL3, and then you want GPL2-only, or you don't care and then you go for GPL3. GPL2+ doesn't make much sense in this day and age.
The decision to use the MIT License is not without its critics
Posted Jun 15, 2021 19:00 UTC (Tue) by nix (subscriber, #2304) [Link]
The decision to use the MIT License is not without its critics
Posted Jun 15, 2021 19:59 UTC (Tue) by Wol (subscriber, #4433) [Link]
That's what I don't like about GPL3, although I understand why they put it in. Although I'm hoping that the Google/Oracle spat has helped clarify the fact that if it's copyrightable it's not patentable ... :-) At present I believe software is unique in that the lawyers would like you to believe it's both?
But GPL3 also has significant bugfixes to GPL2 - bugs that bite badly in an internet era. So GPL2+ suits me fine.
Cheers,
Wol
The decision to use the MIT License is not without its critics
Posted Jun 16, 2021 1:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I don't think the case did that at all. Google won on fair use grounds which is reusable by precisely no one except as a benchmark to compare their reuse against. The patent claims were, IIRC, thrown out early, but kept it on the federal circuit because patent claims automatically go there.
Rewriting the GNU Coreutils in Rust
Posted Jun 23, 2021 12:01 UTC (Wed) by Klavs (guest, #10563) [Link]
I wish it possible/easy to contribute to a project licensed under MIT, or Apache2 - and keep YOUR contribution under the license you wanted (GPLv3 for me - because users freedom matter to me)..
I think the FSF should focus on HOW it could be made possible/easier to manage a project of dual-license.. perhaps "markings" in the project or some form of modularization - to clearly mark licenses?
I REALLY dislike that these few rich, monopoly-seeking, companies get to increase their monopoly by contributing enough (with a permissive license) - to get the whole world walking their way - which means we all suddenly help them keep their monopoly-ish behavior (most unwittingly because they don't care about details such as licenses - which again is sad and evidence of not knowing the history of our societies and how we ended up with all the freedoms they take for granted).
Rewriting the GNU Coreutils in Rust
Posted Jul 28, 2021 8:29 UTC (Wed) by mcortese (guest, #52099) [Link]
Of all the initiatives to enlarge Rust's use base, this is the least interesting, to me.
Small, stand-alone utilities trigger none of the strengths of Rust: use-after-free is not an issue here, fail paths can be ignored, memory safety is not critical... Besides, static linking seems a poor choice for a collection of independent yet correlated executables.
On the other hand, I welcome the effort to renew our venerable tools introducing better ideas, even though this means breaking compatibility with the old syntax. I only wish they also get rid of the classic Unix argument parsing! Does
cat -h invoke the help or print a file named hyphen-h? Of course the former, but only out of convention, not enforced by any syntax rules.
Isn't it funny that a language that explicitly abhorred in-band signaling for e.g. return values, is used to perpetrate in-band option passing?