On Wednesday 10 March 2010 10:55:11 pm Seebs wrote:
But if the CURRENT version meets my needs, great!
So long as the current version continues to work.
It’s not as if most people can realistically get a real feature change
into vi. Even most programmers would be unlikely to find it worth the
time and effort.
Most likely – but having the ability is important.
I’m unlikely to ever want to, say, burn an American flag, but it is
to me that I have that right.
- You’re tied to an OS which is notorious for breaking backwards-
lolwut? I have things from OS X 10.0, written for PowerPC systems, which
still run on Intel in 10.6.
And I’ve seen things break from 10.3 to 10.4 to 10.5.
- The next version of OS X is as likely as not to break the current
version of TextMate.
You have any evidence for this? I’ve been using OS X as one of my desktop
platforms for about a decade now, and thus far, I’ve had VERY few programs
broken by upgrades – and those were always things which I would have
expected to break, like low-level hacks into the window manager or
It’s been long enough since I’ve used OS X that it’s possible I’m
low-level hacks. Then again, I remember even things like VLC would
least 10.3, and this is when 10.4 was the latest. So…
- Once you do upgrade, the new version of TextMate is as likely as not
to refuse to work on old versions of OS X, so you’d better upgrade all
your boxes at once.
Again, this claim “as likely as not” seems pretty implausible to me. It’s
extremely unusual for anyone to make a tool like this not work on at least
the two or three most recent revisions.
Two or three is nice, still means you’re going to have to upgrade when
four, five, or six revisions out of date – either the program or the
Again, I don’t mind this so much in open source, because in cases where
version had some merit, and we think they screwed up the new version too
we can fork the old version and maintain it. In particular:
Do you have any kind of data to back this claim up, or is this just generic
FUD? If we’re gonna be doing FUD, how about I warn people that they
shouldn’t be relying on Ruby, because a new version of Ruby might break
1.9 might, yes. But Ruby is open source. Don’t like 1.9? Fork 1.8.7, or
1.8.6. I believe someone is currently maintaining a stable 1.8.6.
With proprietary software, that’s not an option – Microsoft wanted to
Vista on everyone, so they threatened to pull support for XP. That
meant security vulnerabilities, among other things, making life
those of us wanting to stay on XP – no chance of any bugfixes.
maintains support for old version of Windows, but to a point – beyond
the community CANNOT take over.
Now consider the case of a killer app developed by a single individual.
are the chances he’s going to expend significant time and energy
old versions of TextMate when he could be working on a new version (and
charging for it) instead?
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,
than a proprietary project developed by a single person?
- Switching OSes – to Linux, to Windows, to Plan9, to whatever – is
out of the question for you.
I would consider that pretty normal for a lot of tools. I expect to have
to switch tools when I switch OS’s. There are exceptions,
My text editor of choice right now is Kate, and the entire KDE project
cross-platform. My other text editor of choice is vim, and it even runs
Windows, with some help. For school, I’m forced to use Java, so I use
which is also cross-platform. Ruby is cross-platform. Rails is
My web browser of choice is Google Chrome, which is cross-platform. My
web browser of choice is Firefox, which is cross-platform. Third would
Konqueror, which is as portable as KDE.
For writing and publishing, I’m using OpenOffice and Scribus, which are
For image editing, Krita or Gimp – cross-platform, and cross-platform.
For remote management, I use ssh and rdesktop – cross-platform, and…
there it is. I bet rdesktop doesn’t have a Windows version, huh? That’s
can use Windows’ native Remote Desktop client.
Whew. That was hard to find the one tool which isn’t portable, and I’m
even sure about that – it might run under Cygwin!
If it was the right tool for the job, yes.
I’m making myself an iPhone app. I dunno if I’ll ever even get it to the
point where I’d submit it to the app store. I want it for my own use. It
is heavily tied to several proprietary frameworks.
So what? Nothing else lets me do what I want.
Really? Android doesn’t? That’s interesting.
If not, why not, and why would you use a proprietary text
editor, or debugger, or any proprietary programming tool?
I don’t have a problem with proprietary tools, IF they do their job well
enough to justify the hassles.
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
OS or editor.
And that is a big if…
I generally don’t bother people about developing on OS X. It’s annoying,
but most of the Ruby stuff is going to be general Unix stuff anyway, not
Mac- specific. But then, switching OSes is easy when your tools are
It is usually a bit of a tradeoff. I’ll accept some non-portability of
tools to get jobs done sooner and with less effort.
I’ll do that, if it’s enough sooner and enough less effort to justify
of flexibility. I’d much rather spend a bit more time and get it right
first time, using portable, flexible, open tools, so that I don’t have
completely redo it if something needs to be changed.
There’s always a tradeoff, I just find it interesting where people draw
line. For example:
I am a moderately experienced Unix geek, but the shared disk used by the
various computers in my house is attached to a box running OS X Server,
because the cost of my time to set all that stuff up correctly is an
order of magnitude more than the cost to have something where I click the
“yes, make this available to Windows too” button.
sudo apt-get install samba
A fileserver is about the easiest thing to set up. I have to ask how
you’re being paid where half an hour or so of your time is more valuable
the hardware markup for an OS X server.