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 virtualization) for the migration to be done in advance and tested thoroughly before final migration. It's not like there aren't many ways to do this pretty simply that are used every day, even for clunky, old applications systems that are "hard to migrate".
"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
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.
I think a lot of money went into the beta. It was probably supposed to modernize Slashdot's innards. But the big problem there was that not only was the code base being modernized, but an entire redesign of the interface was also rolled into the project, as well as a change to Slashdot's core mission. That last change produced most of the Fuck Beta hostility.. But I suspect that when beta crashed and burned, those code rewrites went away as well since they were all rolled up together.
Don't you think it's weird that they would dive into a rewrite and not manage to separate out the UI display into its own modules? I'm not even a developer and this is almost the first thing that comes to mind -- classic display, new display, mobile option, and so on.
I suppose they just couldn't resist a bunch of new features, er, monetization options, which weren't compatible with classic interface, either.
Don't you think it's weird that they would dive into a rewrite and not manage to separate out the UI display into its own modules? I'm not even a developer and this is almost the first thing that comes to mind -- classic display, new display, mobile option, and so on.
Weird, sure, but it's possible that when they saw the Beta reaction, that they let go of the entire team.
I work for a company where something like that happened over a decade ago. The project was scrapped, and the old project code survived. I'm sure by this point all that code was gone, but it was slowly replaced rather than all-at-once replaced with a flashy new rebranded product. The problem was that the newer code, while newer, was also appreciably slower in an application where execution speed was one of
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:Rather unnecessary, though (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 virtualization) for the migration to be done in advance and tested thoroughly before final migration. It's not like there aren't many ways to do this pretty simply that are used every day, even for clunky, old applications systems that are "hard to migrate".
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: (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
Re: (Score:2)
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.
I think a lot of money went into the beta. It was probably supposed to modernize Slashdot's innards. But the big problem there was that not only was the code base being modernized, but an entire redesign of the interface was also rolled into the project, as well as a change to Slashdot's core mission. That last change produced most of the Fuck Beta hostility.. But I suspect that when beta crashed and burned, those code rewrites went away as well since they were all rolled up together.
Re: (Score:2)
Don't you think it's weird that they would dive into a rewrite and not manage to separate out the UI display into its own modules? I'm not even a developer and this is almost the first thing that comes to mind -- classic display, new display, mobile option, and so on.
I suppose they just couldn't resist a bunch of new features, er, monetization options, which weren't compatible with classic interface, either.
Re: (Score:2)
Don't you think it's weird that they would dive into a rewrite and not manage to separate out the UI display into its own modules? I'm not even a developer and this is almost the first thing that comes to mind -- classic display, new display, mobile option, and so on.
Weird, sure, but it's possible that when they saw the Beta reaction, that they let go of the entire team.
I work for a company where something like that happened over a decade ago. The project was scrapped, and the old project code survived. I'm sure by this point all that code was gone, but it was slowly replaced rather than all-at-once replaced with a flashy new rebranded product.
The problem was that the newer code, while newer, was also appreciably slower in an application where execution speed was one of