- Published on
KembaraXtra–Computer Terms – 34010, 34020
The 34010 and 34020 are graphics coprocessors developed by Texas Instruments for use in high-end PC graphics boards. They became a de facto standard for programmable graphics processors at a time when offloading graphics calculations from the main CPU was an important performance advantage. Both chips use 32-bit internal registers, but they differ in how they interact with the rest of the system: the 34010 is paired with a 16-bit data bus, while the 34020 uses a full 32-bit bus, allowing higher data throughput. The 34020 is designed to be compatible with the earlier 34010, so software written for the older chip can still run when upgraded hardware is installed. These coprocessors are designed to work with TIGA, the Texas Instruments Graphical Architecture, which defines a standard interface so that a single application driver can support an entire class of graphics boards based on this architecture rather than requiring separate drivers for each different board.
- Published on
KembaraXtra–Computer Terms – 3.5-inch floppy disk
A 3.5-inch floppy disk, often called a microfloppy, is a removable magnetic storage medium widely used with both Macintosh systems and IBM-compatible microcomputers. Physically, it consists of a flexible round disk of polyester film coated with ferric oxide, sealed inside a rigid plastic shell equipped with a sliding metal cover that protects the disk surface when not in use. On the Macintosh platform, a single-sided 3.5-inch disk can store about 400 kilobytes of data; a standard double-sided disk can hold approximately 800 kilobytes; and a double-sided high-density disk can hold about 1.44 megabytes. On IBM-compatible systems, common formats for 3.5-inch disks include 720 kilobytes for double-density disks and 1.44 megabytes for high-density disks. During their peak years, these disks were used for everything from system boot disks and software distribution to personal file storage and data transfer between machines.
- Published on
KembaraXtra–Computer Terms – 360K
The term 360K is short for 360 kilobytes and represents the storage capacity of a standard double-sided, double-density 5.25-inch floppy disk. These disks were common in early IBM PCs and compatible systems and served as a primary method of loading programs, storing documents, and backing up small amounts of data. Though extremely limited by modern standards, 360K disks played a crucial role in the early personal computing era.
- Published on
KembaraXtra–Computer Terms – .386
The extension .386 identifies files used as virtual device drivers under Windows 3.1. These files provide low-level services that allow Windows to manage hardware and system resources in its 386 enhanced mode, which leverages features of the 80386 processor such as virtual memory and multitasking. By loading .386 virtual device drivers, Windows 3.1 could simulate multiple virtual machines, provide better memory management, and coordinate access to hardware among multiple running applications.
- Published on
KembaraXtra–Computer Terms – 386
The designation 386 typically refers to the Intel 80386DX microprocessor, a 32-bit CPU that marked a major step forward from the earlier 286 line. It introduced full 32-bit registers, a 32-bit data bus, advanced memory management capabilities, and support for protected mode with large address spaces. The 80386DX became the foundation for many desktop and server systems and enabled the development of more powerful operating systems and applications.
- Published on
KembaraXtra–Computer Terms – 386BSD
386BSD is a version of the BSD UNIX operating system created for systems based on the Intel 80386 processor. It is distinct from BSD386, which was produced by Berkeley Software Design, Inc. Released in 1992 as a freely distributable system, 386BSD played a key role in the history of open-source UNIX-like operating systems. Over time, it gave rise to two significant descendants, NetBSD and FreeBSD, each of which evolved into separate, widely used projects. These later systems continued and expanded the design goals of 386BSD, focusing on portability, robustness, and performance across a wide range of hardware platforms.
- Published on
KembaraXtra–Computer Terms – 386DX
The term 386DX refers to the full-featured Intel 80386DX microprocessor, a 32-bit CPU with a 32-bit data bus and 32-bit registers. It supports advanced operating modes, including protected mode, and can address large amounts of memory. Systems built around the 386DX were capable of running sophisticated multitasking operating systems and applications that significantly outperformed earlier 16-bit platforms.
- Published on
KembaraXtra–Computer Terms – 386SL
386SL is the name used for a variant of the Intel 80386 processor designed for portable and low-power computing environments, such as early laptop computers. This chip integrates power-management features and other functionality that reduces energy consumption, extending battery life while still maintaining compatibility with 80386 instruction sets. It allowed laptop manufacturers to deliver mobile systems with PC performance levels that were similar to desktop machines of the time.
- Published on
KembaraXtra–Computer Terms – 386SX
386SX refers to a cost-reduced version of the Intel 80386 microprocessor. While it retains a 32-bit internal architecture and instruction set, it uses a 16-bit external data bus and often a narrower address bus. This made it cheaper to integrate into computer systems, as it could be paired with less expensive support chips and memory subsystems. As a result, 386SX-based systems offered many of the programming advantages of 32-bit processors at a lower overall cost, although with somewhat reduced performance compared to 386DX systems.
- Published on
Artificial Intelligence – Testing and Maintaining Your Applications
Building AI systems—whether they learn continuously from new data (online learning) or are trained once and used afterward (offline learning)—requires more than just creating a model. It also requires ongoing testing and maintenance to make sure everything keeps working the way it should. No matter how the model learns, we must establish reliable monitoring systems and safety checks that alert us whenever the model’s predictions or its essential infrastructure start acting unexpectedly.
Expanded Explanation
In traditional software development, testing is relatively straightforward: for each specific input, we know exactly what the output should be. This makes it easy to write tests that verify whether the system behaves correctly.
Machine learning, however, doesn’t follow that neat pattern. A model may produce different outputs for inputs that look similar, and those outputs depend on many factors—training data, randomness, environment, even hardware differences. This makes classic, rule-based testing harder to apply.
Despite these challenges, testing remains crucial. In machine learning projects, “testing” involves carefully verifying the following:
In this chapter, we will explore practical methods for testing machine learning code, including strategies tailored for systems that behave unpredictably. We’ll also go through best practices that help ensure reliability even when perfect reproducibility isn’t possible.
Keeping AI Applications Healthy After Deployment
Once an AI model is released into the real world, the job isn’t over. Models may degrade over time as the world changes—a phenomenon known as model drift. To keep the system stable, AI applications must be continuously monitored and maintained.
DevOps tools, such as Jenkins, play an important role here. They can automatically run a set of tests every time a new version of a model or application component is created. Only if all tests pass will the updated version be allowed to move into production. This reduces the risk of shipping broken or unsafe updates.
While we do not expect machine learning engineers to design full development or deployment pipelines on their own, it is important to understand the key principles behind them. These concepts help you collaborate effectively with DevOps teams and ensure that your models are safely and efficiently deployed.
What This All Means?
Imagine you built a robot that gives you advice—maybe it helps with homework or tells you what game to play. To make sure your robot stays helpful and doesn’t start acting weird, you need to check on it regularly.
Testing
Testing is like asking the robot:
In regular computer programs, the answer is the same every time, so it’s easy to test. But with AI robots, they might give different answers because they learn from data. That makes testing trickier!
Maintaining
After your robot is built, you still need to watch it. Maybe it starts learning things that are wrong or confuses new information. So you check it from time to time and fix things if needed.
Tools like Jenkins are like helpers that test the robot every time you teach it something new. If the robot starts making mistakes, the helper won’t let those mistakes go into the real world.
So basically:
Building AI systems—whether they learn continuously from new data (online learning) or are trained once and used afterward (offline learning)—requires more than just creating a model. It also requires ongoing testing and maintenance to make sure everything keeps working the way it should. No matter how the model learns, we must establish reliable monitoring systems and safety checks that alert us whenever the model’s predictions or its essential infrastructure start acting unexpectedly.
Expanded Explanation
In traditional software development, testing is relatively straightforward: for each specific input, we know exactly what the output should be. This makes it easy to write tests that verify whether the system behaves correctly.
Machine learning, however, doesn’t follow that neat pattern. A model may produce different outputs for inputs that look similar, and those outputs depend on many factors—training data, randomness, environment, even hardware differences. This makes classic, rule-based testing harder to apply.
Despite these challenges, testing remains crucial. In machine learning projects, “testing” involves carefully verifying the following:
- Inputs: Are we providing the model with data in the right format and within expected ranges?
- Outputs: Are the predictions reasonable, consistent, and within acceptable boundaries?
- Errors: Are we handling failures, missing data, or unexpected behaviors safely?
In this chapter, we will explore practical methods for testing machine learning code, including strategies tailored for systems that behave unpredictably. We’ll also go through best practices that help ensure reliability even when perfect reproducibility isn’t possible.
Keeping AI Applications Healthy After Deployment
Once an AI model is released into the real world, the job isn’t over. Models may degrade over time as the world changes—a phenomenon known as model drift. To keep the system stable, AI applications must be continuously monitored and maintained.
DevOps tools, such as Jenkins, play an important role here. They can automatically run a set of tests every time a new version of a model or application component is created. Only if all tests pass will the updated version be allowed to move into production. This reduces the risk of shipping broken or unsafe updates.
While we do not expect machine learning engineers to design full development or deployment pipelines on their own, it is important to understand the key principles behind them. These concepts help you collaborate effectively with DevOps teams and ensure that your models are safely and efficiently deployed.
What This All Means?
Imagine you built a robot that gives you advice—maybe it helps with homework or tells you what game to play. To make sure your robot stays helpful and doesn’t start acting weird, you need to check on it regularly.
Testing
Testing is like asking the robot:
- “Are you listening correctly?”
- “Are you answering in a way that makes sense?”
- “Are you freezing or making mistakes?”
In regular computer programs, the answer is the same every time, so it’s easy to test. But with AI robots, they might give different answers because they learn from data. That makes testing trickier!
Maintaining
After your robot is built, you still need to watch it. Maybe it starts learning things that are wrong or confuses new information. So you check it from time to time and fix things if needed.
Tools like Jenkins are like helpers that test the robot every time you teach it something new. If the robot starts making mistakes, the helper won’t let those mistakes go into the real world.
So basically:
- Testing: making sure your AI works properly.
- Maintaining: keeping it working even as things change.
