Hacker Newsnew | past | comments | ask | show | jobs | submit | jw_cook's commentslogin

The linuxserver.io image for Nextcloud requires considerably less babysitting for upgrades: https://docs.linuxserver.io/images/docker-nextcloud

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.


"You're absolutely right!"


Check if your router has an option to add custom DNS entries. If you're using OpenWRT, for example, it's already running dnsmasq, which can do split DNS relatively easily: https://blog.entek.org.uk/notes/2021/01/05/split-dns-with-dn...

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.


That's a good tip. I had my local self-hosting phase during covid, but if I ever come back to it, I'll try this.


The article mentions Vikunja as an alternative to Nextcloud Tasks, and I can give it a solid recommendation as well. I wanted a self-hosted task management app with some lightweight features for organizing tasks into projects, ideally with a kanban view, but without a full-blown PM feature set. I tried just about every task management app out there, and Vikunja was the only one that ticked all the boxes for me.

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 that isn't cluttered with stuff I don't need (i.e., not Jira)
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 compose


I know this post is more about nextcloud...but can i just say this one feature from Vikunja "...export task summaries and comments..." sounds great!!! One of the features i seek out when i look for a task, project management software is the ability to easily and comprehensivelt provide for nice exports, and that said exports *include comments*!!

Either apps lack such an export, or its very minimal, or it includes lots of things, except comments...Sometimes an app might have a REST api, and I'd need to build something non-trivial to start pulling out the comments, etc. I feel like its silly in this day and age.

My desire for comments to be included in exports is for local search...but also because i use comments for sort of thinking aloud, sort of like an inline task journaling...and when comments are lacking, it sucks!

In fact, when i hear folks suggest to simply stop using such apps and merely embrace the text file todo approach, they cite their having full access to comments as a feature...and, i can't dispute their claim! But barely any non-text-based apps highlight the inclusion of comments. So, i have to ask: is it just me (who doesn't use a text-based todo workflow), and then all other folks who *do use* a text-based tdo flow, who actually care about access to comments!?!

<rant over>


Yeah, I hear you. I almost started using a purely text-based todo workflow for those same reasons, but it was hard to give up some web UI features, like easily switching between list and kanban-style views.

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


> Yeah, I hear you. I almost started using a purely text-based todo workflow for those same reasons, but it was hard to give up some web UI features, like easily switching between list and kanban-style views.

Yeah, i like me some kanban! Which is one reason i've resisted the text-based workflow...so far. ;-)

> ...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...

Aww, man, then i guess i misread. I thought it was sort of easier than that. Well, i guess that's not all bad. Its possible, but simply requires a little elbow grease. I used to use Trello which does include comments in their JSON export, but i had my own little python app to copy out and filter only the key things i wanted - like comments - and reformated to other text formats like CSV, etc. But, Trello is not open source, so its not an option for me anymore. Well, thanks for sharing (and for making!) your vikunja export tool! :-)


This was a fun read, and well written. Thanks for sharing! Adding/improving support for some niche piece of hardware sounds like an ideal way to get started with kernel development, and something I'd like to try myself sometime.


I also assumed those were going to be links, but after a second of confusion I really liked the side pane with animations. It adds a lot to the article and it's more pleasant than the usual alternatives (lightbox on top of the text, or opening a bunch of tabs).

Off 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?


Other readers' cursors. You can turn that off with the 'quiet mode' toggle in the upper right.


I think the idea is cute but, a cursor while reading? Seems odd


This was such a delightful read, and I thoroughly agree with it.

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."


Could you elaborate a bit? Do you think said "GitHub culture" is just because it's the largest platform, or more intrinsic qualities of the platform? Anecdotally I see many of the same problems elsewhere (GitLab, and even independent/self-hosted), but some things I can think of that might be more unique to GitHub are:

* 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.


> Do you think said "GitHub culture" is just because it's the largest platform, or more intrinsic qualities of the platform?

Neither. Everyone and everything develops a culture and/or a set of norms. This is the one that emerged on GitHub. Looking for the reason inside the machine is misguided. It's the people.

> Anecdotally I see many of the same problems elsewhere (GitLab, and even independent/self-hosted)

Putting your repo and bugtracker somewhere that isn't github.com isn't sufficient to neutralize the GitHub culture. (Do people from country/culture X stop being affected by it when they go off and spend the summer in country Y?)

For many or maybe even most people doing open source on GitHub today, they're not even going to know which direction to drive towards in order to achieve the norms of pre-GitHub culture because they never experienced it.


For what it's worth: Thank you for your work on SQLAlchemy and Alembic!

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!


if you put angry/demanding vs supportive/helpful on a 0-10 scale, things hover in the 6-7 range typically. i think computer programming for whatever reason correlates a lot with a certain kind of impatience that we all have. I have gobs of it. We're all fighting it each day to not piss each other off because when youre in "flow" we all know how it is when whatever OSS project suddenly surprises you.

truth be told I spend my OSS maintenance day being more and more pissed off all day really and a lot of it comes from the desire to recognize when people are either subtly or not-so-subtly asking of you to make sacrifices for them. The person who didn't read the docs, the person who didn't read your "new issue" template asking them to please open a discussion since they likely didn't find a bug, to write clear self-contained demonstration code and to not assume your well defined and documented behavior is a "bug, let me know when this is fixed", the programmers who are asking you to upend your whole project for what they in a very dunning-kruger sense think is a good idea, these are all things that someone can respond to in a patient and friendly manner. Heck anyone that works in the service industry has to have an iron-clad patient and friendly manner with all forms of idiots and jerks, including when it's me. But for me personally, doing the open source thing, and also quite obviously for a lot of other folks doing it, man it's hard to keep the fireballs in check while at the same time 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.

rant over I guess!


> rant over I guess

Richly deserved, brother


> anyone that works in the service industry has to have an iron-clad patient and friendly manner with all forms of idiots and jerks

> 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!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: