3 ms·

I don't really agree with that decision, but maybe that phrasing is not 100% accurate. Maybe they just meant that they should run the scan on a local test envir

by aflag 6y ago

I don't really agree with that decision, but maybe that phrasing is not 100% accurate. Maybe they just meant that they should run the scan on a local test environment and not in the production deployment. Obviously, there's value in running it against live, but at least for this particular issue, they could probably had caught it in a testing environment.

lmilcin 6y ago
You are probably thinking in today's terms. Back then it was unlikely there was separate test environment. For application... probably, but not for what is a static website and HTTP server.
- aflag 6y ago
  They may not have had a fully fledged staging environment which is an exact copy of production. But I'm sure they ran the http server locally in their desktop to test new configuration. I was a high school hobbyist "developer" (maybe a power user would be more appropriate) at the time and I certainly tested my pages locally before I'd upload them to Geocities. 2000 is not the bronze age :P. People were already talking about TDD then and the concept of testing things before shipping existed for much longer.
  - mprovost 6y ago
    I think you're looking back at this from the modern perspective of cheap hardware and open source software. We didn't have Sun workstations as desktops - we were using FreeBSD on cheap Dells. Our production servers cost something like $200k each. And the http server cost money - we didn't have licenses to run copies locally. These days you can just run things in Docker and have a reproducible environment but it wasn't that easy back then.
    - lmilcin 6y ago
      I have been sysadmin at that time. Usually, HTTP servers would be huge bloats of configuration running on huge machines. As a sysadmin, it was not typically feasible to replicate the configuration on the local machine. With a static website nobody would figure you can accidentally actually do something harmful to the website. The worst thing that could happen was that you made a configuration error in which case you just rolled back the config. Of course we were supposed to have backups in case the server failed. While the servers would typically use RAID arrays we knew it would not save against rm -fr so there was a backup but backups rarely could be restored instantly.
      - aflag 6y ago
        Interesting. I never thought it was so complicated to run the http server. What was the bottleneck that prevented them from running locally? The memory used by all the config?
        lmilcin 6y ago
        The amount of hardcoded stuff that was specific to the machine. All the domain addresses, firewall rules, etc. There was no git or ci/CD to keep everything in sync (easily).

by aflag 6y ago

lmilcin 6y ago

You are probably thinking in today's terms. Back then it was unlikely there was separate test environment. For application... probably, but not for what is a static website and HTTP server.

aflag 6y ago
They may not have had a fully fledged staging environment which is an exact copy of production. But I'm sure they ran the http server locally in their desktop to test new configuration. I was a high school hobbyist "developer" (maybe a power user would be more appropriate) at the time and I certainly tested my pages locally before I'd upload them to Geocities. 2000 is not the bronze age :P. People were already talking about TDD then and the concept of testing things before shipping existed for much longer.
- mprovost 6y ago
  I think you're looking back at this from the modern perspective of cheap hardware and open source software. We didn't have Sun workstations as desktops - we were using FreeBSD on cheap Dells. Our production servers cost something like $200k each. And the http server cost money - we didn't have licenses to run copies locally. These days you can just run things in Docker and have a reproducible environment but it wasn't that easy back then.
  - lmilcin 6y ago
    I have been sysadmin at that time. Usually, HTTP servers would be huge bloats of configuration running on huge machines. As a sysadmin, it was not typically feasible to replicate the configuration on the local machine. With a static website nobody would figure you can accidentally actually do something harmful to the website. The worst thing that could happen was that you made a configuration error in which case you just rolled back the config. Of course we were supposed to have backups in case the server failed. While the servers would typically use RAID arrays we knew it would not save against rm -fr so there was a backup but backups rarely could be restored instantly.
    - aflag 6y ago
      Interesting. I never thought it was so complicated to run the http server. What was the bottleneck that prevented them from running locally? The memory used by all the config?
      - lmilcin 6y ago
        The amount of hardcoded stuff that was specific to the machine. All the domain addresses, firewall rules, etc. There was no git or ci/CD to keep everything in sync (easily).