标签：#Computers

1. Language Architecture in Ghidra When Ghidra loads an architecture (such as the MOS 6502), it parses the .ldefs manifest file, which declares metadata and binds three foundational specification pillars: The .pspec (Processor Specification): Defines the processor’s hardware context. It declares special-purpose registers (e.g., stack pointer SP , status/flags registers), default memory maps (RAM, ROM, I/O), and hardware interrupt vectors. The .cspec (Compiler Specification): Defines the ABI and calling conventions (e.g., parameter passing mechanisms), stack alignment rules, and return value handling. This is the critical building block enabling the decompiler to reconstruct assembly into readable C code. The .sla / .slaspec (SLEIGH Specification): .slaspec : The human-readable source file describing the instruction set architecture (opcodes, instruction formats, and p-code semantics). .sinc (SLEIGH Include): Modular inclusion files (typically used to split complex architectures like ARM or x86, or isolate instruction subsets like Thumb). Given the simplicity of the 6502, everything is defined directly within the .slaspec file. .sla : The compiled binary version of the .slaspec (generated by the Sleigh compiler). Ghidra loads this compiled .sla file into memory at runtime for optimal performance. 2. The Challenges of Reverse Engineering Undocumented Binaries When dealing with a binary compiled for an undocumented processor, Ghidra's default paradigm faces major limitations: The .slaspec file is unavailable. Ghidra attempts to aggressively disassemble everything. Analyzing an undocumented target requires a strict two-phase approach. 3. Missing .slaspec File Without a valid .slaspec definition, Ghidra renders ?? for every opcode. The primary objective when tackling an unknown CPU is precisely to reconstruct this missing .slaspec specification. 4. Overcoming Ghidra's Aggressive Disassembly By default, Ghidra (like most disassemblers) employs an exhaustive strategy (usin

As gaming laptop prices continue to rise, it’s increasingly difficult to find affordable options that aren’t terrible. Here are your best options based on performance and cost.

If you've started learning DBMS for software engineering interviews, you've probably come across terms like Functional Dependency , Attribute Closure , Candidate Key , Normalization , and Canonical Cover . For many beginners, Canonical Cover feels like another algorithm to memorize. It isn't. Before you ever learn how to compute a Canonical Cover, you should understand why it exists . This article focuses only on the Introduction and Foundations . We intentionally won't discuss the algorithm yet. What Is the Interviewer's Intent? When interviewers ask about Canonical Cover , they are usually not testing your memorization . Instead, they want to know whether you understand: How databases represent business rules Why redundant rules create problems Whether you can simplify complex dependency sets Whether you understand the foundations of normalization In interviews, Canonical Cover often appears before questions on: Normal Forms Dependency Preservation Lossless Decomposition BCNF Schema Design Interviewers are checking your understanding of database design , not your ability to recite definitions. Why Do Interviewers Ask Canonical Cover? Imagine a database contains hundreds of dependency rules. Many of those rules may: Repeat the same information Contain unnecessary attributes Be derivable from other rules A good software engineer should recognize unnecessary complexity. Canonical Cover is essentially about answering one question: "Can we represent exactly the same constraints using fewer and simpler rules?" That's why interviewers ask it. They want to see whether you appreciate: simplicity correctness maintainability efficient schema design Where Does Canonical Cover Fit Inside DBMS? Think of DBMS topics as a learning roadmap. DBMS | -------------------------------- | | Database Design Transactions | | Functional Dependencies | Attribute Closure | Candidate Keys | Canonical Cover | Normalization | 2NF → 3NF → BCNF Canonical Cover belongs to the database design portio

Samsung dared to bring 6K to the world of gaming monitors before our PCs were truly ready for it.

A Deep Dive into the Memory Model From Source Code to Machine Instructions A five-part journey through compilers, executables, virtual memory, and the CPU Introduction: What Really Happens When Code Runs Consider a simple C program: include <stdio.h> int value = 10; int add(int a, int b) { return a + b; } int main() { int x = 5; int result = add(x, value); printf("%d", result); return 0; } Most programmers look at this and see only the visible outcome: 5 + 10 = 15 But behind that single printed number lies a much deeper story. Where does the data actually live? Who moves it from one place to another? How does the CPU find the instructions it needs to run? And how does the result finally make its way to the screen? Answering these questions means understanding a concept that many programmers use daily but rarely examine closely: the memory model. What Is a Memory Model, Really? Ask most developers what a "memory model" means, and the answer usually comes back in two words: stack and heap. That answer isn't wrong - it's just incomplete. A memory model is really a description of five things at once: How data is stored How data is accessed How long data exists Who is responsible for managing that lifetime How different parts of a system communicate through memory A program never leaps directly from C source code into RAM. Several distinct layers sit between the two, each one translating the layer below it into something the layer above can reason about. This article walks through all of them, one at a time, and then reassembles the full picture. The Four Layers, at a Glance Layer What It Deals With Typical Concepts 1. Programming Language Human-readable code scope, lifetime, ownership 2. Compiler Translating code to instructions registers, optimization, assembly 3. Operating System Running the program as a process virtual address space, .text/.data/.bss 4. CPU Architecture Executing raw instructions registers, cache, pipeline, ALU The rest of this article follows a sing

Industrializing the disassembly of an undocumented processor from a raw binary is a complex task that can be broken down into four key steps: Verify that the binary does not belong to a known processor. Verify that the binary is not obfuscated, compressed, or encrypted code for a known processor. Build an undocumented processor generator. Create the analysis pipeline and custom disassembler generation process. For the first phase of this project, the goal is to build dedicated, lightweight disassemblers—since, for bare-metal binaries, tools like Ghidra require manual processor target selection before analysis can begin. 1. Why Build a Custom Disassembler? To determine whether a binary was compiled for a specific architecture, the strategy consists of disassembling the binary (both statically and dynamically) against candidate instruction sets until: One or more bytes fail to match any valid instruction for that architecture, allowing us to rule it out. The disassembly succeeds completely. (Note: a successful disassembly does not guarantee that the binary was originally intended for that CPU; control flow validity must also be verified). Static disassembly is the first line of defense. However, if it fails due to obfuscation, compression, or encryption, we must escalate to dynamic execution and analysis. Only after systematically eliminating all known architectures can we confidently conclude that we are dealing with a custom or undocumented processor . 2. How to Build Your Custom Disassembler Before deploying heavy machinery for undocumented processors, the logical first step was to check against known architectures. Approach 1: Ghidra and SLAgh Ghidra relies on the SLAgh specification language and maintains an extensive library of processor definitions. The original plan was to leverage its API to extract a normalized opcode mapping table. However, after several attempts, Ghidra proved unsuitable for this specific pipeline for two reasons: Operand Type Loss: Detail

We’ve come a long way since exclusively $1,000+ OLED gaming monitors. Alienware’s latest display brings the price down to a shocking $350, though it comes with some important compromises.

大模型来了，有个说法是如果一个问题容易验证 那么ai就容易学会解决！说说这个特性与p np问题的关联性 这个说法听起来很直观，但其实 混淆了"验证的复杂性"和"学习/求解的复杂性"这两件不同的事 。我们把它拆开看。 先把"容易验证"在 P/NP 里的精确定位理清 在计算复杂度理论中： NP = 给定候选解（证书），能在多项式时间内验证其正确性的问题 P = 能在多项式时间内直接求解的问题 P ≠ NP ? = 是否所有容易验证的问题，也都容易求解？ 所以"容易验证"在 CS 里的严格含义是： 验证者在多项式时间内工作 ， 不是说 AI 训练成本低 。 "容易验证 ⇒ AI 容易学会"——部分成立，但有重要的限定 这个直觉 在某些场景下确实成立 ，原因是"验证"提供了 稠密的训练信号 ： ✅ 成立的情形：验证器可作奖励/过滤 当一个问题具备"易于验证"的结构时，我们可以用它来： 生成训练数据 ：比如 SAT 问题，随机生成一个赋值，代入公式验证，正确就得到一对 (公式, 赋值) 训练样本—— 数据无限且免费 RL 中的奖励塑形 ：LLM 生成代码 → 编译器/单元测试验证 → immediate reward Self-play / 自我蒸馏 ：AlphaGo 等用模拟器验证落子结果 Verifier-Guided Search ：用"易于验证"的判据引导 beam search / MCTS，如 AlphaCode、AlphaGeometry 💡 这就是为什么像 代码生成、形式化证明、数学解题 这些领域近期进展飞快——它们都有"相对容易的验证器"（单元测试、类型检查器、证明校验器）。 ❌ 但这个推论远非普遍成立 "容易验证"≠"AI 容易学会"，有几个关键原因： 1. 验证器只给二值信号，梯度稀疏 验证器通常只输出 0/1（对/错），而深度学习需要平滑的损失曲面。对于复杂的 NP 问题，绝大多数随机猜测都是错的 → 奖励恒为 0 → 梯度消失，学不到东西 。这就是"稀疏奖励"难题。 2. P ≠ NP 意味着：验证简单 ≠ 求解简单 即使验证是 O(n)，找到那个能通过验证的解可能仍需 O(2ⁿ)。AI 模型本质上是在做启发式搜索，面对组合爆炸， 没有 free lunch 。例如： 数独：验证 O(n²)，但最难的数独对人类和 AI 都极具挑战 TSP：验证一条回路 O(n)，但找最优回路是 NP-Hard 3. 分布偏移与泛化 NP 问题的"容易验证"是** worst-case 复杂度**意义下的。AI 学到的是训练分布的统计规律，遇到分布外的实例会失效。比如 LLM 在数学竞赛题上表现好，但换个数字或换种表述就可能崩。 4. 验证本身也可能不在 NP 里 很多现实问题是 PSPACE 或更难 （如围棋先手胜负），验证一个"策略"需要指数时间——这种问题连"提供证书让 AI 模仿"都很困难。 一张对照表 问题类型 验证复杂度 AI 易学吗？ 例子 P 类 多项式 通常容易 （有高效算法可直接教） 排序、最短路径 NP-Complete，且有稠密验证信号 多项式 中等 （RL + 验证器有效） SAT、数独、TSP 近似 NP-Complete，但验证信号稀疏 多项式 困难 （奖励太稀） 某些密码学难题 超出 NP（PSPACE 等） 超多项式 极难 （验证本身就很贵） 围棋先手胜、QSAT 不可判定 不存在 不可能 （理论上限） 程序等价性 真正的关联在哪里 "容易验证 ⇒ AI 容易学会"更准确的说法应该是： 📌 如果一个问题有"多项式时间的验证器"，并且我们能从中提取稠密的训练信号（如 partial credit、逐步验证），那么 AI 可以通过"生成 + 验证"的循环去逼近求解。 这本质上就是 用 NP 的"验证侧"去攻击"求解侧" ——也是当前 LLM + Verifier 范式（如 RLHF 中的 reward model、AlphaProof 的 formal verifier）的理论基础。 但要注意： 这不是 P=NP 的证明，AI 找到的解在 worst-case 仍可能不是最优的 AI 解决的是 平均情况（average-case） 或 特定分布 ，而非 worst-case 一旦问题规模增大到超出训练分布，性能会急剧下降 一个更深的视角：平均-case 复杂度 理论计算机科学里有个分支叫 Average-Case Complexity ，研究"典型实例"的难度。很多 NP-Complete 问题在 average-case 下其实有不错启发式算法——这也解释了为什么 AI 在某些 NP 问题上表现惊喜，但在 adversarial 构造的 hard instance 上翻车。 所以回到你的说法： "

There are both cheaper and more powerful entry-level gaming laptops out there, but the Alienware 15 walks that tightrope between price and quality.

I just made Whizz, an esoteric programming language that is full of capability and possible experimentation. Before I interest you in that, I'll explain to you something. What is an esoteric programming language? An esoteric language (or an esolang, colloquially), is a programming language designed to not fit the coding 'norms' or conventions. Take an example: BF ('BF' is an abbreviation and euphemism of brainf***). A standard language would notate a 'Hello, World!' program as something like: print ( " Hello, World! " ) BF, on the other hand, requires something like this: ++++++++ [ > ++++ [ > ++ > +++ > +++ > + <<<< - ] > + > + > - >> + [ < ] < - ] >> . > ---.+++++++..+++. >> . < -. < .+++.------.--------. >> +. > ++. As you can see, BF, like most esolangs, is different: it's hard to write and a puzzle. Whizz is inspired by BF, as its incrementing, decrementing and looping are inspired by it. I made Whizz because I thought languages like BF were way too monotonous to write. Esolangs should be hard and puzzling to write, but not laborious. BF requires you type '+' as many times you want to increment (without loops): so you have to find shortcuts and unscalable solutions, just to achieve your goal. In Whizz, just type that incrementation repetition count before the '+' sign, and there you have it! These wonderful features that Whizz boasts keep the challenge in esolang-ing, but contradictorily makes it more 'scalable'. Another notable feature is functions: the epitome of order. An example of a Whizz program would be: zeroToNine { [ create variables ] counter 10+ [ track state ] char 48+ [ print this one ] space 32+ [ space char ] ( char!+ [ print and increment char ] counter-; [ decrement counter and end if zero ] space! [ print space ] ) } zeroToNine* This, self explanatorily, outputs '0 1 2 3 4 5 6 7 8 9'. Again, in minimized form: c10+n48+s32+(n!+c-;s!) I genuinely hope you experiment with Whizz, and solve puzzles & challenges with it, as if it were BF! Install it

Thanks to the surge in local AI processing and the ongoing memory shortage, it’s incredibly difficult to buy a Mac Mini.

If your router is short on ports, you can add more with one of the best Ethernet switches. These are my top picks from what I’ve tested.

TL;DR Eight engineering disasters. Zero arithmetic errors. Every single one was caused by two numbers — both correct, both carefully computed — meaning different things on opposite sides of a software interface. One cost $65 billion. Another killed 28 soldiers because 0.1 can't be represented in binary. The fix is never the math. The fix is the label. There is a particular kind of silence in a control room when someone realizes the number on the screen is in the wrong unit. It lasts about two seconds. Then it's replaced by the kind of noise nobody wants to hear. On September 23, 1999, that silence happened at the Jet Propulsion Laboratory in Pasadena, California. The Mars Climate Orbiter had just disappeared behind the planet. Telemetry showed the spacecraft at 57 kilometers above the surface. It was supposed to be at 140. The silence was four seconds long. Then someone said "oh no" — the official NASA transcript uses a stronger word — and $327 million of aluminum, titanium, and human effort disintegrated into the Martian atmosphere. What follows are eight stories about the same bug, wearing different uniforms. Some are famous. Some you've never heard of. Two of them are pure software failures that every developer who's ever written for (let i = 0; i < 10; i += 0.1) has come within a rounding error of replicating. 1. The Patriot Missile — When 0.1 Is Not 0.1 (1991) Let's start with the one that belongs in every CS curriculum. Because this isn't a "unit conversion" error in the traditional sense — nobody confused meters and feet. The error was in the way a computer counted time. And it killed 28 American soldiers in a warehouse in Dhahran, Saudi Arabia. The MIM-104 Patriot missile system tracks incoming targets using a phased-array radar. The radar scans the sky, and the fire-control computer predicts where the target will be when the interceptor arrives. That prediction depends on knowing exactly when the radar echo returned. Time is measured by the system's interna

This series follows a fictional conversation between an experienced engineer and his nephew. Every episode explores one stage of how software moves from an idea to production. 👦 Nephew: Uncle, requirements are clear. I checked the codebase — there's already a FavoritesService I can extend for Wishlist. Now can I open VS Code? 👨‍🦳 Uncle: Almost. Tell me — what do you think HLD even is ? You've heard the term in every interview. What do you think it actually means? 👦 Nephew: Some kind of... diagram? Boxes connected with lines, before you start coding? 👨‍🦳 Uncle: That's what it looks like. That's not what it's for . Let me ask differently. Why do you think experienced engineers insist on drawing this before touching code, when they could just start building? 👦 Nephew: ...to plan the work? 👨‍🦳 Uncle: Closer, but still not it. Here's the real answer: HLD exists to decide, in advance, where the walls go — so that six months from now, when someone adds a new feature, they know exactly which room to build it in, without knocking down a wall that was holding up the ceiling. 👦 Nephew: That's a strange way to describe a diagram. 👨‍🦳 Uncle: Then let me show you, instead of describing it. That's the only way this actually lands. What Talks to What 👨‍🦳 Uncle: Suppose we're building this at Flipkart. Not a college project — a company with hundreds of live services, where breaking one thing can affect ten others you've never even heard of. Here's the simplest picture for Wishlist. Frontend ↓ Wishlist API ↓ Wishlist Service ↓ Database 👦 Nephew: That's it? Four boxes? 👨‍🦳 Uncle: That's it. HLD answers exactly one question, and nothing more — what talks to what. Not how the button looks. Not what fields the database table has. Just: which component calls which, and in what direction. 👦 Nephew: Then why does everyone treat it like it's such a big deal? This took ten seconds to draw. 👨‍🦳 Uncle: Because the value isn't in the ten seconds you spend drawing it today. The value is in what i

Building a Decompiler Pipeline in Rust: Why Fission Separates NIR and HIR Decompiler output often looks simple from the outside. A binary goes in. Pseudocode comes out. But between those two points, a decompiler must recover several different kinds of information: instruction semantics register and memory effects control flow stack variables calling conventions data types expressions loops and conditionals readable source-like structure Trying to represent all of this in one intermediate representation quickly becomes difficult. While building Fission , a reverse-engineering and binary decompilation workspace written primarily in Rust, I decided to separate the decompiler pipeline into two main intermediate representations: NIR , a lower-level representation intended to preserve machine semantics HIR , a higher-level representation intended to express recovered, human-readable program structure This article explains why that separation exists, what each representation owns, and why it makes decompiler development easier to reason about. Correctness and readability want different things A decompiler has at least two responsibilities. First, it must preserve the behavior of the original machine code. Second, it must produce output that a human can understand. Those goals overlap, but they are not identical. Consider a simplified fragment of machine-level behavior: tmp0 = RAX tmp1 = tmp0 + 1 RAX = tmp1 flags = update_flags(tmp0, 1, tmp1) A human reader may prefer to see: rax ++ ; The concise form is easier to read, but it omits details that may still matter elsewhere in the pipeline. The flags update could affect a later conditional branch. The operation width may matter. The source and destination could alias. The operation may have originated from an instruction with additional side effects. If the decompiler converts everything into source-like syntax too early, it becomes easy to discard evidence. If it keeps everything at machine level until the final rendering st

If you have written any optimization code, you have met linear programming even if nobody called it that. "Maximize output without blowing the resource budget" is an LP problem, and the classic algorithm that solves it is the simplex method. It is worth understanding not because you will hand-code it (you'll usually call a solver), but because knowing how it moves makes you far better at modeling problems for it. Here is the algorithm stripped down to its logic. The problem shape Every LP problem has three parts: an objective function to maximize or minimize, e.g. Z = 5x1 + 4x2 a set of linear constraints, e.g. 6x1 + 4x2 <= 24, x1 + 2x2 <= 6 non-negativity: all variables >= 0 Geometrically, the constraints carve out a feasible region (a polytope). The optimum always sits at a corner of that region. The simplex method is just a smart way of hopping from corner to corner, uphill, until there is no higher corner to move to. The algorithm as pseudocode build initial tableau (add a slack variable per <= constraint) loop: compute Cj - Zj for each column if all (Cj - Zj) <= 0: break # optimal reached pivot_col = column with most positive Cj - Zj # entering variable ratios = RHS / pivot_col entries (only positive entries) pivot_row = row with smallest non-negative ratio # leaving variable pivot(pivot_row, pivot_col) # elementary row operations return solution from final tableau That's it. Four moves per iteration: score the columns, pick the entering variable, run the ratio test for the leaving variable, pivot. Repeat until the optimality condition holds. A quick worked run Take Maximize Z = 5x1 + 4x2 subject to 6x1 + 4x2 <= 24 and x1 + 2x2 <= 6. Add slack variables s1, s2, build the tableau, and iterate. The optimum lands at x1 = 3, x2 = 1.5, Z = 21. Two pivots and you're done. Simple on paper until the numbers get ugly. Where humans (and debugging) actually break The algorithm is clean. The arithmetic is not. A single wrong entry in one pivot silently corrupts every table

https://mdooai.com AI 모델을 다루다 보면 코드는 돌아가는데 왜 성능이 안 나오는지 이해하지 못하는 순간이 옵니다. 그 답은 대부분 수학에 있습니다. 실무 AI 개발자로 성장하기 위해 반드시 잡아야 할 최소한의 수학 개념과, 그것을 어떻게 공부해야 하는지를 구체적으로 살펴보겠습니다. 코딩만으로는 해결할 수 없는 AI 모델 성능의 열쇠 많은 주니어 개발자들이 비슷한 경험을 합니다. PyTorch나 TensorFlow로 튜토리얼 코드를 복사하고, 학습도 돌리고, 결과도 나옵니다. 그런데 모델이 왜 이렇게 예측하는지, 왜 학습이 멈추는지, 어떻게 하면 성능이 올라가는지는 설명할 수가 없습니다. 이 간극의 정체가 바로 수학입니다. 가령 모델이 과적합(overfitting)될 때 L2 정규화를 쓰라는 조언을 듣습니다. 코드 한 줄로 해결되지만, 그게 왜 작동하는지는 가중치 벡터의 크기를 제한한다는 선형대수와 확률론적 추론이 얽혀 있습니다. 이 원리를 이해하는 개발자와 모르는 개발자가 새로운 문제에서 만들어내는 솔루션의 질은 다를 수밖에 없습니다. 다행인 건, AI 개발에서 필요한 수학은 대학원 수준의 수리해석학이 아닙니다. 핵심 개념 몇 가지를 실용적 도구로 이해하는 것으로 충분합니다. 선형대수와 확률통계, 어떤 개념부터 공부해야 할까? 선형대수와 확률통계는 AI 수학의 두 축입니다. 그런데 이 두 분야 전체를 공부하려 들면 끝이 없습니다. 개발자 관점에서 실제로 반복해서 등장하는 개념만 추려내면 다음과 같습니다. 선형대수에서 우선해야 할 개념 벡터와 행렬의 연산 : 데이터는 사실상 전부 벡터와 행렬로 표현됩니다. 이미지는 픽셀값 행렬이고, 텍스트는 임베딩 벡터입니다. 행렬 곱(matrix multiplication)이 신경망의 순전파(forward pass) 그 자체입니다. 내적(dot product)과 유사도 : 추천 시스템, 어텐션 메커니즘(Transformer의 핵심)이 내적 연산 위에 서 있습니다. 고유값(eigenvalue)과 고유벡터(eigenvector) : PCA(주성분 분석)처럼 차원을 줄이는 기법을 이해하려면 반드시 필요합니다. 행렬 분해(SVD 등) : 추천 시스템과 자연어 처리의 기반 기술에 등장합니다. 확률통계에서 우선해야 할 개념 확률분포와 기댓값 : 모델의 출력이 확률인 이유, 소프트맥스(softmax)가 하는 일을 이해하는 기반입니다. 베이즈 정리 : 사전 지식을 데이터로 업데이트하는 논리 구조로, 생성 모델과 불확실성 추정에 직접 연결됩니다. 최대 우도 추정(MLE, Maximum Likelihood Estimation) : 모델 학습이 왜 손실 함수를 최소화하는 방향인지를 설명하는 원리입니다. 크로스 엔트로피 손실 : 분류 모델에서 가장 자주 쓰이는 손실 함수로, 확률론과 정보이론이 만나는 지점입니다. 분야 핵심 개념 AI 실무 연결 지점 선형대수 행렬 곱, 내적 신경망 순전파, 어텐션 선형대수 고유값·고유벡터 PCA, 차원 축소 선형대수 행렬 분해(SVD) 추천 시스템, NLP 확률통계 확률분포, 기댓값 소프트맥스, 분류 출력 확률통계 베이즈 정리 생성 모델, 불확실성 추정 확률통계 최대 우도 추정 손실 함수의 논리적 근거 확률통계 크로스 엔트로피 분류 모델 학습 활성화 함수와 역전파에서 미적분은 어떻게 작동하는가? 미적분은 신경망 학습의 핵심 메커니즘인 역전파(backpropagation)를 이해하는 데 필요합니다. 겁먹을 필요는 없습니다. AI 개발에서 실제로 필요한 미적분 개념은 크게 두 가지입니다. 1. 편미분과 기울기(gradient) 손실 함수는 모델의 가중치를 변수로 가지는 다변수 함수입니다. 학습이란 이 함수의 값을 줄이는 방향으로 가중치를 조금씩 조정하는 과정입니다. 이 '방향'을 계산하는 도구가 편미분이고, 모든 가중치에 대한 편미분을 모아놓은 것이 기울기(gradient)입니다. 경사하강법(gradient descent)은 이 기울기의 반대 방향으로 가중치를 업데이트합니다. 수식으로는 다음과 같습니다. 새 가중치 = 기존 가중치 − 학습률(lr) × 기

I’ve been out of context with my computer science degree for years, and honestly, it feels overwhelming. I want to change that, so I'm starting this log to document my comeback story, my failures, and my progress. What I did today: Acknowledged the starting line. Took 10 minutes to think about where I left off and what I need to tackle first. Decided to write daily logs. This is not my first attempt to finish the degree, but hopefully with some public eyes on it, it will be the last. 10 subject left. Starting with Mathematical analysis. The biggest challenge right now: Feeling completely out of context and fighting the urge to get distracted by everything else. Many things have changed since i was actively going to classes. My generation graduated many years ago and i feel like getting all the information I need will be extremely difficult since i don't know anyone. Getting information from the university websites and emailing professors will be slow. Next steps: Tomorrow, I'm going to try to overcome my overdramatic anxiety and post in the student groups I was in, in hope that somebody might have new information about the subjects. I will go start lesson #1. Goal is to ease into the material and start a habit, rather than pressuring myself to do everything at once. Come back tomorrow.

**🙄 فى كتاب chapter الصدمة دي هي بالظبط اللي حسيت بيها وأنا بقرأ أول “operating system: three easy Pieces “ ‘OSTEP’. 🖤اهلا بيكم ! يارب تكونوا بخير 💯 حابه اشارك معاكم رحلتى مع قراءة الكتاب ونستفيد منه سوا قبل ما نعرف هو !!!! ولا لا OS is virtual machine 🤔 !!!!دا يعنى ايه ووظيفته ايه OS تعالوا الاول نعرف ال موجودة فى الكمبيوتر ولا لا ؟؟؟؟ RAM وال CPUزى ال HARDWARE وهل هو قطعة ::هنبدأ من الاخر موجود على الكمبيوتر SW هو عبارة عن HW يسيدى مش قطعة OSال .على الجهازINSTALL ولازم يبقى ووظيفته ايه؟؟؟ OS طب يعنى ايه ‘OS’ اختصار “OPERATING SYSTEM”. .“يعنى نظام تشغيل “ .👁‍🗨👁‍🗨 تعالوا نعرف معنى ” نظام تشغيل” ونفسرها نظام تشغيل يعنى مسئول عن 1_ “HWالنظام “من غيره مش هيبقى فيه نظام خصوصا لقطع ال . يعنى بناخد منه الاذن للعمليات HW ببعضه وكمان بيدير ال HWيعنى هو بيربط ال 👏 . (Order)من الاخر بيخلق “النظام” 2_.”التشغيل “هو المسئول عن تشغيل البرامج Learn about Medium’s values هو اللي بيتحكم في دورة حياة البرنامج بالكامل؛هو اللي بيبدأ تشغيله في الذاكرة،OSيعني الـ وبيحدد هو محتاج إيه من إمكانيات الجهاز عشان يشتغل بكفاءة وبيفضل مراقبه ويحميه طول ما هوشغال ، ولحد ما تقفليه بنفسك 🌹 .ويقوم هو بتنظيف الذاكرة وتوفير المساحة لغيره 🧐::وظيفته بقا بيخلي البرنامج يشتغل بسهولة:1️⃣ لأنه بيخلق للبرنامج بيئة وهمية مريحة، وبيخفي عنه كل التعقيدات والأسلاك بتاعة الهاردوير عشان يشتغل بسلاسة 2️⃣: بيسمح للبرامج إنها تشارك الذاكرة بين كل البرامج بالعدل RAM بيشتغل كعسكري مرور بيوزع مساحة الـ . وبيحمي كل برنامج في مساحته الخاصة 3️⃣: بيمكن البرامج إنها تتعامل مع الأجهزة بيعمل كـ “وسيط” أو مترجم بيوصل كود البرنامج بالقطع الحقيقية (زي الشاشة أو الهارد) .عشان ينفذ أوامره فوراً بيعمل التلات حاجات دول إزاي في نفس الوقت وبمنتهى السلاسة؟ ؟؟؟OS طب الـ بيعملهم يسيدى عن طريق أكبر خدعة سحرية في عالم الكمبيوتروهي الـ Virtualization👌 كنت حابة جداً أكلمكم المرة دي عن خدعة الـ “Virtualization” 💎 😌👁👁اللي اتكلمنا عليها في العنوان، بس لقيت البوست هيبقى طويل أوي عليكم ✔🔥!!وعشان متعبكمش معايا.. هنخليها للبوست الجاي إن شاء الله 💯✅!!بيعمل الخدعة دي إزاي OSاستنوا البوست الجاى عشان نعرف الـ 💋.دمتم بخير **

Introdução O nome do princípio vem do próprio nome do projeto de pesquisa (que remete a Deméter, deusa grega da agricultura — a metáfora era "cultivar" software que cresce de forma incremental e adaptável, não do princípio de acoplamento em si). O projeto Demeter investigava como reduzir o custo de manutenção de sistemas orientados a objetos observando que boa parte das mudanças de software quebrava código muito distante do ponto onde a mudança real acontecia — um efeito cascata causado por classes que conheciam profundamente a estrutura interna de outras classes. Essa observação foi confirmada empiricamente alguns anos depois: em 1994, Chidamber & Kemerer publicaram as famosas métricas CK ( A Metrics Suite for Object Oriented Design ), nas quais o CBO (Coupling Between Objects) — quão acoplada uma classe é a outras — se tornou um dos preditores mais fortes de defeitos e esforço de manutenção em estudos empíricos posteriores de engenharia de software. Ou seja: a intuição por trás da Law of Demeter (menos acoplamento = menos bugs ao mudar código) tem respaldo em dados de décadas de pesquisa empírica em qualidade de software. Definição Também chamada de "Principle of Least Knowledge" , a formulação clássica é: Um método M de um objeto O só deve chamar métodos de: O próprio O Os parâmetros recebidos por M Qualquer objeto que M crie/instancie internamente Os componentes diretos de O (seus atributos/campos) Variáveis globais acessíveis a O Resumo popular: "use apenas um ponto" — evite código como: pedido . getCliente (). getEndereco (). getCidade (). getNome () Isso é conhecido como "train wreck" (trem de vagões) — cada . é um vagão acoplado ao anterior. Se a estrutura interna de Cliente ou Endereco mudar, todo código que fez essa travessia quebra, mesmo estando em um módulo completamente não relacionado. Porque isso importa na prática? Quando o método M faz objeto.getX().getY().metodo() , ele passa a depender da estrutura interna de X e Y , não só da interface pública d