It's orders of magnitude less of a pain in the ass than password cycling.
-2 karma · joined December 20, 2019
It's orders of magnitude less of a pain in the ass than password cycling.
Forcing people to constantly change passwords just means they either iterate a number or write them down. It also means they start to resent the tech and people who make them do it. It helps no one.
The most common use case is, "I need to store data where the schema is unknown or can change without notice, and have my shit not break." This is what we used Mongo for.
The other use case I could see (and this is pretty much only with Dynamo) is, "I want to build an application that's cross-region native. Most of my data is relatively static, so I accept eventual consistency on changes. I will have a separate data store for transactional data and data that cannot be eventually consistent." I want to build this project, but it will never happen because it's too easy to RDBMS in a single region to start.
2 police and 4 citizens die, and your response is to open with something cute? That's your choice?
Sure, I'm excited to see what happens next.
Why should I, as a business owner, be required to do business with those I find repugnant?
Yeah there are crazies that will be fine with that, but what they can do without the support of “normalish” people is limited.
The alternative is to allow the escalation to continue.
I’d say people (using the term loosely) in his sphere should think of that, but that would require a level of self awareness that’s clearly lacking.
If their CEO had kept his mouth shut they might have had a chance, but they never can seem to do that.
The events of yesterday evening are well within these companies rights and in keeping with both free market and conservative principles.
Why should I, as a business owner, be forced to do business with those I find repugnant? We see this all the time with the so-called 'evangelical' movement against those who they deem 'immoral'. It works the same way when going in the other direction.
If you're not happy with the terms these businesses operate under, you're free to go and make your own platform. Of course, considering how interconnected the world is, you may find yourself also having to replace other services who are making the same decision to not do business with you. But that's on you to figure out.
The world doesn't owe you a soapbox.
Additionally there’s ample ability to deplatform them and their supporters through the agreements they signed with social media companies and payment processors.
The free market won’t have trouble deciding that these traitors are done with both public life and making enough money to ever have to pay taxes again.
Moreover, we are all well within our rights to practice the conservative principle of not doing business with those we find repugnant.
We actually ended up having to do defensive SEM/SEO on bing simply because of how cheap it is to game results there, just because they're not google (no one does it except scammers and people addressing scammers).
Though most people are just going to use a framework plugin to manage the messaging layer, so what's behind that is largely irrelevant.
They've since seemed to put a lot of work into it. To the point where I don't notice it anymore.
They're iterating, and that's what I want to see.
Business tier (we needed custom certs) + advanced ssl is like $220/month and you get a WAF, a world class cdn, and DDOS protection.
edit: Downvote and be mad if you want, but payments made through known tor/vpn services are not getting through fraud review.
If I remember correctly SQS is hard limited to a fairly short timeout to requeue messages delivered but not acked. In rabbit it's much more configurable.
Also regular rabbit hosts support the kludge pattern of, 'just run one host and accept if it goes poof you can lose messages,' which is useful if you don't want to bother with the complexity of clustering or are on a shoe string budget.
Lastly you get a nice user interface with the management plugin and you can stand it up locally with docker compose (without depending on AWS for dev or any of the 'aws but on your laptop' solutions).
Yes we could do that, but we had already been using rabbit in a bunch of places. It made no sense to change it.
I'm getting out of ops for the simple reason that it's way more lucrative to be called in after the fact rather than try to stop incidents ahead of time (whether by probing and disclosing or trying to build out a blue team without being paid a contract to do so).
RabbitMQ is a smart play as Rabbit is very easy to use, understand, and troubleshoot at the low end (which is where I suspect the vast majority of queue systems live).
It also has a feature which is actually really hard to do (and sqs doesn't do). Guaranteed delivery of a message once.
That was THE reason we never migrated to SQS, there are scenarios where SQS can double deliver. Our codebase was built up from nothing over time and couldn't gracefully handle double delivery of messages in all scenarios. We could have refactored, but it wasn't worth the work when we were already doing a half billion in revenue without getting even close to the limitations of rabbit AND were close to selling (which we ultimately did).
AWS is great at selling multiple slight variations of the same product. If you look you can usually find ONE variation that works for you. The real test will be if the billing isn't garbage (garbage billing is why we didn't use their other AMQP service and part of the reason why we don't use things like EKS or Managed SFTP despite having the need).
They're one of three hosting companies I instantly blacklist across the board when I take custodianship of a network. We don't want their customers business.