That can help, but policy doesn't execute itself, it's executed through the police officers. Most cities aren't prepared to be able to follow-through to the logical conclusion the steps they'd need to take if their police force is fully intransigent with regard to following policy, so the policy itself is set based in part on what the force itself is willing to enforce.
Yes, but I think maybe people in this thread are painting it unfairly? Another way to frame it is that they used industry best practices and their intuition to develop the game, then revisited their decisions to see if they still made sense. When they didn't, they updated the game. It's normal for any product to be imperfect on initial release. It's part of actually getting to market.
To be clear, I don't think it's a huge sin. It's the kind of mistake all of us make from time to time. And it got corrected, so all's well that ends well.
I’m a Zig outsider. I gathered the context from reading the conversation around it, most of it posted to HN. Which is why I also pointed out I may have incomplete information.
If one looks past the immediate surface, which is a prerequisite to form an informed opinion, Zigbook is the one who clearly looks bad. The website is no longer up, even, now showing a DMCA notice.
The way these sorts of things look to outsiders depends on the set of facts that are presented to those outsiders.
Choosing to focus on the existence of drama and bullying without delving into the underlying reason why there was such a negative reaction in the first place is kind of part and parcel to that.
At best it's the removal of context necessary to understand the dynamics at play, at worst it's a lie of omission.
The primary challenge I see is that at least in the US, government positions are often elected and termed, meaning there is no guarantee your cash flow from your government job will continue long-term. This is why you must continue to operate as a private citizen, with a government job.
The second potential issue is one of pay - the best of society can make far more in a commercial setting than in a government setting - barring corruption, of course.
For your second potential issue, I’m saying that’s the point. Nobody becomes a priest for money.
These people who become priests do so for other reasons and they largely want to exit the commercial economy. That’s the type of people government should be made of. Under this system pretty much 100 percent of politicians wouldn’t have even become a politician.
Since we are talking about political leadership at the highest levels (not pastoral local municipalities), a good comparison with priesthood would be the Vatican. Even in priesthood, when there is concentrated power over vulnerable populations, we can find: wealth hoarding, money laundering, collaboration with organized crime, and protection of rampant sexual abuse. For hundreds of years. This suggests to me that the issue is hierarchy more than it is quality of those who reign over us.
Here's my hot take: politicians should be paid a lot of money, and in return they should be subject to limits on how they can invest, if they can invest at all. Remove the incentives that cause corruption and attract talent. I think it's a bit naive to say that public servants need to be earning a meager salary. Underpaid people don't stay in their roles very long.
The first point is true of most employment, unless you're one of the ~10% of US employees with a union contract. Your paycheck is always subject to the whims of your employer.
I don't have a great solution for the 2nd issue you pose though. Raising the pay of elected officials is often politically unpopular, but you're certainly right that one makes more in the private sector than as a junior congressperson.
Yes and no - if you lose your job at Apple, you can go down the street to Microsoft. If you lose your elected government job, you can't run again for years. Meaning, you have to switch from being a government employee back to being a commercial employee.
A lot of them actually. Ceph personally I've used. But there's a ton, some open source, some paid. Backblaze has a product Buckets or something. Dell powerscale. Cloudian has one. Nutanix has one.
Ceph is awesome for software defined storage where you have multiple storage nodes and multiple storage devices on each. It's way too heavy and resource intensive for a single machine with loopback devices.
Ceph has multiple daemons that would need to be running: monitor, manager, OSD (1 per storage device), and RADOS Gateway (RGW). If you only had a single storage device it would still be 4 daemons.
systemd has been the de facto standard for over a decade now and is very stable. I have found that even most people who complained about the initial transition are very welcoming of its benefits now.
Depends a bit on how you define systemd. Just found out that the systemd developers don't understand DNS (or IPv6). Interesting problems result from that.
> Just found out that the systemd developers don't understand DNS (or IPv6).
Just according to Github, systemd has over 2,300 contributors. Which ones are you referring to?
And more to the point, what is this supposed to mean? Did you encounter a bug or something? DNS on Linux is sort of famously a tire fire, see for example https://tailscale.com/blog/sisyphean-dns-client-linux ... IPv6 networking is also famously difficult on Linux, with many users still refusing to even leave it enabled, frustratingly for those of us who care about IPv6.
Systemd-resolved invents DNS records (not really something you would like to see, makes debugging DNS issues a nightmare). But worse, it populates those DNS records with IPv6 link local addresses, which really have no place in DNS.
Then, when after a nice debugging session why your application behaves so strangely, all the data in DNS is correct, why doesn't it work, you find that this issue has been reported before and was rejected as won't fix, works as intended.
Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS.
i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively) DNS records.
The debug tool for this is `getent ahosts`. `dig` is certainly useful, but it makes direct DNS queries rather than going via the system's name resolution setup, so it can't tell you what your programs are seeing.
systemd-resolved responds on port 53. It inserts itself in /etc/resolv.conf as the DNS resolver that is to be used by DNS stub resolvers.
It can do whatever it likes as longs as it follows DNS RFCs when replying to DNS requests.
Redefining recursive DNS resolution as general 'name resolution' is indeed exactly the kind of horror I expect from the systemd project. If systemd-resolved wants to do general name resolution, then just take a different transport protocol (dbus for example) and leave DNS alone.
It's not from systemd though. glibc's NSS stuff has been around since... 1996?, and it had support for lookups over NIS in the same year, so getaddrinfo() (or rather gethostbyname(), since this predates getaddrinfo()!) have never just been DNS.
systemd-resolved normally does use a separate protocol, specifically an NSS plugin (see /etc/nsswitch.conf). The DNS server part is mostly only there as a fallback/compatibility hack for software that tries to implement its own name resolution by reading /etc/hosts and /etc/resolv.conf and doing DNS queries.
I suppose "the DNS compatibility hack should follow DNS RFCs" is a reasonable argument... but applications normally go via the NSS plugin anyway, not via that fallback, so it probably wouldn't have helped you much.
I'm not sure what you are talking about. Our software has a stub resolver that is not the one in glibc. It directly issues DNS requests without going through /etc/nsswitch.conf.
It would have been fine if it was getaddrinfo (and it was done properly) because getaddrinfo gives back a socket and that can add the scope ID to the IPv6 link local address. In DNS there is no scope ID, so it will never work in Linux (it would work on Windows, but that's a different story).
If you don't like those additional name resolution methods, then turn them off. Resolved gives you full control over that, usually on a per-interface basis.
If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.
It's not broken - it's a tradeoff. systemd-resolved is an optional component of systemd. It's not a part of the core. If you don't like the choices it took, you can use another resolver - there are plenty.
I don't think many people are avoiding systemd now - but those who do tend to do it because it non-optionally replaces so much of the system. OP is pointing out that's not the case of systemd-resolved.
It's not a trade-off. Use of /etc/resolv.conf and port 53 is defined by historical use and by a large number of IETF RFC.
When you violate those, it is broken.
That's why systemd has such a bad reputation. Systemd almost always breaks existing use in unexpected ways. And in the case of DNS, it is a clearly defined protocol, which systemd-resolved breaks. Which you claim is a 'tradeoff'.
When a project ships an optional component that is broken, it is still a broken component.
The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.
Yes, violating historical precedent is part of the tradeoff - I see no contradiction. Are you able to identify the positive benefits offered by this approach? If not, we're not really "engineering" so to speak. Just picking favorites.
> The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.
I'm well aware - my day job is writing networking software.
That's the main problem with systemd: replacing services that don't need replacing and doing a bad job of it. Its DNS resolver is particularly infamous for its problems.
Um, if they are asking for an avenue to do so, probably yes?
I personally spend hundreds a month on charitable donations - to political advocacy groups, social outreach organizations, and to open-source software that provides me immense value. I think this is one of the most direct ways I can influence the world around me.
It is well known in fund raising most people who say they would donate will not donate. And anyone can give Mozilla Corporation money now by subscribing to their services.
I'm not sure this is exclusive to fundraising - the same is said in business about people who will actually purchase a product, versus those that say they will. Regardless, the comment felt unnecessary in context.
And for what it's worth - subscribing to services is not really the same. For one thing, it puts a cap on how much I can (reasonably) provide.
My rear view mirror does this, I wish my side mirrors did too. Although recently I've noticed some cars headlights can even pierce my rear view mirror's polarized dimming. It never used to be a problem in the past. I've seen the difference when drivers turn their high beams on and off. It always did a great job against driver's brights including large trucks. But occasionally there's now a vehicle with the light of a thousand suns that is too bright for the auto-dimming.
reply