[akham]

Government official dies during data center fire recovery efforts

In a catastrophic failure of digital governance, a fire at a South Korean national data center has resulted in the permanent loss of nearly a petabyte of government data.

The incident shows a shocking disregard for basic disaster recovery principles, leaving tens of thousands of civil servants unable to access years of work.

The fire broke out on September 26 at the National Information Resources Service (NIRS) in Daejeon, destroying the government’s ‘G-Drive’ cloud storage system. Officials confirmed that for this critical 858TB system, no external backups existed, making the data loss irreversible.

https://winbuzzer.com/2025/10/06/sou...ackups-xcxwbn/

A 56-year-old government official overseeing network restoration after a fire at the National Intelligence Resources Center has died after jumping from a building.

According to the Ministry of the Interior and Safety and police, the official, a senior officer in the Digital Government Innovation Office, was found in cardiac arrest near the Central Building of the Government Complex in Sejong at around 10:50 a.m. on Oct. 3. He was taken to a hospital but did not survive. His mobile phone was found on the south terrace smoking area of the 15th floor, and no suicide note was recovered.

Authorities said he was not involved in the police investigation into the fire. He had been overseeing the restoration of computer networks after the blaze. Police are investigating the exact circumstances, including whether workload may have contributed to his death. The ministry expressed condolences, saying it mourned the loss of the official.

The ministry plans to continue recovery work throughout the Chuseok holiday. Eight days after the fire on Sept. 26, only 115 of 647 affected networks had been restored, a recovery rate of 17.8 percent. While the government aims to restore all networks as quickly as possible, full normalization may take at least a month.

The slow recovery is partly due to networks on the 2nd to 4th floors, which were not directly damaged, being linked to the destroyed 5th-floor network and shared storage systems. The government plans to minimize public disruption by offering alternative services for heavily used systems.

https://www.donga.com/en/article/all/20251004/5885938/1

[kellyhound]

clusterfuck

[soja]

the most frustrating of all the fucks.

[Mr.NoCredit]

Just bring in AI to figure out what’s been lost. It won’t take but a minute and they’ll be back online again in no time at all!

[William May]

Originally Posted by kellyhound ↗

clusterfuck

Clusterfuck and computers go together like hot dogs and buns.

You would THINK that stuff like Spam phone calls, and internet viruses, would have been IMPOSSIBLE with proper programming. But EVERYTHING programmers do is by the seat of the pants, with a "let's get it out NOW, and we'll fix the bugs later!" attitude that has resulted in computers being completely fucked up, from 1995 until right now. 30 YEARS, and the SAME problems still persist. NONE of this shit should EVER have been released for use. NONE of it was ready then, and ALL of it is deficient in some way right now.

That is also why I have NO FAITH in A.l. It's just ANOTHER batch of bullshit that is riddled with faults and problems, and will probably NEVER be actually straightened out.

[IvorySmith]

Originally Posted by William May ↗

Clusterfuck and computers go together like hot dogs and buns.

You would THINK that stuff like Spam phone calls, and internet viruses, would have been IMPOSSIBLE with proper programming. But EVERYTHING programmers do is by the seat of the pants, with a "let's get it out NOW, and we'll fix the bugs later!" attitude that has resulted in computers being completely fucked up, from 1995 until right now. 30 YEARS, and the SAME problems still persist. NONE of this shit should EVER have been released for use. NONE of it was ready then, and ALL of it is deficient in some way right now.

That is also why I have NO FAITH in A.l. It's just ANOTHER batch of bullshit that is riddled with faults and problems, and will probably NEVER be actually straightened out.

Whether their incompetence was intentional, I'm not sure, but they definitely did well to ensure job security for a while by programming errors into the computers. Maybe it's like planned obsolescence, but it's planned incompetence

[akham]

Originally Posted by kellyhound ↗

clusterfuck

That's true. Their cluster is fucked.

I just love the sad looks on the managers' faces as they stare at all the charred servers under water.

That is, literally, their server pool.

Next time they will make sure they have a backup pool.

[akham]

Originally Posted by William May ↗

Clusterfuck and computers go together like hot dogs and buns.

You would THINK that stuff like Spam phone calls, and internet viruses, would have been IMPOSSIBLE with proper programming. But EVERYTHING programmers do is by the seat of the pants, with a "let's get it out NOW, and we'll fix the bugs later!" attitude that has resulted in computers being completely fucked up, from 1995 until right now. 30 YEARS, and the SAME problems still persist. NONE of this shit should EVER have been released for use. NONE of it was ready then, and ALL of it is deficient in some way right now.

That is also why I have NO FAITH in A.l. It's just ANOTHER batch of bullshit that is riddled with faults and problems, and will probably NEVER be actually straightened out.

This is the ChatGPT analysis of your comments (true, not kidding).

Let me break down the post’s claims and see where they are correct, overblown, or misleading.

“Clusterfuck and computers go together like hot dogs and buns.”

Strong rhetorical flourish. Certainly computing projects (like any engineered systems) often run into disasters or poorly handled releases. But this is a generalization, not a claim we can verify or falsify as is.

“You would THINK that stuff like Spam phone calls, and internet viruses, would have been IMPOSSIBLE with proper programming.”

Spam calls: This is largely a consequence of economic incentives (cheap automation, spoofing, telecommunications regulations, international routing), not just software bugs. Even “proper programming” can’t prevent abuse if the attackers have the infrastructure and incentives to exploit weak regulatory controls, loopholes, or vulnerabilities in telephony infrastructure (e.g. SS7 abuses, SIM‐swaps, carrier interconnects).

Internet viruses / malware: Though many vulnerabilities arise from coding mistakes (buffer overflows, logic errors, memory safety, input validation), security is a very hard domain. Even with “proper design,” tradeoffs in usability, feature pressure, backward compatibility, performance, and complexity introduce risks. Also, many systems depend on third-party libraries, integration, networking, etc., which expands the attack surface. So it’s not correct to assume that a “perfect” by-design software ecosystem would entirely eliminate such threats.

So the claim is overly simplistic. A “properly programmed” world is an ideal, but there are many dimensions (hardware, compilers, libraries, interoperability, human factors, legacy systems) that contribute to vulnerabilities.

“EVERYTHING programmers do is by the seat of the pants … ‘let’s get it out NOW, and we'll fix the bugs later!’ … 30 YEARS … SAME problems still persist. NONE … should EVER have been released … ALL … is deficient in some way right now.”

It is true that in many real organizations, deadlines, market pressure, under-resourcing, and management decisions push software out before it’s “perfect.”

But the sweeping statement “EVERYTHING” or “NONE should have been released” is hyperbole. Many software systems do work reliably in many contexts (banking, air traffic, telecommunications, industrial control).

The persistence of recurring classes of bugs (e.g. memory safety, concurrency errors, network security flaws) is real, but progress has been made in languages, tooling, formal methods, static analysis, fuzzing, secure development practices, etc.

So the post exaggerates to make a rhetorical point. It has a kernel of truth (software reliability is often worse than ideal), but it overreaches.

“That is also why I have NO FAITH in A.l. … riddled with faults and problems … probably NEVER be actually straightened out.”

AI systems (especially large, complex ones) do indeed have faults: bias, hallucinations, adversarial vulnerability, brittleness, incomplete robustness, etc. It’s reasonable to be skeptical.

But to assert “will never be straightened out” is again a categorical claim. The history of software is one of iterative improvement, and it is possible improvements in theory, training, verification, adversarial robustness, interpretability, etc., may reduce many of these faults over time.

And this is how it would respond to you:

I totally get the frustration — large software systems do often ship with serious flaws, and we’ve seen the same types of bugs (security, memory, concurrency, unexpected edge cases) recur over decades. But the sweeping “EVERYTHING is broken, none should ever have been released” view is too pessimistic and ignores what has been achieved and what constraints actually exist.

Let me push back a little with context and caveats:

Complexity is unavoidable. Every real software system operates in a messy world of hardware diversity, legacy components, network interactions, user inputs, timing, third-party libraries, versioning, and human operators. The more functionality and scale you aim for, the more room for subtle failures. Some bugs are fundamentally very hard to eliminate.

Tradeoffs, deadlines, and risk. In practical engineering, there is always a trade between “perfect” and “good enough under constraints (time, cost, compatibility)”. Many systems are released with known risks that are judged acceptable in context (with mitigation, patching plans, monitoring, failover). The alternative is stagnation — never shipping anything.

Progress exists. Over time we’ve developed better programming languages, static analysers, model checkers, fuzzers, sandboxing, containerization, formal verification in critical domains, more secure defaults, and better CI/CD practices. Systems today can be vastly more reliable than those a few decades ago (for example in some safety-critical systems). A 1995 OS or network stack is not directly comparable to 2025 variants.

Operational failures are different from coding bugs. The Korea incident is a dramatic example of an operations / redundancy / disaster recovery failure. Even with “perfect code,” if you put all your data in one vulnerable location and don’t replicate it, you’re exposed. The decision not to have external backups for G-Drive was a (very dubious) architectural choice, not a coding flaw per se. That’s a cautionary example, but not proof that all systems or AI are inherently hopeless.

AI has special challenges, but also opportunities. AI systems (especially large models) are brittle, opaque, and prone to hallucinations or adversarial inputs. But the field is young (relatively), and techniques in verification, interpretability, adversarial training, robustness, hybrid AI+symbolic methods, and safer architectures are actively evolving. It’s fair to be skeptical, but not necessarily to conclude “never fixable.”

So overall: yes, the failures, disasters, and recurring software maladies are real and frustrating. They are legitimate grounds for critical scrutiny of software practices, accountability, architecture, regulation, and incentives. But it’s hyperbole to claim that nothing should ever have been released and everything is irredeemably flawed. The South Korea fire is a powerful cautionary tale, but it’s not a proof that software (or AI) is hopeless — just that in infrastructure and critical systems, negligence or architectural mistakes can produce catastrophic failures.

I asked ChatGPT how much corn it thinks you deserve for your post. It said this:

[QUOTE]
I’d give that Internet post

[akham]

Oops, looks like I was too long. (It happens to me a lot). Here's the last part:

[QUOTE]
I’d give that Internet post

[akham]

Nope, it wasn't length - I guess it was the corn cobs. Post preview was fine. Trying again.

(I can't edit, could a mod plese clean this up?)

I’d give that Internet post (corn-rating: 2 / 5).

Here’s why:

Two cobs: “Frustrated but overcooked”

The post captures a real, relatable frustration — that software often ships with flaws and that big, preventable disasters (like the Korean data-loss incident) keep happening. That earns it one cob.
It also expresses an authentic emotional truth about the speed-over-quality culture that can plague tech. That’s the second cob.

Missing the other three cobs:

Oversimplified cause-and-effect. It blames “programmers” and “bad coding,” when the Korean case was mostly infrastructure and policy failure, not line-of-code bugs.

Zero nuance. It paints all software and all AI as hopeless, which is as unrealistic as saying every car ever built is unsafe because some crash.

No factual foundation. The sweeping “30 years and nothing improved” claim ignores decades of advances in security, verification, and reliability engineering.

Rhetorical excess. Funny metaphor aside, the post reads more like a vent than a reasoned argument.

So: a good rant, poor analysis — 2 corn cobs out of 5.