colburnmh

A few ideas to consider:

Do you mandate working tests and reasonable test coverage as part of your checkins? That could help, but it if you don't currently do that, productivity will drop further before it picks up. But that's the nature of any impactful change.

When there absurd back and forth on PRs, step-in and mediate a resolution. Pull the people into a room and require a resolution before anyone can leave--drastic, but soon people will realize that they pay more for pointless whinging. It's not doing the company any good for pointless bickering, and it's not improving the product either.

Considering using an external code-review as a service like PullRequest while you are gone. And maybe keep them if it works well.

No, the police bear no responsibility for someone issue a false report. That's a crime for a reason. If you report your car stolen, the police don't first investigate you to be sure you are telling the truth, they just work to find the car.

The police do, however, bear responsibility for not allowing those arrested to have access to medication, maintain their jails to appropriate health standards, or prevent assaults--all of which were also reported in the article.

Further, if a person is constantly falsely reporting their car stolen, they should be arrested for filing a false report. But in this case, there is no central authority that would be in a position to track that because there is no centralized control of the police and these all probably happened in different police districts.

Mistakes do happen, but this sounds like a pattern of egregious behavior that is likely (and rightly if the facts in the article stand up) going to result in large fines, mandated oversight, legal restraint, and removal of a number of people at Hertz. It's not like any of that is going to be helpful to a company that is struggling to stay alive.

Presidents, like leaders in business or the military, realize that they don't have the current experience, situational knowledge, or training necessary to dictate details on the ground. Therefore, they dictate high-level foreign policy, political, and strategic military goals and delegate the strategic and tactical details to the military leaders who have the appropriate knowledge to carry them out. Occasionally, they get involved in specific tactical decisions, like authorizing politically sensitive actions (e.g., the Bin Laden raid).

You would not expect the CEO of a large multi-national company to manage all of the details of every department within their company. When you combine all 5 of the armed forces together, it's far more complex than any company on earth, and managing the military is not the President's only responsibility.

The President's direction of the military is also bound, to some degree, by the Legislative and Judicial branches of the government. For example, they can't declare war on a country unilaterally. But those restrictions, while important, are not particularly constraintaining at a day-to-day level. The President has wide latitude to direct the military as they see fit. That includings projecting military power as deterrents against hostile foreign powers or engaging in short-term, small-scale offensive operations abroad.

So, no, Presidents aren't going to the front lines and directing troops like kings of old. That went out of fashion around the time of Napoleon. But good business leaders don't micromanage their workers and departmental details, either. They realize, hopefully, that doing so would do more harm than good.

MIT might be a better license for broad adoption. Both GPL and LGPL are viral licenses. They serve a purpose, but you need to assess if that purpose is the same as yours.

The one that allows you to run your application on the computer you are using.

Data in iCloud is going to be encrypted by the host provider in-transit and at rest. That is not the same as being encrypted at the source by Apple. It means that Google, Amazon, Azure (and whatever other platforms Apple uses for iCloud storage) will be doing that encryption with keys that they have for Apple. All the major vendors have storage encryption both in-transit and at rest. I suspect that it would be a requirement from Apple for any future vendor, too.

It does mean that the data is not sitting in clear-text form on the provider's disks. But the exact details of that encryption may vary from provider to provider.

They do. I saw it happen.

In many ways it's really a meta-rant on the criticism's he's received about his first article. And where it's not, it is mostly just re-litigating the same arguments he made previously, which could be summed up as "Go is not Rust". "Go doesn't have sum types", "no immutable types", "no operator overloading", etc. Yes, Go is not Rust. It's also not Java, or Lisp, or C.

Rust and Go have very different language models with very different design goals:

Go was designed to be a very simple language to understand and develop in where reasoning about the program is very easy. The language spec can be read and understood in under a day, and programmers can be reasonably proficient in a week. It was designed to be a system language at Google, where there are lots of smart developers that may know how to code but may not know one of Google's "Big Four" languages (Java, C++, Python, and now Go). Many of the design trade-offs were made to specifically address common code problems found in both the Google and the various Bell Labs code-bases. (Pike and Thompson both worked at Bell Labs before Google.) For example, the lack of operating overloading in Go was not an oversight, it was an explicit design decision arrived at through looking at millions and millions of lines of code: operator overloading is frequently misused and creates subtle, difficult to debug errors.

Rust, on the other hand is a very difficult language to learn and master: the borrow-checker is a harsh mistress, and learning the memory model takes time, practice, and significant cognitive load. The reward for climbing that steep learning curve is the resulting code should be easy to reason about and be very safe. But, Rust code can be inscrutable and have errors and security problems, too, it's just much harder to do than it is in many other languages.

Which one is right? Depends on your goals. Go allows you to solve problems quickly and onboard developers very quickly. Rust requires much longer developer onboarding but provides strong safety guarantees. Both have their place.

Ultimately, the author is arguing in bad faith. There is no objective assessment of the two languages' strengths and weaknesses. And he points out sharp edges in Go--some of which are contrived examples that are explicitly antagonistic to the language design--without acknowledging that Rust is anything less than perfect.

And some of the examples he gives are valid, but are not the indictment that he claims. For example, the Tailscale netaddr.IP article shows that while the design of Go's standard library implementation of the network address type has a number of design issues when used at very large scale. But it also shows that it's possible to create a set of types that satisfies even Tailscale's production demands.

Go has limitations and some sharp edges, but so does every language, especially when used in ways that go against the language design. That doesn't make Go the useless, idiosyncratic development tool that his titles and prose imply.

Board members' opinions always count. However, individually, they may not be influential enough to change the direction of the company, which I think is what you are saying?

True to an extent--meaning mostly true in practice.

You can mutate the Git data if you chose to using commands like "filter-branch". "filter-branch" isn't used frequently, since it causes issues with every up/down-stream replica if the data has been pushed/pulled, but it is possible. But, even some commonly used commands like "amend", "rebase", and "squash" cause limited data mutations which are broadly considered appropriate and useful.

So, what's your opposition to the special district that provides Disney with the ability to maintain it's property is a manner that is consistent with their business needs--which surpass the normal requirements of either Orange or Osceola counties?

Sure it's a benefit to Disney, but it's also a benefit to the county taxpayers:

* Disney subsidizes both counties' services and infrastructure by paying property taxes to pay for services/infrastructure, but not consuming them, or contracting for them where needed.

* Allows counties to avoid costly legal and procedural issues when Disney wants to add new features, attractions, or services at their park, or wish to ensure consistency of services provided by the two different counties.

So, what is the crux of your objection?

As noted elsewhere in this thread: the special district laws and the RCID, specifically, have survived constitutional review by the Florida Supreme Court. The state certainly understands that these laws we deemed constitutional.

The state doesn't, the taxpayers of Orange and Osceola counties pay for it.

Given that this law went from draft to law in under 96 hours, it's hardly surprising that the implications were not fully reviewed or understood by the legislature. Further, a number of the points being discussed here were brought up in conversations before the law was passed, so it's not like the legislators couldn't have, or shouldn't have known--they just chose to ignore the issues rather the spend time to understand and address them.