I've been active on Slashdot for many years. This is my second account, my new account only five years old or so. I have an affection for this site.
I've been managing servers far longer, since 1997 or so. I've owned two hosting companies and consulted for several others. I've had the opportunity to contribute code to the Apache server, the Linux kernel, and a lot of the other software we all use. I've been writing code in Perl, like Slashdot uses, the whole time. I was once the only person allowed to tou
I have this sneaking suspicion that Slashdot still runs on a ton of legacy code and systems that make migrating it far more complex than we think of for other systems. Based on my experience with the site, I don't think it's ever been owned by a particularly deep-pocketed outfit or one that has thought it's worth investing major money in for an overhaul. There was "beta", but as it turned out, fuck beta, as they said.
Still, I would kind of expect it to at least be modular enough (or made modular via virtu
"I have this sneaking suspicion that Slashdot still runs on a ton of legacy code and systems that make migrating it far more complex than we think of for other systems. Based on my experience with the site, I don't think it's ever been owned by a particularly deep-pocketed outfit or one that has thought it's worth investing major money in for an overhaul."
Slashdot manager "whipslash", Logan Abbott [twitter.com], posted this explanation as a comment on another story, 'Java [slashdot.org]
I guess I'm still missing out how something like virtualization doesn't make this a lot simpler for them, even if the whole site is running on non-virtualized hardware.
Usually we wouldn't P2V a very large bare metal system (ie, many TB of local disk), we would migrate apps and data to a newer platform running on thevirtualized platform, but I have seen a handful of those kinds of systems P2V'd first because of dubious source hardware or because the client wants to kick the rest of the upgrade down the road a while and just wants the source system in the VM environment.
Anyway, why not virtualize whatever it was they had?
Also (Score:5, Funny)
Rather unnecessary, though (Score:3)
I've been active on Slashdot for many years. This is my second account, my new account only five years old or so. I have an affection for this site.
I've been managing servers far longer, since 1997 or so.
I've owned two hosting companies and consulted for several others. I've had the opportunity to contribute code to the Apache server, the Linux kernel, and a lot of the other software we all use. I've been writing code in Perl, like Slashdot uses, the whole time. I was once the only person allowed to tou
Re: (Score:2)
I have this sneaking suspicion that Slashdot still runs on a ton of legacy code and systems that make migrating it far more complex than we think of for other systems. Based on my experience with the site, I don't think it's ever been owned by a particularly deep-pocketed outfit or one that has thought it's worth investing major money in for an overhaul. There was "beta", but as it turned out, fuck beta, as they said.
Still, I would kind of expect it to at least be modular enough (or made modular via virtu
Re: (Score:2)
"I have this sneaking suspicion that Slashdot still runs on a ton of legacy code and systems that make migrating it far more complex than we think of for other systems. Based on my experience with the site, I don't think it's ever been owned by a particularly deep-pocketed outfit or one that has thought it's worth investing major money in for an overhaul."
Slashdot manager "whipslash", Logan Abbott [twitter.com], posted this explanation as a comment on another story, 'Java [slashdot.org]
Re:Rather unnecessary, though (Score:2)
I guess I'm still missing out how something like virtualization doesn't make this a lot simpler for them, even if the whole site is running on non-virtualized hardware.
Usually we wouldn't P2V a very large bare metal system (ie, many TB of local disk), we would migrate apps and data to a newer platform running on thevirtualized platform, but I have seen a handful of those kinds of systems P2V'd first because of dubious source hardware or because the client wants to kick the rest of the upgrade down the road a while and just wants the source system in the VM environment.
Anyway, why not virtualize whatever it was they had?