yeah, could be. IBM has been working on AI for ages. They have been able to make a splash with events in chess and Jeopardy, but can't seem to keep up the interest. Of only IBM had the marketing skills as good as some of their research.
Seems to me that IBM is trying to differentiate their AI from others by offering a complete solution that can be self-hosted.
The part that cannot be produced locally, the core model, IBM publishes the inputs and indemnifies. From there, IBM and RedHat provide a holistic solution for fine-tuning, pipelines, and a platform to run on (RHEL AI and OpenShift) that endeavors to "just work."
The fine-tunning tool can be used on any model from Huggingface. So could the pipeline tooling. IBM is saying that they are trying to build core models that are more friendly to fine-tuning. Smaller, faster, and more focused.
They are not trying to be OpenAI or Anthropic, but the IBM models could be a really nice fit for many applications.
Ah, AOLServer! I remember using it when it was NaviServer. I helped to launch my employer's website (packardbell.com) on NaviServer on Solaris way back then. Some of the things I liked:
* It had a decent HTML editor that our marketing people could easily use to update news items on the website. The editor talked directly to NaviServer in a WebDAV-ish way to browse and edit the files.
* It was packaged with Illustra RDBMS for full-text search of the hosted website. Never heard of Illustra? Neither had I back then, but when I fired up the Illustra CLI, it looked awfully familiar! I quickly learned that Illustra was a commercialized version of Postgres.
* I emailed the vendor at the time for a Linux port. The response was that Linux didn't have proper threading libraries. This is back when Linux had sub-par support for threads in the libraries. I replied with a pointer to a thread on LKML about Linux kernel-level threading (IIRC, clone()) and the response was that the functionality looked similar to Irix, and they would try a port. They released a Linux port not long after.
* NaviServer didn't just serve HTML pages. It was also a basic application server due to integrated tcl. I never really mastered tcl, but I was able to build a basic repair center lookup page on the site.
All this back in the mid-90's!
In many ways, NaviServer was way, way, way ahead of its time.
You are correctly. I was imprecise. They were trusting another company to peer for them. They thought they were purchasing "CDN services". The problem is that one of those companies was Cogent. Cogent prides itself with settlement-free peering. But since Netflix put so much traffic onto Cogent's network, it caused traffic to push beyond the peering agreements. Cogent didn't want to pay for peering. Once Netflix took on peering themselves, things went much, much better and the customers have been pretty happy ever since.
If Netflix understood peering from the beginning, they wouldn't have ran into these issues and might have saved themselves some money.
Peering is what saved the Internet back in the late 90's through early 2000's and proved Metcalfe wrong. People using the Netflix problem to push for NN were wrong.
But Netflix was NOT paying transit. They were paying for peering. Transit costs more. To reduce costs, they peered with large networks. The problem is that the company they paid to setup peering (Cogent) didn't want to risk their settlement-free peering agreements. Cogent would have had to start paying for peering. It turned out it was much better for Netflix to setup their own peering agreements.
That is my reaction. Am I missing something here? Are Net Neutrality rules getting in the way?
I know when the NN topic was really hot, many were conflating treating the packets the same with peering agreements. Peering has nothing to do with NN.
Years ago people were complaining about Netflix performance issues and thinking that the ISP was throttling Netflix when it was an issue with peering capacity.
If the rules in the EU mess with peering negotiations, then the rules need to be fixed.