eyalm

Cloud native/kubernetes race is just exploding.

RH strategy was mostly focused around OpenShift lately, which makes complete sense. Kubernetes is the next datacenter OS, just as ESX (and virtualization in general) was in the past 15 years and it's going to drive a radical shift in the enterprise IT world in the coming years. IBM (as an active member of the kubernetes community) see that huge opportunity and are doubling down on their efforts.

Any bets on the next player in this space to be acquired by an IT behemoth? Docker and Rancher both come to mind.

The Nazis established a massive, systemic and vicious program for the complete annihilation of any "enemy" of the aryan race, and by "enemy" we are talking about innocent jews, Romani and many more (although, the complete annihilation of the jewish people was it's main target). You may know this as the "Final Solution". I'm not aware of any event in modern human history that resembles the scale, the intent, the execution level and the pure evil that makes the final solution program.

This does not mean that other atrocities done by any other group of people (including the "allies") are not horrific and should not be condemned or remembered. But, the final solution should always be remembered as an extreme, unique and singular event in modern human history.

"Console hacking 2010"[0][1] - The story and history of the different hacks and security bypasses around the Sony PlayStation 3 gaming console. Absolutely brilliant.

[0] https://events.ccc.de/congress/2010/Fahrplan/events/4087.en.... [1] https://www.youtube.com/watch?v=8KNZsNTPlec

The title here is misleading. The vulnerabilities were not actually publicly disclosed, the only thing that was disclosed publicly is the fact that the vulnerabilities exist. The actual details of the vulnerabilities were disclosed privately with AMD.

> These are people that regularly write good quality code themselves, but there is a high amount of distrust. Why doesn't a team of talented programmers trust each other?

This has nothing to do with trust or any other personal matter. Everybody makes mistakes, everybody might misinterpret code they use and not every programmer has a complete understanding of the scope of the changes they are making. This happens for both senior and junior engineers. (Obviously one would expect this happening much less for seniors)

The only way minimising the amount of future issues is to have thorough, rigorous and pedantic code reviews. Another major benefit for this approach to code reviews is having more people on the team understand deeply the component you coded.

I'll add to that - It is still very easy to hijack SMB connections and use it steal the NTLM hash in almost any network with Windows machines (Managed with a DC or not). Just go ahead and try [1] (Disclaimer - running responder.py without authorization might be considered as a crime and I do not take any responsibility for it. I encourage you to use it only if you understand what you are doing and you have full permission to do it).

[1] https://github.com/SpiderLabs/Responder

Not really. Requires to have the CAP_NET_RAW capability, which is pretty rare. (This capability allows you raw access to the network interface, which is usually only given to the root user)

Bottom line - locally exploitable vulnerability in the linux kernel, in case you have the CAP_NET_RAW capability which never really happens. Not a real security threat for your standard linux distro.

On the other hand, this is a great technical write-up that describes thoroughly the internals of some of the linux kernel subsystems. Probably the best documentation you can find for some subsystems. Also shows how they bypassed exploit mitigations technics such as KASLR, SMAP&SMEP.