software is too hard to compile
this is bad for the ecosystem of software and also culture as a whole
this might sound like a weird claim if you've a) never tried to pull a large software project off a website and build it from scratch, or b) do that all the time. but
it's a problem because it kind of undermines the concept of open source in a pretty basic way. for a lot of software, grabbing the thing and making it do what you want involves an indefinite amount of overcomplicated bullshit as you try to install the right versions of a bunch of dependencies you've never heard of and decipher output from an idiosyncratic build system. you can't just get in there and experiment
which pushes people away from contributing, especially if they have skillsets outside core programmer stuff
i think typically most projects don't see this as an issue, because nobody on the team has a problem with it, and if it gets brought up there are always historical reasons for why it's this way, and it's not THAT complicated, just follow the instructions dumbass,
@aeonofdiscord tbh I see this kind of "blindness to the perspective of the newbie" as both very difficult to avoid, but also a red flag if the project leadership clearly doesn't even make a basic effort.
@technomancy yeah def, i think this is such a widespread problem that it's not even anyone's fault as such. like there are clearly bigger factors causing this (bad tooling, for one)
@technomancy you can work around it and provide a good new-user experience out of the box but it takes effort and in most cases i don't think people see a compelling case for it
@aeonofdiscord there are so many examples of these cases where the experience for the newbie is just unbearably tedious in ways that it's literally nearly impossible for the project maintainers to even comprehend, because there are so many things that they just take for granted because they've been doing it so long they don't even realize they're doing it any more.
@technomancy @aeonofdiscord maybe we should normalize blowing away your development environment every few months and recreating it from scratch by carefully following your own project documentation lol
@HunterZ @technomancy unironically endorse this
@HunterZ @technomancy actually i think companies should do this for internal software as well to cut down on onboarding bullshit

@aeonofdiscord @technomancy having just gone through a weeks-long onboarding process for a new project (most of which just went out the window due to funding shifts lmao) I heartily agree.

On a previous project, I got things to the point where you just clone a build repo via git and invoke CMake in a standard way, and it clones the rest of the codebase for you and pulls down the dependencies from Artifactory via Conan. That's pretty much my ideal.

@HunterZ @technomancy @aeonofdiscord Not sure if it's a joke, but tools like Chaos Monkey kind of do that and it looks like the companies that use it have pretty reliably working services, especially given how complex they are.

I've also see Drew DeVault recommend something similar for testing backups. Pull the plug on a machine and see if the crew can restore it.

@HunterZ At work we actually do that, because we create a new build environment for every release branch (otherwise switching branches can corrupt the caches in IntelliJ — bad reason, I know (well, cache invalidation is hard), but good side-effect ☺ ). @technomancy @aeonofdiscord

@HunterZ @technomancy @aeonofdiscord I have to do this when writing docs and tutorials (my main work things ATM) to make sure I get dependences listed correctly, and can be surprisingly hard to work out exactly which bits of toolchain from my 'has everything installed so stuff just builds' workstation is actually required in some cases.

A freshly installed Raspberry Pi 4 (if your software is buildable on ARM) is extremely useful to see what the dependency hell situation looks like IRL.

@HauntedOwlbear @HunterZ @technomancy yeah, i've used VMs for this as well
@HunterZ On second thought: Do you mean I should re-create my Emacs setup every few months? 😱 — my documentation is not yet up for that … @technomancy @aeonofdiscord
@ArneBab @technomancy @aeonofdiscord yes, if that's a requirement for being able to develop in your codebase(s). I would recommend trying to be IDE/editor agnostic though, because different people prefer different IDEs.

@HunterZ @ArneBab @technomancy @aeonofdiscord

It's amazing how useless / out of date most build sections of a readme are. For projects that have continuous deployment they should just point you to their build YAML file. They have to keep that up to date or their tests fall apart.

@alexjgriffith @ArneBab @technomancy @aeonofdiscord yeah it seems like in a just world, CI/CD build solutions ought to support building for development and manual test too.
@HunterZ CI/CD does a lot more stuff than what you need for development. @alexjgriffith @technomancy @aeonofdiscord
@ArneBab @alexjgriffith @technomancy @aeonofdiscord right. The point is that if you already have a CI/CD solution that automates setting up a build environment as part of its process, then there's little excuse for making developers do those same things manually in order to be able to build the same codebase.
@HunterZ It would be great if the CI would just execute what’s needed for development. What I find strange is how often README’s do not say how to call maven or gradle (what’s the actual "build be" argument?) @alexjgriffith @technomancy @aeonofdiscord
@ArneBab @HunterZ @aeonofdiscord from a fresh checkout of your dotfiles repo, why not?
@aeonofdiscord what's wrong with closed-source s/w? -- one has to study it with reverse-engineering tools, very slowly, and modifying it becomes a PITA
open-source s/w does deny the four freedoms almost as well, just by other means

@aeonofdiscord That was one reason why in the Freenet project we switched to gradle *with the wrapper*: That’s annoying, but it is easy to build as a newcomer if you already run Freenet (because then you already have Java): git clone https://github.com/freenet/fred && cd fred && ./gradlew jar

I wish gradle did not enable that by sidestepping your whole distribution, but by working with it (i.e. on guix it could create a local environment, if docker is available, use that, …), but it works.

GitHub - freenet/fred: Freenet REference Daemon

Freenet REference Daemon. Contribute to freenet/fred development by creating an account on GitHub.

GitHub

@aeonofdiscord That said: GNU autotools fixes that with ./configure && make && make install

but it lacks dependency-support.

@aeonofdiscord it's one of the primary mechanisms by which software development is gatekept today. when a compile fucks up and it's not obvious why you are on the receiving end of person-centuries of the sneering elitism of computer programmers who hate their users and want to be the priesthood through which all software is accessed.
@aeonofdiscord this has become a big sore spot for me as well. I shouldn't have to manually download/build libraries/dependencies to be able to then build your stuff. If you have dependencies then they need to be easily installable via a non-obscure package manager, or pulled in as git submodules, or something else that doesn't have a learning curve.
@aeonofdiscord I want every project’s readme (or similar) to have a “requires/you will need” section that lists all the dependencies. Compiler/language and build system, to start.

@a @aeonofdiscord The hard part is keeping it up to date. At several jobs I've made that one of my duties. I try to watch for PRs that break the onboarding, blow away my setup and try to follow the Readme.

I suspect it doesn't make me very popular with my teams :) But it's the sort of janitorial duty I think senior engineers should take charge of. What are you without a sense of ownership?

@aeonofdiscord Well build recipes in most distros/ports should be there for you, like I don't really need to care about how much of a hell it is to configure firefox or chromium buildsystem.
And of course it manages the dependencies.
@lanodan @aeonofdiscord Yeah but sometimes you can't rely on those, like if you're working with software that isn't packaged
@lanodan @aeonofdiscord though i should admit that many of my frustrating experiences compiling software have been packaged software, and it never occurred to me to reference the build recipes for advice
@Yujiri @aeonofdiscord Well then either you can cheat with looking at a recipe or even picking it up as-is from another distro or filling a packaging request.

And sometimes something is packaged almost nowhere, which can be a bit of a red flag.
@aeonofdiscord and open source api's seem to fluctuate a lot.
for instance, there is realistically no good solid libraries for graphics in linux (unless you want to do everything by the framebuffer, good luck with that).

there is no directx or metal equivalent, i guess there is vulkan and SDL but those aren't really all that easy.

now this is problematic because tinkerers like myself want to see results as we tinker which is just not possible at all on linux, i spend more time debugging and building the graphics then i do tinker with the code i actually want to be tinkering with.

let me put this into prospective so it makes sense...
it was easier to do graphics absolutely from scratch in my own kernel then it is to work with any of these libraries
😆 course im not completely done yet and it's far from optimized but it was easier to implement then having to use the already built up libraries that are suppose to make things easier. #🤔
@logan uhh i can't say i really agree but i guess it depends what your requirements are

@aeonofdiscord A good CI system can really help with this. The project I contribute to is arguably esoteric, but GitHub Actions builds it.

This means you both have a well-tested path to set it up on a clean GitHub Runner (pretty stock Ubuntu setup in our case), and the ability to even test and play via CI. (I don't build the project locally, but occasionally abuse the CI to build test versions for me, as I can download the builds from Actions as well.)

@aeonofdiscord The #geekproblem we do need to take the "problem" outa "geek" if the is to be any progress on composting the piles of #techshit