> Introducing Rust is impossible for some platforms and hard for
others.
Please could someone elaborate on this.
Please could someone elaborate on this.
Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
I don’t maintain any tools as popular as git or you’d know me by name, but darned if I’m going to put in more than about 2 minutes per year supporting non-Unix.
(This said as someone who was once paid to improve Ansible’s AIX support for an employer. Life’s too short to do that nonsense for free.)
To me it looks like big corps enjoying the idea of having free service so they can avoid maintaining their own stuff, and trying the "too big to fail" fiddle on open source maintainers, with little effect.
It's not like older versions of git won't work perfectly fine. Git has great backwards compatibility. And if there is a break, seems like a good opportunity for them to fork and fix the break.
And lets be perfectly clear. These are very often systems built on top of a mountain of open source software. These companies will even have custom patched tools like gcc that they aren't willing to upstream because some manager decided they couldn't just give away the code they paid an engineer to write. I may feel bad for the situation it puts the engineers in, I feel absolutely no remorse for the companies because their greed put them in these situations in the first place.
Oh no, if only these massive companies that print money could do something as unthinkable as pay for a support contract!
Seriously, I guess they just have to live without git if they're not willing to take on support for its tool chain. Nobody cares about NonStop but the very small number of people who use it... who are, by the way, very well capable of paying for it.
If that is due to the build environment deviating from the standard, then I agree with you. However, when its due to the codebase deviating from the standard, then why blame the build environment developers for expecting codebases to adhere to standards. That's the whole point of standards.
According to git docs they seem to try to make a best effort to stick to POSIX but without any strong guarantees, which this change seems to be entirely in line with: https://github.com/git/git/blob/master/Documentation/CodingG...
If your codebase used to conform to a standard and the build environment relies on that standard, and now the your codebase doesn't anymore, then its not the build environment that deviates from the standard, its the codebase that brakes it.
Because they don’t. For instance, if they were fully POSIX compliant, they’d probably already have LLVM.
It's probably not straightforward but the users of NonStop hardware have a lot of money so I'm sure they could find a way.
That's fine. The only impact is that they won't be able to use the latest and greatest release of Git.
Once those platforms work on their support for Rust they will be able to jump back to the latest and greatest.
But no doubt it's a great way for the big companies funding Rust development to undermine smaller players...
Your comment is needlessly dramatic. The only hypothetical impact this has is that whoever uses these platforms won't have upgrades until they do something about it, and the latest and greatest releases will only run if the companies behind these platforms invests in their maintenance.
This is not a good enough reason to prevent the whole world from benefiting from better tooling. This is not a lowest common denominator thing. Those platforms went out of their way to lag in interpretability, and this is the natural consequence of these decisions.
In any case HPE may have 60k employees but they're still working to create a smaller platform.
It actually demonstrates the point I was making. If a company with 60k employees can't keep up then what chance do startups and smaller companies have?
They build on open source infrastructure like LLVM, which a smaller company will probably be doing anyway.
RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
GCC simply supports more platforms.
Linux systems: Any library is system library because otherwise there will be no real OS libraries or API.
Rust: No ABI. = No (real) shared libraries.
Debian: https://www.debian.org/releases/trixie/release-notes/issues....
Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@!
I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier.
I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C.
Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.
Also you are incorrect - because you are already making wrong assumption:
> crates are not libraries
"never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable.
Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up.
You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer.
SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer.
Rust fails spectacularly at last point unless library uses C headers.
But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon.
When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code.
Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism)
Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman.
Then you have people that think slow development and no revolutionary changes should be IT priority in modern times.
Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way.
And then you have contrarians.
[1] https://doc.rust-lang.org/beta/rustc/platform-support.html
https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
Platform support needs to be maintained. There is no way around that. Any change in the codebase has the possibility of introducing subtle platform-specific bugs. When platform support means that some teenager a decade ago got it to compile during the summer holiday and upstreamed her patches, that's not worth a lot. Proper platform support means having people actively contributing to the codebase, regularly running test suites, and making sure that the project stays functional on that platform.
On top of this, it's important to remember that platform support isn't free either. Those platform-specific patches and workarounds can and will hold back development for all the other platforms. And if a platform doesn't have a maintainer willing to contribute to keeping those up-to-date, it probably also doesn't have a developer who's doing the basic testing and bug fixing, so its support is broken anyways.
In the end, is it really such a big deal to scrap support for something which is already broken and unlikely to ever be fixed? At a certain point you're just lying to yourself about the platform being supported - isn't it better to accept reality and formally deprecate it?
In theory I agree with you, and code written in a platform-agnostic way is definitely something we should strive for, but in practice: can keeping broken code around really be called "good engineering culture"?
This might make a much more interesting case for GOT than before https://www.gameoftrees.org/
they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces)
then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
> I like programming
> I program to make money
If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like
“You have to vet all open source code that runs on the computer.”
So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.”
I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him.
You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see?
It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.