What I’m most curious about is whether the things that were tagged vibecoding are now gone, since there’s no tag for those stories. Or are people trying to game the tagging system and classifying those types of stories as something else?
My assessment is that they’re either gone or greatly reduced.
score 1 · canonical
My tastes say that I should filter “vibecoding” out. But since it means so many things to so many people, decent posts end up being tagged with it. And so, I don’t filter this tag out, and here I am–engaged in yet another community discussion about this tag that means nothing to everyone as a whole, but something to every individual.
In my opinion, there is no salvaging this tag. The tag is itself a pejorative for something that reasonable people have different appetites.
Archive it, split it, kill it–whatever that means–but there’s clearly no consensus on what the tag means, or should mean, and continues causing unnecessary division in one of the internet’s best communities. This isn’t a complicated problem; nobody is invested in this tag. Its absence will be forgotten a lot faster than the acrimonious discussions that pop up around it.
score 7 · canonical
My perception of Flutter is very dated at this point (2018-2019), but I figured it might be worth sharing.
At the time I was left with the perception that Flutter came to life less to serve the needs of developers, but to serve a flagging interest in Android as a mobile development target. Android development felt very brittle at the time. (I was an Android user at the time, and developing mobile applications during this period is actually what drove me to iOS. I could see my development pain reflected in many of the apps I used.) Meanwhile, smaller mobile development shops and SaaS startups making difficult decisions about which mobile platforms to target with their limited mobile development capacity were increasingly targeting their MVPs at iOS. Arguably, because a smaller team of iOS developers could turn out higher quality applicaitons in less time and lower ongoing maintenance costs.
So Google came along to give those shops with limited resources a new development target in Flutter. There has long been a “write once run everywhere” goal in software (e.g. Java), and Flatter was aimed at that. It was quite attractive, if only supported by a Google pinky promise. The sacrifice shops had to make was to risk their entire mobile apps on the hope that Google would continue support for Flutter. There’s a pretty extensive history of how well advised that hope is [1]. I personally wouldn’t advise anyone hitch their career wagon to the Google train. Not to say that others haven’t had success doing so, but that such success comes at high risk.
With that said, Google has an ongoing interest in maintaiing Android as a dominant mobile platform, and for that reason, I have a hard time imgagining Google won’t continue support for Flutter on iOS and Android. Any platform not directly competing with Android is likely at risk.
[1] https://killedbygoogle.com/
score 15 · canonical
I run a general purpose Nomad cluster housing all my personal projects, which also hosts my Nextcloud. While overkill for running Nextcloud in general, I find that it’s a good fit for me since the Nomad cluster is running either way.
The storage backing my Nextcloud instance is a mix of a small Hetzner volume (10GB – their minimum volume size) for low-latency, small file storage. For larger stuff like videos, images, music, etc. I use Nextcloud’s “External Storage” feature with a Linode Object Store, which is a S3-compatible object store.
These are poor financial choices, and probably not the safest place to put my data in terms of durability. And to be objective – it’s a bit of a Frankencloud. However, this is where I choose to put my data because it feels well within my control, and I don’t wonder about any product’s dubious business practices.
score 1 · canonical
Even if the bot hadn’t closed the request, if I was the maintainer, I’d have likely closed it myself. It felt like yet another drive-by request where the requester wasn’t particularly invested in the outcome. The requester couldn’t even be bothered to explain what problem(s) WHIP attempts to solve. The least they could do is have lain out some use cases where adding WHIP to Jitsi would solve some known problems or fill a known gap, by referencing existing issues. The OP didn’t even bother engaging with the issue after it was open.
Maintainers have to be forgiven for not engaging with these sort of uninvested feature requests.
score 1 · canonical