chipx86

I worked on some large commercial software for Linux for many years that had to support a wide variety of Linux installs (old and new), I can vouch for it not being easy. The technical side of supporting Linux in this environment can be very difficult.

There are, as you note, issues with the locations or presence of certain files, directories, and scripts. That's one part of the problem, but probably the easier one to solve (we had a whole big function that would try to detect how to open a URL by checking for xdg-open and older variants, checking configuration for KDE/GNOME/etc., and then falling back on detected browsers). This also has to be done for opening arbitrary files using their assigned program.

What's more complicated are library dependencies. Depending on system installs on GTK+ isn't always enough. You may need features not available on that install, due to version issues. You may have to work around versions of system libraries that have a bug present on one particular distro due to a custom patch.

Themes and icon sets are a problem if you hit any version compatibility problems. Your UI can appear broken if you reference icons that aren't registered on that system (generally an issue on older installs). This actually gets complicated quick in some cases.

So as an ISV, you have a couple of options for how you approach all this. You can limit the distros and versions you support, putting out builds for each. This is a perfectly fine strategy if you can get away with it, but not everyone's going to be able to use your program in that case.

Another option, which is what we did, was to basically ship everything we needed along with the program. Libraries (glibc, gtk, x11, everything we were forced to ship for compatibility), icon sets, themes, etc. You then try to dynamically figure out which modules you can load from the system, and which you need to load from shipped modules. You also need to handle setting up paths for anything like icon sets and fallback themes you may need, and deal with the compatibility issues that can occur from that (older versions of the XDG icon theme spec didn't have a properly-functioning fallback system when specifying multiple icon theme directories).

If you ever need to do anything more specialized (support for hardware devices, anything using D-BUS on older installs, more specialized window management abilities), you run into a whole new set of issues.

These days I focus almost entirely on web-based software, so that sort of wide range of compatibility problems are entirely behind me. (Ahem.)

So this is not at all the cheapest option, but if you have a Synology NAS (which are just absolutely fantastic, imho), you can use Note Station. It's very much like Evernote in terms of design and capabilities (though still young), and it has a very straight-forward importer for Evernote notes. I use it as a backup for Evernote. Note Station has mobile apps and web clipper extensions for the browser as well.

Since this resides on your Synology, it's not stored in a cloud service. Depending on your viewpoint, this can be a pro or a con. It also doesn't have a native app, and I have no idea how it does with 8,000 notes.

I do know they're continuing to update it, and I truly hope they add features like Markdown support. I personally use Evernote still (and using Alternote for the actual note taking part), but could see myself switching if Evernote ends up losing my notes or something.

You gain AppleCare+ as a benefit, bringing the price a lot closer. It's also unlocked, which could be nice for some people.

Here's the big difference, though, at least with AT&T's Next: With Next, the "how often can you upgrade" and "how long do you have to pay" are highly mismatched.

The most frequent upgrade plan is once very 12 months ("AT&T Next 12"). To get this, I have to commit to paying 20 months (or ~3.33 years).

If I want to upgrade two years in a row, I've committed to paying 40 months (2 terms of the plan). That at least gets me 3 upgrades in that term. If I want to go for a 4th upgrade, we're now at an overall committed payment term of 5 years.

That's fine if you're doing this long-term, but Apple's appears much simpler: You pay for 2 years. In that time, you get 2 phones.

Verizon's program lets you upgrade "any time" you want, but only once you've paid off the cost of the new phone. Unless you pay a chunk of change early, this means one upgrade every 2 years, just like a contract, compared to Apple's once-a-year.

What I'm not sure about with Apple's is whether you can end your 2 year plan with a second phone, and then terminate and keep the phone. This is what I'd most like to know before considering this further. The Terms and Conditions page doesn't seem to be up yet..

Given that the upgrade is once every 12 months, timing also seems important. I'd imagine you'd want to activate the plan just after a new iPhone comes out, and hopefully time it so that you end the 2 years right after another new iPhone comes out, if you really want the latest-and-greatest.

Overall though, it seems to be more fair compared to AT&T's Next and Verizon's Early Upgrade programs.

Yeah, there is a lot of potential for abuse. Mostly hoping that it would spur on some additional thinking in this area.

John Oliver's segment was great. What I'm unsure of, though, is how much a cop can really do? The offenders are not necessarily going to be in the same general area. They may not be in the same country. This would need to be handled internationally, in some way, wouldn't it?

Kudos to her for standing up to it, but she should clearly never have to. This kind of thing just shouldn't be happening...

I don't think I know anybody who does this to women. I really hope that's because I don't actually know anyone who does, and not that people I otherwise respect are secretly doing this. How would a person know, if it's anonymous?

Well, maybe a few ways. The question is, are these all actually anonymous? Jessie's post lists messages on IRC and e-mails. I'd bet some people get harassed on Twitter, Reddit, or other widely-used platforms. Some of these people must be identifiable, surely? At the very least, some might be using the same username/e-mail address across many services, and might end up using one in relation to a job application.

The last thing I'd want is a witch hunt, where innocent people end up on the wrong end of an Internet lynch mob. What I'm about to wonder out-loud might be a bad or ill-conceived idea, but here goes:

Would it be reasonable/helpful/worthwhile to have some centralized place where these kinds of harassments can be forwarded and grouped? E-mails with headers, tweets with screenshots of the full context, IRC messages with Nickserv registration info, etc., so that repeat offenders would have a form of evidence (and I stress evidence) stacked against them? Some form of "witness" system, where other recipients (Twitter users, IRC users, etc.) can sign off that they saw this take place?

Basically, create a sort of tech industry predator list. Not everyone on there would be readily identifiable, but maybe some would be. I certainly would check it before hiring anyone, look up GitHub usernames and such, and it might help give people who don't experience this a better sense of just how terrible and prevalent this all is.

So, good idea, at least in part? Terrible idea with too much potential for further abuse? Somewhere in-between?

Very cool. I always wondered if someone would do that (considered it myself, once). I'll keep my eye on this. Thanks!

I used to do a lot of REBOL programming, back in the day. I even wrote some tutorials for an old webdev site called Gelicon.

Back then, there was no Django or Ruby on Rails, and while PHP worked, it wasn't always suitable for a lot of tasks. With REBOL, for instance, I could (and did) build a client that would read from some early web services, parse the data, and then interface with IRC servers to both stream some of the data to a channel and act as a control interface for further parsing, along with generating static webpages from the data. Implementing each part of that was a lot easier than most languages I've used (assuming you're not using third-party modules for things like IRC).

What made REBOL cool, back when it was new, was just how easy it was to work with the Internet and parse results. For instance, see the one-liner in example 42 on that link, which scrapes a page for all links:

    parse read http://www.rebol.com [any [thru "A HREF=" copy link to ">" (print link)] to end]

That reads from www.rebol.com and sets up a parser for it with the given rules. Those rules state that it should skip all bytes through "A HREF=", then copy any bytes up until the ">" into a "link" variable, and then print the variable. Simple example, but it's fairly easy to write something a lot more complex.

The language can be a bit wonky at first, but especially back then, once you learned it, it was fantastic and fun. Writing a parser for a protocol like IRC was just easy. You could easily output a file that was both data and a valid self-parsing REBOL program. Writing a self-modifying program to store the state for the next run was almost trivial. You could write little DSLs for whatever you wanted. Like LISP, the code was data.

Oh, and the selection of data types was pretty neat. For example, e-mail addresses were a valid datatype (http://www.rebol.com/docs/core23/rebolcore-16.html#section-2...). So was currency (http://www.rebol.com/docs/core23/rebolcore-16.html#section-3...), HTML tags (http://www.rebol.com/docs/core23/rebolcore-16.html#section-2...), URLs (http://www.rebol.com/docs/core23/rebolcore-16.html#section-2...), etc.

I think REBOL had the potential at the time to go far, but it really suffered from the restrictions the company placed on it as an attempt to monetize the language. The core of REBOL was free, and you could do a lot with that, but you could not invoke external programs or bind to any native libraries. To gain that functionality, you had to pay a decent amount (at least for me, at the time) for a full license. There may have also been restrictions on bundling the core REBOL interpreter.

I believe that's all free now, but then, the world's grown beyond Perl and PHP since then. REBOL had a lot of time to grow beyond where it seems to be now. I still think about coding something up in REBOL every so often, but I usually just reach for Python instead.

Still, fun language. Worth playing with sometime.

We're always looking for someone to help improve our documentation over at Review Board (https://www.reviewboard.org/).

As our support for third-party extensions grows, we're especially interested in writing a series of guides to help extension authors, as well as those using our API to do interesting things.

Workstation and Fusion are, under the UI, practically the same application. If it works in Fusion, it should work fine in Workstation.

One of our contributors has recently done exactly this, triggered by a `git push`:

Announcement: https://groups.google.com/d/msg/reviewboard/SVOF-4KZ-VU/lSf0...

Video: http://vimeo.com/86448355

Also, for the record, after we wrap up this 2.0 release, we'll be focusing on allowing users to review branches of commits in a review request, and not just individual squashed patches.

I build Review Board (http://www.reviewboard.org), a code review tool, and its SaaS counterpart, RBCommons (https://rbcommons.com/). We use our public Review Board server for every change going into Review Board itself, and RBCommons for every change going into RBCommons.

While "eating your own dogfood" doesn't work in every industry or product (as some of the top comments are discussing), I'm a firm believer that if you're developing something intended for a typical person (developer, casual user, what have you) to use every day, you really should be using it every day as well. I've used too many products that were "mature" yet felt so poorly designed and developed that you'd have to wonder if anyone at the company ever touched them beyond basic testing.

Exactly.

Forcing a checklist upon all reviewers isn't what the article is all about, but rather it's about one developer's way of organizing his own personal process for doing code review so he doesn't forget something.

If I have a huge change in front of me, and I know that I tend to look for certain things, I could certainly try to look for all those in one go. That's error-prone, though. Might forget something, or get bogged down in syntactical stuff and miss something important. However, with a little personal checklist in front of me, I can go "Okay, I'm done looking at syntax. Now let's make sure that there's no off-by-ones." Leads to better organization of thoughts.

I've always seen it as a bit of both.

My startup grew out of an open source project designed to scratch my own itch, which was a great way to start. Being my own user, I saw the pain points and could form a true direction. However, that only goes so far, since not everyone is me. At some point you have to start looking at what your users care about, at least as much as what you care about, if you want the growth.

That's where the mix comes in. You shouldn't just develop it solely for someone else, or you may lose that drive, passion and direction (plus what they want and what they say they want aren't always the same thing). At the same time, you must listen to them (if you want to solve their problems) and take their opinions into consideration. Do it right and you end up building for both yourself and your customers.

I imagine that's just the market. Nearly everyone charges around $30, and it's not completely unreasonable. I've seen some variation in those costs, though, and there's a lot of variation in costs of add-on features.

We ended up going with desk.com. What we found nice there is that you get one free agent every month, plus a concept of a "flex agent." Flex agents cost $1/hour, and desk.com gives you quite a lot of free flex time when signing up and doing a few tasks (plus the occasional grant of flex time as you use the product). There's only two of us, and we haven't had to pay a dime yet, going on I think 6 months.

On the other hand, they charge $50/month for a full-time agent (unlimited usage, basically), so it really depends on how many people are going to use the site and how often.