2,054 karma · joined May 24, 2012
Once you've had part-time experience it's easier to continue at the next place. By the way, people might try to nudge you into fulltime once you're there so quite some discipline is needed to keep a fixed schedule.
That said, I also use them as bookmarks.
Edit: https://www.uu.nl/en/organisation/mathematical-institute/res...
Also there have been several accidents independently in Fukushima, 3 mile Island and of course Chernobyl. Even more modern reactor designs solve some failure cases but really not all.
Germany is already at almost 50% renewables. That's practically risk-free and the technology is there. I mean just look at all the battery tech craze. That said, Nuclear is heavily subsidized and no insurance in the world insures a Nuclear reactor.
(But I know the problem, extended grooming meetings can be the most draining of all...)
At many industries you won't. But it can be quite an effort to find such jobs - and of course succeeding at the interview unless salary/location are suboptimal.
IMHO the most realistic attack vector in this context is a bug in TLS or a popular implementation that is being leveraged to target an individual. Whoever is in this situation, should seriously consider the way he or she uses the internet...
I'd definitely agree with Rails. IMHO it has been defining Web development for a long time. Even today patterns from Rails like are copied outside of the Rails context. Service Objects seem to be a recent example.
Hotwire seems definitely cool tech but after having been exposed to Ruby on Rails it's possible to go into various directions. (Classical server-side rendering, Hotwire or e.g. React-based SPAs)
If you 1) choose to use a proxy and 2) that is a proxy you don't trust, then TLS is pointless for your use case. (Edit: you need to actually activate proxy usage)
I'm using home internet since the mid 90s and I think none of the ISPs I ever used required a proxy. (Mobile excluded, I'm certainly no mobile expert anyway) But I'm aware of ISPs in the late 90s that required ISP proxy usage.
Personally at some point I had set up a local squid to speed up my internet. But today? I think only really bad ISPs and some corporate networks use that. In the latter case it might make sense since you deal with corporate data/code that is owned by BigCorp anyway.
Regarding the CA stuff: yes sure but well, that's the point of the CA. You trust it, some OSs require you to explicitly install those if that matches your risk profile. But really, if you're at that point, maybe the far riskier attack vector is someone shoulder surfing or stealing your laptop?
That said, yes there's certificate transparency but I think it's still experimental and at that level of paranoia you might be optimizing/focussing on the wrong thing.
I can really relate to that. It's necessary to choose something that is not too far out of the comfort zone. Like choosing something novel is good but the majority of the libraries/tools should not be new. That's key to be able to both start and continue a long time. I'd make sure the first proof-of-concept can be done within a month, afterwards I'd either stop the project or continue. Otherwise it's just too frustrating.
Afterwards you can still build stuff on top. If the problem is open ended but has a reachable first plateau that provides a basic use case this can be a nice "rabbit hole project" that you can spend an infinite amount of time on if that's what you're looking for.
> The whole point of a blockchain is for people who can’t trust each other.
I guess that's a very valid point and from my understanding the anonymity baked in is quite unique. And yet, even if I bought say coffee from an independent online market. Probably it's good to have a chain of trust to the seller to know that it's high quality. (Like Amazon reviews)
After all this is what GPG or x509 provide, a chain of trust.
Disclaimer: I have only a vague idea about the whole underlying tech but I've also been wondering if there isn't a simpler approach.