From: David Masover Date: 2010-03-21T12:41:07+09:00 Subject: 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.