I have found that it often takes a very long time for Tor to build a circuit (bootstrap) using obfs4, because of what seems to be difficulty finding bridges.

Every now and then this question comes up. It’s a timeless software engineering conundrum. Kind of like how med students might start to think they have all kinds of diseases and conditions because they’re learning all these symptoms.

Software engineers, especially new ones, tend to be heavily biased toward applying technical solutions to non-technical problems. Most never actually grow out of this.

I’ll advise what I advise every time someone approaches me or one of my peer groups with this very question:

Get yourself a notebook and a pen.

I’m dead serious, not trolling, and not some kind of technophobe zealot.

When it comes down to it, if you let go of what you think you need in a to-do list app, you’ll find that what you actually need is much simpler.

Notebooks are e2e encrypted. Self hosted. Offline. As ephemeral as you like. Indexable for search. Versatile. Take a picture of a page if you really want to. OCR it if you need to.

Pen and paper.

Tor comes packaged with torify which you can prefix any CLI command with to have it route through Tor and resolve onion sites properly.

No, you’re not looking to understand. You’re looking to persuade.

Can’t close your account or request deletion of your data, either. Same thing happened to me.

love it.

Seems like something you may need to change in Transmission’s configuration, somewhere. Because it’s Transmission that is redirecting you and what you want is for that redirect to include the uri prefix.

Otherwise, I see two options:

• use a regex location block and match against all expected patterns
• use a dedicated subdomain (i.e: server block) for this (each) service you want to proxy and just proxy all traffic to that domain with a root location block.

The latter is what I would do.

https://www.eff.org/wp/digital-privacy-us-border-2017

General advice from EFF. A bit dated, but much of what I would have advised is here.

The way this comment is written doesn’t sound anything like the OP or the GitHub issue. Different tone, different dialect/spelling… lot of linguistic red flags. Not that I’m judging either way, it’s just suspicious how vastly different they are.

RE autoscaling: effective distributed systems design isn’t really language-dependent. Java apps can scale just as well as ones written in Go. That said, I can see there being a case for Java apps not making it as easy to build that way. There’s definitely a lot of mainframe/monolith-oriented patterns in both the standard library and in enterprise Java culture.

As for the job market and career investment, I’d say this:

• Keep investing more deeply in what you’re good at. That’s your foundation and what sets you apart.
• Avoid chasing the “next big thing” based on speculation and trends alone.
• The next step in your career hinges more on your ability to think and design at higher levels than it does on lateral moves to another programming language.
• Explore languages and technology that you think are interesting, relevant, or can provide value or elevate what you’re already doing. The main benefit of doing this is to engage your brain differently and encourage change, improvement, and growth. This will indirectly improve your work and help your career.

I’ve written a lot of Java in my career and studied it in college, and I’ve written one app professionally and several hobby projects and utilities in Go. There’s a lot to like about it, regardless of its marketability on a resume.

If you’re using Gmail, and you’re considering alternatives for privacy reasons, then 100% without a doubt, objectively and unequivocably, Proton is the better choice of the two.

There are other email providers with privacy assurances, and yes, you can self-host, but don’t let perfection be the enemy of the good.

To address the trustworthiness of Proton directly: I’ve been a Proton user for about 10 years. It gets the job done. I have complaints, but privacy is not among them.