alanpost's comments

I'm fond our our privacy policy and it has served us quite well.

I've been an owner since late 2016--a mutual friend let me know Luke was interested in selling and I had been a customer for many years at that point. I liked the service and wanted it to continue. Still do.

Today's announcement is my purchasing the remainder of the company. The Acceptable Use Policy, Privacy Policy, and related documents will not be substantively changing.

The comment about diverging ideas and priorities relates to feature development and the product roadmap. Over the years we've received customer requests, suggestions, and feedback that on the one hand have a clear central tendency, but on the other requires difficult choices about where to focus and when. It's a situation better suited to the now simpler ownership structure.

I hope you will continue to recommend Prgmr where you find it appropriate to do so. Details about new features will need to wait for a formal announcement--but I'm happy to answer questions or concerns given that constraint.

Prgmr.com owner here.

While that copy is old, and our pricing reflects the hardware we run on today, the quip has now been updated to: "You get $5/month of support," which is the price of the smallest package we offer.

That wisecrack aside, the reality of the support we provide is more in-line with our byline: "We do not assume you are stupid." In practice, and with a hat tip to pera replying to you here, that means we provide what you might call peer support--we explain what's going on, what steps are necessary to correct it, and take responsibility when we caused the issue. And expect similar candor.

As you might expect, most of the technical support we provide is routine--with sufficient information communicated to both parties the problem is typically straightforward to resolve. But we treat tickets on their merit and customer reports do come in that admit more substantive investigation and resolution:

the LAN of 16 Million Hosts: https://prgmr.com/blog/2020/07/17/classful-networking.html

Possible Data Corruption on Debian Buster: https://prgmr.com/blog/2020/07/15/debian-buster.html

Debugging freebsd.org Resolution Failure: https://prgmr.com/blog/2020/04/23/debugging-freebsd-resoluti...

The people you talk to when you write us have the authority to investigate and--if correctable on our end--resolve your problem.

You might be interested in Andrew Stone's CocoaCon mailing list, whose members have regular in-person gatherings to get help, show off projects, or talk shop.

http://lists.cocoaconspiracy.com/mailman/listinfo/updates

lobste.rs sysadmin here. Would you be willing to email me a screenshot or the error message you get accessing lobste.rs and having it blocked by Blue Coat?

We do customer support over IRC, on Freenode and OFTC. Particularly with the availability of web clients on Freenode, casual IRC users can reach us with minimal hassle while long-time users idle and voice when they're highlighted or the discussion interests them.

My experience of Freenode is improved since PIA's involvement. Staff lurk in our channel on-hand to help if something comes up. Last month when services went down a developer put their head in to talk about the outage and share the patch developed from the experience.

I don't think there is another chat platform with that kind of robust community. The tooling for IRC makes the experience more like an auditorium than a parlor. I'm optimistic about this announcement--if IRC has a future I believe it will be due to the social scale at which it is capable of operating.

I visited Weirdstuff earlier this year looking for parts to mount a vertical PDU. I found spare 45U l-brackets and a u-bracket I'm pretty sure was designed for the problem I was solving--I'll miss digging through part bins and wandering down the aisles.

We use Yubikey for our production systems and yes: every operator has two keys that have been configured and registered in our access database.

We decided though not to make our backup keys hot. It's a manual operation to enable it. The risk that everyone could simultaneously lose their key was lower than the risk of a backup key being lost and then used--since a person isn't likely to routinely check on their backup keys the later problem may go undetected for some time, whereas you know the day you lose your primary key and must report that situation anyway.

Correct. It's the ability to share documents and conversation snippets provided by vendors, as well as curating and summarizing the significant amount of information available.

I've never seen an exploit that involves microcode updates, compiler fixes, kernel patches, and KVM/Xen updates all together. The number of moving parts is staggering.

Being able to filter and summarize that across company boundaries has helped me both understand and more effectively work to mitigate this problem.

Here is where I asked to join:

https://twitter.com/prgmrcom/status/949023633581592576

Following up to @scaleway on Twitter in the same manner would hopefully work out.

I've sent you an email with a bit of elaboration on this.

You can manage your VPS over SSH using our management console.[1] Since most of our users access their VPS using SSH, it's nice to use the same protocol for powering a machine off and on or accessing the serial console.

By and large our customers know what they're doing. That lets us provide IRC and email-based support that has been described more as working with a colleague than interacting with a vendor. This can be helpful when, for example, a user self-hosting email receives a complaint or has a delivery issue.

Most of the time though we just get out of the way and let you work on your VPS.

1: https://wiki.prgmr.com/mediawiki/index.php/Management_Consol...

Prgmr.com has been participating on the Slack channel this article mentions. Being able to share notes gleaned from reaching out to vendors and sort through the information and mitigations for Spectre and Meltdown has been a huge help.

I'm sorry to read this. I've watched the single board computer space slowly lose ethernet; the connector is too large. I'd love a board with two built-in ethernet connectors so I could route traffic. With Soekris exiting the market, what options are now available?

I was told it was to avoid changing my DNS when I spun up a new server. With the load balancer being $50/month; that was the pitch that put me off Rackspace.

They'll make a modest proposal that they can replace the Kansas City Federal Bank. Missouri has too many federal reserve banks anyway.

From reading the text, it seems like those folk wishing they had been alive in 1776. (The year of the Declaration of Independence of the United States from Great Britain, which the Ethereum Classic document appears to be modeled after.) This document does remind me of reading "A gentle introduction to Unqualified Reservations (part 2)" (https://unqualified-reservations.blogspot.com/2009/01/gentle...), which includes this passage by way of a set-up:

    Anyway. Our point is the conflict you call
    the American Revolution. For a quick self-
    test, ask yourself how close you are to
    agreeing with the following statement.
    (You're not expected to take this on faith
    - we will demonstrate it quite thoroughly.)

    Everything I know about the American
    Revolution is bullshit.

The thinking behind the Ethereum Classic Declaration of Independence seems to stems from a reading of Mencius Moldbug, from which you may draw your own conclusions.

My comment is based on the single report substantiating the larger story in the article. I think you ask a reasonable question. Maybe the particular contractor had an axe to grind. Maybe the bookkeeping was a mess but for reasons of incompetence rather than fraud.

I think the larger picture is troubling, but I can also see a scenario where each of the pieces that builds up to that case has a plausible and benign explanation. I don't think there are enough details in this article to conclude one way or the other.

One salient detail that's a bit difficult to pick out of the article: Hampton Creek gave cash to contractors with instructions to use that cash to purchase Just Mayo. However, they recorded (some of?) these cash payments as wages on those contractor's 1099s, meaning those contractors had to pay taxes on that "income" when in truth this was (at best) a business expense.

I'm not able to locate any information on the "rash of high-profile staff resignations." Is anyone able to fill in some context here?

AT&T. Doing it with gmail wouldn't solve the problem I have that causes me to want to send SMS messages in the first place, so that's out.

Given that this exploit happens during capability negotiation (or whatever SSH calls that part of the protocol), it also cannot be mitigated via pledge[2], which is where OpenBSD has been focusing a lot of attention. This is an unusual stumble for the OpenBSD team. Client-side privsep support, if such a thing existed, might mitigate attacks like this. As it stands protecting against exploits of this type wasn't even on the hardening roadmap.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...