Why no TextMate for Linux?

[Seebs]

So long as the current version continues to work.

Well, yeah. You know, some of the computers I've bought in the past
don't work anymore, either. Doesn't mean I was ripped off.

Most likely -- but having the ability is important.

I'm unlikely to ever want to, say, burn an American flag, but it is important
to me that I have that right.

Non-comparable. No fundamental civil rights are infringed when I'm told
I can't burn *someone else's* American flag. My right to write software
is not infringed by my lack of a right to modify someone else's without
permission.

And I've seen things break from 10.3 to 10.4 to 10.5.

So? I've got code which has been broken by just about every Linux system
revision since RHEL4 or so. However, the bulk of my stuff keeps working,
and the same is true of OS X; the bulk of the code out there continues to
run.

It's been long enough since I've used OS X that it's possible I'm remembering
low-level hacks. Then again, I remember even things like VLC would require at
least 10.3, and this is when 10.4 was the latest. So...

That's backwards. Obviously, when developing, you tend to target a relatively
recent system. That doesn't mean that a version of VLC which had been built
for 10.2 wouldn't still work on 10.4. Your claim was that it was "as likely
as not" that any given upgrade would break TextMate. But all you've shown so
far is that at least one group of people who were actively updating software
for new systems released something that ran on a previous system and the
current system, but not on systems before that -- but that could be just
because they linked against that system's libraries.

Two or three is nice, still means you're going to have to upgrade when it's
four, five, or six revisions out of date -- either the program or the OS.

Yep. But five or six revisions is getting on towards a decade, and I buy
a lot of programs that don't run for nearly that long.

With proprietary software, that's not an option -- Microsoft wanted to force
Vista on everyone, so they threatened to pull support for XP. That would've
meant security vulnerabilities, among other things, making life difficult for
those of us wanting to stay on XP -- no chance of any bugfixes. Microsoft
maintains support for old version of Windows, but to a point -- beyond which,
the community CANNOT take over.

Right.

Which might be a good argument against considering XP to be the basis of your
business or livelihood, unless you have some particular reason for which it's
really the best choice for you anyway.

Now consider the case of a killer app developed by a single individual. What
are the chances he's going to expend significant time and energy maintaining
old versions of TextMate when he could be working on a new version (and
charging for it) instead?

Not particularly high -- but an editor isn't comparable to an OS (unless
it's emacs). I don't have to worry about new malware targeting my editor,
I do have to worry about new malware targeting my OS.

Can you see why I might be more inclined to trust a popular open-source
project developed by dozens (hundreds?) of people around the world, rather
than a proprietary project developed by a single person?

Yes.

But I can't see why you'd argue not just that this is a benefit, but that
it's such a huge benefit that anyone who would prefer ANY other combination
of features, values, or requirements over it is somehow objectively wrong.

Whew. That was hard to find the one tool which isn't portable, and I'm not
even sure about that -- it might run under Cygwin!

Oh, sure, tons of stuff is portable. On the other hand, having suffered
through Gaim^WPidgin for years, I *love* using Adium X. Yes, it means that
my preferred chat program is OS X only. But that's a TINY price to pay
for having a user interface that doesn't make me want to stab the developers
with every kitchen implement I can find.

My photo editor of choice is OS-specific. So are a few of the graphics tools
I use, and my preferred word processor and paint program. On the other hand,
they work a lot better for me than the alternatives, so I use them.

Really? Android doesn't? That's interesting.

One of the things I want is a pleasant development environment. The NextStep
design was brilliant, and I still find it pleasant to work with. I've worked
with a dozen or so UI toolkits, and this is the only one I haven't actively
hated since Intuition.

I tend to agree, yet I notice, again, a trend where people like that
everything Ruby is open source, yet don't care to look for the same in their
OS or editor.

Different kinds of tools have different requirements. Open source is *a*
benefit. It is not *the* benefit. There are many cases where other things
matter more.

For editing, what I require most of all is that my editor be convenient,
flexible, and stay out of my way. If Textmate does a better job for me
than the open source alternatives, then of course I should use it. That
I might not be able to later doesn't mean I shouldn't use the best tool
I can find now.

I'll do that, if it's enough sooner and enough less effort to justify the loss
of flexibility. I'd much rather spend a bit more time and get it right the
first time, using portable, flexible, open tools, so that I don't have to
completely redo it if something needs to be changed.

I don't view choice of editor as really being a matter of "completely redo".
It's one of many tools I use, and if I switch, well, I use a different editor.
Whatever.

An editor that works enough better for me than an alternative will save me
an hour a day. Learning a new editor will take, say, a forty-hour week.
If I use an editor for over forty days, I'm probably ahead on the deal -- if
it really is that much nicer.

sudo apt-get install samba

Yeah, I did actually set up samba. Three times. It was a nightmare to
get it working reliably with several different windows systems, the
documentation was crap, and it crashed fairly often. Building it is not
the hard part; *configuring* it is. Wouldn't It Be Nice if someone
shipped something that handled the basic cases ("I want to export this
filesystem to authenticated users in this local workgroup") automatically?

It may well have improved since I set it up; that was a few years back.
I did not find it a particularly enlightening experience.

A fileserver is about the easiest thing to set up. I have to ask how much
you're being paid where half an hour or so of your time is more valuable than
the hardware markup for an OS X server.

It's not "half an hour". It's "two hours the first time, one hour every
time I have to redo things for some reason, and half an hour a week because
of stuff going unexpectedly wrong". Whereas, with OS X, I clicked a button,
and it worked fine, and has continued to work fine (except, of course, that
the *client* machines were still unreliable).

I don't enjoy system administration. The less time I have to spend on it,
the happier I am.

With the OS X machine, it took me half an hour to get reliable file sharing
over three different (and unrelated) protocols, only one of which I could
easily have configured myself, as well as having user authentication working
for several different kinds of clients. Yes, I know how to set up
authentication services. It's a pain, it takes time, and I don't enjoy it
or find it rewarding. My interest level in learning enough about it to
correctly set up a Windows workgroup in order to authenticate users in order
to provide shared access to files which preserves user permissions between
Mac, Windows, and BSD clients? Pretty much zero. My interest level in
having it all work with a handful of clicks on clearly labeled UI items?
Pretty high.

I used to do a bunch of this stuff myself. I'd guess it cost me 20-30
hours a year. Compare to $500... That's around $25/hour, give or take.
Now imagine that the server lasts for two years. It's now only a good
deal if I make $12.50 an hour.

Since $DAYJOB is salaried, I don't have a semantically-coherent hourly wage
anymore, but this stuff all happens in my spare time, and none of the
money-related things I do in my spare time are under $75/hour. A year's
hassle dealing with the home network costs me a lot more than a mini with
OS X server would.

-s

 

[David Masover]

Non-comparable. No fundamental civil rights are infringed when I'm told
I can't burn *someone else's* American flag. My right to write software
is not infringed by my lack of a right to modify someone else's without
permission.

I suppose that's the difference between buying and renting software.

Put another way, I'm not saying I should be able to burn someone else's flag.
But if you sold me a flag, why should that automatically allow you to dictate
how I use it? Should I have to sign a no-burning contract before any flag I
buy?

No, after I buy it, it's mine, even if you're the one who made it.

Regardless, the point was not that this is an essential right, and that's
clearly hyperbole (on my part). The point is that it's important to me to have
that ability, whether or not I have a clear and present need for it.

So? I've got code which has been broken by just about every Linux system
revision since RHEL4 or so.

I haven't seen much of that, not that it matters -- the point is that
generally, open code that has a userbase of programmers will be maintained
across those versions, and even the old, unpopular versions are often forked
and maintained. Neither of these is guaranteed for proprietary software.

But all you've shown so far is that at least one group of people who were
actively updating software for new systems released something that ran on
a previous system and the current system, but not on systems before that
-- but that could be just because they linked against that system's
libraries.

Could be -- though I was under the impression that most libraries are included
with the program, and that this was an advantage of the .app folder concept.

VLC isn't the only example, but the obvious ones that come to mind are things
like a virtual desktop manager (pre-Spaces), which likely fits your criteria
of being a low-level hack, something you'd expect to break. I remember seeing
similar things with TunnelBlick, though again, it's been long enough that this
may be my imagination.

I withdraw that claim.

Right.

Which might be a good argument against considering XP to be the basis of
your business or livelihood, unless you have some particular reason for
which it's really the best choice for you anyway.

Maybe.

It's also an argument against considering Windows to be the basis of your
business or livelihood, unless you're willing to accept that upgrade
treadmill. Again, before Win7, the choice was likely between XP and Vista, and
many savvier consumers disliked Vista with a passion.

So your choice was to stick with XP, which was relatively light, fast, and
proven, but risk Microsoft letting it slowly rot... or upgrade to Vista, which
was buggy, slow, new, and prone to breaking XP apps in interesting ways.

And the only way out? Win7. But that was, again, depending wholly on Microsoft
to solve the issue.

Not particularly high -- but an editor isn't comparable to an OS (unless
it's emacs). I don't have to worry about new malware targeting my editor,

With textmate having its own URL schema, yes, you do. And that's ignoring
other stuff that you'd hope is easy to get right, like proper handling of the
text itself.

But I can't see why you'd argue not just that this is a benefit, but that
it's such a huge benefit that anyone who would prefer ANY other combination
of features, values, or requirements over it is somehow objectively wrong.

I'm not arguing that.

I'm arguing that it is a huge benefit, and I'm puzzled that people place so
little value on it, especially when I presume it's exactly this kind of
benefit that would lead someone to Ruby in the first place.

However, I did a fair amount of development for HD-DVD, and I always keep a
copy of Windows around, so I do understand. Then again, my reasons for using
Visual Studio as an IDE for HD-DVD don't apply to TextMate.

Oh, sure, tons of stuff is portable. On the other hand, having suffered
through Gaim^WPidgin for years, I *love* using Adium X.

Adium was good. I like Kopete, these days.

I don't view choice of editor as really being a matter of "completely
redo". It's one of many tools I use, and if I switch, well, I use a
different editor. Whatever.

Right, that's the major difference between an editor and the kind of tool that
justifies this long of a discussion. For example, your iPhone projects sound
like they're of the type where it would be a significant effort, possibly even
a full rewrite, to port them to another platform.

I think I wandered offtopic there.

Yeah, I did actually set up samba. Three times. It was a nightmare to
get it working reliably with several different windows systems, the
documentation was crap, and it crashed fairly often.

Can't speak much for the documentation, but I have created Samba setups
(fairly simply) which worked, out of the box, on every Windows I came across.
I have never once seen Samba crash.

I enjoy sysadmin work, but I've also gotten a static webserver working in
under five minutes, and a local torrent tracker (complete with relevant
torrents) in under half an hour (due to crap documentation).

 

[Seebs]

I suppose that's the difference between buying and renting software.

Sort of.

It is not obvious that "buying" a thing necessarily in all cases entails
the right to manipulate it in arbitrary ways.

Put another way, I'm not saying I should be able to burn someone else's flag.
But if you sold me a flag, why should that automatically allow you to dictate
how I use it? Should I have to sign a no-burning contract before any flag I
buy?

Should you have to before buying any flag? No. Should it be possible for
someone to sell you a flag only if you agree to sign a no-burning contract?
Sure. Should that contract be enforceable? I'd say in general it should.

If you don't like it, don't buy from that vendor.

Regardless, the point was not that this is an essential right, and that's
clearly hyperbole (on my part). The point is that it's important to me to have
that ability, whether or not I have a clear and present need for it.

I think it's certainly *potentially* useful, but I've found that in many
cases, it's not so useful as to make me abandon something else I care about.

I haven't seen much of that, not that it matters -- the point is that
generally, open code that has a userbase of programmers will be maintained
across those versions, and even the old, unpopular versions are often forked
and maintained. Neither of these is guaranteed for proprietary software.

Neither of them is guaranteed for anything. I'd say, though, that I've
seen a lot better support for five-year-old proprietary software than I
usually have for two-year old open source -- because open source users
tend to be a lot more willing to upgrade, since it's close to free to do
so.

People whose livelihood depends on the quality of their support have
an incentive to meet user demands.

Could be -- though I was under the impression that most libraries are included
with the program, and that this was an advantage of the .app folder concept.

Only libraries which aren't standard system frmaeworks.

VLC isn't the only example, but the obvious ones that come to mind are things
like a virtual desktop manager (pre-Spaces), which likely fits your criteria
of being a low-level hack, something you'd expect to break.

Yes. I had one, it broke, I was not surprised. But it was definitely worth
it, to me, to have a working virtual desktop manager for the year or so I had
it, even though it's obviously worthless now. A good use of money.

It's also an argument against considering Windows to be the basis of your
business or livelihood, unless you're willing to accept that upgrade
treadmill. Again, before Win7, the choice was likely between XP and Vista, and
many savvier consumers disliked Vista with a passion.

Yes.

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.

And the only way out? Win7. But that was, again, depending wholly on Microsoft
to solve the issue.

Sure.

But so what? People in general know that going in, and sometimes they make
the decision that it's the right tradeoff. I'm not trying to argue that
there's no downside to a proprietary solution -- only that it's not at all
obvious that it'll always, or even usually, be foolish to pick one.

With textmate having its own URL schema, yes, you do. And that's ignoring
other stuff that you'd hope is easy to get right, like proper handling of the
text itself.

I don't use that feature. So all I care about is plain text.

I'm not arguing that.

It comes across as if you are.

I'm arguing that it is a huge benefit, and I'm puzzled that people place so
little value on it, especially when I presume it's exactly this kind of
benefit that would lead someone to Ruby in the first place.

Not really. 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.

Keep in mind, an option you can't actually use is not a real option. I'm
comfortable enough with C to have diagnosed an arcane memory management bug
in the pgsql driver. Not many other people I know would have had a good
chance of finding that bug -- meaning that in practice, access to the
source would not really be useful to them.

For many, many, people, the direct advantages of open source are a pure
non-issue. I'd bet that most Ruby developers would not be usefully able
to modify the Ruby source to fix a language-implementation bug. So why
should they care whether they have source or not?

Adium was good. I like Kopete, these days.

I try KDE occasionally. Around 4.x, they had a wonderful feature, which
was that they never in any way saved user keybindings, such that every
login got you all the defaults again. I guess maybe I'll try again sometime,
but that's a level of quality control I would normally associate with
Microsoft...

Right, that's the major difference between an editor and the kind of tool that
justifies this long of a discussion. For example, your iPhone projects sound
like they're of the type where it would be a significant effort, possibly even
a full rewrite, to port them to another platform.
Yup.

Can't speak much for the documentation, but I have created Samba setups
(fairly simply) which worked, out of the box, on every Windows I came across.
I have never once seen Samba crash.

YMMV. In my case, the net result was that switching the home server to OS X
trimmed many hours of tedious work off my list. I'm probably gonna get
a new OS X server machine in the next couple of weeks, which will replace
two or three existing machines.

I enjoy sysadmin work, but I've also gotten a static webserver working in
under five minutes, and a local torrent tracker (complete with relevant
torrents) in under half an hour (due to crap documentation).

In general, I can do sysadmin, it's just not fun or exciting to me. I'd
rather not have to. I enjoy coding, I don't enjoy wrestling with startup
scripts. I got a jabber server up and running... It was a pain. The
next time I do server stuff, I'll put in OS X server, click "enable chat
server", and have a working jabber server. It won't crash. 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. I won't have to replace it with
a different one due to a crashing bug that no one cares about, or build
a programming language environment before I can use it. And that's worth
a fair bit of money to me.

This comes back to why I like Ruby: Use the right tool for the job.
Open source is usually a bonus for most tools, but it is often much less
important than other features. I only occasionally see a pure choice
between genuinely equivalent things, one of which is open source.
Usually, there's many other factors which are more significant.

-s

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

I don't understand the debate, it's just a text editor. It doesn't encode my
data in some format I can't get it back out of, it is just an environment I
work in, and I assume most of us customize our environments.

TM is simply the editor that has made me the happiest, I know how to
customize it in lots of different ways, even editing the language
definitions, macros, automating commands, impressive power editing, etc (big
thanks to James Edward Gray 2 for his TextMate book).

I would almost certainly be less happy working in a different editor, so I
don't see any reason to do so. And yes, it has dramatically increased my
productivity, and the ease with which I can do lots of different things.
Even simple things, like try out some quick Ruby script. It is so quick and
trivially easy that I find myself doing it constantly, as Linus Torvalds
said in his git talk, "That's the kind of performance that actually changes
how you work. It's no longer doing the same thing faster, it's allowing you
to work in a completely different manner." (

) That is the kind of change that
TextMate has made for me.

For example, the "execute and update" option has utterly replaced irb for
me. I would be exceedingly unhappy if I had to go back.

And it's not just with Ruby, take C, for example, a few keystrokes to jump
from any application into a new TextMate window that knows it contains C
code. A macro to generate the basic code C requires and kick my cursor to
where it should be, write the bit of code I was thinking about, a keystroke
to compile, run, and display the results.

I can get to the point of writing the code as fast as I can think about
wanting to do it.

Anyway, while having all the source of a language or an application like
FireFox or something might mean that I can go in and change it, but as Seebs
said, that is not really a tangible ability for me. I quite simply don't
have the experience or knowledge to make such changes. While I can't go to
that level in TextMate, I can change almost everything that I would ever
want to, and the ability to do so is extremely accessible, so I've done a
lot more custom coding to TextMate than any other application. (though I do
hack different on smaller less mature libraries when necessary).

So aside from feeling a little weird about a new environment, if I have to
jump to Linux or Windows, I really see no downsides of TextMate. Of course,
I'd experience that, regardless.

As far as the link thing goes, if there is a standard, then I'd chastize
TextMate for not following it. If there isn't a standard, then I don't see
how this is a mark against them. If an open source project added this
functionality, we would be using it as an example of open source pushing
progress.

Also, Alan isn't the only dev on TextMate anymore, there is at least one
other guy. Whether he'd be able to take over if something happened to Alan,
I don't know, but it's a viable enough product that it is unlikely it would
just go away.

And also, TextMate takes a lot of influence from open source styled
projects, with a sort of community based repository of themes and bundles
and plugins (you can make dramatic changes to TM itself with plugins).

So, yeah, I generally think that open source is preferable to proprietary,
but that's a general trend, not a law of the universe, and I really can't
see any of the arguments being viable against something as orthogonal to the
code as a text editor. And there may be (and probably are) other very viable
options out there, but TextMate fits my needs and preferences extremely
well, and I am quite satisfied with it.

 

[Michal Suchanek]

Neither of them is guaranteed for anything. =C2=A0I'd say, though, that I= 've
seen a lot better support for five-year-old proprietary software than I
usually have for two-year old open source -- because open source users
tend to be a lot more willing to upgrade, since it's close to free to do
so.

People whose livelihood depends on the quality of their support have
an incentive to meet user demands.

If you are willing to pay the money you did for the proprietary
support I am sure you would get support for any opensource application
of you choice as well.

Yes.

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 el= se.

Sure.

But so what? =C2=A0People in general know that going in, and sometimes th= ey make
the decision that it's the right tradeoff. =C2=A0I'm not trying to argue = that
there's no downside to a proprietary solution -- only that it's not at al= l
obvious that it'll always, or even usually, be foolish to pick one.

The problem is that people often do not do this decision. They just
have something on their computer like the MS Access/Office environment
so they write their application in it not realizing that in 1-2 years
there will be a new MS Office version and their application will no
longer work. So bringing this up is important but it is quite a bit
offtopic here.

 

[Diego Virasoro]

Yes, it may cost some retraining time to move to another text

So, that's a nuisance and a cost, and depending on how much you find yourself
relying on a given tool, it may start to be significant.

Here I disagree. When I moved from another text editor to emacs, it
was a pain to learn it. That didn't stop me from moving to Texmate
now, and maybe to move to something else in the future. That's how
life goes.

It sounds like you are saying that I should pay a cost in my
productivity _right_now_ for the _possibility_ that Textmate's future
won't meet my needs and I will need to move again, paying some cost to
learn the new tool. And what if instead the future Textmate will still
be great? I will have lost productivity now and in the future, just
because I am being paranoic.

The only thing that is really important is that my data is portable,
which is why I care that Ruby is open: otherwise my code would be
useless.

But there isn't really a lot of choice in cars. If I want a decent car at an
affordable price, I pretty much want something manufactured, probably
something used. It's entirely impractical to build it myself.

Are you saying that it takes no time to
a) read and understand the code that makes an open source texteditor
b) make the necessary changes to the code, and test it
c) and maintain the fork in case the developers don't agree with your
change?
Personally the cost of learning a new text editor pales in comparison!

Diego

 

[Diego Virasoro]

Non-comparable. No fundamental civil rights are infringed when I'm told

I suppose that's the difference between buying and renting software.

eh??? How's Textmate a rented software? I can use it forever: nobody
is stopping me. And I am not paying per month. What's your definition
of renting?

What I cannot do is make changes, add new features that are "cool" as
the technolgy progresses. But then neither have I been able to add HD
to my TV: but that doesn't make it rented.

Diego

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

What I cannot do is make changes, add new features that are "cool" as
the technolgy progresses.

With all the things you can change and program, there is a pretty decent
likelihood that you will be able to.

 

[Michal Suchanek]

eh??? How's Textmate a rented software? I can use it forever: nobody
is stopping me. And I am not paying per month. What's your definition
of renting?

Yes, it is rented, pretty much all software is. By law you own only
software you have written yourself or some software which has somebody
written from scratch for you and transferred the copyright ownership
to you. For most other software you only obtain a license to use it
and the license terms typically provide the licensor the option to
discontinue the license so "rented" what describes the software quite
well.

Opensource and free software for different definitions of free is also
rented, you can use it as long as you fulfill the license
requirements.

Only public domain software is not owned by anybody so you can use it
without renting it.

Thanks

Michal

 

[David Masover]

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.

Should you have to before buying any flag? No. Should it be possible for
someone to sell you a flag only if you agree to sign a no-burning contract?
Sure. Should that contract be enforceable? I'd say in general it should.

I'd agree with all of the above, in a legal system. I point it out because in
general, people don't buy physical items with contracts. There are exceptions,
like cell phones, and those contracts tend to screw consumers over most of the
time.

If you don't like it, don't buy from that vendor.

I don't.

However, I also occasionally speak up and make people question the tradeoffs
they're making. 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.

Voting with your dollar individually doesn't get you nearly as far as getting
other people to cast similar votes.

I think it's certainly *potentially* useful, but I've found that in many
cases, it's not so useful as to make me abandon something else I care
about.

It depends how much I care about it. You cited, as an example, hideous UIs. I
don't mind ugly UIs, as long as they're usable and get the job done.

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?

For example, if your app broke on Vista, it now becomes a somewhat more
expensive proposition...

It's not directly about the cost. It's about the risk, and about being forced
to trust a single external vendor -- which becomes that much worse when it's a
single person.

I don't use that feature. So all I care about is plain text.

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.

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?

Keep in mind, an option you can't actually use is not a real option. I'm
comfortable enough with C to have diagnosed an arcane memory management bug
in the pgsql driver. Not many other people I know would have had a good
chance of finding that bug -- meaning that in practice, access to the
source would not really be useful to them.

However, as Michal Suchanek pointed out, you can hire someone else to do so.
That is something which, again, is not necessarily an option for a proprietary
app.

The other advantage is one that a healthy community provides -- even if you
don't personally have the skills to, say, maintain a Ruby 1.8.6 fork, chances
are that if 1.8.7 really changed that much, _someone_ will have the skills and
inclination to make 1.8.6 continue to work.

I try KDE occasionally. Around 4.x, they had a wonderful feature, which
was that they never in any way saved user keybindings, such that every
login got you all the defaults again. I guess maybe I'll try again
sometime, but that's a level of quality control I would normally associate
with Microsoft...

Yes, the exact 4.0 release was pretty awful. It's gotten better.

However, on that particular issue, OS X had something nearly identical -- it
wasn't all keystrokes, but a particular one which would be forgotten after
every reboot. This remained unfixed (after I reported it) for something like a
year.

On an open source platform, I guarantee that at some point, sheer
determination would've led me to patching it myself, or working around it.
Fortunately, it usually doesn't come to that, as I can switch easily enough
from KDE to GNOME to Fluxbox to whatever else -- more an incidental benefit
than a direct benefit, I'll admit.

I got a jabber server up and running... It was a pain. The
next time I do server stuff, I'll put in OS X server, click "enable chat
server", and have a working jabber server.

Again, YMMV. For me, this was along the lines of:

sudo apt-get install ejabberd

It won't crash.

Hasn't crashed for me yet.

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.

I won't have to replace it with
a different one due to a crashing bug that no one cares about, or build
a programming language environment before I can use it.

Nope, and nope. Erlang was auto-installed as a dependency.

And that's worth
a fair bit of money to me.

I did some initial research before picking ejabberd. I suppose that's also
worth some money.

I only occasionally see a pure choice
between genuinely equivalent things, one of which is open source.

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.

 

[Seebs]

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.

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.

However, I also occasionally speak up and make people question the tradeoffs
they're making.

And that's a good thing. I think the reason this started out more
confrontational than it otherwise might have been is that, although it
may not have been intended that way, your posts came across as implying
that no one who had questioned those tradeoffs could possibly have
ended up choosing a proprietary editor.

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.

I'd like to see more variety there, and conveniently, Google already did
the first variant -- if you buy an unlocked phone, you get a LOWER monthly
rate.

It depends how much I care about it. You cited, as an example, hideous UIs. I
don't mind ugly UIs, as long as they're usable and get the job done.

I don't care much how they *look*, but when I talk about a "hideous UI", I
mean one that makes it harder to get things done.

For the canonical example, consider QuickTime 4, which introduced the worst
volume control ever implemented in a piece of software: A virtual thumbwheel.
You clicked on it and dragged to move volume up or down, but it was a
thumbwheel, so you couldn't cover the whole range in a single drag the way
you could with a slider.

Interface features can make a HUGE difference in the usability of a program.
One of the reasons I use Pages, rather than OpenOffice or Word, is that it
is much more likely that I can get something done reasonably well, reasonably
quickly. (If I need a lot more than that, I go to a markup language.)

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.

For example, if your app broke on Vista, it now becomes a somewhat more
expensive proposition...

Sorta. I have XP licenses around.

It's not directly about the cost. It's about the risk, and about being forced
to trust a single external vendor -- which becomes that much worse when it's a
single person.

Okay, imagine this. Imagine that I'm guaranteed that TextMate will cease to
exist as of Jan 1, 2011. I mean, actually stop working, because this is
a hypothetical scenario.

And imagine that using TextMate to write Ruby code improves my productivity
by about 10% over any other tool I have access to, and that I write a lot of
Ruby code.

Long story short: Buying a Mac mini, and a TextMate license, and using it for
those nine months, is probably a much, much, better deal than any other
alternative.

And if 10% sounds high to you, lemme tell you, it is not unreasonable at all.
I once ended up with a project which genuinely HAD to be done using Microsoft
Word. I'd guess that it increased the time it took me to get anything written
by about 30%, maybe a bit more, compared to writing in anything else I can
think of; nroff, HTML, XML, SGML, Pages, OpenOffice, you name it. It was
unbelievably bad. I'm still amazed at how much it sucked. And it cost me
a HUGE amount of time. I'd guess that, of any given hour spent writing, at
LEAST 15-20 minutes was spent just fucking around with Word, and that's to
say nothing of the extra time introduced by crashes, compatibility issues,
and so on.

So, yes. If I have convincing evidence that a tool's a big enough upgrade,
I'll use it even if I *know* that I'll stop being able to use it in a bit.
And in the case of TextMate, I would guess that the version I have right
now, with no further upgrades on my part, will still be usable to me five
years from now.

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.

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.

But. Note that this was qualified; *IF* I wanted something less
vendor-dependent... (Actually, I wrote "less vendor-dependant", showing
that I still can't !*#@!@# spell.) And in many cases, I'm willing to
accept some degree of risk because the payoff is good.

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.

However, as Michal Suchanek pointed out, you can hire someone else to do so.
That is something which, again, is not necessarily an option for a proprietary
app.

Sure. But it may not be an option for me in general, either. I couldn't
afford to hire someone to mess with that driver, so the theoretical option
doesn't do me much good.

The other advantage is one that a healthy community provides -- even if you
don't personally have the skills to, say, maintain a Ruby 1.8.6 fork, chances
are that if 1.8.7 really changed that much, _someone_ will have the skills and
inclination to make 1.8.6 continue to work.

Maybe. But that brings you right back to the risk issue, and honestly, I
don't think it's enough better for me to care.

I've seen very, very, few "forks" that were viable enough to be worth the
hassle.

On an open source platform, I guarantee that at some point, sheer
determination would've led me to patching it myself, or working around it.
Fortunately, it usually doesn't come to that, as I can switch easily enough
from KDE to GNOME to Fluxbox to whatever else -- more an incidental benefit
than a direct benefit, I'll admit.

Heh. I've got one of those right now; there's an X.org bug that breaks
key repeat, and every Linux system available to me has a buggy version, and
none of them appear to plan to fix it. Since rebuilding X is wayyyy too
much hassle, I've compromised on patching in a dodgy patch to WINE to
work around it for the one app I care about.

Again, YMMV. For me, this was along the lines of:

sudo apt-get install ejabberd

I was doing this a couple-few years back, and at the time, I had to
compile erlong and ejabberd myself.

Hasn't crashed for me yet.

ejabberd hasn't. I tried the "official" jabberd before that, and it
was crashy.

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.

Nope, and nope. Erlang was auto-installed as a dependency.

See above.

I did some initial research before picking ejabberd. I suppose that's also
worth some money.

Yup. When I did this, ejabberd was new enough (and erlang was new
enough on the BSD machine) that I had to do some of that research myself.

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. I don't think
I've ever seen it done. And that's one of the cases where the proprietary OS
makes up for the weaknesses of a lot of software -- I am not dependent on
software vendors supporting PDF.

-s

 

[David Masover]

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.

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.

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.

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.

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.

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.

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...

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.

 

[Seebs]

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.)

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.

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.

No one who had the money would seriously consider a monthly plan for a
computer.

I think it would depend on the terms.

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?

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.

Oh, sure.

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.
Yup.

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.

I don't know. For me, nvi works well enough that I haven't used other
stuff much. However, I've certainly heard people speak highly of its
relative performance.

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 -- it's just sitting there waiting
for me to replace it with a new machine.

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

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... 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.

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

Oh, sure. There's a ton of variety.

But as I understand it, right now, I have a mildly broader range of targets
for PHP than I do for Ruby. Not enough to make me tolerate it, though.

That's why another huge factor I use to choose software is whether a package
exists yet.

Certainly a good thing to look for in some cases.

Also, there's a particularly brutal hack I've used from time to
time involving starting a 'screen' instance...

Heh.

-s

 

[Charles Roper]

It is free but unless you register will give you a popup at startup time
saying "your license has expired" (then allowing you to continue)

Yeah, e needs quite a bit of love on Linux still. I don't believe that
"your license has expired" message is intentional.

The only open source textmate clone I'm aware of is Redcar. It just
released a new version with snippets now

http://redcareditor.com/2010/03/redcar-034dev-released/

I like Redcar a lot, but sadly they announced this not so long ago:

"We’ve also officially dropped plans to support Textmate commands now.
Textmate highlighting (done) and snippets (to be done soon) will still
be supported, but commands are extremely difficult to make work cross
platform, and we have some other ideas that we think are more exciting."

-- http://redcareditor.com/2010/02/redcar-033dev-released/

So it's no longer a Textmate clone, strictly speaking, which is a shame.
The "other ideas" sound interesting, though.

Charles

 

[David Masover]

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.

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 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.

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?

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.

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.

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.

 

[Seebs]

Not the legal right to torture, and I'm not sure when you're allowed to kill
them.

So far as I can tell, whenever you want.

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'.

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.

If it is, I have the option of buying the more expensive phone and the cheaper
contract. However, in my experience, the contract rates are not usually
affected by the phone or lack thereof. The contract has a fixed price. If
you agree to pay that fixed price for 2 years, you get $N off a phone,
otherwise you don't.

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.

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.

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

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.

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.

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.

Yeah. When there's a formal standard, that's going to make Ruby a much more
attractive target in some cases.

-s

 

[David Masover]

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.

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.

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?

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.

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.

 

[Seebs]

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?

Probably because you can't cap bandwidth -- the phone is effectively broken
if you do -- and people freak out if you charge them huge amounts of money
for bandwidth.

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.

Maybe, but not enough to justify the effort, especially since most of the
stuff I want is already written and working in C or shell.

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.

The point is, it's an example of a case where I can use a program already
existing, written in C, but I can't use one already existing, written in
Ruby.

I'm talking about *using* programs -- because I write programs in order that
people could use them.

So I tend to write things in C for portability if I want people to have
access those things.

Configuration, at the very least.

I don't see any to do.

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,

Yeah, that's the thing. Right now, a build of the whole shebang this is
being used with takes over an hour on an 8-core machine with 48GB of
memory and fast disks. Running stuff inside my current library adds
about 16% to everything, give or take -- more with lots of small files.
Running inside a larger/slower language would be crippling.

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.

You'd think, but no. Running the same tar command can take SUBSTANTIALLY
longer under a wrapper like this. Adding more processing complexity noticably
affects that.

Yes, it's I/O bound, but I'm adding a lot of I/O to many I/O operations...

-s

 

[David Masover]

Probably because you can't cap bandwidth -- the phone is effectively broken
if you do

Well, its Internet functionality is. It can still make phone calls, unless
you're counting phone calls towards bandwidth -- in which case, I hope you
aren't charging for minutes. (If you are, you're charging them twice for the
same call, which is a bit sleazy.)

and people freak out if you charge them huge amounts of money
for bandwidth.

They also freak out if you charge them huge amounts for text messaging, or
regular calls, or minutes of regular calls.

The same simple rules apply -- offer a per-usage rate (per-minute, per-bit),
offer various tiered rates, offer an "unlimited" flat-rate if your network can
handle it.

In fact, that's exactly what they do anyway -- they just charge an additional,
arbitrary "smartphone" fee on top of it if you happen to be using a
smartphone. And you're saying it's because of bandwidth? With what they're
charging for bandwidth, you'd think that's already built into the bandwidth
plan -- and it has to be, to some extent, given that my "non-smartphone" can
already download apps, music, and video, and can message/email said
music/video to others.

The point is, it's an example of a case where I can use a program already
existing, written in C, but I can't use one already existing, written in
Ruby.

Well, again, it comes down to compiling Ruby vs compiling your C program. If
they can compile Ruby, there's no compiling needed for your Ruby script, it
just runs -- so it's still exactly one compile step.

I could even argue that if your build process is more complicated than "type
make" or "gcc foo.c", it might be that much easier to install something like
Ruby, with a large community of maintainers and a number of people who may be
able to help if you have problems compiling on a weird platform, rather than
installing whatever make/autoconf/whatever you come up with.

Yeah, that's the thing. Right now, a build of the whole shebang this is
being used with takes over an hour on an 8-core machine with 48GB of
memory and fast disks. Running stuff inside my current library adds
about 16% to everything, give or take -- more with lots of small files.
Running inside a larger/slower language would be crippling.

Huh. I concede the point, then. I'd have to look much closer for opportunities
to script, and you're probably right.

 

[Seebs]

Well, its Internet functionality is. It can still make phone calls, unless
you're counting phone calls towards bandwidth -- in which case, I hope you
aren't charging for minutes. (If you are, you're charging them twice for the
same call, which is a bit sleazy.)

It is more complicated. For instance, one of my phones, if reset, restores
its phone book from the internet.

In fact, that's exactly what they do anyway -- they just charge an additional,
arbitrary "smartphone" fee on top of it if you happen to be using a
smartphone. And you're saying it's because of bandwidth? With what they're
charging for bandwidth, you'd think that's already built into the bandwidth
plan -- and it has to be, to some extent, given that my "non-smartphone" can
already download apps, music, and video, and can message/email said
music/video to others.

It may well be, but I suspect that in practice, the difference in network
load between a phone that watches youtube and a phone that browses plain text
web sites is pretty large.

Well, again, it comes down to compiling Ruby vs compiling your C program. If
they can compile Ruby, there's no compiling needed for your Ruby script, it
just runs -- so it's still exactly one compile step.

Except that, in practice, "I need to install a new programming language" is
a bigger deal than "I'll run this thing which uses existing standard tools".

Huh. I concede the point, then. I'd have to look much closer for opportunities
to script, and you're probably right.

Basically, it isn't in Ruby for the same reason that libc isn't written in
Ruby. It is, admittedly, arguably a special case.

-s