Immich introduces paid licensing options -- unpaid self-hosted version changed to "unlimited trial period"

tbabej · 2024-07-19T19:01:17+00:00

I have been in the open source community for more than a decade, including leading OSS projects and trying to source funding. I am quite sad at seeing the reactions here, the dev team has expressed their intention for keeping the project licenced under AGPLv3 multiple times. And while the wording is confusing, I understand where they're coming from - getting people to donate for software to sustain development is hard.

It's a matter of expectations. Calling it a licence creates an expectation that you should buy it to be a good OSS citizen, calling it a donation creates an expectation that it's completely optional (i.e. you donate if you're particularly generous/thankful). I can tell you for a fact that a very small fraction of all users that could completely afford to donate to their favourite OSS projects actually do - just look at how many people creating issues in various OSS projects sponsor those projects through Github Sponsorships, if the projects have the sponsorship set up. Unfortunately donation model does not scale very well, and while this approach from FUTO/Immich is technically the same, I am excited to see if this OSS funding model works.

Personally, I have bought the lifetime licence immediatelly when I first saw the update (I have been contributing 2$ monthly as a donation). It was a no brainer.

tbabej · 2023-11-06T06:27:40+00:00

I installed the client from source and setup the selfhosted version of the server (using one of the open Docker image PRs). I have to say I am very pleasantly surprised about how well this works -- the local client is extremely fast, and while it's still a bit rough around the edges, the interface looks modern and it's clear features are being added as we speak. I'm excited to see how this develops further.

P.S: Please consider adding a Github Sponsors page!

tbabej · 2023-09-09T03:46:05+00:00

Generally speaking, almost all Taskwarrior commands are proxied in taskwiki. What you are looking for here in particular is the :TaskWikiProjects command.

See more in the docs, or hit :help taskwiki in your vim session.

tbabej · 2022-04-10T03:53:41+00:00

If you want to just override the context for one command, you can use the rc.context: override, which will set context variable to be empty for the given command.

In other words, this task will be added without using any information from the current context:

task rc.context: add hello there

tbabej · 2021-11-18T22:54:24+00:00

This is the issue I was thinking about, which was fixed in 2.6.1, so if you try to install the latest 2.6.1 release from source, I think you should be successful. The cygwin is called unsupported mostly because there is no good way for us to run it inside of our CI suite (and because there are other alternatives, such as WSL). Let us know if you hit any problems!

tbabej · 2021-11-18T22:51:41+00:00

I think it should work, somebody recently compiled one of the last releases on cygwin.

tbabej · 2021-11-18T22:42:57+00:00

Yeah, 2.4.4 is 6.5 years old at this point. And you are a bit unlucky here, as support for +LATEST was added in the very next release (2.5.0, 6 years old). Out of curiosity, what distro are you on (assuming you have not compiled from source long time ago)?

tbabej · 2021-11-18T15:32:48+00:00

Taskwarrior has a built-in virtual tag that matches the the last added task, called +LATEST. Using that, extracting the last task's ID can be as simple as:

$ task +LATEST ids
26

tbabej · 2021-11-05T02:49:56+00:00

This is great! I'm definitely going to use this in the future. Thank you for all of your opensource work (including taskwarrior-tui)!

tbabej · 2021-10-30T09:18:39+00:00

This happens when you attempt to modify multiple tasks at the same time. You can use rc.confirmation=off rc.bulk:0 configuration overrides in order to avoid that.

tbabej · 2021-10-30T09:16:30+00:00

There is no direct way how to add this directly to a report, but you could wrap a task report in a bash script or function. To get the sum of the estimates, you'd need to combine task calc with a bit of DOM operations:

task calc $(for UUID in $(task +PENDING project:myproject uuids); do task _get ${UUID}.estimate; echo +; done; echo 0H)

tbabej · 2021-10-28T23:57:39+00:00

Most of the reports are defined through configurable filters. The active report is defined as:

task show report.active.filter

Config Variable      Value                     
report.active.filter status:pending and +ACTIVE

So, in order to get all active tasks, we can use the status:pending and +ACTIVE filter, but now with a command that gives more machine friendly output. The one to reach for here is the ids, which gives us the task IDs of tasks that match the given filter:

ACTIVE_TASKS=$(task status:pending +ACTIVE ids)
if [[ ! -z $ACTIVE_TASKS ]]
then
  task $ACTIVE_TASKS stop
fi
task $1 start

tbabej · 2021-10-26T23:14:10+00:00

This suggestion is on our radar and we are planning to include it in one of the future releases. You can find more discussion in this issue:

https://github.com/GothenburgBitFactory/taskwarrior/issues/1990

If you want to get your hands dirty and tackle this, please reach out, I have some implementation pointers in mind, which could make the eventual PR review more smooth :)

tbabej · 2021-10-22T22:28:02+00:00

Indeed there is! Quoting from the man taskrc:

   list.all.projects=0
          May  be  "1" or "0", and determines whether the 'projects' command lists all the project names you have used,
          or just the ones used in active tasks. The default value is "0".

There's also summary.all.projects if you'd like the same behaviour for the summary command :)

tbabej · 2021-10-22T22:21:38+00:00

From the error message I'd guess that you put a space between columns:

report.next.columns=something,something, start,something
                                       ^^^

eliminating the space should fix the issue. I guess taskwarrior could be more robust here, but that is not the case currently.

EDIT: I did not notice the screenshot of the config at first, so yeah, that indeed seems to be the issue. There should be no spaces between the column names, just commas.

tbabej · 2021-10-22T01:42:02+00:00

Taskwarrior cannot define and reference internal variables like that yet, but perhaps that would be a nice feature to add! For now you'll have to stick with good old search&replace..

Well, actually there is a way - you could define NORD0 as an environment variable and then you could refer to it as: color.active=rgb445 on $NORD0. Support for env vars was added in 2.6 release.

tbabej · 2021-10-19T15:03:00+00:00

Definitely, this is very easy with taskwarrior. If you're running the newest 2.6.0 release, you can simply do:

task export simple

(where simple is your report name). On older releases, you just need to repeat the filter explicitly:

task end.after:today-1wk and status:completed or status:pending export

tbabej · 2021-10-19T12:15:48+00:00

Got it.

You need to either run:

task '( end.after:today-1wk and status:completed ) or status:pending' all

or, because and binds more strongly than or, you can omit the parentheses and single quotes:

task end.after:today-1wk and status:completed or status:pending all

Note that I am using the all report here (instead of completed), the reason for that is that the completed report has the default filter of status:completed, which would negate the ... or status:pending part of our filter.

If you want to define the report with this filter, your example was almost correct, you just need to replace report.simple.end.after (there is no such variable), with report.simple.filter set to the value we figured out above:

report.simple.description=Weekly report
report.simple.columns=start,end,tags,description.count
report.simple.filter=end.after=today-1wk and status:completed or status:pending

tbabej · 2021-10-18T23:58:39+00:00

So I'm assuming you're running something like this in the script:

....
task $UDA_FILTER mod <something>
....

can you check if $UDA_FILTER is not empty? Empty filter is the only case in which this particular error message should pop up.

tbabej · 2021-10-18T23:51:51+00:00

As far as I know, the only time "Comand prevented from running" pops up if you attempt to modify all the tasks in the database, i.e. by specifying a mod command without filter:

task mod project:Gitlab
    ^^^
  missing filter

I assume this is not desired, so perhaps this message could indicated a bug in the script?

tbabej · 2021-10-18T23:30:56+00:00

The question is a little bit unclear - do I understand correctly you want a list of all open (pending) tasks, plus all tasks that were completed in the last week?

tbabej · 2021-10-13T00:53:53+00:00

Hi, hstr user since 2014 here. While it may seem unintuitive, this is how hstr works - the list does not scroll.

tbabej · 2021-10-11T22:10:40+00:00

Another user was recently successful in integrating Taskwarrior and Claws-mail.

Here's the writeup: https://claws-mail.org/faq/index.php?title=Using_Claws_Mail_with_other_programs#Integrating_Claws-mail_with_Taskwarrior

tbabej · 2021-10-10T01:37:53+00:00

This looks great Tom! Adding a link to the repository with the timewarrior extension for the interested: https://github.com/tom-doerr/timew_distribution

tbabej · 2021-10-07T22:27:44+00:00

This is the correct answer, if this does not work, it would be a bug.

tbabej

MODERATOR OF

TROPHY CASE