Hacker News Reader

Comment by jll29 | Hacker News Reader

The sabotage scenario is perhaps less likely than the alternative scenario of industrial and political espionage.

There are also practical advantages: the ability to fix a bug in-house instead of waiting for a technology giant from another continent.

View on HN

Less likely? This is exactly what happened earlier this year.

Here's an article from the same newspaper that showed up to me as "related" when browsing TFA:

https://www.heise.de/en/news/Criminal-Court-Microsoft-s-emai...

So you point to one instance of highly targeted sabotage aka sanctions. But Snowden and others exposed many instances of espionage dragnets.

> the ability to fix a bug in-house

Yes, but bureaucracies make this impossible. If you have worked at a bank before, you'll know how difficult it is to make a change to some in-house piece of software. And that's a bank, not a gov't institution. Think how much more friction there will be in the latter.

The culture can only change when it actually becomes possible to make any changes to the systems.

If all the software one institution uses comes in the form of proprietary binaries, there is simply no need to even think about making policies about fixing those systems in-house.

These institutions don’t bother making fixes where they can, so it seems unlikely that giving them more options will change much. Ironically, things like windows auto-update being the default probably actually help their IT departments maintain some level of security

Auto update is not rocket science. Linux distributions have it too.

Yeah and it is better. Most things can be updated without a reboot and even for the kernel, you can either live-patch it (not always possible) or reboot only the kernel.

EU bureaucracy is where optimism goes to die

I wonder if it is in fact easier in a German region than a bank though. A bank has massive compliance complications, where the state insists on rules being met, so their are teams of people trying to make sure no rules being broken, and therefore anti-change. Germany is a Federal system, and the region has law making powers, a bit like a US state. Therefore it can set the rules to make sure migration to a new system happens. If big fixes are not allowed, they have themselves to blame. At a bank it is the state causing the friction.

It's funny, I was doing some budgeting stuff, and I ran into some corruption of payee-data in my bank's export files.

Good: I already wrote a script to fix the exact same issue.

Bad: It was in a pile of old stuff from 10+ years ago.

Good: It worked anyway.

Bad: The bank still has the same bug.

At a certain size (and government departments are absolutely large enough) it makes sense to manage software deployment centrally, from an internal package repository/cache.

Once that’s in place, the process for populating that repository can easily adopt locally modified versions of upstream software: defaults changed, bugs removed, features added, etc.

No one in a big business/government blinks at changing group policies for internal deployment. Changing the code is really very little different once the ability to do so is internalized.

Reply on news.ycombinator.com