Ubuntu 25.10 plans to swap GNU coreutils for Rust Efforts are afoot to replace the GNU coreutils with Rust ones in the version after next of Ubuntu, 25.10 – which also means changing the software license. The next version of Ubuntu, 25.04 "Plucky Puffin," isn't here yet – but a significant change is taking shape for the release after that, which will be 25.10. That is when …
I think you might want to read up on how the project to port started.
Many of these tools are indeed battle-tested but that doesn't mean they're invulnerable and, more importantly, easy to maintain. Along with many modern languages, it's fairly easy to write tests for Rust and this is one of the reasons, along with language design, why there are generally fewer critical bugs in them. By the end of the project I'd expect the Rust version to have significantly better test coverage than the original.
Except I didn't make the claim that Rust was invulnerable. I was highlighting the idea that "battle-tested" isn't always enough, as we've seen with things like OpenSSL.
Rust has, however, seen increasing adoption across multiple domains because it solves real-world problems that people were having. As for maintenance: that was the idea at the start of the project.
It's not "invulnerable" and NOBODY would claim it is. But it eliminates a lot of vulnerabilities caused by C regarding buffer overflows, double frees etc. It's still entirely possible to write logic which is broken in any language, and no one has said any different. As for maintainability, I suggest the people tasked with maintaining coreutils may feel it's held together with string at this point and NEEDS a rewrite. In which case, why not use a language which reduces the attack surface and scope for bugs.
And politics of course never reflects the real world or feedback loops with it . . .
Tech Bros certainly have discarded copyleft, but many of their projects are themselves discardable and already showing not to stand the test of time. Meanwhile, for example, who uses OpenOffice anymore? If anyone uses a free office suite it's the fork LibreOffice which very deliberately relicensed copyleft for reasons you could absolutely decribe as political—but if you dismiss them out of hand on those grounds you'll be missing the very practical and historically-informed reasons behind that political move. And those reasons are ones that remain worth considering for any new project (or fork of a project) today.
I prefer OpenOffice: it's more stable and looks less like a toy. BTW. The Document Foundation appropriated EU funding for features that were supposed to benefit both projects, but then "forgot" to pass the code back upstream.
Others might prefer SoftMaker or OnlyOffice: it's good to have a choice.
This post has been deleted by its author
> no-one cares one way or another about licences, and couldn't tell you the difference between them. It only appears to be very small group of folks for whom they're important.
Such as your company's lawyers - and your coder friends after they've been sacked for not learning a basic part of the professional job and exposed their company to unwanted legal issues. Even if all that was needed was to put attribution into the About box, not caring enough to learn when that is necessary is - not a good look.
Assuming the coders you know are actually working joes, that is.
Commons are frightening to capitalist businesses…
As I said, politics. Stallman should be commended for the software he developed and for the debates he started, but he also should be criticised for trying to turn software licensing into a political movement. It's our software and we'll choose the licenc we want, noting en passant that as well as being "copyleft" the GPL is also a copyright grab.
but he also should be criticised for trying to turn software licensing into a political movement.. Nope, it was always about FREEDOM with him. Suggest you watch videos from Eben Moglen to better understand it.
the GPL is also a copyright grab. Again... nope! GPL is about using the copyright system to maintain freedom.
And exactly what freedom is that?
GPL doesn't actually guarantee freedom in the way you may mean it.
Some might say that there are moral obligations that one should really stick to, and many do distribute code in ways that makes source far more available than they're actually obliged to provide. But GPL3 really doesn't obliged one to do very much by way of onward distribution. It's still the old only to recipients, only if they ask within 3 years and on whatever machine readable media is reasonable at the time (which probably still includes floppy disks, just) or a network server that doesn't have to be publicly accessible.
However, "moral obligations" are subjective. Law is the rules under which society is governed. By and large common law prohibits most behaviours that most people find morally unacceptable. By definition, everything else is permitted. It is not reasonable to imply that someone is doing something wrong to oneself (e.g. claiming that one's freedom is being infringed) simply because they're not doing something, when there is no clause in a license nor law of the land that says they should do that thing. At some point of escalation, such unfounded claims end up amounting to harassment, which really is illegal!
"GPL is about using the copyright system to maintain freedom".
In Stallman's case it's more like using copyright theft to start a side hustle. He stole the code for GNU Emacs from James Gosling and a couple of other guys who had been working on it. Stallman stripped their license headers and claimed it for his own.
I regrettably hosted Stallman in my home almost thirty years ago when he was in the UK and his previous accommodation arrangement fell through. He was an ungrateful bastard and an utter creep around women when my local Linux user group took him out for dinner.
I've only met him personally once, but have heard similar reports from others who've met him, including at a conference in Brazil where he refused to pay for anything himself. Mind you, sexual predators seem to have been the thing in California in 1970s – Eric Raymond is more eloquent and entertaining but also a complete creep around women.
Missing invisible social cues and daring to ask women out on dates (and then respecting their wishes if they say no) --> you're a sexual predator!
Esr isn't into freedom (he's into convenience and faster development no matter the consequences; http://catb.org/~esr/open-source.html), but I have seen no evidence that implies he is a sexual predator.
Interesting that El Reg will publish such kind of libelous comments, but refuses to publish some of my carefully researched ones.
>using copyright theft to start a side hustle.
Making a copy of software doesn't steal anything, as not a single bit of the original has change.
When copyright is infringed, that is legally regarded as copyright infringement, not theft (as it isn't theft).
>He stole the code for GNU Emacs from James Gosling and a couple of other guys who had been working on it. Stallman stripped their license headers and claimed it for his own.
Complete libel.
James Gosling and a couple of other other guys were working on a C Emacs implementation (derived from and inspired by a previous version of Emacs that rms and others worked on) and part of the agreement was that the other developers could distribute their own version under whatever terms they liked if they wanted to.
Gosling later proceeded to betray the other developers and humanity by selling his copyright and a copy of the software it to Unipress, who proceeded to offer it as proprietary software (stealing freedom from humanity).
Before or after this betrayal, one of the developers sent rms a copy of his version and rms continued development, making many improvements and crafting it into GNU Emacs (he didn't call it "Gosling Emacs" as per the agreement).
After a while, Unipress realized that GNU Emacs was superior to their version of Emacs and started legally threatening rms for daring to distribute software that respected the users freedom that was also functionally better.
rms asked the developer that shared the software to him for the email that granted him such permission (to send to Unipress), but unfortunately he couldn't find it, as it was on a backup tape somewhere.
Although at that stage, almost all of it had been rewritten, thus he spent a day replacing the little that remained from the original and Unipress no longer had anything to claim copyright on.
>He was an ungrateful bastard and an utter creep around women when my local Linux user group took him out for dinner.
Considering you lied previously, I doubt this is the truth.
Assuming it occurred at all, I suspect him and his software was insulted multiple times and shockingly he wasn't "grateful" to receive such insults.
How dare he ask women out on dates (it's impossible for them to say no).
There is the GPLv1, GPLv2, GPLv3, LGPLv2, LGPLv2.1, LGPLv3, AGPLv1, AGPLv2 & AGPLv3 - although none of those licenses assign copyright to the FSF as the other poster pointed out.
The FSF usually only accepts copyright assignments for GNU packages and even then the assignment is carefully crafted, only granting the FSF permission to relicense to benefit free software (they have no permission to relicese to a proprietary one) and permission to do anything is assigned back to the submitter at the end (so not a copyright grab either).
The choice of licence rightly belongs to the developer. If a developer wishes to make the code available to you then you have the code irrespective of whether it's GPL2, GPL3, MIT or BSD. If you wish to make changes to it there's nothing in any of those licences which obliges you to send them back to the original developer. The first two oblige you to make the changes available under the same terms to anyone to whom you supply a binary but those recipients are still not obliged to supply them to the original developer. The main difference is that the latter two tell you the developer doesn't care about that.
In fact it can be quite problematic to install a .deb from a Ubuntu environment in Debian or compile from source because of fussing about library versions.
Indeed so.
There's been a lot of talk about RedHat's behaviour w.r.t. Linux source. There is an opportunity to weaponise the GPL against them. RedHat can only have access to the source code, if someone distributes it or a binary to them. If everyone conspired to ensure that the Linux kernel project source code was not accessible to RedHat IP addresses, and no one sends them a binary either, they're cut off from the upstream (even though some of the code in the upstream is code RedHat may well have written).
I doubt that such a boycott could be made totally solid, but if it were RedHat would start diverging from Linux, but that would be the way to discourage RedHat-like behaviour.
BSD 2-clause;
"Redistribution and ***use*** in source and binary forms, with or without modification, are permitted ***provided that the following conditions are met***:
GPLv3;
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance."
Every single time (even if they could have easily written something better themselves - but it saves a buck), some business just takes it and makes it proprietary software (half the time they don't even follow the attribution requirement of the licenses, as nothing has ever happened to a business that didn't follow a weak license from an individual), resulting in the software being proprietary (and not even source-available) for most of its users.
All GNU licenses are commercial - any business is very welcome to commercially use, or commercially sell software under the GPLv3-or-later, or AGPLv3-or-later or GPLv2-or-later or LGPLv3-or-later etc - the copyleft ones just don't grant the power to take the users freedom by making the software proprietary.
By the same lieu that a programmer deserves to be rewarded for writing a useful program, they deserve to be punished for writing harmful software - for example proprietary software, or if they choose to release software under a weak license, with the knowledge that its primary use case will be to assist taking the freedom of millions or billions of people (most weakly licensed software doesn't fall into this category, but some does).
Er, Ubuntu is an ancient African word, meaning "I can't configure Debian" Urban Dictionary.
Or, An African phrase meaning "humanity towards others"
Or, If possible, "Use Devuan"?
Exactly.
Until the law mandates end user access to Source Code, strong, "not sharing is stealing" licences like the GPL are a necessary defence for developers against the caging-up of code.
Although weak, "sharing is not stealing" licences may seem "more free", we should be wary of affording anyone the "freedom" to do something we have a good reason to prefer not to do, lest we fall victim to a variant of Karl Popper's Paradox of Tolerance. There is nothing wrong with a law against "unthinkable" behaviour. In the best case, it doesn't make you any less free because you weren't going to do it anyway; and in the worst case, it may prevent someone else from making you less free.
Got to be slightly careful with requesting law mandates end user access to source code. One certainly would not want to see a statute on the books that compelled someone to share source code on their own servers in perpetuity (for that would be insane). It would be more pragmatic to require one-time sharing to a "respected open server", obligation discharged on upload to it. There'd be a ton of work to do to define what an acceptable open server is; law is unlikely to name specific services.
One of the things I find interesting is how projects like FreeBSD with its license has remained more or less un-abused by all and sundry. Sure, companies have exploited it for their own ends, but that's fine because the license says "go right ahead". What I mean is that there's no fork (compatible or deliberately incompatible) that's stomping on FreeBSD's turf, stealing away its developers / users. Does the "weakness" of the license (as some may see it) become a kinda strength? Everyone could walk off with the code and build a commercial empire with the aim of exterminating the FreeBSD project, so no one does?
A 17% failure rate strikes me as being much too high for something being proposed as a replacement for a key part of the operating system. Especially as Rust is promoted as something that reduces errors, by design. I'm going to give credit for providing the option to enable / disable it, rather than forcing it on people, but I just can't see the point of ditching robust battle hardened software for the sake of wanting to use today's trend-of-the-week.
This isn't about rewriting the code for the sake of the "trend-of-the-week"; its about rewriting the code in a more robust and maintainable form that can't suffer from some of the classes of bug that the GNU utils have suffered from in the past. In the process many of the tools are also getting faster.
You're correct that 17% test failure rate is not acceptable as a final state, but it's a little ridiculous to say that incomplete feature compatibility of a work in progress somehow reflects badly on the language because "Rust is promoted as something that reduces errors, by design". There's a big difference between failing a test for edge case settings on command line parameter parsing and having a use-after-free memory error. If you go look at the issue tracker you'll find the open items are in the former category. Canonical are not looking to make this change today and if you look at their test tracker [*] you'll see that they've been making steady progress. As the article rightly points out, the increased scrutiny from a widely used distro switching to them is only likely to speed up the fixing.
[*] https://uutils.github.io/coreutils/docs/test_coverage.html
“There's a big difference between failing a test for edge case settings on command line parameter parsing and having a use-after-free memory error”
Is there? Because from where I sit, the first is *orders of magnitude* worse than a simple use-after-free memory error.
The vast, vast *vast* majority of command-line stuff being executed, is sitting there in bash scripts. Mostly legacy, often decades old, and almost always undocumented. So now you’re telling me that across the world, bash scripts which no living human understands, are going to “sometimes” do something “slightly different” than what they did before? And they often have admin-level access, and operate on things like file permissions.
Slow hand-clap. Badly done, sir, badly done. *This* is exactly the sort of crap I was warning about. Rust people are *obsessed* with just one single type of bug, and completely miss the wood for the trees.
There seems to be a little cognitive dissonance in your reply. Your response to my suggesting that there is a big difference between two classes of bug is to first ask "Is there?" but then go on to say that one is "orders of magnitude worse" than the other, suggesting that there is.
The comment to which I was replying said "A 17% failure rate strikes me as being much too high ... Especially as Rust is promoted as something that reduces errors, by design." My point was that what's causing these tests to fail has little to do with the errors that Rust reduces by design. As I said, a 17% test failure rate in the functional compatibility testing is not acceptable as a final state, for precisely the reasons that you state. That's why the project explicitly treats any incompatibility as a bug and is diligently tracking its progress towards removing them all.
I'm unsure how you read into my reply some suggest that it's acceptable for core tools to behave slightly differently, especially when I just stated that it's not acceptable, but your final snark perhaps gives a clue. Many of the comments one reads about Rust seem to be obsessed with the idea that Rust programmers are obsessed with memory bugs to the exclusion of all else. I'm not a habitual Rust programmer, but I know many, and for the most part their goals (obsessions if you want) are around reliability, maintainability, portability and reusability, and they happen to find Rust a good tool for that particular job. The source code to GNU utils is just as arcane as the shell scripts that you mention. A rewrite whose explicit goal is 100% compatibility while being more portable and maintainable, and as it happens immune from certain classes of bug, seems like a worthwhile cause.
Most tests will presumably test a great many things so the failure rate is likely way below 17%. On the other hand, Unix core utilities are almost certainly used by millions of user shell scripts. Shell scripts tend not to be terribly flexible when it comes to dealing with even minor changes in input and output rules/conventions including stuff like spacing, character sets, and capitalization that probably wouldn't bother human users much. The tests that are being used best reflect the need for strict compliance with existing conventions or there will likely be problems for users.
I wonder how much of that test suite was written retrospectively to cover bugs as they were found in the current utils. I imagine quite a lot as the utils were around for a long time before TDD became a widely established practice. This will skew the coverage to the sorts of things that go wrong in a C language implementation and do nothing for the things that might go wrong in a Rust implementation.
The "big rewrite in the sky" never went well for me anytime in my 40+ year association with software development... Maybe it will be different for these guys. Tests help a lot. The right tests help even more.
That largely depends what the tests are failing on. Most likely because a lot of the tests are going to be running options which perhaps aren't implemented yet or on the critical path, That certainly seems to be the case, looking at some test results which are mostly just missing or stub argument support - https://github.com/orgs/uutils/projects/1/views/1?pane=issue&itemId=3865405&issue=uutils%7Ccoreutils%7C1872
I bet if you were to run busybox over the coreutils tests you'd also get a bunch of similar failures for similar reasons.
Because it’s “just not American! ….errr sorry…GNU!”
I long-since tired of the GNU religion. It’s not that I object to someone licensing their code as GPL - software authors can use whatever license they like and it’s not my business to tell them otherwise.
But I intensely hate the “…BUT IT’S NOT GPL!!! - HERETIC!!! NON-BELIEVER!!! STONE HIM!!!!” attitude that seems to go along with it far too often.
The GPL and the Jesus culture that surrounds it is a pain in the arse and as far as I’m concerned the more non-GPL software the better.
And as a note to all those Jesus-loving GNU people that will vote this down, I’m not saying this because I like the idea of BIG TECH stealing code and not contributing. I have written quite a bit of free stuff in my time that I’m happy to be used by anyone (not under a GNU licence, of course. In fact most of it has no license at all). But go ahead - vote-down the non-believer!!! Better still - BURN HIM!!!!
For someone who tries to point out an apparent cult like behavior in people who care about FOSS, your incoherent babbling looks suspiciously close to a conspiracy theorist rant.
And if you think putting your code online with no license at all is anything more than wasted bandwidth then you only show you are too ignorant to participate in this discission.
I never said anything about putting my code online.
As for your point, I refer you to DJB’s experience (ref http://cr.yp.to). He has published lots of code online for years and it has been used by literally millions of people and businesses. Probably the most well-known is qmail. He eventually (after many years) put a license on it. But he only did that because he got fed up of people complaining it didn’t have one even though he said it was free to use. Not having a license never stopped anyone using it though (except those that needed to tick a box)
So your baseless assumption that software MUST have a license to be useful is demonstrably and unsurprisingly nonsense.
The problem with not using any license at all for something any larger than trivial is that it begs someone to slap a copyright on your code, and then hit you with a copyright infringement, which you then have to fight through the courts.
Even if you can prove that the code was prior-art when the the copyright was registered, you still need to defend the claim, and this can cost LOTS of money.
This has happened to people publishing their own music on social media, particularly YouTube with their obnoxious take down claims, so don't think that it can't happen to your code.
I always include a copyright notice.
But I don’t see a need for a license. Licenses are what company lawyers fret about. Jo in the street couldn’t give a monkey’s most of the time (unless it’s GPL and all that entails - which brings us back to the point I made that GPL is a pain).
If the copyright holder of a piece of code doesn't license that code, anyone using it is legally indistinguishable from a software "pirate". The copyright holder would be within their rights to sue unlicensed users for copyright infringement. Even if actual damages are zilch, statutory damages can be extracted if the copyright holder registers their copyright with the USCO prior to or within three months of its publication. That's $750-$30,000 per case of infringement.
Naturally, you'll want to talk to an actual lawyer about becoming a copyright troll, I'm just regurgitating 17 U.S.C. § 504 and 17 U.S.C. § 412 at you. Oh, and 17 U.S.C. § 505 means that the winner can request the court award attorney's fees and costs. Jo in the street might start giving a monkey something if they were individually targeted with a lawsuit like this.
It's not freely available though.
You said you put a Copyright notice on it. If it has a Copyright notice, then without the express permission of the Copyright holder, it is illegal to produce a copy - that's the literal definition of Copyright. A License is an agreement which, amongst other things, grants people the right to make copies under some circumstances. The only time this doesn't apply is if works have been committed to the Public Domain, but Public Domain works don't have Copyright. And this is a broad enough description that it applies to any country with Copyright laws.
Note that a License could be as simple as "The author gives you permission to use this for whatever." People like the standard open source licenses because the give certainity, as much as is possible, but there's no reason why other, more simple, Licenses can't be used.
One can't make someone put a license on their copyrighted code, just because they've put it in a publicly accessible place.
If a third party sees it, thinks "That looks handy, we want to use it", then that's cause to contact the copyright holder and enquire as to what licensing terms might be granted. I suggest that the copy made in viewing it probably counts as "fair use", if its on a publicly accessible server.
> One can't make someone put a license on their copyrighted code, just because they've put it in a publicly accessible place.
Very true. The problem is that Rich 2 is repeatedly saying *here* that he wants people to be free to do what they want with his code but he also states that he is explicitly *not* saying that in the code itself. Which just sems rather contrary.
> that's cause to contact the copyright holder and enquire as to what licensing terms might be granted
That can also happen, very true. But you also expect to see the author making that offer first, so it would probably have to be an exceptional circumstance where anyone would consider trying to make that contact. If they even have usable contact details.
> probably counts as "fair use"
Careful, that is not a universally accepted term (really, it is just a US concept and definitely has no meaning in the UK).
Let's not forget that the normal way of utilising someone else's copyright material is as I've suggested, 1) obtain a copy and like it, 2) approach the copyright holder and negotiate if possible. That's what one does with books, films, music, the whole lot; none of that comes with a license. And - generally speaking - if the copyright holder does not enforce their ownership through actions, the copyright tends to lapse anyway. Ultimately, what one can do is to record efforts to contact the copyright holder making offers to negotiate a license and the subsequent lack of reply, then exploit the material. If the material were obviously freely available (e.g. it's on some website with identifiable contact details) and one had lodged attempts to negotiate, that's a great defence should the copyright holder later wake up and get lawyered up. Certainly, no reasonable judge is going to criticise the user of the material or impose penalties on them; the emphasis is on the copyright holder taking action.
This is why you get pubs that are holding a Harry Potter themed quiz night get letters from lawyers requiring them to seek permission, and why permission for such cases is almost certainly granted f.o.c. The copyright is preserved by having taken action.
It's only really in the OSS world where material is released pre-licensed, and that rather distorts people's views of what the whole picture is.
> But I don’t see a need for a license. Licenses are what company lawyers fret about.
So your intent is to release code and prevent companies from using it? And also to prevent anyone who doesn't mind companies using their code from making any use of your code? And possibly any post-grad work that is intended to be published and shared. Definitely not anything that anybody hopes to spin-off from academic work (obviously, as that goes straight into the "company" category).
But without having to bother actually, you know, writing that out explicitly, just leaving a trap for the unwary.
An interesting approach.
Still, at least you avoided the trap of saying that you had released your code into "Public Domain" :-) It gets bothersome having to point out that PD is not a worldwide concept.
As has already been pointed out to you, by placing a copyright notice on your code you have explicitly stated that nobody is free to use your code (bar for satirical purposes and other "fair use" cases - in those jurisdictions that provide for "fair use", which is not universal).
Having done that, the *only* way you can allow anybody to legally use your code is to give it a licence. Al of the cases I mentioned (and others) are simply those situations where the putative code user has to be deen to be acting in accordance with the law.
You have commented here in a way that makes it clear you have deliberately created this situation - and yet you then declare that wishing to be law abiding is some "artificial constraint". One can only pray that you do not hold a professional position, as that attitude could be very career limiting if you apply it at work as carelessly as you do for your code.
"But I intensely hate the “…BUT IT’S NOT GPL!!! - HERETIC!!! NON-BELIEVER!!! STONE HIM!!!!” attitude that seems to go along with it far too often."
You are more than welcome to stick with your microsoft produced garbage, we won't miss you one little bit. Oh and BTW we are not to fond of assholes like you who do nothing but criticize the people trying to make a difference in this world.
Why would switching to a more permissive license be an issue?
Because Ubuntu's plan is presumably to add features and fix bugs and then refuse to make the source code for those fixes/additions available. It's a strategy to make compatibility between distros more difficult to maintain and to lock users into Ubuntu so they can't move to RH because RH won't have the fixes/features in coreutils that customers depend on. It's a pretty standard business practice.
So, alpine moving from coreutils to busybox is a non issue, license wise.
The OG author of busybox is working on "toybox" , an analogue set of utilities, but BSD licensed.
I am surprised that cannonical jumped on the bandwagon BEFORE redhat, as a MIT lisenced set of coreutils would be a boon to their efforts of curtailing theclone makers by restricting code sharing.
"So, alpine moving from coreutils to busybox is a non issue, license wise."
eh? Alpine uses Busybox *by default* with coreutils available to be additionally installed if desired. So what's/where's this Alpine move from Coreutils to Busybox you're referring to?
"The OG author of busybox is working on "toybox" , an analogue set of utilities, but BSD licensed."
I'm not sure what "OG author" means here (specifically the "OG" part").
It seems you are referring to Rob Landley who was the Busybox *maintainer* (not author as Busybox has had many authors, of which he was one) for a while before he started Toybox.
The original author of Busybox was Bruce Perens back in the 1990s.
Well that's going to massively bloat the development environments of anyone that builds coreutils.
I have one open source project in Rust which I use, it's under 24,000 lines of Rust code, yet it needs 1GB in .cargo and produces 1.2GB of intermediate files, which is obscene.
I recommend any distro based on Ubuntu (like Mint) move to Debian to avoid this nonsense.
Storage is emphatically *not* essentially free. I really don't know where this pernicious lie comes from, but it absolutely is not the case.
The cost per megabyte may very well be at an all time low - it may not cost you that much to buy a large capacity drive (though they're definitely not free) - but that doesn't take into account having somewhere to put it!
Most laptops have physical space for 1 hard drive. Once that drive is full you have to remove it (if you even can), spend money on a larger replacement (which had better be an SSD, since modern bloated OSes are hideously painful on spinning rust - at which point you're into three figures) and spend time transferring everything across.
Even my desktop PCs each have an SSD boot drive, a spinning-rust storage drive and neither the physical space nor the spare power connectors and drive bays for more.
External drives are a partial solution, but a relatively fragile one with compromises speedwise, and also not "essentially free" for the kinds of capacities that can cope with software like Vivado, or the trend towards everything being containerised. NAS boxes are a more robust solution, but again *definitely* not free.
I disagree, while you may think storage is essentially free, I'm aware of certain Linux projects and embedded systems that load the entire OS, including drivers and applications into RAM disc and operate with no hard disc in 1GByte of RAM so rust is a massive disadvantage if it produces binaries significantly larger than the C equivalent. As I understand it while there are some size optimisations you just can't achieve the tiny sizes of a C binary.
Unfortunately just that one thing puts me right off Rust being used in the Linux kernel.
I do care about licensing (I'm a pragmatists and use the Nvidia driver, but I wouldn't want my core system being non-free).
But I don't -- I simply don't have an issue with the MIT license.
As for porting these tools to Rust -- really, I've used Rust and it's got pretty similar syntax to C, if it had additions making code refuse to compile if it doesn't follow some memory safety rules. I don't view this port as a bad thing. They may even find parts where 'well we had to rewrite this like so to suit Rust', the same change can be made to rhe C coreutils to make that part immune to some memory safety issue.
Re: Bloody Rust... I didn't see that post initially. I must admit to not too closely at how many resources Rust was hoovering down while building the couple times I used it. Agreed a 1.2GB intermediate file for a 24lk line program is pretty obscene.
I think the latency--time between pressing the key and a program recieving a character--was greater with a USB keyboard. Since it makes no difference when playing Nethack or Dwarf Fortress, never mind.
I find it an interesting question whether a non-GNU licensed version of GNU core utilities would eventually become a closed-source proprietary component of Ubuntu Linux. I don't have any insight into Ubuntu's roadmap, but even if I did, the management can change or the company be sold.
It's been a few years since I experimented with Rust. Back then it did not have a shared library runtime. If that's still the case, each command in Rust core utilities might load hundreds of thousands of extra bytes. The resulting slowdown may be difficult to measure with micro-benchmarks; however, the large executable sizes might thrash both disk and CPU caches.
As I said, "because they were the new thing", not because their keyboards had broken and they needed a replacement.
Are you telling me that the rush on USB keyboards was because all these ps/2 keyboards decided to break at the same time? Or maybe, a huge number of the community were so anti-ps/2 they'd just been using their computer with a joystick until USB keyboards came out?
You obviously weren't around at the time. They were bragging about getting them for no reason other than they were the new USB.
I was around at the time, as I am 50+ now.
What I saw at my neck of the woods was people using the USB advent to replace crap PS/2 foam keyboards and Crap membrane PS2 keyboards with less crap membrane keyboards, using the USB part as an excuse to justify the switch. Doubly so if the Crap foam/membrane keyboard used an AT->PS/2 adapter.
Ditto, people with decent PS/2 foam/membrane keyboards with "ergonomic" USB keyboards.
Also, people sick and tired of decent PS/2 Keyboards with no-windows-key carrying over from build to build (again, doubly so if said keyboard used an AT->PS/2 adapter) using the USB advent as the justification to get a keyboard with the Win Key.
Also, people that wanted "special keys" (say, media keys), getting USB keyboards to justify getting them.
Even if, after the purchase, they had to use the newflanged USB keyboard for a while using the USB->PS/2 dongle that was included with all USB Keyboards at the time...
What I saw was USB used as an excuse/way to get/justify* something else that was desirable, not a means unto itself.
*Justify to yourself, justify to your parents, justify to your significant other, or justify to the accounting/IT/Purcharses department...
> that can not be changed after the fact..
I still use PS/2 keyboards every day, and have spares for when these go phut. With a tiny little USB converter on the plug.
A PS/2 to USB converter is - and always has been - way, way cheaper than getting a new keyboard of decent quality, the sort of thing that might be considered in need of future-proofing.
I have transcended mere programming these days (I've promoted to places where I do less harm), but I was once heavily involved with C, and I'm currently taking an interest in Rust. What strikes me is that although memory-safety is certainly the Big Thing promoted by rustaceans, Rust has strong opinions about other things, too. There's a powerful macro system, a different approach to object-oriented development compared to C++, enums and exception handling may not match your experience elsewhere. If you are ahead of me you could probably add a half a dozen other aspects.
If you are a C developer trying to learn Rust thinking you only have to learn about memory management stuff, you're in for a world of pain. You've got to keep your mind open to lots of "different ways of doing things".
For the benefit of reflex commenters, I'm not passing judgement on whether Rust has made the "right" decisions compared to Your Preferred Language. I'm just saying it's not *just* about memory management.
In my opinion, if you use a GPL source code and rewrite it in another programming language, you must maintain the same license with the same credits, otherwise you will be committing plagiarism.
In the same way, using proprietary source code and rewriting it is illegal.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
