social.noyu.me

i do not like google's model of software development and its reckless reliance on CDNs, high-speed internet access and large disks. if dl.google.com ever goes down virtually all android apps will become impossible to build overnight and that should terrify everyone

retvrn to real sdks

HOW MANY FUCKING STAGES IN THE BUILD PROCESS NEED TO DOWNLOAD RANDOM ZIP FILES FROM DL DOT GOOGLE DOT COM DO YOU GUYS HAVE NO DISCIPLINE AT ALL ARE YOU ALL FUCKING INTELLIGENCE AGENCY PLANTS TRYING TO ENSURE THERE'S AS MANY BACKDOOR OPPORTUNITIES AS POSSIBLE

i am fine with package managers!! i am not opposed to package managers!! but the package manager should only be invoked exactly once! if you cannot even count the number of steps where some kind of package manager might download some kind of stuff something is very very wrong!

And on the pedestal, these words appear:
My name is Google, King of Platforms;
Look on my URLs, ye Mighty, and despair!
Nothing beside remains. Round the dead
Links to countless CDNs, boundless and bare
The lone and level ewastes stretch far away

@hikari I first have to compile my companies build tools before i can use them to build the library this app needs to build its own database schema management tool, and once they're all compiled, i can start running the tests

@EndlessMason @hikari look on the bright side. Our company has internal tools routinely sent around as exe files. You don't have to compile them in that case. :-)

@poleguy @hikari Just mount the NTFS share and click the icon! no problemo

@EndlessMason @hikari If only it were so simple. There is no official NTFS share where the tools are hosted. There are policies against that.

You have to find out about the tools by word of mouth. Then you have to ask where to get them. The answer is I don't know but I can send them to you. Then they send an exe that's been renamed .exxe and you are given instructions to rename it.

In the end everybody has a different exe stored locally. If it doesn't work, the support path is similar.

@poleguy @hikari not sure if I like emailed .exxe or exe attached to wiki page better ...

@EndlessMason @hikari They got rid of the wiki (that was originally hosted on my PC under my desk) because they didn't like that there was no access control. It was replaced by Confluence, which has text formatting capabilities that must share lineage with Microsoft Word's famous ability to adjust picture positions on a page.

But nobody posts .exxe files there, or even writes a description of the tools. Nobody wants a paper-trail proving that these .exxe based tools exist. Word of mouth only.

@EndlessMason @hikari I have an archive of the old wiki I made the day it was ported to Confluence. Mediawiki has a nice export feature. Clean user-facing export features are signs of honest software.

@poleguy @hikari Confluence is fine, you just have to ignore anything more advanced than bold / lists and accept that you're not "making a web page" you're "dumping somewhere somebody else can read it"

@poleguy @hikari
> Clean user-facing export features are signs of honest software.

There's a particular kind of UI-jank that screams that the applications UI is cut up into rental blocks, so 3rd parties can rent chunks of the screen from the vendor and charge you rent for a plugin that adds a button or a menu or working search or whatever else

@hikari amusingly, you can build android without this sort of bullshit (after you do a `repo sync` and download a toolchain)

@hikari While enabling (un)intentional supply chain attack is a side effect of this, I believe the main reason is to create an umbilical cord, and allow things to become digital paperweights once Google decides to pull the plug.

People hate languages like C++, but being able to vendor in everything and say "just type make, you need glibc and g++ only" is the real freedom and power flex in software realm.

@hikari fuck Gradle

@hikari thank my great cousin, he invented it :)

@hikari Hmm, my vote for most bizarre thing is that they've eschewed forwards and backwards compatibility. Try building with too old or too new java. And of course the syntax changes slightly with different versions so you need to keep java, gradle and syntax in sync. Oh and nowadays you're supposed to write your gradle scripts in kotlin.

@trademark yes and this lack of compatibility in both directions is a big part of why they're in this mess. normally a newer SDK can compile code written for an older one, and to a more limited extent vice-versa, but they seem to have completely lost sight of this, it's bizarre

@hikari I've stopped writing proper Android apps, react native instead. It has its own problems, but less bad. Considering switching to just have a single webview and write apps in that :(

@trademark @hikari but also inexplicably kotlin builds are slightly slower than groovy (???)