I am a big fan & advocate for Bitcoin and don't know anyone in the space who claims Bitcoin is anonymous. In fact everyone talks about how it's not and ways to fix that.
This is fun. I'm gonna show it to my 8 year old, who I suspect will like it, but the problems will be too difficult after just a few levels. Would be cool to have some way to limit the difficulty.
This would also do well on paper, so I wonder if it can be printed.
I have been very happy using fastmail as my email provider and 1password as my password manager. They have an integration which allows you to generate masked emails, which makes what you're describing possible.
Crossbeam | Senior full stack engineer | Philadelphia | REMOTE
Crossbeam is hiring a lead developer for partnerbase.io, which is a database, built by Crossbeam, to catalog the entirety of the world’s partnerships. Stack includes Vue.js, Clojure, and Postgres. We are currently redesigning the entire site and beginning product planning for a backlog of features, so this is a great opportunity to make a big impact and take ownership.
We are a remote-first company, with many teammates being fully remote and the rest work from home usually 2-3 days a week, with the other days at our headquarters in Philadelphia. We are only hiring within the US, however.
Crossbeam is a collaborative data platform that helps companies build more valuable partnerships. We sync and find matches in data from disparate data sources and allow partners to share insights between each other. We are a remote-first team, with an office in Philadelphia as well as a number of remote teammates across the US.
We’re looking for a talented engineers to join us in scaling Crossbeam. You’ll join a small team of engineers to build the next generation of our software. At our early stage, this is an opportunity to truly influence and contribute meaningfully to the product.
All of the arguments seem to assume you have today's current tools and knowledge at your disposal, just with timezones abolished. This is clearly not what would happen. The real answer to "What time is it there?" without timezones would be the same exact thing, you google "what time of day is 4:25 in australia?" and google would tell you something like, "it's equivalent to 8:00 where you are"
That doesn’t help with the day/date mismatch. Switching everyone to UTC for absolutely everything solves a few problems (international meeting scheduling confusion, cranky programmers) and creates huge problems for almost everything else. Not to mention that access to technology like that is not universal.
I'm curious what your thoughts are on implementing this via a reverse proxy in front of your services. In terms of implementation it appears to me much simpler. But it obviously comes at the cost of maintaining the proxy if you are, say, already using ELBs.
Before I read this article (having just seen the title) I assumed this was going to be covering a reverse proxy system, and started pondering how I would implement something like this myself. A very basic approach probably would be simpler than middleware, but the question I got stuck on was whether or not a reverse proxy would need to be "smart" about the content it was limiting. That is, would it need to be programmed to parse requests and understand what the intention and purpose was of each request?
For example, limiting traffic by IP address via reverse proxy is simple, but it seems like it would be more difficult to limit by request priority.
I was surprised when the article revealed it was middleware, and suddenly that made a lot more sense and seemed easier because it no-longer requires duplicating application logic to understand the content of requests. Middleware definitely seems like the better approach to me after these considerations.
What kinds of methods would one use to solve the problem of needing to parse and understand incoming requests using the reverse proxy method?
From the bit I know, I think there are at least some options available. For example, in nginx I believe you can use the "map" module to mix and match different components of the request into your limiting.
From what I saw, HAProxy appears to be even more powerful. Its ACL concepts are completely able to create rules based on headers, IPs in the request, etc. and you can compose them into larger ACLs.
With the example of request priority, if you can determine the priority by it's URL or a header, let's say, you can achieve this with nginx. But if you need to look the user up in a DB and see how much they're paying you, you obviously have to do it in the application.
This can be done either way, and is really infrastructure dependent. There are pros and cons on both sides. We opted to bake it into the web stack instead of in front so that we get all the benefits of existing infrastructure like log aggregation, exception tracing, HTTP error response formatting and tracking, user-specific gating, auto service scaling, etc.
Without entirely ruling out the opinion, you can take any advice that such logic must take place in a reverse proxy in front of the app with a grain of salt. It's one thing to place certain anti-DOS/DDOS logic in front of the app, but basic rate limiting that depends on inspection of each request (including cache/database lookups for per-user limit increases) is certainly something that is very commonly found at the application middleware layer (after user authentication and route parsing, but before the controller).
Rate limiting is not meant to be a hard defence against denial of service attacks - that is an entirely separate engineering problem, where even a reverse proxy is not enough protection when you're facing a network-level flood. The primary purpose of rate limiting isn't to prevent hitting the application at all - it's to prevent hitting the heavy logic that starts when the controller is invoked. As long as your application's bootstrapping layer is lightweight, there is no problem with leaving rate limiting as part of the application.
I have been working on this recently, using nginx as the reverse proxy. Nginx makes it pretty trivial to limit requests based on various factors, like request rate, number of connections, etc. A post like https://lincolnloop.com/blog/rate-limiting-nginx/ has snippets that show how it works.
But the simplification is that you do not need to write any application code. I can very easily have certain routes or domains limited differently by updating the nginx config. Especially in a microservices world I am trying to avoid having to update N services to get all of them to be rate limited.
I've been using Firefox for several months and have no regrets. On Ubuntu Chrome was doing all sorts of weird things, plus being slow. Firefox's tab groups is also a great feature.
On my Linux MINT machine, chrome keeps doing something[1] that ends up locking up my whole machine and I have to hard-reboot. It got to a point where I actually had to set up Ctrl+Alt+K to issue "pkill -9 chrome" so as soon as I see the mouse-pointer movement become non-smooth or music start to skip, I slam on those keys to kill chrome before I have to restart my whole machine. Then I just went to Firefox developer edition[2]. Is it better? I dunno, but I like its cool dark theme, my system hasn't locked up since and now I got all those cool extensions back again.
I had that problem with Linux Mint on some configurations too. I found that by going into chrome://flags/ and disabling everything related to GPU acceleration the crashes went away. YMMV, of course.
The discussion is about Google Chrome not working on Linux Mint. I said that Google Chrome works for me on Linux Mint. How is that not relevant?
I'm not saying there's no problem, I'm just offering my experience to demonstrate that perhaps the problem isn't just "Chrome runs poorly on Linux Mint", and to offer a counterexample to "Linux Mint is a buggy mess".
I can second the Ubuntu motivation. Chrome is buggy and unreliable on Ubuntu, and I was tired of the Aw Snap several times a week. Firefox appears to be much more stable, and Developer Edition looks better too.
Thanks for this. I switched my input mode to VI and was greatly missing using Ctrl-L to clear the screen when in input mode. I hadn't known about the inputrc before. Adding this line below your "\C-p" line fixed that for me:
You seem to be implying that because North Korea is less free than us, we are completely free with nothing to lose. That's pretty faulty logic. Better to be aware of the freedoms we are losing (even though we still have many) than to risk ending up like North Korea.
> You seem to be implying that because North Korea is less free than us, we are completely free with nothing to lose. That's pretty faulty logic. Better to be aware of the freedoms we are losing (even though we still have many) than to risk ending up like North Korea.
Clearly my point completely flew over your head. I was only commenting on how ridiculous it was that tomjen3 claimed that we had already lost all our freedoms in the very same sentence that he mentioned a country that is far more oppressive than our own.
