[flagged]
1. Linux is not a niche in the target market for this project.
2. The project is written in Common Lisp with hard dependencies on SBCL-provided libraries[1], so there's reason to suspect it should work on other OSes supported by SBCL.
3. Sure, the presence of Makefile and sb-posix imply it requires a POSIX compliant OS, but Linux is not the only one that fits the bill.
4. The included Linux-only binary 'oras' is clearly a vendored artifact, not part of this project, and clearly an OCI client. A simple search shows it is indeed cross-platform[2].
Perhaps you should try what almost every Linux user has had to do when encountering software actually built for only one "niche" operating system that they want to use on their OS: look.
1. https://github.com/ocicl/ocicl/blob/170aff0/ocicl.asd#L34
I did look - at the README of the linked site, which clearly states:
> ocicl (...) only works on Linux
I don't see a reason why the author(s) of ocicle should lie to me. (If they do: even worse.)
> Linux is not a niche in the target market for this project.
[citation needed]
That's looking for the wrong thing. Us Linux users see things like that all the time: proprietary software has a download page that only lists Windows (and sometimes macOS) but never Linux.
But we don't stop there. We don't look for a reason to abandon hope (or worse, complain idly). We look for a way to run that software on Linux. And usually, it is a lot harder than this case.
>> ocicl (...) only works on Linux
> I don't see a reason why the author(s) of ocicle should lie to me.
Is it not obvious? They aren't lying. They're being clear. As they go on to say, in the very same sentence: ", but adapting to other systems and platforms should not be difficult."
If you'd looked for a way to run it on your niche operating system, like me, you'd have found an easy way. And, maybe, you could have even contributed the solution to the project, as it says two sentences after where you stopped reading and decided to idly complain in a thread on an unrelated forum.
Just two posts above this one, you claimed that downloading a different ocas binary would probably work. So ocicl does not only work on Linux, right?
I get that you probably just want to win an argument, for the sake of winning an argument, and most likely you're not actually interested in getting some software to run on your niche operating system.
But, just for the far fleeting chance that you are actually interested in doing the right thing:
1. I did not claim that the "oras" binary was the only incompatibility. I guessed your quick judgement was based on that binary being vendored for one platform only and showed that it does exist for other platforms. The latter clearly does not imply the former.
2. Ocicl developers claiming it "only works on Linux" is not a promise they make to you. You cannot hold them at gotcha-gunpoint just in case the software happens to run on a non-Linux OS. They are not interested in playing a game of gotchas with you.
They _are_ being clear: they have only tested it to work on Linux. It is you that misreads it, probably because, I'm guessing, you aren't familiar with the language of OSS READMEs
That might well be the case here. No, I don't try to win arguments on the internet. :-) Thank you.
this thread is evidence to the contrary.
I am not able rightly to apprehend what sort of world-view one has to have to complain that a LISP project runs on an incorrectly-named "niche" operating system in 2023.
(I can't believe I'm saying this, but) even Windows runs Linux now.
> How is this related to my comment?
Your comment indicates your access to computing does not include Linux. That would indeed be a niche area of computing, when intersected with the area targeted by this project, where Linux is commonplace.
Optionally. WSL2 is not (installed and) activated by default.
> intersected with the area targeted by this project, where Linux is commonplace.
I wrote none of my Lisp tools on Linux, and I never received a Linux-related bug report for those. I wonder where I can find numbers on that.
Windows also does not ship with ocicl (by default), but no one's gonna complain about that. If you'd like to install this piece of software on a Windows machine, think of enabling WSL2 as a preparatory step, like how you'd have to install MS Visual Studio / Cygwin to build Windows-only software, or install a DLL to run some Windows-only software.
> I wrote none of my Lisp tools on Linux, and I never received a Linux-related bug report for those.
Congrats. It is absolutely a good thing that you did not have to touch Linux in order to write software that (presumably) runs on Linux. Maybe the other OSes of the world can learn a thing or two about that.
And it is also good that you never received a Linux-related bug report. Presumably, your software runs flawlessly on Linux. Or, more likely, Linux users of your software know how to fix issues that may pop up and move on.
However, your limited experience of the world does not have to accurately portray how the world actually is.
> I wonder where I can find numbers on that.
The most popular implementation of CL is SBCL (ref: State of Common Lisp Survey 2020). SBCL is primarily developed and tested on Linux, and its largest industrial users also run it on Linux servers (same goes for ECL, Allegro, and LispWorks). This I know from being a (passive) participant in the CL community. I'm not sure I can get you numbers on this, but I can get you numbers that show SBCL receives bug reports for Windows far more than it does for Linux, despite Windows being one of the least tested or prioritised platform, so I'm not sure your method of judging a platform's importance is very good.