Re: Why no TextMate for Linux?

On Monday 15 March 2010 03:05:14 pm Seebs wrote:
> On 2010-03-15, David Masover <[e-mail]> wrote:
> > On Saturday 13 March 2010 12:05:06 am Seebs wrote:
> >> It is not obvious that "buying" a thing necessarily in all cases entails
> >> the right to manipulate it in arbitrary ways.
> >
> > Actually, that in particular was blatantly obvious until very recently.
> 
> Not necessarily for the best.
> 
> Consider what happens when you buy, say, a cat.  Do you have the right
> to torture it to death over a long period of time?  Most people would say
> you don't.

A cat is a living creature, which complicates things.

> If you buy a house, do you have the right to, say, set fire to it? 
>  Probably not, especially if it's near other houses.

The only two wrinkles I see are whether it's near other houses, or whether 
you've got some insurance on it.

It's probably better with some sort of compromise in certain circumstances, 
but I lean much towards the end of letting the end-user do arbitrary things 
than letting the content creator add arbitrary restrictions.

> > Again, take cell phones. I could simply refuse to buy a cell
> > phone, or I could get on my soapbox and try to convince others to stop
> > buying into these contracts. If enough people actually did start
> > demanding cheaper unlocked phones and shorter (or purely monthly)
> > contracts, the end result would be better terms for me.
> 
> I'm not sure of this.  It might be that the result would be more expensive
> phones with shorter contracts, because the subsidies really do reduce the
> cost of the phone.  Many cell phones are sold for less than they cost to
> produce -- with the excess being covered out of the contracts.

Well, right, but the contracts do cost more over the long run, and they lock 
you in. No one who had the money would seriously consider a monthly plan for a 
computer. People tried attaching a computer to Internet service, as some sort 
of appliance, and that failed pretty spectacularly. For some reason, people 
seem to tend towards simply paying however many hundreds or thousands of 
dollars it is, and then owning the computer -- or iPod, or whatever.

Yet with cell phones, people tend towards the slightly higher monthly fee with 
a long-term contract. I suppose we also do that with cars and houses, but it 
still seems odd that otherwise-intelligent people, who have the money to spend 
on the phone up front, would choose this.

> >> But for some users, that upgrade treadmill may be worth it -- especially
> >>  if, say, you gain enough benefit from a particular Windows-only app
> >> that it is more efficient to upgrade frequently than to make do with
> >> something else.
> >
> > The problem is, again, how frequently, and how much do you trust
> > Microsoft?
> 
> I trust Microsoft roughly as far as I can throw them.
> 
> But here's the thing.  Right now, if an app that did something Very
>  Important To Me ran on Windows, and not on anything else, I might well run
>  it anyway. I wouldn't expect it to survive, but as long as "using it for a
>  while" isn't worse than "never using it at all", that's okay by me.

So would I.

However, I would first try every alternative that's reasonable. For example, 
if I have to use Word, fine, but I'm going to try OpenOffice first.

> > For example, if your app broke on Vista, it now becomes a somewhat more
> > expensive proposition...
> 
> Sorta.  I have XP licenses around.

Netbooks forced Microsoft to extend support.

The issue here is that an OS is something that will stop working after awhile. 
If Microsoft stops delivering security patches for XP, it's going to take 
significantly more effort on your part to keep it working. Disabling txtmt 
URLs in TextMate is one thing, running XP in a completely isolated and 
firewalled VM (or a physically-disconnected machine) is another entirely.

> And if 10% sounds high to you, lemme tell you, it is not unreasonable at
>  all.

I'm not skeptical that any text editor can be 10% more productive than any 
other. I am skeptical that TextMate is 10% better than _all_ current 
alternatives.

> > Doesn't matter. Unless you've actually disabled it (or unless it's
> > disabled by default), I can still give you a malformed txtmt URL, so you
> > still need to either pay attention to the potential vulnerabilities (and
> > actively disable functionality like that) or keep yourself patched.
> 
> Well, yeah.  But disabling functionality I don't want is one of the first
> things I do with most programs.  :)

Huh, alright.

First thing I do is use it in its default configuration -- people usually put 
some thought into those defaults. Then I tweak whatever needs to be tweaked.

It's a fair point, though.

> >> What leads me to Ruby in the first place is that it's pleasant
> >> to work with.  If I wanted something less vendor-dependant or less
> >> likely to be suddenly changed out from under me, leaving me with no
> >> practical support, there are probably half a dozen languages I'd be
> >> better off with.
> >
> > Interesting. I wonder what it is about those other languages that makes
> > them more suited to that purpose?
> 
> Well, as an obvious example, I use C because I can be pretty confident that
> any OS out there will be able to run simple C programs.

Pretty much any OS that can run C probably has a Ruby port, and failing that, 
Perl is _everywhere_.

> For instance, I use Ruby in preference to PHP, not because Ruby is less
> vendor-dependent, but because it doesn't make me want to bleach my brain
> after I have to read code in it.

Right, but I'm still not seeing where Ruby is particularly vendor-dependent. 
It runs on most Unices and Windows. I'm aware there are strange other beasts 
out there, but it's already well beyond vendor lock-in.

Contrast to requiring a single OS, or worse, requiring a single proprietary 
OS.

The difference between single-vendor lock-in and not being ported to 
everywhere C runs is significant, I think.

> >> It won't
> >> have a mysterious bug that took me a dozen reboots to track down causing
> >> it not to start up when started from /etc/rc.local even though it starts
> >> fine when invoked from the command line.
> >
> > It starts from somewhere else, not rc.local, but it starts automatically
> > when installed and on every reboot.
> 
> Once there's a package for it, yes.  I was doing this before that, and it
> was on a BSD machine, and there was some weirdness that made it not work
> when started from rc.local until I fixed it.

That's why another huge factor I use to choose software is whether a package 
exists yet. Also, there's a particularly brutal hack I've used from time to 
time involving starting a 'screen' instance...

> > I'll agree with that, but this happens a lot more often when I consider
> > whether they're equivalent for my needs. I'll freely admit Photoshop is
> > probably still far better than The Gimp, but I'm also not a graphic
> > artist, so open source plus price wins. For most things I'll have to
> > print, OpenOffice wins -- some people need certain obscure features of
> > Word, I like a big "export to PDF" button, and again, open source, open
> > format.
> 
> Yup.  One of the things I like on the Mac -- it is extremely difficult to
>  make a program for the Mac which can print, but can't export to PDF.

Same with Linux -- there's a "print to file" button in there somewhere. Worst 
case, it prints to postscript, which can be convented to PDF.

On Windows, with MS Office, it was somewhat more difficult. Maybe it's 
improved.