RSS

Tag Archives: system architecture

Storage is Essentially Free!

Twice in the last few days, I ran into low, artificial limits on how much text a website would allow me to enter into a field.

Once upon a time, this was reasonable. Disk was expensive. RAM was expensive. Constraints were real, and tradeoffs were unavoidable.

That time is long past.

Out of curiosity, I asked Gemini to help me research the history of nonvolatile storage costs. This is what I learned:

  • In 1956, an IBM 350 provided about 3.75 MB of nonvolatile storage for $9,200/MB.
  • Today — during a price spike caused by a NAND shortage — a 2 TB SSD costs around $250.

That’s a 99.99999864% reduction in price per megabyte, without adjusting the 1956 price for nearly 70 years of inflation. For all practical purposes, storage is free.

And yet, both places I hit limits this week were meant to hold directions.

In one case, I was updating instructions to cover a scenario that had been missed in the previous version. I couldn’t add the necessary text without hitting the limit. I trimmed the existing content and ended up with something serviceable, but fragile. The very next update will run into the same wall.

This is absurd.

Text (especially text meant to instruct) should be effectively infinite. Modern disks can handle it. Modern memory can handle it. The constraint is not technical; it’s conceptual.

(And don’t get me started on amateurs who think eight characters is enough for a first name, so I end up with mail addressed to “Christop!” See Falsehoods Programmers Believe About Names.)

 
Leave a comment

Posted by on February 10, 2026 in Software techniques

 

Tags: , , ,

Understanding Mobile Device Enrollment

They say there are only two hard problems in computer science:

  1. Naming things
  2. Invalidating cache contents
  3. Off-by-one errors

I was reminded of the first problem as my company recently struggled to communicate clearly among ourselves and with vendors about the types of device enrollment in Mobile Device Management (MDM) systems.

I couldn’t find any industry-standard terms that applied here. If I’m wrong, I’d be happy to hear about it. If I’m right, maybe others will find the following names and definitions useful.

Enrollment Classes 

For enterprises, Apple Business Manager, Android Zero Touch Enrollment, and Samsung Knox are reliable, large-scale methods of enrolling devices in MDM management.  However, only authorized resellers can add devices to those systems.  A business buying a fleet of phones from a carrier or major retailer can rely on the reseller setting their phone up for easy management.   

However, an MVNO or other service provider cannot always establish the “chain of custody” necessary to prove ownership and get devices into those systems.  There are other methods, but they have limitations. Apple and Google have different procedures and names for their device enrollment processes. Platform-agnostic terminology can make it easier to talk about the end state of an enrolled device regardless of platform. Toward that end, we defined three classes of enrollment. 

  • Class A enrollment is the most secure and permanent. The MDM has nearly complete control of the device and after a factory reset the device will be automatically reenrolled in the MDM which can reestablish control. 
  • Class B enrollment is nearly as good.  The MDM has nearly complete control of the device, but a factory reset will disconnect the device from the MDM and require manual intervention to reenroll the device. 
  • Class C enrollment is useful but fairly weak. The MDM can control and monitor some aspects of the device, but the device holder has the ability to bypass the MDM controls and make changes that put the device or its user at risk. 

Class A 

Class A enrollment requires a device to be added to a zero-touch enrollment platform: Apple Business Manager (for iOS), Knox Mobile Enrollment (for Samsung), or Zero-Touch Enrollment (for Android, including Samsung). 

The zero-touch enrollment platforms are best suited for organizations managing large fleets of devices.  While some exceptions can be managed with effort, the usual path is that the organization buys devices from an “authorized reseller” who adds the devices to the platform for the organization. 

  • Advantages: Class A is sticky (even a factory reset doesn’t remove the device from the MDM) and easy (the devices are put in the portal by the reseller, and the organization doesn’t have to do anything to enroll them). 
  • Disadvantage: Class A is very difficult to add to existing devices. 

Class B 

Class B enrollment can be done to existing devices without concern for the zero-touch enrollment platforms. 

This is useful for organizations trying to onboard existing devices while maintaining tight control.  A Class B enrollment leaves the device “owned” by the MDM so it can enforce always-on VPN and other privileged policies. 

  • Advantages: Class B does not require the devices to be in a zero-touch enrollment platform, and it allows privileged policies to be enforced. 
  • Disadvantages: Class B requires touching every device, requires the device to be factory reset (“wiped”), and the device does not automatically reenroll after another factory reset. 

Class C 

Class C enrollment can be done to existing devices without the need to factory reset them. 

This can be useful for adding management to deployed devices.  However, because the device is not “owned” by the MDM, privileged policies like always-on VPN cannot be enforced. 

  • Advantage: Class C does not require a factory reset. 
  • Disadvantage: Class C does not prevent the user from disabling important policies like always-on VPN, or even from uninstalling the MDM client.  
 
Leave a comment

Posted by on November 5, 2025 in Definitions

 

Tags: