s
This commit is contained in:
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: 'The Race For Intelligence'
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
|
||||

|
||||
|
||||
**Within 2 years we will no longer be using all those hundreds of apps, but we will be talking to AI driven agents.**
|
||||
|
||||
### **The Role of AI in Our Lives**
|
||||
|
||||
- Right now, humans interact with the internet mainly through apps on their phones, computers, and other devices.
|
||||
- In the near future (within 2 years), apps will fade into the background, and **AI-driven agents** will become the primary way we interact with technology. For example, instead of using multiple apps for messaging, shopping, or searching, you might simply ask an AI assistant to handle all those tasks through conversation.
|
||||
- These AI agents will be accessed using modern devices like phones, glasses, or even futuristic interfaces like brain implants (e.g., Neuralink).
|
||||
|
||||
|
||||
|
||||
|
||||
### **The Race for Intelligence**
|
||||
|
||||

|
||||
|
||||
|
||||
The world is in a rapid phase of technological advancement, driven by innovations in AI, quantum computing, and biotechnology.
|
||||
|
||||
**Key milestones in internet history:**
|
||||
|
||||
- **1960s:** The internet started as a free and open platform, allowing people to share ideas, collaborate, and connect directly.
|
||||
- **2000–2024:** The internet has become increasingly controlled by large corporations. These companies dominate through data collection and commercial interests, compromising the internet’s original vision of freedom and openness.
|
||||
- **2025 and Beyond:** Large corporations are now racing to develop **Artificial General Intelligence (AGI)**—AI systems that can think and reason like humans. This raises concerns about centralization, control, and ethical use.
|
||||
|
||||
### **A Vision for the Future**
|
||||
|
||||
Instead of leaving the future of AI in the hands of a few powerful corporations, there is a push to create **Augmented Collective Intelligence.**
|
||||
|
||||
- This concept envisions AI as a tool that empowers everyone, enabling collaboration and shared decision-making rather than monopolizing power.
|
||||
- The goal is to restore the internet’s original ideals of openness, privacy, and community-driven innovation.
|
||||
|
@@ -1,88 +0,0 @@
|
||||
---
|
||||
title: 'Hardware Badly Used.'
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
### The IT world fails to harness the full potential of computer hardware.
|
||||
|
||||

|
||||
|
||||
|
||||
While hardware advancements have surged forward, user experiences and features have often stagnated, failing to keep pace with these developments.
|
||||
|
||||
The original Commodore 64, with only 64 KB of memory, was a remarkably capable machine for its time. In contrast, today's computers have 8 GB or more of memory, yet their capabilities have not necessarily improved proportionately.
|
||||
|
||||
This highlights a regression in our ability to fully utilize computer hardware.
|
||||
|
||||
We are committed to bridging this gap by optimizing our approach to hardware utilization, thereby unlocking its full potential.
|
||||
|
||||
## Why are servers so badly used?
|
||||
|
||||

|
||||
|
||||
Context switches occur when a computer's processor shifts from executing one task (or context) to another. While necessary for multitasking, too many context switches lead to inefficiency, as demonstrated in this diagram. Here's a simplified explanation:
|
||||
|
||||
---
|
||||
|
||||
### Why Context Switches Are a Problem:
|
||||
|
||||
1. **What Are Context Switches?**
|
||||
|
||||
- Imagine you're working on two tasks: reading a book and answering emails. Every time you switch between them, you lose time refocusing. Computers experience a similar "refocusing" delay when switching between tasks.
|
||||
|
||||
2. **The Layered Architecture Causes Overhead**
|
||||
|
||||
- Modern computing systems use many layers (e.g., applications, storage drivers, network layers) to get work done. Each layer requires the system to switch between different modes (user mode and kernel mode) and tasks.
|
||||
- For example:
|
||||
- A web app might need to talk to a storage driver.
|
||||
- This requires moving data through multiple layers (network, file system, etc.).
|
||||
- Each layer adds a context switch.
|
||||
|
||||
3. **Millions of Switches Per Second**
|
||||
|
||||
- Each switch requires saving and loading the state of a process. This takes time and uses CPU power. When millions of context switches occur every second (as shown in the diagram), most of the computer’s capacity is spent switching rather than doing useful work.
|
||||
|
||||
4. **Result: Wasted Resources**
|
||||
|
||||
- Sometimes up to 90% of the computer’s capacity can be lost because of this inefficiency.
|
||||
- Instead of performing tasks like running applications or processing data, the computer is stuck managing unnecessary complexity.
|
||||
|
||||
|
||||
### Simplified Analogy:
|
||||
|
||||
Imagine driving on a highway where you have to stop and pay a toll at every intersection. You waste more time paying tolls than actually driving to your destination. Similarly, excessive context switches in modern systems cause the computer to "stop and pay tolls" constantly, leaving little time for real work.
|
||||
|
||||
|
||||
### How did we get here:
|
||||
|
||||

|
||||
|
||||
### Context Switching Details
|
||||
|
||||
In the context of CPU scheduling in Linux (and in most modern operating systems), a context switch refers to the process of saving the state of a currently running process (such as its registers, program counter, and other relevant information) and loading the state of a different process to allow it to run. This switching of execution from one process to another is a fundamental aspect of multitasking operating systems, where multiple processes share the CPU's time.
|
||||
|
||||
Here's how a context switch typically works in Linux:
|
||||
|
||||
1. **Interrupt Handling**: When a higher-priority process needs to run or an event requiring immediate attention occurs (such as I/O completion), the CPU interrupts the currently running process.
|
||||
|
||||
2. **Saving Context**: The operating system saves the state of the current process, including its registers, program counter, and other relevant data, into its process control block (PCB). This step ensures that when the process resumes execution later, it can continue from where it left off.
|
||||
|
||||
3. **Scheduling Decision**: The operating system scheduler determines which process should run next based on scheduling algorithms and the priority of processes in the system.
|
||||
|
||||
4. **Loading Context**: The operating system loads the state of the selected process from its PCB into the CPU, allowing it to execute. This includes restoring the process's registers, program counter, and other relevant data.
|
||||
|
||||
5. **Execution**: The newly loaded process begins executing on the CPU.
|
||||
|
||||
Context switches are essential for multitasking, but they come with overhead that can impact system performance:
|
||||
|
||||
1. **Time Overhead**: Context switches require time to save and restore process states, as well as to perform scheduling decisions. This overhead adds up, especially in systems with many processes frequently switching contexts.
|
||||
|
||||
2. **Cache Invalidation**: Each time a process is switched in, it may result in cache invalidation, where the CPU's cache needs to be refreshed with data from the new process's memory space. This can lead to cache misses and performance degradation.
|
||||
|
||||
3. **Resource Contentions**: Context switches can exacerbate resource contention issues, especially in systems with limited CPU cores. If multiple processes are frequently contending for CPU time, the overhead of context switches can further delay process execution.
|
||||
|
||||
4. **Fragmentation**: Frequent context switches can lead to memory fragmentation, as processes are loaded and unloaded into memory. This fragmentation can degrade system performance over time, as it becomes more challenging to find contiguous slice of memory for new processes.
|
||||
|
||||
While context switches are necessary for multitasking, excessive context switching can indeed lead to a significant loss of execution power by introducing overhead and resource contention in the system.
|
||||
|
||||
Therefore, efficient scheduling algorithms and optimization techniques are crucial for minimizing the impact of context switches on system performance.
|
Binary file not shown.
Before Width: | Height: | Size: 69 KiB |
Binary file not shown.
Before Width: | Height: | Size: 98 KiB |
Binary file not shown.
Before Width: | Height: | Size: 210 KiB |
Binary file not shown.
Before Width: | Height: | Size: 134 KiB |
Binary file not shown.
Before Width: | Height: | Size: 227 KiB |
Binary file not shown.
Before Width: | Height: | Size: 161 KiB |
@@ -1,116 +0,0 @@
|
||||
---
|
||||
title: 'Internet Protocol Is Broken'
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
The foundational protocols of the internet, TCP/IP (Transmission Control Protocol/Internet Protocol), were created in the 1970s to connect a few academic and military computers. While they served their initial purpose, they were never designed for the complex, global, and interconnected world we live in today. Even IPv6, which addresses some scalability issues, does not solve the fundamental design flaws.
|
||||
|
||||
|
||||
### How the Internet is Broken Due to TCP/IP Design
|
||||
|
||||
The internet, as we know it today, is built on an outdated foundation that was designed for simpler times. Decades ago, TCP/IP was created to connect a handful of computers for research and military purposes. It worked well back then, but it’s no longer enough to handle the complexities of our modern, globally interconnected world. Unless we address its flaws, the internet will struggle to keep up—and could ultimately fail us.
|
||||
|
||||
One major issue is that the internet has no way of "remembering" conversations. For example, when you watch a video or make a video call, your device creates a session—a temporary connection with another server. If this session is interrupted, the entire connection breaks, and you must start over. TCP/IP wasn’t designed to manage sessions, making it unreliable for modern apps and services that depend on continuous communication.
|
||||
|
||||
Another problem is the internet’s complexity. The way it works involves layers of technology stacked on top of each other—apps, storage systems, networks, and more. These layers often don’t communicate efficiently, wasting resources and making everything slower, more expensive, and harder to fix. This complexity also makes the internet fragile, as small issues can cascade into larger failures.
|
||||
|
||||
Security is another area where TCP/IP falls short. It wasn’t designed with cybersecurity in mind, which is why we rely on add-ons like firewalls, VPNs, and encryption. But these tools are essentially patches over a flawed system, and they add even more complexity, making the internet less robust and more vulnerable to attacks.
|
||||
|
||||
Modern services and devices have also outgrown the static design of TCP/IP. The system assumes that servers and devices stay in fixed locations, but today’s internet is dynamic. Cloud services, mobile devices, and apps often move across networks. This static model creates inefficiencies and slows down the system.
|
||||
|
||||
Adding to the problem is the internet’s dependence on a few centralized services, such as Google, Amazon, and Microsoft. These companies control much of the infrastructure we rely on for communication, storage, and services. If one of them fails—or if access is blocked due to political conflicts—entire regions could lose critical internet functions. This centralization makes the system fragile and leaves users vulnerable.
|
||||
|
||||
> The stakes are high. The internet is essential for communication, education, business, and so much more. Yet its foundation is crumbling under modern demands. Without major changes, we’ll see more frequent failures, slower services, and increased vulnerabilities. In extreme cases, parts of the internet could break entirely.
|
||||
|
||||
To fix this, we need a smarter, more resilient approach. Decentralized networks can distribute resources and reduce our dependence on a few central providers. Emerging technologies like RINA (Recursive Inter-Network Architecture) offer a simplified, more secure, and more efficient alternative to TCP/IP. These systems are designed to handle the needs of the modern internet, with built-in reliability, smarter communication, and security at their core.
|
||||
|
||||
> The bottom line is clear: the internet’s outdated foundation is holding us back. If we want the internet to remain reliable and serve future generations, we must address these issues now. A decentralized, secure, and modernized internet isn’t just a technical upgrade—it’s a necessity for our connected world.
|
||||
|
||||
|
||||
## Tech brief (only for the experts)
|
||||
|
||||
|
||||
### 1. **Lack of Session Management**
|
||||
- **TCP/IP’s Shortcomings:**
|
||||
- TCP/IP lacks true session management. A session represents an ongoing communication between two entities (e.g., a user browsing a website). If the connection is interrupted (e.g., due to a network outage or device change), the session is lost, and applications must restart or recover manually.
|
||||
- This flaw creates inefficiencies in modern applications that require reliable, continuous communication, such as video calls, gaming, or IoT devices.
|
||||
|
||||
- **Why It Matters:**
|
||||
- Every time a session breaks, applications have to rebuild connections at a higher level (e.g., re-authenticate or restart a video call). This is inefficient and increases complexity, making the internet fragile and less resilient.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 2. **Layer Violations**
|
||||
|
||||
- **The Problem:**
|
||||
- TCP/IP combines different functionalities into a single stack, leading to inefficiencies. For example:
|
||||
- Routing decisions happen at the IP layer.
|
||||
- Reliable data transfer happens at the TCP layer.
|
||||
- However, these layers are not isolated and often interfere with each other, creating unnecessary overhead.
|
||||
|
||||
- **Impact:**
|
||||
- Modern networks require additional layers (e.g., firewalls, VPNs, NATs) to patch these issues, making the architecture increasingly complex and brittle.
|
||||
|
||||
---
|
||||
|
||||
### 3. **No Built-In Security**
|
||||
- **TCP/IP Design Flaw:**
|
||||
- Security was not a priority when TCP/IP was designed. The protocols do not inherently protect against common threats like spoofing, hijacking, or denial of service.
|
||||
- IPv6 introduces some improvements, such as built-in IPsec, but these are optional and often not used, leaving the same vulnerabilities.
|
||||
|
||||
- **Impact:**
|
||||
- Every modern application must implement its own security mechanisms (e.g., HTTPS, VPNs), leading to duplicated efforts and inconsistent protections.
|
||||
|
||||
---
|
||||
|
||||
### 4. **Scalability Issues**
|
||||
|
||||
- **IPv4 vs. IPv6:**
|
||||
- IPv4, with its 32-bit addressing, exhausted available addresses, leading to NAT (Network Address Translation) as a workaround. This introduced complexity and broke the end-to-end connectivity principle of the internet.
|
||||
- IPv6, with 128-bit addressing, solves the address exhaustion problem but does not address underlying issues like routing table explosion or inefficiencies in the protocol stack.
|
||||
|
||||
- **Routing Problems:**
|
||||
- The lack of built-in session and naming management makes routing inefficient. Large routing tables and decentralized updates slow down the internet and make it harder to scale.
|
||||
|
||||
---
|
||||
|
||||
### 5. **No Support for Application-Centric Networking**
|
||||
- **TCP/IP’s Assumption:**
|
||||
- The protocol assumes communication happens between fixed endpoints (e.g., IP addresses). Modern applications, however, focus on data and services rather than specific endpoints. For example:
|
||||
- Cloud applications may move across data centers.
|
||||
- Mobile devices frequently change networks.
|
||||
- TCP/IP’s static model is incompatible with this dynamic, service-oriented world.
|
||||
|
||||
- **Impact:**
|
||||
- Workarounds like DNS (Domain Name System) and CDNs (Content Delivery Networks) add layers of complexity, but they’re still built on a flawed foundation.
|
||||
|
||||
---
|
||||
|
||||
### RINA: A Better Alternative
|
||||
|
||||
The **Recursive Inter-Network Architecture (RINA)** proposes a solution to the flaws of TCP/IP by rethinking the internet's architecture. Here’s how RINA addresses these issues:
|
||||
|
||||
1. **Unified Layering:**
|
||||
- Unlike TCP/IP, which has rigid and distinct layers, RINA uses recursive layers. Each layer provides the same functionalities (e.g., routing, security, session management), simplifying the architecture.
|
||||
|
||||
2. **Built-In Session Management:**
|
||||
- RINA natively supports session management, ensuring continuity and reliability for modern applications, even in the face of interruptions.
|
||||
|
||||
3. **Application-Centric Networking:**
|
||||
- RINA treats applications as first-class citizens, focusing on the services they need rather than rigid endpoint communication. This aligns with the dynamic nature of modern networks.
|
||||
|
||||
4. **Improved Security:**
|
||||
- Security is integral to RINA, with mechanisms for authentication, confidentiality, and integrity built into every layer.
|
||||
|
||||
5. **Simplified Routing and Scaling:**
|
||||
- RINA reduces the size and complexity of routing tables, making the network easier to scale and manage.
|
||||
|
||||
- **Source:**
|
||||
- [RINA Leaflet](https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf)
|
||||
|
||||
---
|
||||
|
||||
### More info
|
||||
|
||||
more info [https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf](https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf)
|
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: Painkillers
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||

|
||||
|
||||
# The Onion Analogy
|
||||
|
||||
Most cloud & internet stacks can be compared to an onion, where each layer represents an additional component or service added to address a problem in the system. However, like peeling an onion, as you dig deeper, you often find that these layers are not solving the core issues but merely masking symptoms, leading to a complex and often fragile structure.
|
||||
|
||||
**Quick Fixes and Additions**
|
||||
|
||||
- **Problem:** When an issue arises, such as performance bottlenecks or security vulnerabilities, organizations often add another tool, service, or layer to the cloud stack to mitigate the issue.
|
||||
- **Analogy:** This is akin to applying a bandage or taking a painkiller when you feel pain. The immediate discomfort might be alleviated, but the underlying problem remains untouched.
|
||||
|
||||
|
||||
### Painkiller Approach: Treating Symptoms, Not Causes
|
||||
|
||||
This onion-like structure represents a "painkiller approach" to cloud management, where immediate issues are addressed with quick fixes rather than tackling the underlying problems. Over time, this approach leads to several challenges:
|
||||
|
||||
- **Cyber Pandemic** The Cyber Pandemic is real, added these layers leads to weak security.
|
||||
- **Increased Complexity:** Each new layer adds complexity, making the system harder to understand and maintain.
|
||||
- **Higher Costs:** More layers often mean more resources, licenses, and management overhead, increasing operational costs.
|
||||
- **Reduced Agility:** The more complex the stack, the harder it is to make changes or adapt to new requirements, reducing the system’s overall agility.
|
||||
- **Fragility:** A stack built on temporary fixes is more prone to failures because the core issues are not resolved, making the system brittle.
|
Reference in New Issue
Block a user