lcof

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.

Interesting research work! Besides the code itself, there is some good reasoning and the documentation is well written

The 2018 paper on heartbeat scheduling is also an interesting read https://www.andrew.cmu.edu/user/mrainey/papers/heartbeat.pdf

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

On Linux, go uses sched_getaffinity to know how many cpu core it is allowed to run on:

https://cs.opensource.google/go/go/+/master:src/runtime/os_l...

Who’s up for a micro-benchmark? Jk, will definitely consider it

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

The relationship with data is that it protects (controls) access to it

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

what about the bitcoin cash fork, that increased block size to 8mb? What about Segwit2x?

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

But was it military-grade encryption?

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

Now with Joplin Server it’s getting better (compared to WebDAV), in terms of syncing speed

I like the idea of not using heavy electron UIs, but really, I does not matter much nowadays, at least for me. Important features are synchronized notes, with mobile and desktop support, and syncing should be end to end encrypted. I should be able to link a note to another, include some media, and use markdown, that is easily importable/exportable. I still to this day couldn’t find a good foss alternative to Joplin with WebDAV or Joplin Server (or cloud offerings).

This feels like a madeleine de Proust: simpler times, so much left to discover. We ruined it

What about bitwarden (or its rust version vaultwarden), did you consider it?

Great read, I have seen this myself in the last 4-5 years with services surfing on the privacy wave - I mean, not just email, but also cloud drive. My conclusion, even regarding established privacy-focused email providers, is that it’s not worth the hassle, really. I use trusted and reliable email providers (according to me), and I just don’t use email for anything sensitive. That’s just right for me.

I know some people do need more privacy and/or security. But a lot of people think they need the same but really, they don’t.

Not sure how Gmailify is different from OSS project simplelogin.io (or similar services). Although this kind of service is targeted at privacy, they do exactly what Gmailify does, are very reliable and can be self-hosted, at least for simplelogin. Moreover, it does not come with such a lock-in. What’s the value proposition here?

Perl CGI is the way to go to get ready for 2026

Thank you, never looked at these. The benchmarks show a big margin, but still, I use both daily and do not notice such a gap

If you use firefox, consider donating!

Then we can compare brave and firefox in terms of speed. I don’t see any noticeable performance difference (I use both on linux and macos)

I wish tab groups to be implemented natively. Or that extensions can manage the tab bar instead of using a sidebar. That’s the best experience we can get so far, but it does not feel right to me.