this is classic "easy vs. simple" folly, witness how someone too lazy to [learn how to] setup proper DNS for their infrastructure will do 10x the work hacking something "easy"
Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?
You lose the concept of DNS forwarding. Usually, if your company has example.com, your DNS server is authoritative for example.com, which means it will actually contain (fqdn,ip) entries belonging to example.com, and it will forward requests for other domains to other DNS servers, possibly one DNS server per domain.
If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on.
You don't have PTR records, which means you can't find out a name from its IP address.
You also miss other features of DNS, like SRV, MX and so on.
More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.
It's interesting as I really address all these things in the article. Not explicitly PTR and SRV, MX records, but these aren't essential within your internal infrastructure. No need to look at MX records if I can just straight up point at the SMTP server(s).
And I explicitly argue within the section about egress filtering that allowing systems access to public DNS is a security risk.
Because managing one database using mature tooling that is purpose-built is easier than managing 10,000+ databases using a homegrown solution with exponentially more complicated software that wasn't built for that purpose.
Serious answer: I run [and must maintain] 100x fewer resolvers than hosts. If an endpoint changes or a host leaves/returns, I'm much better served (heh) by pointing templates at resolvers instead of the horde.
Changes from a single point of failure to a thousand points of failure. What if a host if offline when the Ansible update runs? What if someone wants to run a service that ignores /etc/hosts, like a Docker container?
"quality" isn't succinctly definable. Zen and the art of system maintenance quality code is written by an old and wise programmer and any attempt to rigidly codify what it is they did and why is doomed to fail.
More like 25. C# 1.0 already had capabilities Java developers are still dreaming of, like structs / value types, properties and operator overloading. C# 2.0 in 2005 introduced generics, implemented far more competently than Java ever did.
Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.
So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.
> and many of them can't be fixed... And the boxing with C# unions can and will be addressed later
No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.
The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.
So cool. One reading is “complexity is not what you believe it is”. Another is “complexity is”… “not what you believe it is”. Seems similar but the difference is subtle. Even the “please try listening” line changes in both versions. One is confrontational, the other is empathetic.
> Sure but the OP suggests that these were minor gains
When antirez says 'I ventured to a level of complexity that I would have otherwise skipped,' I don't think you can call that a minor gain. The alternative is likely something 'good enough' that leaves the community dissatisfied for months, and then after initial design mistakes become load-bearing the ideal implementation can never be realized.
He writes that right after saying "For high quality system programming tasks you have to still be fully involved". He's just saying that AI was useful to him for tedious special-case tasks (citing the addition of 32-bit support and fishing out bugs in new low-level implementations), that this required starting from a "huge specification" (not a one-shotted prompt!) and that he still had to go over everything with a fine-toothed comb afterwards. That's the farthest thing from the 10x silver bullet AI is now being sold as.
I haven't used azure devops but I used TFS in its heyday and still haven't ever seen a better integrated ticket workflow with fully customizable states and transitions - it's like a mutant hybrid of jira and github but all built into VS. There's definitely something to be said about keeping the primary admin UI in the dev tools.
it's actually neither. normal forms provide semantic guarantees through structure. the structure proposed here does not constrain the data in any way and therefor cannot be said to be a normalization - tfa is dead wrong basically.
reply