The battle is over. The next generation of programmers reinvented the wheel and it's full of razorblades. I think we should focus our resources on containing this mess with jails/containers. There's no other viable solution. It's our grim reality now.
@feld yet your avatar is Beastie and FreeBSD has the best package management system on Earth. /usr/ports
> incompatible with traditional package management
> source code and no internet access
they all require to have network access to distro repos to be of any use past the initial install
distributed systems are the only way. torrent yourself a 5 TB of `node_modules` and share that HDD on your dialup bbs.
@feld @gme i haven't checked back in a while, but this same conversation was playing out over on the debian mailing lists not so long ago - spurred by npm in particular, but it feels like it's the same problem across the board. giant collections of tiny dependencies with giant collections of their own tiny dependencies managed within piles of ad hoc, half-assed, mutually antagonistic language-specific package managers and build tools.
@gme @feld @brennen welcome to the world of Android development.
Many years ago, when Gradle was new I was at a Google presentation and I was having problems figuring out which jars were needed for a certain feature, so I asked how to deal with that.
The answer was essentially "just put the dependency in Gradle all all will be automatic". I asked what to do if you didn't want Gradle, and they didn't have an answer.
@loke
Now, Debian has the android SDK available as own packages. This gives you far more flexibility to build the packages the way you like. You don't need Google any more to build android packages.
See https://wiki.debian.org/AndroidTools
@Billie @gme @feld @brennen actually I don't find it stupid. I don't doubt that you can get comfortable with it. What I was trying to say was that Android development using IntelliJ IDEA used to be incredibly smooth, but as soon as Gradle and Android Studio (which is just a licensed version of IntelliJ IDEA) appeared the experience got quantifiably worse. And it's still worse, even to this day.
@loke @brennen @feld @gme
Are you on linux?
If yes:
1) Take an up-to date debian distro, e.g. Ubuntu 17.10
2) Install the android sdk from the debian packages
3) Install IntelliJ IDEA
4) Install gradle (e.g. version 3.2.1 in /opt)
Configure IntelliJ IDEA to use 2-4 in the project settings.
The result is a perfectly working android ide without any proprietary stuff from google. Works like a charm. I can confirm it since I code android apps with this setup!
@profoundlynerdy @feld GitLab built on top of IPFS. That would be pretty freakin' cool.
@feld @gme lets see the other side: how about you selfhost everything. now there are 2 things may happen: your thing gets insanely popular over night and your servers cant handle the load anymore. or you are broke and cant continue paying for your server.it is more likely your server goes down (unless you are a big company) then something like github, gitlab, bitbucket and the likes.
Github tags are not releases. The checksums of the downloaded tarballs change based on region and whether or not the Github mirror has voided its cache. You can't require the world to checkout code from a repo. This is against all principals of release engineering, which clearly they do not teach at university.
@feld @gme ah okay, the toot i read sounded like a complaint against github
i agree that tags arent releases (you can use a tag to mark a release), github itself even provides a system of creating "static" releases (e.g. https://github.com/DiscordInjections/DiscordInjections/releases ). you can create release tarballs that arent changing. github itself is nice, but you shouldnt use your git repo as a way to release stuff (github or not).
sorry for the misunderstanding.
@feld @kura @gme I personally run a seedbox on my server. it means you use my server as a peer as a fallback.
if there are few ppl on the download, most of the load is on my server. if everyone is hammering the downloads, most of the load will be evenly distributed.
I recommend most ppl should run p2p mirrors for software they care about. I know I have an over 300 ratio for ubuntu 16.04.3 desktop amd64.
p2p mirrors are used automatically, unlike garbage rsync/http mirrors.
@SoniEx2 @gme @feld im not arguing against it, but many, especially company networks block p2p traffic for security reasons. be it down or uploading illegal content or suffocating the bandwidth. its easier to qos http/s traffic over blind p2p traffic. thats why most company networks (and some isps) blocked irc and dcc back in the days. and after that usenets (though both have lost its values nowadays)
@feld Can I just say "thank you"? You and the entire ports team are literally my heroes. I mean, being able to cd into /usr/ports/...../foo and type `make all install clean` and have every last recursive dependency compiled is like a sysadmin's wet-dream. First thing I do on a fresh FreeBSD system is find konqueror and make all install clean because that compiles KDE, X windows, and everything else under the sun for me downloading the sources directly. It's how I break-in every new system.
I've spent the afternoon trying to package something (Go+Rust) that has so many layers deep in the developer's build framework of expecting to be able to fetch data from the internet and from Github/Crates.io that there's clearly no end in sight.
Proper cleanroom build environments like FreeBSD uses for packaging requires everything be provided with the application source code and no internet access be available during build time.
Sadly this is completely incompatible with modern workflows. You end up chasing down thousands of dependencies by hand, trying to get them all in the right place for the build, and just when you think you've solved the problem the build process runs a command that expects to be able to query a website.
Fucking insanity, man.