AWS doesn't consider them sensitive, but some organizations do. My feeling is that I would rather avoid leaking any info about my AWS environments. Just because AWS doesn't think they can be dangerous doesn't mean someone else won't find a way.
I did this at a previous employer. I leveraged a Lambda functions and tags applied to instances to determine when they should be and when they should be off.
It's odd that regular testing wasn't part of a compliance framework for them. BC/DR testing has been part of every security/compliance framework I've worked with.
It's sad that this is framed as a zero-sum game. At my current role, the expectation is three days a week in the office, but no one freaks out if you end up working remotely for a week.
If I'm disconnected from the real-world impact of my job, I'm likely to think it's bullshit. That doesn't make it a bullshit job; that just means that I can't see how it fits into the bigger picture. Companies aren't going to keep people employed if they're not somehow contributing to profitability or growth.
I'm not sold on the idea that this is an either/or scenario. Classroom-based instruction is critical, imho, for social development, but having personalized learning as an option for areas of struggle (or areas of excellence) that proceeds at your own pace has been helpful for me (as an adult).
I used to love Graylog, but I was evaluated it for use with AWS and a) it's AWS bits seem limited and b) I found a bunch of deadlinks from their github to their site. If they can't keep their docs updated, it doesn't give me warm fuzzies about their product.
> no other profession in the world works like this
I mean, this objectively untrue if you consider IT and tech.
The author makes good points, but there's no widely accredited skillset for a 'manager' to have. Is the goal of a manager to guide their employees on their career path or to help the business make money? My personal feeling is the former, but every company I've worked for obviously leans toward the latter.
It's fair to say Meta didn't give the data, but they provided a platform that allowed CA to develop the app which gathered the data. On the topic of data privacy, that's a bad step by Meta.
You could say that about most ToS bits. A lot of them are hard to prove. This at least provides a potential legal remedy in the event that a) they are lying and b) we are able to determine that.
It's better than nothing (assuming you're still using Zoom).
The takeaway seems less about nifty coding and more about working in isolation. The author found a path he thought would solve the problem and was 'clever', but never really got feedback from peers. I've done that myself; been so enamored with my own idea that I failed to get feedback and ultimately delivered a non-optimal solution.
You still end up beholden to a service. They have human beings now, but they might not in the future. Or they could vanish. Even running everything on your own systems is risky because you still end up being reliant on domain registrars.
A lot of Internet users don't want to pay for content and don't want ads. I guess they're hoping some deity will magically pay all the content producers.
I get it, but man that's some hyperbole in there. I like Mastodon, but since there's still good stuff on other sites, I will read those, too. If the author thinks he's outsmarted analytics and tracking, they should check with their ISP. Or VPN provider.
Years ago, I wanted to learn Unix so I installed FreeBSD and ran mail and DNS on it. I thought, this will be a great learning experience. Except...it never broke. There was never anything to fix, so I didn't really learn that much from it outside of how to set things up (but just once). Then I installed linux and so many things broke all the time that I was learning everyday.
If you have to run an "Enterprise Linux", you are probably required by regulations or compliance to have a support agreement in place. Whether it's RedHat or Oracle or something else, security is going take third place to compliance and stability.
How does Peeng differentiate between 'pings' from different services coming from the same IP? Payload? For example, if I wanted to use this for an appserver and db server and both have a NAT gw as the source, would I need to separate Peeng domains or can Peeng operate on the payload?
As a development exercise, this is neat, but its extreme focus on software dev makes it just that: an exercise. Slack incorporates all of the extra stuff suc ignores because it's a service; you're paying for someone else to handle the integrations for access control and authz and such.
Homegrown solutions require varying levels of support. Something like Slack is predictable and that makes it attractive, from a business perspective.
Don't taxes on things like cigarettes and sodas disproportionally affect lower-income folks? Intended or not, it comes off as a bit classist. I don't have a better solution, tbh.
> Adtech on the other hand has the explicit goal of making me addicted, dumb, and poor.
No, adtech has the explicit goal of increasing revenue by increasing impressions on ads. Whether you become addicted, dumb, and/or poor as a result is considered an acceptable risk.