Search results

tl;dr for those of us that don't go to LET? :3 

In the interest of fair disclosure... the delay wasn't that bad actually.  And honestly, rather understandable... even if you ignore the whole CVPS==CC thing, you can rationalize is at them trying to save one of their bigger customers that simply did not have the technical expertise to do it on...

Don't make claims when you have no clue what you're talking about.  We own our IP space, and as we have no need for .0 IPs, we allocate all of our IP space in /24 blocks.   I'd rather us have clean IP space than start hosting Runescape again.

You have.  It's been posted several times by different people (all using the same forum template, no doubt).. and I've been mail spammed with it enough that pretty much anyone that makes the request now is automatically denied service with us.

True enough.  What really should concern people is the database leak, though.  @ could confirm this... but wasn't the DB leak dated at least a day or more before the actual attack?  The guy could've grabbed any number of VPS dumps in the meantime before tearing everything up.

Umm...what?  The Solus master has direct access to every node - so yes, if the hacker knew of someone already at CVPS they wanted data of, it would be as simple as sending a command like tar zxvf /var/www/data.tgz /vz/private/<vservers.ctid>/ to the node, then grabbing the tarball of that VPS's...

  I think one would just have to look at some of the 12-year-old commentary in this thread, as well as his current signature, to get an answer to that.

Food for thought:  SolusVM has a backup system included.  However, information is stored much the same way as node information is - and if the attacker could wipe the nodes, there was nothing stopping him from wiping even remote backups as well if they were tied into Solus. Sure, there's always...

If the service were truly horrible, we wouldn't still be in the NY location.  Network has been stable, and aside from not having native v6 the only issue we've had there wasn't their fault (one of our MBs decided to die off).  That being said, we are rather unhappy about being lied to on several...

Wouldn't be all that much of a win for us, since duplication diminishes value.  But aye, the trust issue is my primary concern.   Seriously, just stop.

That pretty much sums up this entire thread quite nicely. EDIT: And you couldn't ask for a better topper than that one.  Any chance you had of being taken seriously is now gone.

I could go either way on this one.  I've heard a decent amount now about this Incero now (had little knowledge of them prior).. but I can also see how they would look at the tickets they were getting and decide "Yeah... this needs to be nipped in the bud sooner rather than later".

Two years ago, I wrote a SolusVM module for WHMCS (back before they started IONcubing their own module, and you could see just how horrible all the code was) that did exactly this:  made the panel unnecessary.  Shortly after, we decided to leave Solus completely, and started on Stallion1.  I...

To be 100% honest... if that ticket were with us, it would've never made it past the price bickering. As far as losing customer data... the last date on that ticket on setup looked to be the 17th.  You only had a server up for 3 days in a new deployment, and didn't do extensive testing to make...

Stallion is coming *unzip*

This reads a bit like "if you don't have your own backups on these nodes, you're probably SOL".

Features and ease of use. With Stallion1, we tried to mimic as much of Solus as we could (and added in a few things we always felt were silly to not have, or were broken). Stallion2 is receiving a feature set you simply don't find on distributed panels. We'll also be integrating support and...

Well, we're in the business of selling VPSes, not selling panels. Giving it out would pretty much defeat the purpose of why we built it in the first place :(

I just finished writing the WHMCS module about 20 minutes ago actually.. writing the last function of the Stallion-side API now, then I'll likely get tw and bfj involved in some testing if they have the time. Fran still has the KVM provisioning to wrap up, and this weekend I'll be writing the...