Re: Why no TextMate for Linux?

On Saturday 20 March 2010 06:25:08 pm Seebs wrote:
> >> 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.
> >>  :)
> >
> > 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 this is a problem, though.  My desire for something is
>  influenced by its licensing.  I don't view it as "a product I want, with
>  an intolerable license", but as "a product that is similar to one I'd
>  want'.

It's a fair point, but no less frustrating. In the case of a restaurant, you 
can just (almost literally) _taste_ the product you might actually want, but 
no one is providing it. You might see an opportunity and try to open your own, 
but then you either need to be successful for other reasons, or convince 
everyone else to share your own views about contracts.

So again, it comes back to: I can see where it might make sense to legally 
allow such waivers, but I still find them morally distasteful, and I would 
argue against them.

> > 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?
> 
> Some large businesses lease computers because they don't WANT to own
> computers.  Personal users, of course, tend to want to buy things.
> 
> I rent a computer right now, in fact.  I think it's somewhere in Texas.
> It comes with a bunch of bandwidth.  It was less hassle for me to rent
> bandwidth+computer than it would be for me to own the computer, and I don't
> WANT to "own" that -- I want it to be someone else's job to provide the
> functionality to me.

Makes sense, and so do I -- or a portion of one. Then again, if I could have 
the option to stop paying for that computer after awhile (and just pay for 
bandwidth), I'd probably take it.

> > 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.
> 
> Could well be.  That might be, in no small part, because smartphones tend
>  to use a LOT of bandwidth.

In this case, that's an assumption based on the device, and it's the reason we 
have all this stupidity about tethering. If the bandwidth is an issue, charge 
per bit or raise the monthly fee. (There's also the issue that not all 
smartphone users want or need Internet on their phone.)

Instead, we get potentially a lower monthly fee, plus some arbitrary and 
asinine restrictions on how we use it, in the _hope_ that we use less 
bandwidth. Why not simply have a lower-bandwidth plan?

> > 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.
> 
> It's a lot of work, though, and I'm not sure I can compile all the things
> it would require, or at least benefit from having.

I've done this sort of thing before. It's not as hard as it's made out to be, 
and even a Ruby without everything it'd "benefit from having" would likely be 
better than raw C.

Think about it -- Ruby without readline support (so IRB sucks), or raw C? For 
the cases where I'd be considering Ruby at all, the lack of readline wouldn't 
stop me.

After all, if it's a library I actually want/need (say, OpenSSL), I'm going to 
need to install the same headers and such to use it from a C program anyway.

> > 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.
> 
> My guess would be virtually none.  Certainly, virtually none could be done
> with acceptable efficiency.

Configuration, at the very least. Also, I'm not sure I see efficiency as a 
burden here, for the most part -- it looks like the intended use here is 
compiling, which is already slow anyway, and is a domain where tools like make 
(or even rake) are used also. The part which actually builds an image/package 
is going to be IO-bound anyway.

I can't say Ruby is a good idea there, because I just don't know enough.