Maintainer of the Alpine package referenced here. It's called `glibc`, makes no claims on Alpine Linux and certainly isn't a Linux distribution. You install the package in Alpine Linux, nothing else.
Most people's experience with alpin is through containers. Given you provide `alpine-glibc` containers is likely where the confusion comes from. If you don't know the backstory one would easily assume this is an Alpine endorsed container.
I don't provide "alpine-glibc" Docker images or containers, so I don't really know what you're referencing here. I maintain an Alpine package called `glibc`. Please enlighten me!
Maintainer of the Alpine package referenced here. The same name for what? The package name is `glibc`. I think you're confusing/conflating the source control repository's name with the package when they are different things.
Maintainer of the Alpine package you referenced here. I'm not a "them". ;)
I don't see where "Alpine" is used in the package name, unless you're referring to the source repository name. In case it isn't clear, `alpine-pkg-` is a prefix which denotes that the repository contains an Alpine Linux package manifest and configuration. There's nothing in the repo itself which states that this package is published and/or endorsed by Alpine Linux.
Yes, there's several of them. The problem isn't your package, but the distribution of "alpine" images that integrate the package. Those images should describe themselves more appropriately.
Maintainer of the Alpine glibc package referenced here. For some background context, this package was originally created to solve a specific problem long before Alpine provided glibc compatibility packages like `libc6-compat` and others. I agree that this package shouldn't be considered "blessed" or an official Alpine package or a default solution for running programs originally compiled against the GNU C library on Alpine Linux, far from it. The source control repository uses `alpine-pkg-` as a prefix to denote what it's used for—not as a means of assumed official status or such like.
What I find saddening is to see passive aggressive statements like
> I have additionally suggested that the TSC may wish to have the Alpine Council reach out to the alpine-glibc project to find a solution which appropriately communicates that the project is not supported in any way by Alpine.
To the Alpine Linux TSC: please get in contact with me about any and all disclaimers you want to add to this package! I'd love to have these discussions faster and in the open, rather than discovering this disquiet tangentially. Let's get these issues resolved as soon as possible in a way that everyone concerned finds acceptable.
We did not communicate with Sasha because bluntly, we have no objection to the existence of this package itself, but rather third parties distributing the combination to others without disclosing the many caveats about it.
Sasha's package is not the problem, it is the third-party distributors who distribute the final result as an "alpine" image, which leads people to believe that everything is legit about it.
j/w: What use cases do you have or have in mind for your glibc package? Do you see it as a temporary step for adding pre-built things to Alpine images during development, before you have time to rebuild them against musl? Do you feel some prod use cases are ‘safe enough’?
Or nowadays do you generally prefer the upstream compatibility packages you mentioned?
I don't compile my own software against glibc and run it in Alpine. As mentioned previously, this package was created ~ 6 years ago to run software compiled against glibc (that didn't have the source code available) in Alpine Linux. I don't recommend that anyone uses it over the equivalent Alpine package or compiling your software against musl-c.
I did, and understand your frustration with my comment (I've been in a similar startup before and I empathize with the denial). Here are a few pointers to help as a litmus test, that I wish I had back then:
- How many self serve customers have built a business on top of your platform? (this is where good documentation helps)
- Is your leadership excessively concerned about the branding and how the company comes across, or do they actually talk to customers and developers?
- Have the founders raised excessive capital relative to business maturity?
- Is there cultish behaviour, where bad decisions are not questioned? how vulnerable is the broader leadership?
- Where do engineers spend their time? Making cool stuff or building towards clear customer outcomes?
As I said, genuinely friendly comment. I really hope I am wrong, but sharing as someone who has gone through something similar who was triggered after I saw this.
I do try and make sure that HsQML works on Windows and MacOS in addition to Linux. Although, I admit I haven't tried MacOS 10.9 as my Mac is still running 10.8.
I don't think I've ever been contacted concerning issues with Windows or MacOS, which is probably indictative of the size of the user base combined with probability of any one person deciding to go to the effort. On the other hand, I have fixed genuine build failures for Linux users because the platform is diverse enough that it "worked on my system" but not theirs.
In any case, my contact details are on the HsQML Hackage page. If you'd like to send me the error message you're seeing, I'd be happy to try and help you get it working.
Get in touch with the developers and work with them to get it building. Often times they don't have access to your platform, so just being that helps. Anything you can do on top of that is gravy.
I wasn't making any point. Fwiw, I have been able to meet my own (quite limited) gui needs in Haskell with gtk...
Edit: On reflection, I find your assertion a little strange here. Anecdotal failure to build on one particular setup doesn't seem like a particular highlighting of bad bindings.
I can add another anecdote. In almost 10 years now of using Haskell on Mac, Linux and Windows, I've never once had any success building any GUI binding for Mac OS, despite trying every one I could find (gtkhs included) at least once a year on many different OS/hardware combinations.
(unless you count HOC, but I never actually got it working as-was - I brought it back from bit-rot on a couple occasions, adding ObjC 2 support and rewriting a fair chunk of the low-level stuff, but never did find the time to update the fragile header-parsing stuff for the actual Cocoa-binding generator)
Huh. It is sounding like there's an issue with Mac GUIs, then. Maybe the Mac/Haskell overlap is just too small? Both are small-to-niche... It would probably make sense to get a group oriented around getting that fixed up. For myself, I'm meeting my needs - and both 1) more GUI apps and 2) more Mac support are almost entirely orthogonal to them, so I'm not likely to participate.
> Maybe the Mac/Haskell overlap is just too small?
Probably so. Though I would suggest that the neither one is a small niche in itself. Mac especially--it's the favored platform for every developer I know except one. Yes, it's less popular outside tech circles (probably due in part to the price).
Imagine this scenario: There are tons of Mac users who want to learn Haskell. They try it, but can't install libraries. The Haskell community never hears from them; one could say the system failed silently. Meanwhile, Linux works fine, and the Haskell-Linux community keeps growing.
So perhaps there's a self-reinforcing Linux-centric bias in the developer population.
I wouldn't at all say either is "a small niche." As niches go, they're both pretty large... I actually have no idea how the prevalence of Mac differs inside and outside tech circles. It's a decided minority in every case, with Windows still dominant and likely Linux still dominated (though I'm far less confident about that in dev circles than I used to be). For what it's worth, virtually every developer I know well enough to know what they prefer uses either Linux or Windows, with the exception of my mother who decided some few years back that Mac is "Unix enough" now. I expect that there's a lot of clustering, though, and neither of our experience represents a uniform sampling.
Your general point - that it's likely self-reinforcing - is certainly strong. I'd even expect it to be exacerbated a bit in this case by it being GUI things in particular showing issues, where (at the risk of stereotyping) there is probably a correlation between those who prefer a Mac and those who prefer a GUI.
> virtually every developer I know well enough to know what they prefer uses either Linux or Windows
Interesting. It must be clustered, as you say.
I use a Mac largely because there are a handful of professional apps that don't run on Linux. (Otherwise, I'd probably go with Mac hardware and a Linux OS.) Which implies that the demands of my industry is what pushed me (and perhaps the people I know) onto Macs.
> there is probably a correlation between those who prefer a Mac and those who prefer a GUI.
It's not so much that I personally prefer a GUI. (I don't, in general.) It's that I make a lot of software for other people, so GUIs aren't a matter of preference but of professional obligation. Also, there are certain applications I'd like to do where a GUI is pretty much the only sensible option: Design tools, certain types of games, etc.
Sometimes I do. Often, if a Haskell package doesn't have a Github repo, I don't know how to contact the developers or submit a bug report. Is there a standard place on Hackage or in ghc-pkg where one can find that info?
"Is there a standard place on Hackage or in ghc-pkg where one can find that info?"
Both! It's in the ghc-pkg dump output, though there's doubtless a better way at getting at that. As for Hackage, if you just pare the above link back to https://hackage.haskell.org/package/hsqml you'll find package meta-info which includes:
Author Robin KAY
Maintainer [email protected]
Home page http://www.gekkou.co.uk/software/hsqml/
Source repository head: darcs get http://hub.darcs.net/komadori/HsQML/
I'll try installing QML on mavericks tomorrow and debugging it. Feel free to list anymore that failed to compile for you and I'll try to do the same for those.
What you are seeing/referencing is the output of commands during earlier runlevels; the X server won't start until runlevel 5 (number selected off the top of my head). That said, it'd be good to give users of mainstream Linux distributions like Ubuntu the option to suppress output from the boot scripts.
> That said, it'd be good to give users of mainstream Linux distributions like Ubuntu the option to suppress output from the boot scripts.
Haven't major distros been doing this for years? I only see the output if I press escape, and pressing escape again suppresses it. Otherwise I just see a progress bar/animation.
I don't think that the runlevel numbers are sequential. You can switch between levels (and that corresponds to more or less services running) but you pretty much boot directly to runlevel 5.
Within a runlevel, services are ordered, though (either by an arbitrary integer or by dependency).
