jw_cook
The execs shown in those clips used some pretty revealing language. I also had to do a double-take when they described a customer's (compromised) house as an "LG household," where they "know who's in [it], we know which devices are there... we know how to extend that reach into mobile" and tell advertisers they can "own the living room."
The sense of entitlement is so over-the-top that it's difficult to distinguish from satire.
gh config set telemetry disabled1. Mostly use the mobile app, and take photos and upload observations directly from there. Local photo collection either isn't a priority or is backed up by their phone's cloud sync.
2. Mostly use inaturalist.org via a desktop browser, with either a standalone digital camera or mobile photos synced to desktop. Local filesystem (hopefully plus backups) is the source of truth.
I have been working on a desktop application[2] with a long-term goal of full bidirectional sync, and a secondary goal of offline usage. The current feature set is fairly modest and read-only, though, focusing on organizing local photos using data from iNat.
https://github.com/inaturalist/inaturalist/blob/main/app/ass...
https://github.com/inaturalist/inaturalist/blob/main/app/ass...
https://github.com/inaturalist/inaturalist/blob/main/app/ass...
https://www.gbif.org/dataset/50c9509d-22c7-4a22-a47d-8c48425...
https://www.gbif.org/dataset/8a863029-f435-446a-821e-275f4f6...
The iNat API certainly has some quirks and shortcomings, but in terms of usability it's uncommonly good compared to most biodiversity platforms. I maintain the python API client[1], which is used for data visualizations, doing useful things with your own observation data (which is how I got into it), Jupyter notebooks, Discord bots, and some research/education workflows.
Discussion: https://news.ycombinator.com/item?id=46934404
My use case looks roughly like this: for a given project (as in hobby/DIY/learning, not professional work), I typically have general planning/reference notes in a markdown file synced across my devices via Nextcloud. Separately, for some individual tasks I might have comments about the initial problem, stuff I researched along the way, and the solution I ended up with. Or just thinking out loud, like you mentioned. Sometimes I'll take the effort to edit that info into my main project doc, but for the way I think, it's sometimes more convenient for me to have that kind of info associated with a specific task. When referring to it later, though, it's really handy to be able to use ripgrep (or other search tools) to search everything at once.
To clarify, though, Vikunja doesn't have a built-in feature that exports all task info including comments, just a REST API. It did take a little work to pull all that info together using multiple endpoints (in this case: projects, tasks, views, comments, labels). Here's a small tool I made for that, although it's fairly specific to my own workflow: https://github.com/JWCook/scripts/tree/main/vikunja-export
As long as you only upgrade one major version at a time, it doesn't require putting the server in maintenance mode or using the occ cli.
If not, and you don't want to set up dnsmasq just for Nextcloud over LAN, then DNS-based adblock software like AdGuard Home would be a good option (as in, it would give you more benefit for the amount of time/effort required). With AdGuard, you just add a line under Filters -> DNS rewrites. PiHole can do this as well (it's been awhile since I've used it, but I believe there's a Local DNS settings page).
Otherwise, if you only have a small handful of devices, you could add an entry to /etc/hosts (or equivalent) on each device. Not pretty, but it works.
Some specific things I like about it:
* Basic todo app features are compatible with CalDAV clients like tasks.org
* Several ways of organizing tasks: subtasks, tags, projects, subprojects, and custom filters
* list, table, and kanban views
* A reasonably clean and performant frontend (i.e., not Jira) that isn't cluttered with stuff I don't need
And some other things that weren't hard requirements, but have been useful for me: * A REST API, which I use to export task summaries and comments to markdown files (to make them searchable along with my other plaintext notes)
* A 3rd party CLI tool: https://gitlab.com/ce72/vja
* OIDC integration (currently using it with Keycloak)
* Easily deployable with docker composeOff the top of my head, I'm not sure how else you'd visually communicate "this bit is interactive on click/hover but isn't a link." Maybe a different text color (without underline), background color, outline (replaced by the colored highlight bar on hover), or a slightly larger and more distinct icon to replace the generic 'image' icon?
Favorite quote:
"attempting to apply its childlike logic to realistic dynamics can only lead to cognitive dissonance even more mind-melting than hearing Goofy ah-hyuck his way through a discussion of his own atrocities."
* The larger presence of commercial OSS projects setting a tone of "projects here are products to be marketed"
* Social media-like features encouraging popularity contests, curating a personal brand, etc.
* Both of the above leading to more users acting like you owe them something ("you're competing for my attention, right?")
I'm not 100% convinced that those or other GitHub-specific factors are primary causes of maintainer burnout, but I think it's certainly possible.
> giving each of these users a clue that there's something they could be doing to make life easier for the maintainers of the project that they are using for free.
The intersection of these two things is something I've been mulling over lately. In other words, how do we respond to the implicit proposition of "I'm going to pay you $0 and expect the effort and patience of a well-compensated service industry employee"? Putting in the mental energy to deescalate conflicts and be diplomatic with challenging personalities is something I'm willing and able to do... but not for a hobby/unpaid volunteer project!
But then there are many different types of people behind those interactions, including but not limited to:
* Someone who's genuinely a sociopath, or at best an entitled ne'er-do-well who just wants free labor
* Someone in full "socially inept engineer mode," with terse communication that comes across as curt or demanding via text, but are otherwise reasonable if you spend more time talking with them; in their own mind, they're probably just being "direct" or "efficient"
* Someone new to open source etiquette, who doesn't yet know what a good bug report or feature request looks like, but are willing to learn with a little guidance
Sometimes it's hard to tell the difference, and all of those cases can have the same effect of being rather draining, at least in the short term. Longer-term, I've had at least a few cases of someone who seemed like an entitled jerk at first blush, but turned out to be a valuable power user who stays engaged with the project and provides useful feedback. Of course power users come with their own challenges, like wanting to cram every feature under the sun into your project without appreciating the long-term maintenance costs. But at least they're more fun to work with!
On large projects like those, what ratio of community interactions would you say are angry/demanding vs supportive/helpful? And any advice for dealing with the negative ones?
For me, probably less than 5% of interactions on PRs/issues/discussions are negative, but even that small amout sure does have a way of draining one's enthusiasm and motivation!
That got me thinking: how do other self-hosters/homelabbers here go about automating their server setups? None/purely manual? One big shell script? Multiple scripts wrapped in a Makefile (or justfile, or other command runner)? More enterprisey provisioning/automation tools like Ansible, Puppet, etc.?
I'm in a similar boat, where I use NextCloud but really wish there was a better option (especially for mobile photo sync). Syncthing + Photoprism is currently at the top of my list of possible viable alternatives.
"The file was in my sleeve the whole time!"
Sibling comment:
> This is a valid need that any project maintainer should aspire to address.
I think either of these things can be true, depending on the goals and intended audience of the project. It's totally valid for someone to make software like this primarily for themselves, and leave it up to others to tailor it to their own needs or contribute to make it more accessible.
I get the impression this project was made for the author's particular use case and isn't (yet) seeking a broad audience. The readme for this project doesn't really explain this, though, which makes me realize several of my own projects don't clearly set these expectations either.
For cataloguing both plants and wildlife, inaturalist.org may be closer to what you're looking for (depending on what you want to do with that information).