Same here too for personal/family vaults. Have been using the bitwarden cloud offering in professional context too.
vaultwarden, or bitwarden-rs as it used to be called, have been working flawlessly for years on my side, updates always work just as expected, and it supports a lot of organizational features too.
But I felt like it was better to trust bitwarden’s cloud for professional stuff, just for the reliability.
I feel mostly the same as the author. The Go ecosystem is so simple, logical and smooth that it is hard to reach out for something else. I do use other languages for one-off programs of course, be it bash, perl or javascript, depending on the task.
On bigger projects, the first pain point to appear for me is dependency management. It feels so antiquated in most other ecosystems, with loose compatibility contracts that add mental overhead. Go let’s you focus on the problem you are trying to solve, and you get so used to that luxury that using anything else quickly becomes painful.
Again, I might be wrong as I did not use this directly in a couple years, but saying “the limit is 50% share of 10 cores” is not equivalent to “the limit is 5 cores”. This is still “how much” versus “how many”, and cannot translate into each other without sacrificing flexibility
if you want to limit the number of Ps, then you use a cpuset, that sched_getaffinity will take into account. cgroups only allows you to limit cpu usage, but not lower the number of cpu cores the code can run on. This is “how many” versus “how much”, and GOMAXPROCS only relates to the “how many” part.
I may have misunderstood the rationale here, but I think the discussion about cgroup support is not about limiting the number of Ps
No it’s an interesting comment. This is not really about load, but about control flow: if goroutine is just spinning wild without going through any function prologue, it won’t even be aware of the synchronous preemption request. Asynchronous preemption (signal-based) is mainly (I say “mainly” because I am not sure I can say “only”) for this kind of situation.
I don’t have the link ready, but twitch had this kind of issue with base64 decoding in some kind of servers. The GC would try to STW, but there would always be one or a few goroutines decoding base64 in a tight loop for the time STW was attempted, delaying it again and again.
Asynchronous preemption is a solution to this kind of issue. Load is not the issue here, as long as you go through the runtime often enough.
By “us”, I was referring to normal, everyday go devs (versus working on go itself).
I think starvation mode is a pragmatic way of solving the issue: overtaking happens when the fast path assumption is wrong - but absolute fairness is not a requirement. So it’s ok. The gains of the fast path is enough to justify having that starvation mode.
I would argue that if some piece of code ends up wasting lots of time on futex calls, it suggests that this code was not designed with the right use case in mind.
Interesting comment about wine’s allocator, did not know about this
This sounds like a great idea on the paper, I think it can bring value. But once you enable this in an organization, if it works well, it could be hard to remove it without resentment
I wonder if the overhead of using context values is noticeable in the context of logging. I guess you want to reconstruct the logger only when needed, kind of lazily
Indeed, starvation mode is just a way to ensure fairness, at the cost of surrendering control and being woken up later. Mutexes can be costly when there is a lot of competition, it is up to us to use it correctly
I think entities or nodes can be categorized as incoming, outgoing, and internal transfers.
Once you get this right, the natural next step is to take time into account. The current chart is the ideal moneyflow, but from months to months I’ll deviate from it. Taking time into account means that these deviations are saved and analyzed. It also means one can analyze or prospectively test new allocations: given average annual returns on investments, what would my savings look like in the future? How did it evolve over time?
That’s just my thoughts on it
I really like the idea. Having a bird's eye view of money flow is central to building and maintaining a strategy. I have been looking for this kind of tool for years, and currently am using a spreadsheet for this, as nothing worked for me. This simple diagram is so much clearer.
But you need to refine the UX, which is barely usable at the moment: it took me a few minutes to understand how to change the numbers. I am still not sure how to add pockets. The name pocket itself is not very descriptive to me, but I am not sure how I would call them. Maybe just « entity », and have a few variations of them (income, accounts, etc).
I would need pockets that take a percentage of another one, such as tax withholding.
This feedback is not structured, but I really like this idea and hope it will help
Onlyoffice is IMHO the best alternative to Google sheets. Services like infomaniak’s kDrive includes it, and for personal free gsuite-like suite, check out ik.me
I am not using Joplin’s cloud offering but hosting it on my own. But I think their cloud pricing is fair (2.40 euro/month for yearly payment, for the basic plan). I’d pay for that