Just anecdotal but I observed a few dozen PhD's try to set up an OpenStack cluster. The end result was a bloated unstable unsupportable mess that had to be entirely scrapped and started over by a new team one year later. I have witnessed the same hot mess by people forking Ansible and Chef for no good reason beyond because they can and it would look good on their CV and could give them some perceived job security.
I would rather gauge a persons authority on a topic based on their professional experience and their actual revenue generating results vs. some thesis. Make such laws outside of totalitarian countries and people will just buy degrees or just lie. I've observed that as well. Plenty fake it until they make it knowing few will verify their degree. It just so happened that my last employers verified degrees, high school diplomas and much more. Plenty of companies do not verify anything.
If you want a fun and quick exercise, search your favorite AI for CEO's and famous intellectuals that were high-school dropouts.
Successful CEOs don't need to be influencers. Influencers are people wanting to make money influencing. They should be professionals to be allowed to monetize.
They may wish to consider using different SNAT pools for employees vs. data-center bots to avoid the confusion. Perhaps name the PTR for employee pools something like employee-snat-1000.building.region.fb.net. If the bot SNAT pools have unique names and CIDR SWIP delegation it would also be easier to identify bots regardless of user-agent and easier to know who to complain to.
Alternately require employees to use a dirty-net VPN to view porn or whatever edgy / taboo content so it does not even come from meta allocated networks but is still routed through their security devices. As apposed to the consumer commercial VPN's in the spirit of preserving the "top-10 porn viewer awards. If anyone asks about the dirty net VPN it is for researching malware, ransomware and sites posing as meta/fb.
Employees shouldn’t be using the corporate network to view porn. Everyone nowadays (especially Meta employees) has smartphones with personal hotspot capability. Just use that if you really need access to such content in the office.
In fact I don’t really buy their reasoning - surely everyone working as a software engineer knows that SNIs are unencrypted and any corporate network will log them, so nobody should be accessing any kind of objectionable content via the corporate network for their own good to avoid embarrassment.
So I suspect the porn access may have been due to an actual AI scraper (not arguing that they trained on porn - it could very well be there are 2 stages - one is a basic scraper more or less following links, including accidentally following a pornographic link posted on a non-porn site, and another stage classifies the content and the decides whether it should be used for training or discarded).
If this was actually employees accessing or torrenting pornographic content, I’d expect this to be quickly followed up on and the employee facing dismissal after a stern warning (or an IT security investigation if they persevere in claiming they didn’t do it, as it could suggest malware using their machine to proxy traffic).
But I don’t think an occasional user being sloppy would be grounds for a lawsuit. So I suspect a scraper did indeed go haywire and downloaded porn en-masse.
Whether they trained on it is another matter. I suspect that due to the prevalence of porn on the internet there would be incentives to filter out such content (if anything, just because it’s quantity would outweigh the non-porn content) for model training.
> “[T]he small number of downloads—roughly 22 per year on average across dozens of Meta IP addresses—is plainly indicative of private personal use, not a concerted effort to collect the massive datasets Plaintiffs allege are necessary for effective AI training,” Meta writes.
In my opinion if there is no overlapping networks or the Infrastructure as Code understands pods, k8's and such then /etc/hosts can speed up resolution leaving things outside of the data-center to utilize DNS then it makes sense but requires some critical thinking about how all the inter-dependencies in the data-center play together and how fail-overs are handled.
Why aren't cloud providers and FAANGs doing this already
This probably requires that anyone touching the Infrastructure as Code are all critical thinkers and fully understand the implications of mapping applications to hosts including but not limited to applications having their own load balancing mechanisms, fail-over IP addresses, application state and ARP timeouts, broadcast and multicast discovery. It can be done but I would expect large companies to avoid this potential complexity trap. It might work fine in smaller companies that have only senior/principal engineers. Using /etc/hosts for boot-strapping critical infrastructure nodes required for dynamic DNS updates could still make sense in some cases. Point being, this gets really complex and whatever is managing the Infrastructure as Code would have to fully aware of every level of abstraction, NAT's, SNAT's, hair-pin routes, load balanced virtual servers and origin nodes. Some companies are so big and complex that one human can not know the whole thing so everyone's silo knowledge has to be merged into this Inf as Code beast. Recursive DNS on the other hand only has to know the correct up-stream resolvers to use or if they are supposed to talk directly to the root DNS servers. This simplifies the layers upon layers of abstraction that manage their own application mapping and DNS.
Another complexity trap people get lured into is split-views which should be avoided due to growing into a complexity trap over time and breaking sites when one dependency starts to interfere with another. Everyone has to learn the hard way for themselves on this topic.
My preference would be to instead make DNS more resilient. Running Unbound [1] on every node pointing to a group of edge DNS resolvers for external IP addresses with customized settings to retry and keep state up the fastest upstream resolving DNS nodes, also caching infrastructure addresses and their state, setting realistic min/max DNS TTL times is a small step in the right direction. Dev/QA environments should also enable query logging to a tmpfs mount to help debug application misconfigurations and spot less than optimal uses of DNS within the infrastructure and application settings before anything gets to staging or production. Grab statistical data from Unbound on every node and ingest it into some form of big-data/AI web interface so questions about resolution, timing, errors may potentially be analyzed.
This is just my two cents based on my experience. If it seems like I was just spewing words I was watching Shane Gillis and did not want to turn it off.
You made some really good points. But here is my follow up: With /etc/hosts, there is no need to complicate things, for example:
10.0.0.1 sql.app.local storage.local lb.corp.net
This line could be present on every host on every network, everywhere. The only thing that should matter in my opinion is that the name portion needs to be very specific. Even if you have NAT, SNAT, etc..., /etc/hosts is only relevant to the host attempting to resolve a name, it already knows what name to use.
So long as you have one big-and-flat /etc/hosts everywhere, you just have to make sure that whenever you change an IP for a service, the global /etc/hosts reflects that change. and of course the whole devops tests, reviews,etc... ensure you don't screw that up.
Back in the day, this was a really bad idea because the problem of managing /etc/hosts at scale wasn't solved. But it is just a configuration file for which IaC is best-suited.
DNS on the other hand is a complex system that has hierarchies, zones, different record types, aliases, TTLs, caches, and more. in a closed private network, is DNS really worth it when you have already invested in IaC?
So long as you have one big-and-flat /etc/hosts everywhere
I get where you are coming from and in a small to almost medium company that might work but at some point there will eventually be conflicts when networks and environments managed by many different teams will start to conflict or not be able to resolve things until someone opens a ticket to update the other departments Infrastructure as a Service. In my experience teams and orgs want to have control over their thing and while they could logically all share commit access to a big flat thing it will start to introduce artificial problems.
I could be wrong. Perhaps in your company it will work out just fine. As nobody here on HN knows the logical and physical structure of your company maybe pull a meeting together consisting of leaders from each team/org that currently influence DNS records and ask them to pick apart your idea after documenting it in a way everyone can visually understand how the code repositories and multi-department git permissions would be laid out and how each team would be able to independently add, change and delete records whenever they need to and review audit logs both in the repositories and possibly on each node. My views could be skewed by all the politics that naturally occur as organizations grow. For what it's worth I was in a company that had multi-data-center wide /etc/hosts and it was just dandy when the company was small. We outgrew that by the second iteration of our data-centers.
You make a good point, I'm still a bit stuck on the conflict part since you can have multiple names. but i can envision where multiple teams want to use db.local or something, and if you're providing services internally, that could be hard to scale for sure. I'd like to think that those people avoiding pesky tickets and all that end up causing outages by moving their conflict to DNS? but what do I know.
In the end, I trust your experience over my opinion. Thank you.
but i can envision where multiple teams want to use db.local or something
They could just use service1.region1.db.local but the trick is to get all the teams to agree to this or have a top-down decision from leaders in a new greenfield data-center design. Only you and your coworkers can really decide if this works. I hope it works out.
Corporate media have always been used to manipulate the masses but the internet exacerbated this by providing corporate media with additional information about the users and the ability to target people by demographics, political preferences, social class and more. This improved not only manipulation but also rage-baiting, click-baiting, targeted gaslighting, astroturfing, social division further amplifying the previously mentioned capabilities and more. There is a lot of money and power to be gained by manipulating the masses. Those perceptive enough to detect this will lose confidence in the corporate media and with time this lack of confidence will spread to other services as well.
Governments are not able or willing to fix this so the only winning move is not to play. Create block-lists for social media and corporate media sites. Return to smaller interest based platforms that have less than 20K users each. Avoid anything federated as it only takes one compromised platform to spoil the entire fleet. This will be very difficult for many as the dopamine addiction to social and corporate media will be challenging to break and people like belonging to a massive group. Many will instead invoke coping mechanisms and other excuses to continue their habits. I mention social media as corporate media often control, operate and/or manipulate the masses on said platforms. Some of the manipulators are on this site and will try to defend the big corporate and social media platforms. see if you can spot it...
Forget LLM's. We already saw what they can do without firing a shot. They navigated a large stratospheric balloon over many military installations in the USA without it being shot down until it reached the east coast. That was obviously a discovery and practice run. Those balloons can carry thousands of pounds of payload. China have an entire military division dedicated to balloons and they are growing.
All they would need are two, maybe three of those balloons detonating high altitude nukes to knock out the power of an entire continent. Power grids are much more fragile than most would believe. Performed during the winter many would freeze as people have become dependent on electricity and fuel for heat. Fuel and sewage require electricity to pump in cities. The massive substation transformers that would need to be replaced are not kept in stock locally and are produced in ... China. There are documentaries that show why these transformers can not even be replaced in some cities due to the roads no longer facilitating the large earth moving equipment that is required to move them. I would wager most have never even seen one of them moved in their lifetime.
Commander, you should take a break from the conspiracy theories and anti-China political news. Take a moment to check the news[1] , then declare war on Silicon Valley startups and send a passenger plane to shoot down the balloons[2].
The codes exist but I think what they are saying is that in some places codes are not enforced or even checked. I live in somewhat of a "middle ground" where codes do exist and electrical is checked on a brand new build. They will also nag about septic inspections but will never actually get off their butts and do the inspection. Many such places do exist but they are usually places I would never want to reside. I know of places that I can literally build anything and never once be nagged by inspectors or state/county governments. They are happy enough and lazy enough to receive the property tax revenue.
I have mixed feelings about unenforced regulations. Having unenforced regulations opens up the possibility of targeted abuse of any individuals that are not a cultural fit in the eyes of the government offices and being very relaxed regarding anyone that fits in. This also drives the need for very detailed and expensive inspections prior to purchasing a home and that is a loaded topic all by itself.
There are places that don't even have the regulations - or if they do, the number of explicit exemptions is so large as to easily drive an entire house through them.
Agreed. I should have clarified that is what I meant by there are places I can build literally anything. Of all of the places I found to be the case I would not want to reside in any of them. If one digs deeper they may find the local government to have corruption issues and county/state services are often not reliable or useful. Crime is usually high in such areas. There are probably a few hidden gems but it was not worth it to me to find them.
That's a good step in the right direction. Curious if they will ever remove the PGP keys out of the public mirrors. That would be my next step. RPM's can be resigned with any keys and said keys can be replaced in a mirror. It would eventually be caught but I prefer not to have people accustom to these dark patterns in the first place. Keys used to validate RPMs need to be served from locked down servers and companies with internal mirrors must find a secure way to cache and serve them internally.
[ $ man yum.conf | grep -C 5 -i gpg ]
gpgkey list of strings
URLs of a GPG key files that can be used for signing
metadata and packages of this repository, empty by default.
If a file can not be verified using the already imported
keys, import of keys from this option is attempted and the
keys are then used for verification.
gpgkey_dns_verification
Should the dnf attempt to automatically verify GPG
verification keys using the DNS system. This option
requires the unbound python module (python3-unbound) to be
installed on the client system. This system has two main
features. The first one is to check if any of the already
installed keys have been revoked. Automatic removal of the
key is not yet available, so it is up to the user, to
remove revoked keys from the system. The second feature is
automatic verification of new keys when a repository is
added to the system. In interactive mode, the result is
written to the output as a suggestion to the user. In
non-interactive mode (i.e. when -y is used), this system
will automatically accept keys that are available in the
DNS and are correctly signed using DNSSEC. It will also
accept keys that do not exist in the DNS system and their
NON-existence is cryptographically proven using DNSSEC.
This is mainly to preserve backward compatibility.
Default is False.
RPM packages' GPG key(s) can be specified in a .repo file, which can be updated by an RPM package from a repo with or without mandatory signing configured. Typically, all packages in a repo are built with CI build containers that all share the same signing key.
How to bootstrap the [Sigstore [TLS] pubkey, HKP (TLS) pubkey], to verify the [Sigstore hash, GPG .asc signature] of the manifest containing the [Sigstore, SHA-X] hash for each package and/or package file?
Disclaimer: I am not Amish but I researched them just enough to realize I am not cut out for it. I am not an expert.
Most of the Amish are still involved in capitalism, they just don't have a hard dependency on consumerism. Most still produce and sell household items, foods, clothes. Some may even build and sell houses commercially. Some use cell phones and AI. Look up which groups are in your area and find Youtube videos on their particular customs. [1] this document is missing a lot but I am not writing a thesis. Each have different customs and differing levels of strictness to certain rules and customs. Some of the groups use tech but they may avoid dependency on it. Research this heavily before making any life altering changes. Their reality may not match the mental image some have from movies. Some youtube videos may cover some of the undocumented caveats i.e. unique social issues they will not discuss. It is a very hard way of life. Most not born into this are not ready for it.
Something one may wish to consider is trying to find a community that mimics some of their practices without the requirement for a strict adherence to it. i.e. survivalist or emergency preparation communities, hippie communes, naturalists, homesteaders, intentional communities, eco-villages, rural farming communities and so on. Any type of commune may have its own issues such as having "regulators" instead of or in addition to law enforcement. Be aware of cults.
Out of curiosity do you front-end SMTP with postfix to have many queues/MX entries and a battle hardened front-end or is Stalwart handling inbound connections directly? Im thinking of moving from Dovecot to Stalwart so family members have more modern features on my fallback domains about half of my domains do not use Fastmail. In multiple companies I had several Postfix inbound servers to keep the internet from touching Exchange directly and have multiple nodes for companies to quickly hand off to in multiple locations.
I just run single instance for now with RocksDB backend for internal / search and S3 for blobs - that is what made me think it’s so flexible.
Never hosted Postfix / Dovecot stack, in fact this is the first time I host emails, but from what I understand Stalwart is designed to handle inbound directly.
For very high throughput inbound you could check out KumaMTA - it was designed specifically for that, but I think Stalwart doesn’t have bottlenecks in it’s clustered topologies which would require it unless you are doing something crazy.
I would rather gauge a persons authority on a topic based on their professional experience and their actual revenue generating results vs. some thesis. Make such laws outside of totalitarian countries and people will just buy degrees or just lie. I've observed that as well. Plenty fake it until they make it knowing few will verify their degree. It just so happened that my last employers verified degrees, high school diplomas and much more. Plenty of companies do not verify anything.
If you want a fun and quick exercise, search your favorite AI for CEO's and famous intellectuals that were high-school dropouts.
reply