HN user

agj

28 karma

Cofounder @ Read the Docs

I'm at http://ohess.org and @agjhnsn

Posts1
Comments22
View on HN

Correct, Read the Docs isn't going away, and maintainers certainly don't need to worry about moving their documentation. We'll just be switching hosts before the end of the year.

We actually got hints of the fact that Rackspace was axing their F/OSS program back in May, and have been slowly prodding folks in the Python community about sponsoring hosting since then. Rackspace never confirmed if/when the program was going away, but we were anticipating this since their acquisition.

To answer these questions, I think you need to be talking to these companies that you think would/should donate. Finding out what they want or need (from you or DBIx::Class et al in the coming year) is most important. Maybe their budgets are frozen until EOY, maybe you need more time to allow for purchasing, or maybe you aren't providing enough tangible benefits to justify bringing this to their management -- all questions you could uncover.

I would say that companies need more tangible benefits here, they can't justify a feel-good purchase price of $6-12k. I don't think you'll get into marketing budgets with an ad buy on your laptop. I know it's not part of the Perl community to create a website for your library, and it likely wouldn't have the impressions needed to attract any marketing interest either way, so maybe that's the wrong angle.

If DBIx::Class et al are integral to these companies, offering more options for support retainers at lower levels might justify the spend for more companies in the middle ground.

Anyways, I don't know the answer here, and I'm going through the same problems myself. I think you need push forward with all courses of action (save giving up early). Widen your pool of possible contributors, talk to those possible contributors you have a relationship with, and give it some time.

Sphinx, or rather Docutils, does eat Markdown now: https://github.com/rtfd/recommonmark

There is no access to Sphinx's directives/extensions, as it implements Commonmark support, which doesn't yet offer an extension syntax as part of the spec. Once it does, writing in Markdown will me more useful, but currently it's limited to basic markup and naive linking.

It's worth mentioning the besides the steps for requirements installation, this workflow isn't limited to Python. Sphinx has support for writing referential documentation with many other languages. Integrating with per-language tools to provide automatically generated reference docs is something we're starting to build out more with https://github.com/rtfd/sphinx-autoapi, though it's still in its early stages.

Similarly, if your modules are that popular and causing enough of a support burden to result in resentment, maybe this is a signal of an opportunity?

If your code is popular, why not offer support to, or seek out sponsorship from, the companies that are using your modules/applications? A revenue-focused startup is probably a bad resource to tap for this. But getting a few companies to spread out a few hundred dollars each from their engineering/marketing budgets isn't completely unlikely.

Otherwise, you can always recite the age-old mantra to cleansing open source entitlement resentment: "Patches welcome."

It's not clear if you are asking about Homebrew or Macports. If you're asking for a Linux wrapper around Macports, I think you've found it. If you're asking for a cross-platform build system, NetBSD's pkgsrc (http://pkgsrc.org) supports Linux -- though there is no pkgsrc Homebrew equivalent that I know of.

We got hacked 13 years ago

Has anyone heard anything from Moniker, or the other registrars claimed to be hacked? I wasn't able to fetch the registrar data from the zine release, and haven't found another source, though it had sounded like HTP obtained root or privileged access on Moniker.

I haven't heard anything from Moniker. My trust for them has be waning for a while, and radio silence on this doesn't help -- though I haven't attempted to reach out to their support at all either.

I would definitely agree that to progress with any endeavor -- entrepreneurial or creative -- requires critical analysis of your work and yourself. If you are not focusing on your flaws, then you are likely skipping steps necessary for improvement.

Though, I often find myself at the opposite end of this spectrum. I tend to focus foremost on the flaws in my work, and because of this, I do hate much of my own work and I have dissuaded myself from any further attempts. I would say a certain degree of persistence is equally as important as maintaining a critical point of view.

Perl one-liners are a great way to learn more about Perl -- there is a lot of uncommon syntax that makes some of the more advanced examples more like little puzzles.

However, if you are not familiar with Perl, and fall to the common stigma that Perl is unreadable, I urge you to delve more into the modern Perl community. The community doesn't have the same tendencies towards built-in obfuscation anymore.

It's probably the XML.

Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.

I agree -- although I am sure you could write a system that manages config diffs, testing, backups and reporting in Fabric, it won't be pretty.

My current workflow for managing systems does use Fabric however. I maintain configuration using a custom framework and work under git/hg -- Fabric tarballs the tip, syncs the tarball to several dozen servers, and then runs and my configuration module on each server. I did use a bash script previously though.

I prefer bash scripting for this as well. With a small ops team, pushing for adoption of Puppet or Chef, and definitely cfengine, can be difficult. However having a backbone for running the scripts and providing reporting is a great benefit.

I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though.

1: http://code.google.com/p/slack/

2: http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm

There are ways you can manage this line while working from home, but having worked on-call, in both remote and non-remote settings, separating yourself is far more difficult when working from home.

Even when working on call, or doing some work from home, you can still maintain the mindset, "This is my home. I'm at home now. Work can't touch me here." I have tried to maintain that separation while working mostly from home -- by even physically removing myself from my office outside work hours -- but, over a long period of time, I can't help but feel my personal life is my work. I can never fully separate myself from where I normally work.

However, it's not fair to say that everyone will have the same experience, there are a lot of factors: work load, expected duties, office communication, and even your office layout -- I was worn down the most when I didn't have a dedicated office. Personally, I can't wait to get back to an office setting.

This hits the nail on the head, for me. I thought staying motivated would be my primary problem before I started, but what's definitely worn me down the most is the lack that delineation -- both in my routine and in the physical separation of work and home.

I've tried to remain positive -- and have for the most part -- but after time, and especially when I have projects at work accumulating, it's extremely easy to feel trapped at work/home.

For backups, I use rdiff-backup across 60G+ of user data, nightly. rdiff-backup uses librsync to transfer files, but also handles incremental backups and seems to be fairly efficient at storing increments. Nightly, maybe 10%, maximum, of the user data changes and backups complete in less than 2 hours. Load is low enough I could run several times a day if I needed.

Databases should be properly dumped to a file before back up.

I've also tried BackupPC, which was a great project, but probably not the best fit for this case. I was running it in a virtualized container, and I ran into a lot of memory issues backing up large servers. This issue likely came down to memory -- not necessarily BackupPC itself -- but I dropped it because backups commonly took around 6-8h, if they didn't silently hang on me.

I've noticed this trend directly. Our incoming non-spam rate has stayed steady at an avg of about 10 msgs/min in the least few years, but our overall average rate has dropped from 250 msgs/min to about 60 msgs/min.

Another trend that I've noticed recently, and what seems is an example of a targeted attack, is an increase in brute force attacks on user accounts. This is likely anecdotal though, if something works once for spammers, they are pretty relentless at trying to attack it again.

I do find it interesting to watch these trends shift, and to have to respond to new methods. It's a great, big, penis-enlargement-pill-fueled, game of cat and mouse to me.

Why such interest in this script? Besides being written in php, it's also a fairly kludgey approach to managing /etc/hosts. Is it the vulgarities?

    #!/bin/sh
    [ $UID -eq 0 ] || { echo "You're not root, asshole."; exit 1; }
    [ -f "/etc/hosts.$1" ] || { echo "/etc/hosts.$1 doesn't exist, asshole."; exit 1; }
    cat /etc/hosts.{$1,tail} > /etc/hosts
...
    sudo ~/bin/stopfuckingoff play

The alternative that predates this is to this is to just tunnel ppp over ssh using pppd:

    pppd updetach noauth pty "ssh root@example.com pppd nodetach notty noauth" ipparam 192.168.1.100:192.168.1.2
I used this for many years before switching to openvpn. This does require root access on the host to execute pppd however.

It doesn't sound like the OP tried very hard to resolve this before deducing this was all a scam that had to come to light. McAfee isn't going to resolve this out of goodwill after several email complaints -- I wouldn't trust them to. The OP needs to try harder to light a fire under someone's ass. McAfee has little to nothing to gain from bending to the whim of flagged sites.

To say that the OP's experience would be different as a paying customer, either as a mere AV subscriber or as a subscriber to their hacker-safe service, is an unfounded assumption -- to say the next step is forking over protection money and that this is all a scam is pure sensationalist FUD.

I'm firmly in the skeptic camp. Without any evidence, the OP's site could be legitimately flagged. Also, I sure as hell wouldn't let this linger for 2 years. Maybe I missed something though, I gave up on the comments after a minute, my tolerance to the reddit front page hivemind is very low.

Also - thanks for introducing me to Hanlon's razor, it's now posted in my office.