Re: Why no TextMate for Linux?

On Saturday 20 March 2010 07:41:20 am Seebs wrote:
> On 2010-03-19, David Masover <[e-mail]> wrote:
> > A cat is a living creature, which complicates things.
> 
> True.
> 
> But it's certainly a kind of thing you can own, and have, say, the legal
> right to kill whenever you want to.  (Moral rights, well, maybe not.  Or
> maybe so.  Certainly, most pet owners I know eventually hire someone to
> kill their pets, unless their pets die quickly and unexpectedly.)

Not the legal right to torture, and I'm not sure when you're allowed to kill 
them. I know it's generally a case of euthanasia, which is enough of a gray 
area already with humans.

So again, it's the fact that it's a living thing which complicates 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.
> 
> I lean towards letting them make whatever agreement they want, and if you
> don't like a particular vendor's agreement, don't buy their product.  :)

I'm fine doing that from a legal standpoint. I think regulations occasionally 
make sense, but for the most part, this is something I wish consumers would 
enforce, as we do in other areas. (For instance, there don't tend to be 
waivers or licenses required to eat in a restaurant.)

Unfortunately, again, I'm an outlier and I will continue to be, so long as so 
many people continue to, say, buy iPhones. The net result is that very often 
there's a product (or set of products) which I do want, but which have 
intolerable licenses. (Imagine if _every_ restaurant required people to sign a 
waiver not to sue for food poisoning.)

> >> 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.
> 
> I am not sure that they actually "cost more over the long run" -- as in, I
> am not sure that I would get enough better rates without that contract to
> cover the full costs of the phones.  I'm not even sure I'd get better rates
> at all without a contract.

In particular, I think the question is whether a higher-end phone might be 
cheaper to purchase unlocked (with a cheaper contract) than getting a more 
expensive contract with a "free" phone. I haven't run the numbers lately, 
though.

> > No one who had the money would seriously consider a monthly plan for a
> > computer.
> 
> I think it would depend on the terms.

Maybe, but it has been tried in the past, and it's generally failed. Your 
competition now is monthly plans in which, after a certain number of months, 
you actually own the computer -- why would I rent when I can rent-to-own?

> > 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.
> 
> Is the fee actually higher?

I suppose it depends. I do know that the more expensive the contract, the 
better phones come "free" with it. I also know that Verizon, in particular, 
charges much more for a "smartphone" plan than a straight data plan, even if 
you're paying a certain amount up front for the phone.

> >> 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_.
> 
> I have at least one machine that hasn't got Ruby because it's in a state
> where I can't build or upgrade packages...

Is this an example of a machine where you can compile C programs?

If so, I still don't see the barrier -- Ruby is a C program. You may not be 
able to install it into the system, but you can certainly compile it and run 
it locally.

> The other reason I do C is that I do stuff which isn't possible in other
> languages.
> 
> This could not be done sanely in Ruby:
> 	http://github.com/wrpseudo/pseudo

Fair enough -- though with a brief glance, I wonder how much of it could be 
done in Ruby, and might even make sense in Ruby.

> > 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.
> 
> How many Matz are there?  I only know of the one...

In the same sense as there's only one Linus, yes, but Matz isn't the only core 
contributor.

> And I'm not totally
>  sure that code for MRI will work for other Ruby implementations, because
>  there's not really a formal standard to compare with yet.

There's actually one in progress. I don't know what the status of it is at the 
moment. I know there's also a set of tests created by Rubinius.

Right now, it seems like the biggest difference between the various Ruby 
implementations are the differences between Ruby 1.8 and 1.9, and the 
differences in the C APIs -- obviously, any code I've written which depends on 
Nokogiri requires me to either rewrite my code or port Nokogiri to any other 
Ruby VMs I want to run it in.

But as an example, JRuby can run Rails.