Don't think that SSO is a magic solution for all of this. I'd say SSO won't work with any of it. SSO will work for new integrations but typically a team and team members will need passwords or API keys or tokens (all of these are strings, in effect passwords), and for that, beyond SSO, I have used and can recommend, for many teams in large organisations:

- A secrets manager (e.g. AWS Secrets manager) with an API key for each team, and the team can access their secrets on a team level there

- An encrypted file encrypted with e.g. KeePass, and one password for that

- Bitwarden or Lastpass on a team or department level (yes, shared passwords, for example where there is one password for one proxy)

- Yopass https://yopass.se/

int *ptr;

// but let's change it to *int ptr;

// because the pointer symbol is more logical to write first

Please can we solve a real problem instead?

I read a book from 1960 about Quantum Mechanics. There is more content from one paragraph there than from anything from your AppleTV, your Facebook, your WhatsApp, your Telegram or anything else from your stupid overpriced trash media. Ken Thompson is right when he calls Apple an atrocity. Linux and Framasoft are not terrorist organisations but I'm not sure about any other.

The statement looks very misleading or even fraudulent. I used a system with 192 cores often and with GNU parallel, it did not stagnate at 8 parallel tasks for simple demonstrations. If we're talking about a case where 8 is intentionally the maximum (it's possible that some tasks should not parallelize more than 8), then the statement is misleading as well, since it gives the wrong impression. I have the service tag and the output from nproc and the exact version of everything where I used 192 CPUs. I suppose pseudoscience will always return and claim that the statement is true anyway, no matter what observations the rest of the world can give. There is pseudoscience forever who always says that the rest of the world is misunderstood.

My favorite is The Turtle Book "Computer Science" by Aho & Ullman. I also liked the books "Computer Algorithms" (by Baase et al), The Wizard Book, The Dragon Book, The Tiger Book (about compiler) and "The Comet Book" (about os)

Wasn't Hush already the name of the HUmbleSHell ( Hush is a Bourne/POSIX-style shell that was originally part of BusyBox ) ...https://github.com/sheumann/hush

Yes, and it lives on in a variety of minimalist environments under active development, such as:

* U-boot: https://github.com/u-boot/u-boot/blob/master/common/cli_hush...

* Busybox: https://github.com/brgl/busybox/blob/master/shell/hush.c

* Barebox: https://github.com/barebox/barebox/blob/master/common/hush.c

Because 60 % of the people were managers?

Whereas this may be a common reason for failure, we failed because we were all engineers. Nobody with management/sales experience on the team!

I'd love to hear what an ideal ratio is? Somewhere between 10-25%?

Depends on if you have team leads, that generally "manage and steer" with general autonomy of a larger manager or director. I'd say 10-15%, past that it's cruft.

The strength of the leadership and managers is really a key component of how much % is required.

The ideal ratio is the one that makes sales and products.

1) GitLab CI/CD does almost everything for us 2) Everything runs inside corporate network and all network traffic is monitored 3) One must get a permit from the company's security auditors 4) A major one

You can try and just gain more experience and solve problems for more organizations and companies. Have a GitHub or GitLab profile with your projects. Worst case, get any programming gig, try and solve the problems for them, then you can get a reference from them and move on.

Yep yep, I have a github. As for solving problems for companies and stuff, how would I go about that? Like finding small companies where I offer my services for free?