An AI has no capability to have feelings

And what is a feeling? Based on Wiki:

In other words, a feeling is a reaction to an external stimuli. Since reactions are nothing but the neural connections in our brains responding to the external stimuli, there is little reason to say an AI, with its digital connections, can't respond to external stimuli in a similar fashion.

Bcause your sister couldn't be bothered to write things down, this is MS' fault?

I personally pronounce giraffe with a soft G. So it would be geraff and not jiraff.

Don't hate the player.

RealID is so important to security, it can't be used to prove you are a U.S. citizen. So says DHS, the people administering the RealID program.

Do you really mean that if your git repo were corrupted, restoring a snapshot of the repo from backups wouldn't work? If that's true, then it sounds like your backup system is broken. The hashes after restoring ought to be identical to what they were before the backup.

If git used the files' iNode numbers for its hashes, then I could understand how a filesystem-based backup/restore might not really work; you'd have to backup at the block level instead. But git doesn't use the iNode numbers.

git isn't magical. It only knows files. It doesn't know if you moved the repo, copied the the repo, or restored the repo from a ten year old backup. I have moved git repos around plenty of times, `cp -a`ed directories with repos, tared and un-tared directories that contain repos, and the copies have always Just Worked without any hash mismatches.

mkdir ~/test. cd ~/test. git init, touch test.txt, git add test.txt and git commit. cp -a ~/test ~/test2. cd ~/test2 and check out the backup repo. The backup is valid. Then simulate a disaster with rm -rf ~/test. Then recover from the disaster with cp -a ~/test2 ~/test and you've just restored a repo from filesystem-level backup. The resulting repo works perfectly and its hashes aren't off. git has no idea you deleted and restored under its nose. Try it yourself.

What am I missing? I'm not surprised to be called idiotic, and the shoe often fits. But I'm surprised to be called that over this.

My router's hardware's parts were made in China. Its software was made as a worldwide effort but the team seems to be officially based in the Netherlands. And I'm not asking my government's permission for updating either one. Trumptards and their micromanaging far-left centralized-economic-planners can go fuck themselves. Keep your damn dirty ape hands off my computers, comrade.

No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.

Now if you're imagining some alternate world where programmers an be moved at will- then we're already one big team instead of multiple small teams.

And no, a smaller team doesn't win every time. If it did, then then smallest team possible is teams of 1 and we'd all do that. There are sweet spots, which depend on the organization, the work to be done, and the importance of that work. For some that's bigger, for some smaller. I've definitely worked on teams that were both too small for the work, and that were too big.

They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.

They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.

In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.

There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown to low technical knowledge customers frequently (in other words anything that actually needs weeks or months of backend work, algorithm writing, or infrastructure to be written).

The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.

There are a couple of ways to solve this problem:

1)Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.

2)Each manager managing multiple independent teams. This can work if it doesn't overload the manager. The biggest problem is when the manager decides one team is more important and doesn't support the other(s) enough. This works better the closer the teams are, as it requires the manager to know fewer sets of collaborators and politics

Is there room for consciousness to manifest in a brain?

And should be treated as such.

No enterprise concerns if you can just tick a policy box.

And for home users, people who don't know what GPO is let alone have access to it? They're just screwed, aren't they?

There was no issue until Israel drug the U.S. by the nose into a war it can't win.

Remind everyone again who it is that keeps attacking its neighbors claiming "self defense" then whines it's the victim? Or who has been saying another country is "two weeks away" from nuclear weapons for the past 40 years?