I think the more interesting question is how much longer does oracle have and at what point does a hostile takeover make sense.

Their databases are heavily used in government, banking and other large industries which have been slower to adapt to change and strugglyto migrate away. At what point does purchasing oracle to gain customer share, existing data centres and the opportunity to migrate to your cloud platform make more sense than competing?

They still have a high market value. However, the debt they will need to service will result in ongoing price increases which will encourage people to migrate away. Over time they will struggle to service the debt and a buyout will be the best of the bad options.

I think it's a reasonable idea. It's mostly going to affect the "luxury" brands who attempt to limit price reductions.

Perhaps it might encourage producers to do smaller runs to confirm interest before massively increasing volumes. The real issue is to get the lowest price you need to hit minimum volumes. It's cheaper currently to burn unused stock than store it for next year. This may change that model. If it doesn't work it can always be changed.

I'd argue that it has failed in some organisations. DevOps for me is embedding the operations with the development team. I still have operations specialist, however, they attend the development team stand ups and help articulate the problems to the developers. They may have separate operations standups and meetings to ensure the operations teams know what they are doing and share best practices. Developers learn about the operations side from those that understand it well and the operations experts learn the limitations and needs of the developers. Occasionally I am fortunate to discover someone's that can understand both areas incredibly well. Either way, this results in increased trust and closer working. You don't care about helping some random person on a ticket from a tream you don't know. You do care about the person you work with daily and understand the problems they have.

If you can't account for someone spending x% of their time working with a team but for budgetary purposes belonging to a different team then sack your accountants.

DevOps,like agile, when done correctly should help to create teams that understand complete systems or areas of a business work more efficiently than having stand alone teams. The other part of the puzzle is to include the QA team too to ensure that the impact of full system, performance and integration tests are understood by all and that both everyone understands how their changes impact everything else.

Having the dev team build code that makes the test and ops teams life easier benefits everyone. Having the ops team provide solutions that support test and dev helps everyone. Having test teams build system that work best with the Dev and ops teams helps everyone.

Agile development should enable teams to work at a higher level of performance by granting them the agency to make the right decisions at the right time to deliver a better product by building what is needed in the correct timeline.

DevOps and agile fail where companies try to follow waterfall models whilst claiming agile processes. The goal with all these business and operating models is to improve efficiency. When that isn't happening then either you aren't applying the model correctly or you need to change the model.

I was very specific in using the word generally. I taught a mixture of computer science and electronic engineering students. About three to four times more electronic students were competent for every computer science student over the years I taught.

It's not a case of just stating computer scientist weren't capable of doing it. They struggled with the parallelism and struggled with the optimisations and placements when you had to make physical connections on chips.

I'm well aware it's mostly going to be computer scientists writing the tools we use.

For those that want FPGAs to take off like the Arduino platform, I agree. I'd love it. However, it isn't the tooling that's holding it back. The reality is it is that cheaper, faster and easier solutions already exist. Why would you use an FPGA?

The issue with the software team using an FPGA is that software developers generally aren't very good at doing things in parallel. They generally do a poor job in implementing hardware. I previously taught undergraduates VHDL, the software students generally struggles with the dealing with things running in parallel.

VHDL and Verilog are used because they are excellent languages to describe hardware. The tools don't really hold anyone back. Lack of training or understanding might.

Consistently the issue with FPGA development for many years was that by the time you could get your hands on the latest devices, general purpose CPUs were good enough. The reality is that if you are going to build a custom piece of hardware then you are going to have to write the driver's and code yourself. It's achievable, however, it requires more skill than pure software programming.

Again, thanks to low power an slow cost arm processors a class of problems previously handled by FPGAs have been picked up by cheap but fast processors.

The reality is that for major markets custom hardware tends to win as you can make it smaller, faster and cheaper. The probability is someone will have built and tested it on an FPGA first.