6 ms·

There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefor

There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/ https://lwn.net/Articles/998115/

MangoToupe 1y ago
How is this git's concern?
- StopDisinfo910 1y ago
  They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
  - MangoToupe 1y ago
    I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
    - StopDisinfo910 1y ago
      I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
- kazinator 1y ago
  Git's main concern should, of course, be getting Rust in, in some shape or form.
antihero 1y ago
Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
- akerl_ 1y ago
  Isn’t that’s what’s happening? The post says they’re moving forward.
- kstrauser 1y ago
  Yes. It benefits them to have ubiquitous tools supported on their system. The vendors should put in the work to make that possible. 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.)
  - lloydatkinson 1y ago
    As you're someone very familiar with Ansible, what are your thoughts on it in regards to IBM's imminent complete absorption of RedHat? I can't imagine Ansible, or any other RedHat product, doing well with that.
    - kstrauser 1y ago
      I wouldn’t say I’m very familiar. I don’t use it extensively anymore, and not at all at work. But in general, I can’t imagine a way in which IBM’s own corporate culture could contribute positively to any FOSS projects if they removed the RedHat veneer. Not saying it’s impossible, just that my imagination is more limited than the idea requires.
      - halffullbrain 1y ago
        IBM has been, and still is, a big contributor to a bunch of Eclipse projects, as their own tools build on those. The people there were both really skilled, friendly and professional. Different divisions and departments can have huge cultural differences and priorities, obviously, but “IBM” doesn’t automatically mean bad for OSS projects.
Hizonner 1y ago
Sucks to be that platform? 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.
- kstrauser 1y ago
  I strongly agree. I read some of the counter arguments, like this will make it too hard for NonStop devs to use git, and maybe make them not use it at all. Those don’t resonate with me at all. So what? What value does them using git provide to the git developers? I couldn’t care less if NonStop devs can use my own software at all. And since they’re exclusively at giant, well-financed corporations, they can crack open that wallet and pay someone to do the hard work if it means than much to them.
  - milch 1y ago
    "You have to backport security fixes for your own tiny platform because your build environment doesn't support our codebase or make your build environment support our codebase" seems like a 100% reasonable stance to me
    - kstrauser 1y ago
      I’m sold.
    - 1718627440 1y ago
      > your build environment doesn't support our codebase 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.
      - milch 1y ago
        Is there a standard that all software must be developed in ANSI C that I missed, or something? The git developers are saying - we want to use Rust because we think it will save us development effort. NonStop people are saying we can't run this on our platform. It seems to me someone at git made the calculus: the amount that NonStop is contributing is less than what we save going to Rust. Unless NonStop has a support contract with git developers that they would be violating, it seems to me the NonStop people want to have their cake and eat it too. 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/CodingGuidelines https://github.com/git/git/blob/master/Documentation/CodingG...
formerly_proven 1y ago
Nonstop is still supported? :o
maximilianburke 1y ago
Maybe they can resurrect the C backend for LLVM and run that through their proprietary compilers? 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.
- zozbot234 1y ago
  Rust has an experimental C backend of its own as part of rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr . Would probably work better than trying to transpile C from general LLVM IR.
  - hedgehog 1y ago
    Some people have demonstrated portability using the WASM target, translating that to C89 via w2c2, and then compiling _that_ for the final target.
- steveklabnik 1y ago
  Given that the maintainer previously said they had tried to pay to get GCC and LLVM ported multiple times, all of which failed, money doesn’t seem to have helped.
  - jen20 1y ago
    Surely the question is how much they tried to pay? Clearly the answer is "not enough".
  - maximilianburke 1y ago
    I mean at one point I had LLVM targeting Xbox 360, PS3, and Wii so I'm sure it's possible, it just needs some imagination and elbow grease :)
ksynwa 1y ago
Won't someome think of the financial sector
- mcny 1y ago
  Reminds me of a conversation about TLS and how a certain bank wanted to insert a backdoor into all of TLS for their convenience.
saghm 1y ago
At this point maybe it's time to let them solve the problem they've created for themselves by insisting on a closed C compiler in 2025.
- deleted 1y ago
  [deleted]
- kazinator 1y ago
  [flagged]
  - sunshowers 1y ago
    Weighted by user count for a developer tool like Git, Rust is a more portable language than the combination of C and bash currently in use.
  - saghm 1y ago
    >> insisting on a closed C compiler in 2025. > Everything should use one compiler, one run-time and one package manager. If you think that calling out closed C compilers is somehow an argument for a single toolchain for all things, I doubt there's anything I can do to help educate you about why this isn't the case. If you do understand and are choosing to purposely misinterpret what I said, there are a lot of much stronger arguments you could make to support your point than that. Even ignoring all of that, there's a much larger point that you've kind of glossed over here by: > The shitheads who insist on using alternative compilers and platforms don't deserve tools There's frequently discussion around the the expectations between open source project maintainers and users, and in the same way that users are under no obligation to provide compensation for projects they use, projects don't have any obligations to provide support indefinitely for any arbitrary set of circumstances, even if they happen to for a while. Maintainers sometimes will make decisions weighing tradeoffs between supporting a minority of users or making a technical change they feel will help them maintain the project better in the long-term differently than the users will. It's totally valid to criticize those decisions on technical grounds, but it's worth recognizing that these types of choices are inevitable, and there's nothing specific about C or Rust that will change that in the long run. Even with a single programming language within a single platform, the choice of what features to implement or not implement could make or break whether a tool works for someone's specific use case. At the end of the day, there's a finite amount of work people spend on a given project, and there needs to be a decision about what to spend it on.
motorest 1y ago
> There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. 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.
- jlarocco 1y ago
  It's sad to see people be so nonchalant about potentially killing off smaller platforms like this. As more barriers to entry are added, competition is going to decrease, and the software ecosystem is going to keep getting worse. First you need a lib C, now you need lib C and Rust, ... But no doubt it's a great way for the big companies funding Rust development to undermine smaller players...
  - motorest 1y ago
    > It's sad to see people be so nonchalant about potentially killing off smaller platforms like this. 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.
  - detaro 1y ago
    It's kind of funny to see f-ing HPE with 60k employees somehow being labeled as the poor underdog that should be supported by the open-source community for free and can't be expected to take care of software running on their premium hardware for banks etc by themselves.
    - jlarocco 1y ago
      I think you misread my comment because I didn't say anything like that. 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?
pxc 1y ago
Why should free software projects bend over backwards to support obscure proprietary platforms? Sounds absurd to me
jrpelkonen 1y ago
I am curious, does anyone know what is the use case that mandates the use of git on NonStop? Do people actually commit code from this platform? Seems wild.

MangoToupe 1y ago

How is this git's concern?

StopDisinfo910 1y ago
They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
- MangoToupe 1y ago
  I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
  - StopDisinfo910 1y ago
    I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
kazinator 1y ago
Git's main concern should, of course, be getting Rust in, in some shape or form.

antihero 1y ago

Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs

akerl_ 1y ago
Isn’t that’s what’s happening? The post says they’re moving forward.
kstrauser 1y ago
Yes. It benefits them to have ubiquitous tools supported on their system. The vendors should put in the work to make that possible. 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.)
- lloydatkinson 1y ago
  As you're someone very familiar with Ansible, what are your thoughts on it in regards to IBM's imminent complete absorption of RedHat? I can't imagine Ansible, or any other RedHat product, doing well with that.
  - kstrauser 1y ago
    I wouldn’t say I’m very familiar. I don’t use it extensively anymore, and not at all at work. But in general, I can’t imagine a way in which IBM’s own corporate culture could contribute positively to any FOSS projects if they removed the RedHat veneer. Not saying it’s impossible, just that my imagination is more limited than the idea requires.
    - halffullbrain 1y ago
      IBM has been, and still is, a big contributor to a bunch of Eclipse projects, as their own tools build on those. The people there were both really skilled, friendly and professional. Different divisions and departments can have huge cultural differences and priorities, obviously, but “IBM” doesn’t automatically mean bad for OSS projects.

Hizonner 1y ago

Sucks to be that platform? 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.

kstrauser 1y ago
I strongly agree. I read some of the counter arguments, like this will make it too hard for NonStop devs to use git, and maybe make them not use it at all. Those don’t resonate with me at all. So what? What value does them using git provide to the git developers? I couldn’t care less if NonStop devs can use my own software at all. And since they’re exclusively at giant, well-financed corporations, they can crack open that wallet and pay someone to do the hard work if it means than much to them.
- milch 1y ago
  "You have to backport security fixes for your own tiny platform because your build environment doesn't support our codebase or make your build environment support our codebase" seems like a 100% reasonable stance to me
  - kstrauser 1y ago
    I’m sold.
  - 1718627440 1y ago
    > your build environment doesn't support our codebase 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.
    - milch 1y ago
      Is there a standard that all software must be developed in ANSI C that I missed, or something? The git developers are saying - we want to use Rust because we think it will save us development effort. NonStop people are saying we can't run this on our platform. It seems to me someone at git made the calculus: the amount that NonStop is contributing is less than what we save going to Rust. Unless NonStop has a support contract with git developers that they would be violating, it seems to me the NonStop people want to have their cake and eat it too. 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/CodingGuidelines https://github.com/git/git/blob/master/Documentation/CodingG...

formerly_proven 1y ago

Nonstop is still supported? :o

maximilianburke 1y ago

Maybe they can resurrect the C backend for LLVM and run that through their proprietary compilers? 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.

zozbot234 1y ago
Rust has an experimental C backend of its own as part of rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr . Would probably work better than trying to transpile C from general LLVM IR.
- hedgehog 1y ago
  Some people have demonstrated portability using the WASM target, translating that to C89 via w2c2, and then compiling _that_ for the final target.
steveklabnik 1y ago
Given that the maintainer previously said they had tried to pay to get GCC and LLVM ported multiple times, all of which failed, money doesn’t seem to have helped.
- jen20 1y ago
  Surely the question is how much they tried to pay? Clearly the answer is "not enough".
- maximilianburke 1y ago
  I mean at one point I had LLVM targeting Xbox 360, PS3, and Wii so I'm sure it's possible, it just needs some imagination and elbow grease :)

ksynwa 1y ago

Won't someome think of the financial sector

mcny 1y ago
Reminds me of a conversation about TLS and how a certain bank wanted to insert a backdoor into all of TLS for their convenience.

saghm 1y ago

At this point maybe it's time to let them solve the problem they've created for themselves by insisting on a closed C compiler in 2025.

deleted 1y ago
[deleted]
kazinator 1y ago
[flagged]
- sunshowers 1y ago
  Weighted by user count for a developer tool like Git, Rust is a more portable language than the combination of C and bash currently in use.
- saghm 1y ago
  >> insisting on a closed C compiler in 2025. > Everything should use one compiler, one run-time and one package manager. If you think that calling out closed C compilers is somehow an argument for a single toolchain for all things, I doubt there's anything I can do to help educate you about why this isn't the case. If you do understand and are choosing to purposely misinterpret what I said, there are a lot of much stronger arguments you could make to support your point than that. Even ignoring all of that, there's a much larger point that you've kind of glossed over here by: > The shitheads who insist on using alternative compilers and platforms don't deserve tools There's frequently discussion around the the expectations between open source project maintainers and users, and in the same way that users are under no obligation to provide compensation for projects they use, projects don't have any obligations to provide support indefinitely for any arbitrary set of circumstances, even if they happen to for a while. Maintainers sometimes will make decisions weighing tradeoffs between supporting a minority of users or making a technical change they feel will help them maintain the project better in the long-term differently than the users will. It's totally valid to criticize those decisions on technical grounds, but it's worth recognizing that these types of choices are inevitable, and there's nothing specific about C or Rust that will change that in the long run. Even with a single programming language within a single platform, the choice of what features to implement or not implement could make or break whether a tool works for someone's specific use case. At the end of the day, there's a finite amount of work people spend on a given project, and there needs to be a decision about what to spend it on.

motorest 1y ago

> There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. 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.

jlarocco 1y ago
It's sad to see people be so nonchalant about potentially killing off smaller platforms like this. As more barriers to entry are added, competition is going to decrease, and the software ecosystem is going to keep getting worse. First you need a lib C, now you need lib C and Rust, ... But no doubt it's a great way for the big companies funding Rust development to undermine smaller players...
- motorest 1y ago
  > It's sad to see people be so nonchalant about potentially killing off smaller platforms like this. 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.
- detaro 1y ago
  It's kind of funny to see f-ing HPE with 60k employees somehow being labeled as the poor underdog that should be supported by the open-source community for free and can't be expected to take care of software running on their premium hardware for banks etc by themselves.
  - jlarocco 1y ago
    I think you misread my comment because I didn't say anything like that. 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?

pxc 1y ago

Why should free software projects bend over backwards to support obscure proprietary platforms? Sounds absurd to me

jrpelkonen 1y ago

I am curious, does anyone know what is the use case that mandates the use of git on NonStop? Do people actually commit code from this platform? Seems wild.