Showing posts with label Data Center. Show all posts
Showing posts with label Data Center. Show all posts

Nestspace

Mike's Notes

Thursday, 09/04/2026 (NZ time) was the longest day. I couldn't make a single mistake, so I turned off the phone and the internet to concentrate from 8am to 9pm, then slept like a log. I was a walking zombie yesterday. I'm glad this will never need to be done again.

This is the successful culmination of months of mentally challenging preparatory work for the new Pipi Core data centre.

A typical day for me is

  • 50% learning
  • 40% thinking
  • 10% doing

The less I do, the more productive the solutions. The faster the progress.

Speed will come from Pipi-driven automation, not Mike working harder.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/07/2026

Nestspace

By: Mike Peters
On a Sandy Beach: 10/04/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Inside the Pipi Core data centre, the careful migration and reorganisation of hundreds of thousands of Pipi-related files began and were completed yesterday. Each file or directory was placed in only one Nestspace, and then the historical Nestspaces were converted into zip​ archives

It is a good solution, but it took a month of trial and error to figure out. It had to be 100% correct to enable rapid, reliable data centre automation, self-managed by Pipi.

It was fascinating to watch the recent Lex Fridman interview with NVIDIA CEO Jensen Huang, who described NVIDIA's large-scale problem-solving process.

Problems to solve

A large number of problems had to be solved in parallel. Each problem affected the others.

  • Where to put self-organising Pipi swarms.
  • Pipi instances
    • Naming
    • Self-evolving
    • Versioning
  • How to use DevOps automation with all of the above.
  • The knock-on effects on
    • Namespaces
    • Backups
    • Replication
    • Accounts
    • Workspaces
    • i18n
    • Web URLs
    • Developer documentation
    • Training
    • etc.
  • Securing 100% security and privacy
  • Cross-platform and environment portability

This has led to changes in the underlying Pipi System Engine (sys) data model, which I will write about tomorrow.

Nestspace

The fundamental organising principle is to use a uniquely named directory, now named as a "Nestspace".

The unique name is a string combination made of

  • <pipi major version> (integer)
  • <pipi edition> (single lowercase letter)
  • <account type> (single lowercase letter)

Data Centre / DevOps

Here are some examples.

  • 6pg/
  • 9ae/

Backups

Customer backup examples.

  • pipi_9ae_ajabbi_data_pg_20260411
  • pipi_9ae_ajabbi_pipi_www_learn.ajabbi.com_20260411

Archiving

Here are some examples.

  • pipi_6pg_20180219.zip
  • pipi_9ae_20241211.zip

Next job

Now, I can start configuring the files and settings for each Nestspace. The necessary code has already been successfully tested. Eventually, this process will be completely automated.

  • Application.cfc
  • server.xml
  • Datasources
  • OS environment
  • Java
  • Application server
  • Cloud platform
  • REPL

Speed is King

Then, each Pipi will be back in business and can be left running 24x7 in its own Nestspace, thereby increasing DevOps speed by at least 10x. The priority now is to increase Pipi's Data Centre speed by 1000x using automation and keep going. So what previously took a year can be done in an hour. The over-optimistic complete deadline is June 2026.

But nothing happens as expected

It is hard to make completion predictions when this architecture is completely novel, and everything is uncharted territory and hellish difficult. Everything is a back-of-the-envelope guess. I'm slowly getting there ... 

"like a man riding a drunken donkey facing the tail, two steps forwards, one step backwards"

... enjoying the whole journey and it's a hell of a lot of fun. 

Future customers

The increase in speed will also directly benefit all future customers using the SaaS workspace applications. Deployments, configuration, and updates will also get the same 1000x speed increases at no extra cost.

Pipi three-data-centre model revisited

Mike's Notes

I was greatly influenced by a recent article by Gennaro Cuofano in The Business Engineer about how Apple ensures Privacy.

Gennaro wrote ..."

Apple’s response is not to win training. It is to dominate inference

Apple’s strategy is internally coherent:

Tier 1: On-device inference

    • Small local models handle personal and contextual tasks.
    • These run without network dependency and with minimal privacy leakage.

Tier 2: Private Cloud Compute

    • Apple Silicon-based servers handle workloads beyond device capacity.
    • The architecture is stateless and privacy-preserving.

Tier 3: Third-party frontier models

    • Apple relies on external model providers such as Google and OpenAI for world knowledge and advanced reasoning.
    • These models are treated as backend commodities underneath Apple’s interface layer.

..."

Update 18/06/2026

Use Data Diodes. Prices start at $5K

A Data Diode is a physical device that allows data to travel only in one direction.

  • How it works: Inside the device, a fibre-optic LED transmitter sends light to a receiver on the other side. There is no return fibre cable physically.
  • Security benefit: It is physically impossible for a hacker to send a command back or steal data through a write-only data diode because the hardware cannot transmit in reverse.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Business Engineer
  • Home > Handbook > 

Last Updated

30/07/2026

Pipi three-data-centre model revisited

By: Mike Peters
On a Sandy Beach: 29/03/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Data Centres

Because of its unusual architecture and the priority it places on privacy and security, Pipi needs three separate data centres that work together in a chain.

Rendering > Staging > Cloud

  • Rendering: Build enterprise applications.
  • Staging: Send updates, localise and deploy enterprise applications.
  • Cloud: Hosting of enterprise applications for scaling and integration.

I like the way Apple ensures privacy for people using AI on their iPhone. Any extra AI work is offloaded to Apple's cloud servers for processing, which are stateless and store nothing. That got me thinking.

Could part of Pipi be made stateless to add extra privacy like Apple?

The way Pipi is designed;

  • Rendering: Unable to see any customer data.
  • Cloud: Unable to see any Pipi config data.
This is to be done by using separate databases hosted in separate data centres.

Possible data centre model

  • Rendering: This is stateful; each agent-engine has its own database. Each enterprise customer has a separate physical server to host a digital twin.
  • Staging
    • Inwards-server: Receive anonymised logs
    • Outwards-server: Send updates, localise and deploy enterprise applications.
  • Cloud: This would be stateful using customer-eyes-only databases.

Would that work? How?

Network Security Design

It seems that maximum security can be achieved by using physical "air-gaps" initially, followed by data diodes. Use shielding and Faraday Cages to protect against EMR and acoustic leakage. Disable or remove Bluetooth and WiFi.

These New AI Models Are Trained on Physics, Not Words, and They’re Driving Discovery

Mike's Notes

A fantastic use of AI. My instinct is to incorporate fluid-like systems into a future Pipi. That will require a real data centre.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Simons Foundation
  • Home > Handbook > 

Last Updated

19/03/2026

These New AI Models Are Trained on Physics, Not Words, and They’re Driving Discovery

By: Elizabeth Fernandez
Fatiron Institute: 09/12/2025

Elizabeth Fernandez is a science writer specializing in science and society, science and philosophy, astronomy, physics, and geology.

While popular AI models such as ChatGPT are trained on language or photographs, new models created by researchers at the Flatiron Institute and other members of the Polymathic AI collaboration are trained using real scientific datasets. The models are already leveraging the knowledge they learn from one field to address seemingly completely different problems in another.

The Walrus AI model simulates fluid motion.

Walrus/Polymathic AI

While most AI models — including ChatGPT — are trained on text and images, a multidisciplinary team of scientists has something different in mind: AI trained on physics.

Recently, members of the Polymathic AI collaboration presented two new AI models trained using real scientific datasets to tackle problems in astronomy and fluidlike systems.

The models — called Walrus and AION-1 — are unique in that they can apply the knowledge they gain from one class of physical systems to seemingly completely different problems. For instance, Walrus can tackle systems ranging from exploding stars to Wi-Fi signals to the movement of bacteria.

That cross-disciplinary skill set is particularly exciting because it can accelerate scientific discovery and give researchers a leg up when faced with small samples or budgets, says Walrus lead developer Michael McCabe, a research scientist at Polymathic AI.

“Maybe you have new physics in your scenario that your field isn’t used to handling. Maybe you’re using experimental data, and you’re not quite sure what class it fits into. Maybe you’re just not a machine-learning researcher and just can’t burn the time working through all the possible models that might fit your scenario,” McCabe explains. “Our hope is that training on these broader classes makes something that is both easier to use and has a better chance of generalizing for those users, as the ‘new’ physics to them might be something another field has been handling for a while.”

Using cross-disciplinary models can also improve predictions when data is sparse or when studying rare events, says Liam Parker, a Ph.D. student at the University of California, Berkeley, and a lead researcher developing for AION-1.

The Polymathic AI team recently announced Walrus in a preprint on arXiv.org and presented AION-1 on Friday, December 5, at the NeurIPS conference in San Diego.

Walrus and AION-1 are ‘foundational models,’ meaning they’re trained on colossal sets of training data from different research areas or experiments. That’s unlike most AI models in science, which are trained with a particular subfield or problem in mind. Rather than learning the ins and outs of a particular situation or starting from a set of fundamental equations, foundational models instead learn the basis, or foundation, of the physical processes at work. Since these physical processes are universal, the knowledge that the AI learns can be applied to various fields or problems that share the same underlying physical principles. Foundational models have a host of benefits — from speeding up computations to performing well in low-data regimes to finding physics shared across different fields.

AION-1 is a foundational model for astronomy. It is trained on data from astronomical surveys that are already massive in their own right: the Legacy Survey, the Hyper Suprime-Cam (HSC), the Sloan Digital Sky Survey (SDSS), the Dark Energy Spectroscopic Instrument (DESI) and Gaia. All in all, that’s more than 200 million observations of stars, quasars and galaxies totaling around 100 terabytes of data. AION-1 uses images, spectra and a variety of other measurements to learn as much as it can about astronomical objects. Then, when a scientist obtains a low-resolution image of a galaxy, for example, AION-1 can extract more information about it, learned from the physics of millions of other galaxies.

Walrus’ domain is fluids and fluidlike systems. Walrus utilizes the Well — a massive dataset compiled by the Polymathic AI team. The Well’s data encompasses 19 different scenarios and 63 different fields in fluid dynamics. All in all, it contains 15 terabytes of data describing parameters such as density, velocity and pressure in physical systems as wide-ranging as merging neutron stars, acoustic waves and shifting layers in Earth’s atmosphere.

Such foundational models can be powerful. AION-1 and Walrus can utilize physics seen in a different case and apply it to learn about something new. It is similar to our senses. “Multiple senses together — rather than one at a time — gives you a fuller understanding of an experience,” the AION-1 team explained in a blog post about the project. “Over time, your brain learns associations between how things look, taste and smell, so if one sense is unavailable, you can often infer the missing information from the others.”

Then, when a scientist is performing a new experiment or observation, they have a starting point — a map of how physics behaves in other similar situations. “It’s like seeing many, many humans,” says Shirley Ho, Polymathic AI’s principal investigator and an astrophysicist and machine learning expert. Ho is a senior research scientist at the Flatiron Institute and a professor at New York University. When “you meet a new friend, because you’ve met so many people before now, you are able to map in your head … what this human is going to be like compared to all your friends before,” she says.

Foundational models make scientists’ lives easier by streamlining data processing. Scientists will no longer have to create a new framework from scratch for every project or task; instead, they can start with an already trained AI to use as a foundation. “I think our vision for some of this foundation model is that it enables anyone to start from a really powerful embedding of the data that they’re interested in … and still achieve state-of-the-art accuracy without having to build this whole pipeline from scratch,” says AION-1 lead researcher Parker.

Their goal is to make tools that scientists can use in their day-to-day research. “We want to bring all this AI intelligence” to the scientists who need it, Ho says.


Other Highlights From the NeurIPS 2025 Conference

CosmoBench: CosmoBench is a multiview, multiscale, multitask cosmology benchmark for geometric deep learning. Curated from the state-of-the-art cosmological simulations, CosmoBench is the largest benchmark of its kind, with over 34,000 point clouds and 25,000 directed trees. CosmoBench features challenging evaluation tasks from cosmology and diverse baselines, including cosmological methods, simple linear models and graph neural networks. This presentation will show how CosmoBench is pushing the frontiers of cosmology and geometric deep learning.

Lost in Latent Space: Physicists model and predict the behavior of physical systems using their understanding of the laws of physics. However, these calculations require significant computing power. Flatiron Institute scientists and other members of the Polymathic AI collaboration studied whether a less taxing form of computing can still yield accurate results. Known as ‘latent diffusion modeling,’ this computational model utilizes artificial intelligence to generate high-quality images at a lower computational cost while accurately capturing physical behavior.

Neurons as Detectors of Coherent Sets in Sensory Dynamics: Our perception of touch, taste, sight and pain is mediated by neurons that carry signals from peripheral receptors to the brain. This work shows that these neurons can be understood as detecting ‘coherent sets’ within the sensory stream — groups of stimulus trajectories that evolve together over time and therefore share a common past or a common future. By distinguishing these coherent sets, some neurons predominantly encode what has just occurred, while others reliably signal what is likely to happen next. Traditional classifications of sensory neurons can thus be reinterpreted as reflecting a division between past-focused and future-predictive processing. Understanding how the nervous system separates and transforms sensory input in this way may offer new routes for treating mental illness and may also guide the development of biologically inspired artificial intelligence.

Predicting Partially Observable Dynamical Systems: Scientists can predict the motion of a falling object or the evolution of fluids using deterministic models that compute a single future outcome from past observations. But this approach breaks down for physical systems where much of the state is hidden. A prominent example is the sun: We can observe the activity on its surface, but the processes deep inside remain largely invisible. Without access to those internal conditions, there isn’t enough information to forecast a single ‘correct’ future. Researchers at the Flatiron Institute, together with collaborators in the Polymathic AI project, have developed a probabilistic approach that can infer these hidden solar processes. By incorporating information from the distant past into a diffusion-based generative model, their method produces an ensemble of plausible futures, offering a clearer understanding of how past sunspot activity shapes its future evolution.

Having a Data Centre changes the roadmap

Mike's Notes

This is the revised Pipi roadmap now that the data centre is running. The recent Ajabbi Research report, "The Workspace Issue," has also been revised to reflect these changes.

Update 25/03/2026

A very nice chap from Google contacted me to assist with applying to join one of the Google AI Accelerators. I started the application, then stopped when I realised that the 2 years of support and generous free credits started as soon as it was approved. I need to complete all Stage 1 steps in the roadmap below, and the Stage 2 IaC connection to the GCP free tier to deploy Pipi open-source before applying, to make the best use of the opportunity.

I'm requesting support from Google DeepMind to experiment with connecting Pipi via MCP to DeepMind Gemini and to find a way for Pipi closed-core to use Google TPU. Stage 3 will be highly experimental with unexpected results.

Pipi is a non-generative multi-agent system with no tokens. It doesn't need tokens to work and its 27 layers deep so far and counting. I expect it to get very barnacled and crusty over time.

Update 31/03/2026

Setting up data centre automation has revealed that workspace deployments need to be performed in this order of account types due to the permissions cascade.

  • Agent Accounts (to admin Pipi)
  • Researcher Accounts (to edit UoM, ontologies and physical laws)
  • Developer Accounts (to create enterprise workspaces)
  • Personal Accounts (to sort out personal profiles - UI fonts, etc)
  • Enterprise Accounts (to test and use the system for work)
  • etc

Update 17/04/2026

Containers, named Pipi Nest, were created to deploy Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/04/2026

Having a Data Centre changes the roadmap

By: Mike Peters
On a Sandy Beach: 27/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Having a separate Pipi Core Data Centre changes everything. This has a direct impact on what is possible and on the best path forward. 

This is the revised working Deployment Roadmap for Pipi. The sequence is roughly correct; the timing is just a guess.

Stage 1

Production foundations to enable automation and rapid use.

When Task Detail
February 2026 Migration ✔ Separate networks for the isolated Pipi Core Data Centre and the Ajabbi Office.
March - April 2026 Pipi Nest ✔ Pipi deployment container
April 2026 Mission Control ✔ Telemetry on the Data Centre.
April 2026 AutomationPipi Core running autonomously in a Pipi Nest 24x7x365, with a x10 increase in productivity.
May 2026 Data Centre Admin Agent Workspace rendered by the CMS Engine with no errors.
May 2026 Workspace Workspaces containing 15,000 web pages are rendered by the CMS Engine with no errors.
2026 Workspace Workspace UI Menu rendered without errors.
2026 Workspace Draft in-context help & learning material generated for each workspace without errors.
2026 Workspace Module-based UI forms and data grids rendered with sample data without errors.
2026 Workspace Complete HTML workspace demo with connected initial developer documentation rendered without error
2026 Workspaces for Agents & Developers Workspaces are deployed in the Data Centre for production use by System Admin and DevOps, with a x10 increase in productivity.
2026

2026

2026
2026
2026

Stage 2

Automate Pipi deployment across every available cloud platform, with a free tier.

When Task Detail
2026 IaC Deploy infrastructure on the AWS Free Tier.
2026 IaC Deploy infrastructure on the Azure Free Tier.
2026 IaC Deploy infrastructure on the Digital Ocean Free Tier.
2026 IaC Deploy infrastructure on the GCP Free Tier.
2026 IaC Deploy infrastructure on the IBM Free Tier.
2026 IaC Deploy infrastructure on the Oracle Free Tier.
2026 IaC Deploy infrastructure on the Wasabi Free Tier.
2026
...

Stage 3

Deploy to any platform when admitted to its startup program that offers lots of credits to enable experimentation and scaling with early customers.

When Task Detail

IaC Deploy infrastructure on every non-free part of the platform.

IaC BoxLang VM containing Pipi Open-Source, deployed via IaC.
  MCP, A2A, Skills Pipi > LLM > Pipi
  Working Demo Fully working demo workspaces available for customers and developers to try out.
  Customer Deployments Ajabbi Personal, Developer, and Enterprise account Workspaces are available.
  Customer Deployments Ajabbi Researcher and SME account Workspaces are available.
  Scientific Workflows TPU
 
 

Stage 4

At a certain threshold, Pipi 10 will come into being, creating many more possibilities.

Pipi Data Centre Operational

Mike's Notes

Very good news for Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/02/2026

Pipi Data Centre Operational

By: Mike Peters
On a Sandy Beach: 25/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The long-planned migration of Pipi 9 to its own data centre has been completed. It took 2 weeks to execute. The existing setup was split into an office network connected to the internet and an isolated data centre that is not connected to the internet.

Starting from zero

The initial data centre consists of a single 45U rack and some other shelving, with mainly older equipment. It will do for a start and can grow as more racks are added, equipment upgraded, and more servers are added, etc.

External hard drives being used in the shift

Issues

  • Terabytes of data on backup hard drives to shift
  • Clean reinstalls of many operating systems
  • 14 machines to configure
  • Adobe CS4 does not like Windows 11
  • Making do with what is available now
  • Go slow, think twice and get there faster

Opportunities

  • Pipi on 24x7x365
  • All systems can be turned on using multiple servers
  • DevOps automation is now possible
  • The development cycle will speed up 10x
  • The road to Pipi 10 with BoxLang is now open

Whats next

  • Seat-of-the-pants experimenting to tune the setup
  • Stress test to build resiliency and reliability

Firing up the data centre

Mike's Notes

Work is underway to move Pipi 9 to the beginning of the Pipi Core Data Centre.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

03/03/2026

Firing up the data centre

By: Mike Peters
On a Sandy Beach: 13/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Long planned, Pipi 9's migration to its own data centre is now underway. The job has top priority and should be easily completed in a week.

First, the existing Ajabbi computer network was split into two.

  • A small start on the Pipi Core Data Centre to be built out over time, with an attached Mission Control. It is completely isolated from the internet, with all wifi and Bluetooth disabled. It is largely housed in the first 45U rack and some open shelving.

  • The start of the Ajabbi Office Network. It is connected to the internet for email, Zoom/Meet/Teams calls, office work, writing documentation, minor development, testing, graphics, video editing, office servers, accounts, printing, phones, etc.

Racks

45U Rittal welded rack frames will be added as required. Each with the following standard modular fitout.

  • UPS
  • Individually switched PDU
  • Network switches
  • Monitoring
  • Servers
  • NAS
  • Cooling

DevOps

Developer laptops attached to the isolated rack for server work have the following minimal developer stack.

  • Acrobat
  • BoxLang
  • CFML Server Dev edition
  • DBeaver
  • Dreamweaver
  • GeoServer
  • Grammarly
  • JRE 21
  • MS Access
  • MS Excell
  • NoteTab Light
  • PostgreSQL+PostGIS
  • Protege
  • Python
  • QGIS
  • VS Code
  • etc
The servers have a very different stack.

Initially, the data centre will often be turned off. It will be turned on to allow hundreds of Pipi Agents to run batch jobs autonomously. Eventually, many racks will be running 24x7x365.

Moving Pipi 9 to a data centre now opens the door to Pipi 10 in 2027.

Mission Control

The future Mission Control UI, connected to the data centre, could be shared via a live video feed of a monitor, ensuring security against hackers. It could even be a YouTube Live Stream of probes for those who don't like to sleep. 😀 Though my cat tells me it is much better to watch squirrels on YouTube. 😸😹😺😻😼😽

Net-SNMP for PDU?

Mike's Notes

I'm looking for a solution to a problem. Some working notes.

"The first Data Centre

Once scaling begins, Pipi 9 will then need a data centre to use as a render farm to automatically create customised SaaS enterprise applications based on user requirements. The data centre will be completely isolated from the internet to maximise security. It can be expanded in stages if it is planned appropriately.

Each industry and each enterprise customer will get a dedicated server to store a mirrored copy of their deployment configuration and parameters, including localisation. No user data will be stored." - On A Sandy Beach

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

15/01/2026

Net-SNMP for PDU?

By: Mike Peters
On a Sandy Beach: 15/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The future Pipi 9 data centre must be fully automated and physically isolated from the internet.

Power

19" rack-mounted intelligent PDU will distribute power to servers.

According to Server Room Environments

Intelligent Rack PDUs

Intelligent PDUs add a level of sophistication to power distribution within IT server racks and include:

  • PDU and Outlet Metering: metered PDUs provide power-related information locally and remotely, which can include Amps (A), Volts (V), Frequency (Hz), Watts (W), Energy (kWh) and Power (kVA). The power readings can be for individual outlets and the total PDU usage. The information can be used by IT managers for capacity planning, the prevention of circuit overloads, client and cost centre billing (with +/- 1% accuracy) and efficiency calculations, including Power Usage Effectiveness (PUE).
  • Switched and Outlet Switched: a switching PDU will include metering and add the ability to remotely control (ON/OFF) to the PDU and the outlets. Outlet-switched PDUs provide a way for IT and data centre managers to remotely reboot or power down connected loads and allow for cascading power-ups to manage load inrush currents. Switching PDUs adds a layer of security to a server room or data centre power plan in terms of controlling unauthorised access to rack-level loads and their power connections. Costs are also reduced, as an onsite engineer visit is removed in most instances.
  • Remote IP Monitoring: the PDU provides connectivity for remote monitoring and can include HTTP/HTTPS, iPV4 and iPV6, Telnet, SSH, Virtual Serial, SNMP (v1, v2c, v3), JSON-RPC, LDAP, FTP/SFTP and RADIUS for secure login. The monitoring provides a way to view the status of the PDU and its individual socket outlets using a browser, monitoring software or a data centre infrastructure management (DCIM) software suite. The PDU may also offer a RESTful API for bespoke communications applications. Dual Ethernet ports can provide communications redundancy, and the communications module will typically be a ‘hot-swap’ type.

This means that each individual power outlet can be remotely switched on and off via IP. That could be controlled by another server.

A server can power up automatically when the power outlet is turned on. The server can be made to run a program (Pipi 9), do some work, create a backup, and then shut down.

My question is:

"Could the PDU detect that the server has shut down and then turn off the power outlet?"

According to a post on the Schneider Electric forum, this can be done with scripting using Net-SNMP.

Net-SNMP

It runs on Linux and Windows and is open-source.

"Net-SNMP is a suite of software for using and deploying the SNMP protocol (v1, v2c and v3 and the AgentX subagent protocol). It supports IPv4, IPv6, IPX, AAL5, Unix domain sockets and other transports. It contains a generic client library, a suite of command line applications, a highly extensible SNMP agent, perl modules and python modules." - Wikipedia

Pipi 9 in production

Pipi 9 is large but also very power-efficient (it's not an LLM). Each copy of Pipi 9 requires its own server. In this data centre, each enterprise customer has its own backend server running a customised Pipi 9 as a digital twin. I'm experimenting to see whether a small-form-factor refurbished PC could do the job.

There would need to be hundreds of these PCs in racks, autonomously coming online and offline as required to run batch jobs. Massive redundancy is provided by having spare PCs synced, NAS storage, VMs, etc.

This means that single-phase PDUs can be used. Maybe 1 PDU per 10-15 PCs per shelf, with only a few PCs running at any given time. 1 UPS per cabinet at the bottom, supplying multiple shelves.

Mechanical air-lock

Data needs to pass between this isolated data centre and customer deployments hosted in the cloud. My thought is to add a staging area (or several) between the two and pass data back and forth via network switches that are mechanically cycled (analogue). A bit like a double air-lock in space.

This would make it impossible for an external attacker to breach the system.

Robots in control

Pipi 9 is designed to serve as the system administrator for all customer cloud deployments. Coming on only as needed and in quiet times to minimise any disruption.

  • Updates
  • Configuration
  • Security
  • Databases
  • Deploying Docker
  • etc

Number of data centers worldwide 2025, by country or territory

Mike's Notes

Provides some perspective on the distribution of their current locations. The 2025 data is available as a spreadsheet. 

It's also a proxy index of electrification and economic development by country.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

25/12/2025

Number of data centers worldwide 2025, by country or territory

By: Petroc Taylor
Statistica: 19/11/2025

Petroc Taylor is a researcher with Statista's Technology and Telecommunications team. His research focus is global developments in the use of data, including trends in big data, analytics, and storage, as well as the impact of emerging data technologies across industries and sectors. He also supports the team's coverage of operating systems, telecommunications, and the technology industry in Africa..

As of November 2025, there were a reported 4,165 data centers in the United States, the most of any country worldwide. A further 499 were located in the United Kingdom, while 487 were located in Germany.

What is a data center?

Data centers are facilities designed to store and compute vast amounts of data efficiently and securely. Growing in importance amid the rise of cloud computing and artificial intelligence, data centers form the core infrastructure powering global digital transformation. Modern data centers consist of critical computing hardware such as servers, storage systems, and networking equipment organized into racks, alongside specialized secondary infrastructure providing power, cooling, and security.

AI data centers

Data centers are vital for artificial intelligence, with the world’s leading technology companies investing vast sums in new facilities across the globe. Purpose-built AI data centers provide the immense computing power required to train the most advanced AI models, as well as to process user requests in real time, a task known as inference. Increasing attention has therefore turned to the location of these powerful facilities, as governments grow more concerned with AI sovereignty. At the same time, rapid data center expansion has sparked a global debate over resource use, including land, energy, and water, as modern facilities begin to strain local infrastructure.

Data

Statistic: Number of data centers worldwide as of November 2025, by country or territory | Statista

Find more statistics at Statista

Windows LTSC

Mike's Notes

A stable platform is required for the isolated Ajabbi Research Data Centre, which is not connected to the internet. The platform O/S needs to be stable and not require weekly updates for Pipi to run on. Ideally, the platform and the major Pipi version would be updated simultaneously every 2-5 years.

The basic ISO build required is

  • O/S (Windows or Debian Linux)
  • Jave 21 JRE
  • BoxLang

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

24/11/2025

Windows LTSC

By: Mike Peters
On a Sandy Beach: 05/07/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I like using Windows. It's because I'm very visual and need a GUI.

I have no problem with Linux, but that would require others who can spell and are familiar with the command line.

Pipi can use the command line autonomously because every command is carefully loaded into a database, ready for use in a CFML template.

The biggest challenge with using Windows O/S in the isolated data centre is dealing with O/S updates. It turns out that Microsoft offers a version of Windows specifically designed for embedded applications, such as those found in hospitals and factories. Perhaps that would be a better option for creating initial platform stability. I need to do some experiments.

Later, as Ajabbi grows and more people are involved, switching to a minimal version of Debian Linux could be easily done. Maybe as part of the next major version, Pipi 10.

LTSC

  • It seems to be slimmed down.
  • Doesn't have CoPilot, OneDrive, the Microsoft Store and Cortana.
  • Can run Java
  • Windows 10 LTSC is supported until 2033.
Next steps
  • Try it out

A roadmap to Pipi 10

Mike's Notes

Pipi 10 will run on BoxLang in production.

I sent draft notes to Ortus Solutions yesterday to discuss future use of BoxLang. I then edited the notes and shared them with the growing Pipi community. I will add the answers as more is discovered about what needs to be done to make it possible for Pipi 10 to use BoxLang.

Training is available on BoxLang Academy.

Can you spot any errors in my assumptions? Do you have other ideas or queries?

Contact me.

Update 04/06/2024, 05/06/2025

Cristóbal Escobar Henríquez from Ortus Solutions provided excellent answers to the questions sent via email. These answers have been added to the questions at the end of this article, which are slightly different from the original ones (all my fault). Thanks :)

Update 09/06/2025

Luis Majano from Ortus Solutions provided additional answers to my follow-up questions, which I sent by email. They have been added to the post below. Thank you, Luis.

Update 12/06/2025

Luis Majano from Ortus Solutions provided additional answers to my follow-up questions, which I sent by email. They have been added to the post below. Thank you, Luis.

Update 13/06/2025

Luis confirmed that BoxLang cannot use CommandBoc modules. It appears that BoxLang can currently handle 90% of my needs. The only real gap is that Pipi cannot currently autonomously configure BoxLang itself via the command line, which is needed for scaling.

This is sufficient to make a start, with the hope that Ortus will address these issues in the future.

I expect Pipi 10 to be a 12-month build after Pipi 9 is in full production.

Update 14/06/2025

There will be an online meeting with people from Ortus next week to discuss and confirm details regarding the migration plan, paid support, and sponsorship of Ortus' open-source.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

14/06/2025

A roadmap to Pipi 10

By: Mike Peters
On a Sandy Beach: 21/05/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Draft roadmap

  • This is a draft, so expect it to change
  • This roadmap is probably for the next 2-3 years at least
  • The finalised plan will be published for the Pipi Community.
  • No money is available right now.
  • A plan is needed to avoid rework.
  • Don't expect Ortus to do work for free.
  • Realistic expectations of what is possible.
  • Good income will come later from paying customers for solving complex problems.
  • Focus on the core by outsourcing other work to experienced contractors.
  • Open-source all modules on GitHub.

Ajabbi

  • The common name of 
    • A company to handle payments
    • Non-profit foundation to support users (to be established)
    • Research Institute for ongoing development (to be established)
  • Description
    • Solved a huge, expensive problem with no existing competitors
    • Pre-revenue start-up with no $$$
    • Growing community
  • Purpose
    • Act like other foundations (Wikimedia, Apache and Linux) and use the income surplus to support
      • Minority languages i18n
      • Open-source efforts (especially CFML, including Ortus)
      • User groups
      • User conferences
      • Book publishing
      • Open research grants
      • Etc

    Pipi

    • The name of the software
    • Mike has been the architect since 1997
    • Versions 1-4 were in production eventually with 300K lines of code, an 800-table database, ESRI Web GIS, 500 classes, 3K methods, a 5 FTE team and a 3-rack data centre
    • Versions 6-8 were working, non-production, undergoing refactoring
    • Version 9 works, moving to production (current)
    • Version 10 (planned)

    Current Pipi 9

    • Works great
    • Runs in a dev environment
    • Unique architecture with 20+ layers and hundreds of autonomous agents
    • Uses nature-inspired algorithms
    • Going from headless to a Pipi-generated UI
    • Migrating to a 42U server rack completely isolated from the internet.
    • Using old Windows server boxes will do for now.
    • The CFML code runs on ColdFusion Server 2021 Developer Edition.
    • The CFML code could run on ColdFusion MX, Open Blue Dragon, or Lucee. 
    • Uses <CF> tags as in Ben Forta, et al. (don't tell Michaela, I don't want to die)
    • Uses 300+ embedded config databases (MS Access)
    • Uses PostgreSQL for production data
    • Writes CFML code and then executes it
    • Writes SQL and then executes it to create and populate tables
    • Static HTML generator (90K page websites)
    • Uses XML, XML Schema, etc, internally
    • Mostly self-managing
    • Self-documenting
    • Currently rendering a 20,000-page static website for developers
    • The code base will self-grow 10x larger over time

    Planned Pipi 9

    • Some money is coming soon
    • Generate revenue from niche batch render jobs
    • Code generators and the generated code must be rewritten to be BoxLang compatible, so no refactoring by Ortus is required.
    • Pipi 9 will create Pipi 10
    • Pipi 10 to be BoxLang native
    • BoxLang (+++++++) paid support
    • Pipi 10 to become geodatabase capable
    • BoxLang will enable the future use of Python, PHP, etc

      Planned Pipi 10 Systems

      • Render System
        • Functions as an automated AI-assisted development environment
        • Isolated from the internet
        • Uses VM
        • Run on BoxLang installed on Windows on new 64 hardware
        • JDK 21+
        • Ortus to supply a ready-to-run VM image.
        • 100% self-managing via CommandBox dynamic CFML scripts
        • Renders working enterprise system modules (database, code, UI, API, user documentation)
          • MS SQL edition
          • MySQL edition
          • Oracle edition
          • PostgreSQL edition
        • Exports modules to the Staging System via manual hard drive transfers
      • Staging System
        • Connected to the internet
        • Uses VM
        • Runs on BoxLang installed on Debian
        • JDK 21+
        • Ortus to manage the BoxLang platform VM on a long-term contract
        • Uses PostgreSQL
        • Adds i18n to modules
        • Creates updates
        • Integrates i18n modules into customised enterprise systems for paying customers
        • Exports
          • Github
            • i18n modules to GitHub for open-source
            • i18n user documentation
          • Cloud
            • Customised i18n enterprise systems
            • System updates
      • Cloud System
        • Connected to the internet
        • Uses VM
        • Runs on BoxLang installed on Debian
        • JDK 21+
        • Ortus to manage the BoxLang platform VM on a long-term contract
        • VM hosted
          • AWS
          • Azure
          • Digital Ocean
          • GCP
          • IBM
          • etc
          • private cloud.
        • The customer chooses their production RDMS database(s) for their data.
          • MS SQL
          • MySQL
          • Oracle
          • PostgreSQL

      Questions for Ortus Solutions

      Answered by Cristóbal Escobar Henríquez, and Luis Majano.
      • Is a list of supported (or not supported) CFML tags available?
      • Is <Cf tags> style coding supported?
        • Yes, BoxLang fully supports CFML tags when running in CFML compatibility mode. This ensures legacy CFML applications can continue to function with minimal changes.
      • Is there a performance hit from using CML compatibility mode?
        • There is of course a penalty to pay if you are transpiling on the fly.  It's negligible to the point that we are faster in CFML mode than all Adobe engines even in transpile mode.  However, you can transpile to BX as part of your build process and then this won't exist.
      • Does BoxLang use CommandBox modules?
        • No.  BoxLang Modules are something new.  Eventually maybe, but for now, no.
      • Can BoxLang accept (CFML) command-line modules generated by Pipi without needing to be restarted?
        • Yes.
        • The ModuleService has the necessary API for you to load modules a-la-carte.  All of our integration testing uses this approach.
        • You can also uninstall them
      • Will these CF tags become compatible with BoxLang in future?
        • cfftp
          • This is done in our bx-ftp module
        • cfregistry
          • This can be sponsored if needed.
        • cfschedule
          • This is in progress, but can be accelerated by sponsorship
      • Could BoxLang use MS Access via JDBC on the isolated Render System, and how much would it cost to create a module to do this?
        • We can enable MS Access integration by building a custom module using the UCanAccess JDBC driver.
        • Estimated time: 10–15 hours (2–3 business days)
        • Note: This estimate covers driver integration only and does not guarantee full MS Access compatibility. As an alternative, we recommend migrating the database to SQLite, Derby, or MySQL for improved stability and long-term support.
      • What kinds of modules can be developed by Ortus?
        • Ortus can develop any module you need, whether it's for BoxLang, application features, integrations, or infrastructure. We tailor modules to your requirements, from core language enhancements to platform-level tools.
      • What is the cost for Ortus to provide dedicated platform support?
        • We offer dedicated platform support through our BoxLang+ and BoxLang++ plans, which include guaranteed response times, SLAs, priority bug handling, and access to our core engineering team.
        • You can review the full details and pricing here: https://boxlang.io/plans
        • We’d be happy to tailor a plan based on your service level and usage expectations.
      • Can patched VM images be supplied?
        • Yes, we can provide patched VM images as part of a BoxLang++ subscription. If you're not on a ++ tier, this can still be delivered through a separate consulting plan.
      • What about the time zone differences between New Zealand, the US, and Spain?
        • Our team operates mainly on Central Standard Time, but we can easily align with your schedule. If needed, we can also assign a developer located in the EU (CET) for better time zone overlap.
      • Would a 100% dedicated Ortus developer be possible in the future?
        • Yes, we offer team augmentation services, including assigning a dedicated developer to your project. We can adapt the engagement based on scope, timeline, and availability.
      • Is a 24/7/365 platform supported by Ortus possible in the future?
        • Yes, that’s absolutely possible. We can support a 24/7/365 production environment using our teams in El Salvador and Spain. This would require a custom service agreement or license tier beyond the standard BoxLang offerings, but we’re happy to scope and price this accordingly based on your needs in the future.

      Questions for the Pipi Community

      • Would support also be available from independent CFML contractors?

      • Where is the boundary between community contributions and paid contractors?

      • What other new BoxLang Modules would be helpful, including other coding languages?