Development process latency
That plan did not go too far, unfortunately; it would seem that those systems, while seeming like nice boxes, contain NVIDIA graphics adapters. Buying hardware which needs proprietary drivers was most emphatically not on the agenda. Fortunately, it was not necessary to look too far to find a no-system-installed box with integrated Intel graphics. Said box is now being used to write this article; the simple difference in noise levels between this one and its predecessor is enough to make your editor almost cheerful.
The Intel chipset in this box, as it turns out, is quite new, to the point that not all distributions support it. But Fedora 8 was able to use everything installed on this box from the very beginning, and some early experiments showed that Ubuntu 7.10 was just as happy. Once upon a time, full support for very-new hardware was a rare surprise. Now, one can almost just take it for granted. This happy result comes from a combination of factors:
- The hardware vendor (Intel) is strongly committed to shipping
free drivers for its products as soon as those products become
available. Your editor can now definitively say that this policy is
responsible for at least one sale for that vendor.
- The "new" (since 2005) kernel development model is strongly focused on
a short release cycle and getting code out to users quickly. Prior to
2.6.x, new kernel code could take years to get into an official stable
kernel release. Now three months is sufficient in many cases. So
Intel's drivers became immediately available with no need to hassle
with backports, driver disks, or other such inconveniences.
- Contemporary distributions, at least outside of the "enterprise" category, have gotten very good at packaging, integrating, and stabilizing leading-edge software. So those fresh kernels, along with a lot of other goodies, end up in a supported distribution surprisingly quickly.
The end result is that, increasingly often, things Just Work. It is hard to get grumpy about that.
Of course, not everything Just Worked. Many years ago, your editor spent some hours experimenting with the available bitmap fonts for X in the search for the one which provided the optimal combination of information density and readability. The resulting choice (one of the 75dpi Adobe Courier fonts) served well for a long time, even as various components on the desktop moved to more sophisticated font engines. In recent times, only Emacs was still using that font. Emacs is an important part of your editor's desktop, however, so this one remaining user was a crucial one.
That font vanished when the new system came in, with the result that editor windows could no longer simultaneously fit into their assigned screen space and provide highly readable text. Your editor became grumpy again.
What followed was a brief effort to figure out where the special font had gone, and why it did not appear to render the same way even when the requisite font files were brought over from the old system. But even your editor, who can be somewhat slow on the uptake, eventually asked himself: why, exactly, was it necessary to chase down bitmapped fonts from the early 1990's - fonts which he first used on a diskless Sun 3 system - in 2007?
In fact, it's not necessary to mess with those archaic fonts - as long as one isn't tied to the concept of stable releases. Support for the Xft font library in Emacs exists, and has for a while; here's a description in a weblog entry from 2005. This support is, even, in the Emacs code repository on Savannah. But it is not in the Emacs 22 release. It's not even in the development trunk yet.
With a bit of digging, your editor found this page which describes how to check out and build a version of Emacs with proper font support. The results are striking. Here's what standard emacs looks like:
![[emacs with bitmapped font]](https://static.lwn.net/images/ns/grumpy/emacs-bitmap.png)
And here is what the Xft-enabled version can do instead:
![[emacs with Deja Vu font]](https://static.lwn.net/images/ns/grumpy/emacs-dejavu.png)
Your editor is wishing he had investigated this code some time ago; perhaps it would not have been necessary to buy those new, stronger eyeglasses after all.
Building crucial tools directly from development repositories brings a certain thrill; it's part of the free software experience. This version of Emacs has not, yet, exploded in real use. But, all of that notwithstanding, there is something warm, fuzzy, and comforting about getting things like text editors in a stable, supported form from one's distributor. So one might well wonder: when are we likely to see Emacs 23, which will contain the Xft support (along with a lot of other things like proper Unicode support, the multi-term patches, etc.), in a stable form?
The history here is not encouraging: the Emacs 22 release was five years in the making. Richard Stallman, who still keeps a firm hand on Emacs development, is famously averse to making guesses about release dates, so there is little point in asking him when the next release might happen. But it is worth noting that there has been no public discussion of release timelines, or of any desire to tweak the process to get the next version out in less than five years. There is some very nice code sitting in the unicode-2 branch of the GNU Emacs repository; it has been there for a while, but most users may well not see it before the end of this decade.
Different free software projects have different management styles, and
nobody would argue that things should be otherwise. Experience has shown
that each project needs to develop in its own way. But experience has also
shown, over quite a few years now, that confining useful code to
development repositories for years on end brings little benefit to anybody.
There is value in getting features into stable releases and out where
people can make use of them.
Posted Dec 6, 2007 2:08 UTC (Thu)
by ll (guest, #4404)
[Link] (4 responses)
Posted Dec 6, 2007 6:56 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (3 responses)
Posted Dec 6, 2007 7:50 UTC (Thu)
by V-Li (guest, #48321)
[Link]
Posted Dec 6, 2007 11:08 UTC (Thu)
by alex (subscriber, #1355)
[Link]
Posted Dec 6, 2007 11:14 UTC (Thu)
by IkeTo (subscriber, #2122)
[Link]
Posted Dec 6, 2007 2:15 UTC (Thu)
by jwboyer (guest, #23296)
[Link] (4 responses)
Posted Dec 6, 2007 2:46 UTC (Thu)
by yokem_55 (subscriber, #10498)
[Link] (3 responses)
Posted Dec 6, 2007 21:21 UTC (Thu)
by landley (guest, #6789)
[Link] (2 responses)
Posted Dec 6, 2007 23:53 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Dec 7, 2007 4:08 UTC (Fri)
by landley (guest, #6789)
[Link]
Posted Dec 6, 2007 3:36 UTC (Thu)
by guinan (guest, #4644)
[Link] (13 responses)
Posted Dec 6, 2007 4:19 UTC (Thu)
by cdarroch (subscriber, #26812)
[Link] (1 responses)
Posted Dec 7, 2007 7:08 UTC (Fri)
by jordanb (guest, #45668)
[Link]
Posted Dec 6, 2007 7:47 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Posted Dec 6, 2007 11:11 UTC (Thu)
by ms (subscriber, #41272)
[Link] (1 responses)
Posted Dec 7, 2007 0:15 UTC (Fri)
by dirtyepic (guest, #30178)
[Link]
Posted Dec 6, 2007 15:50 UTC (Thu)
by jengelh (guest, #33263)
[Link] (4 responses)
I have to agree, the AA blur is ... sometimes suboptimal. But! You can tune Xft to use the bytecode interpreter (IOW: bitmaps) when TTF files have it -- just like Windows does for any font size < 14pt by default. Well, I prefer AA even below 14pt, and I have stuck to it. What this means for coding - yes, I remain with fixed fonts too. But, the usual fixed fonts like in your screenshots only have 1 pixel wide "struts", which appear increasingly thin on higher resolutions. This is why I have converted some VGA ROM fonts into X fonts for myself, as their struts are generally 2 pixels wide, and give a much sharper picture. Google for hxtools, if interested. I commonly use 'tosh' on X, and 'ahnv' on the console.
Posted Dec 6, 2007 18:41 UTC (Thu)
by allesfresser (guest, #216)
[Link] (2 responses)
Posted Dec 12, 2007 16:00 UTC (Wed)
by darwish07 (guest, #49520)
[Link]
Posted Dec 13, 2007 21:46 UTC (Thu)
by jengelh (guest, #33263)
[Link]
Posted Dec 7, 2007 15:10 UTC (Fri)
by alankila (guest, #47141)
[Link]
Posted Dec 7, 2007 9:30 UTC (Fri)
by rwmj (subscriber, #5474)
[Link] (1 responses)
I'm waiting for a font where the ` (backquote) and ' (single quote) are mirrors of each other, and can be used for ``quoting''. Back in the day when I used a VC4404 terminal, quotes
behaved like this, and so did the fonts on early Linux distros.
But now we use strange M$-inspired fonts which get this consistently
wrong ...
(And yes, I have downloaded ancient versions of Slackware and
SLS trying to look for the right font, but the fonts are in odd
formats that modern software doesn't seem to be able to read easily)
Rich.
Posted Dec 7, 2007 18:39 UTC (Fri)
by njs (subscriber, #40338)
[Link]
Posted Dec 12, 2007 1:27 UTC (Wed)
by da4089 (subscriber, #1195)
[Link]
Posted Dec 6, 2007 4:01 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link]
Posted Dec 6, 2007 4:29 UTC (Thu)
by jasone (subscriber, #2423)
[Link] (7 responses)
Posted Dec 6, 2007 12:49 UTC (Thu)
by mingo (guest, #31122)
[Link] (6 responses)
What i think rms does not realize is that the extreme control that he exerts over Emacs becomes its own essential limit on freedom. Free software concepts should permeate everything, including planning and contribution structure.
As Linux has shown, it's far more important to freedom to increase the developer base than to exert control over the codebase.
Lets look at some hard data: rms's approach has resulted in less than 10 million lines of gnu.org managed GNU code (gcc, glibc, binutils, gdb, etc.).
The Linux approach on the other hand has resulted in around 1 billion lines of FOSS code in the last 10 years. The difference is staggering.
If you look at the package list of any distribution then the percentage of gnu.org managed code is miniscule (even if you weigh them by size, complexity and importance), and that percentage is getting smaller with every new release. It's in the low single digits percentage range.
And i think even free software purists would have to agree that 1 billion lines of FOSS code gives us more real freedom in every sense of the word than 10 million lines of GNU code gives. The world would happily ignore 10 million lines of GNU code - but it cannot (and wont) ignore 1 billion lines of FOSS code.
Posted Dec 6, 2007 15:57 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (1 responses)
Posted Dec 6, 2007 16:03 UTC (Thu)
by mingo (guest, #31122)
[Link]
Posted Dec 6, 2007 20:43 UTC (Thu)
by bfields (subscriber, #19510)
[Link]
Surely the same would be true if you replaced "gnu.org" by any other organization?
Posted Dec 16, 2007 12:24 UTC (Sun)
by man_ls (guest, #15091)
[Link] (2 responses)
RMS may control tightly Emacs development and it may go slowly, but that is not true of many other GNU-sponsored projects which are moving at a furious path (GCC, glibc, GNOME) and with no signs of slowing down. I would contend that Emacs grows so slowly because of its archaic underpinnings and poor modularization, not out of any GNU talibanism.
After all, even the Linux kernel grows more slowly than free software in general. You talk about "the Linux approach" for all free software which is meaningless, since most of that code uses GNU tools, a GNU license, GNU libraries and it is based on a published POSIX interface most of the time. Linux is a wonderful kernel, but there is not a replacement for GNU code either; when I log on to an AIX machine with no GNU code I really feel the pain. There is no point to competing on who is more important IMHO.
Posted Dec 16, 2007 15:24 UTC (Sun)
by mingo (guest, #31122)
[Link] (1 responses)
The reality of the situation is that many of these "GNU" components (such as glibc and even gcc) are mainly maintained and developed by Linux distributors and other large Linux entities outside of GNU.
The real reason why these GNU projects have not been replaced yet, despite all the political fuss from Stallman is simply because silly politics is not yet causing enough problems on the technical side for people to care. There's far more action elsewhere, and why reinvent the wheel. The code quality is excellent as well - the best of the best have put their heart and soul into those projects.
I suspect this would change if someone on the GNU side tried to do some stupid political move, such as force-licensing them to GPLv3 only - a GPLv2 fork outside of gnu.org might happen in a heartbeat.
This happened in the past a couple of times: for example Stallman was so out of whack with reality regarding GNU Hurd that there was just not enough development power available to get a kernel off the ground. Linux just happened as a practical replacement - despite all the huffing and puffing from Stallman. A kernel has tons of parallelism and it's exposed to myriads of small details that the real world throws at us. Get it wrong and developers and users start flocking to other projects very quickly. (but as a kernel developer i could hardly be regarded as unbiased. ;-)
Contrast that with GCC, which is certainly complex (and beautiful) from the mathematics side, but is otherwise a single-threaded piece of code that connects to the real world only through a very thin interface. [and even that small exposure to harsh realities and ambiguities causes tons of problems that make GCC a PITA for the kernel. Just think of the silliness of GCC not having a clean frontend/backend splitup that people could use to experiment with.]
The developers are what make actual code (and maintenance) happen, not some political will or semi-religious umbrella. It's the people that matter.
Posted Dec 16, 2007 17:55 UTC (Sun)
by man_ls (guest, #15091)
[Link]
I suspect you are just repeating Linux-land myths. When accusing people of such things please provide pointers so that others can verify them; otherwise it just becomes nonsensical mudslinging which does nothing to advance your points of view.
Posted Dec 6, 2007 6:13 UTC (Thu)
by charris (guest, #13263)
[Link] (10 responses)
Posted Dec 6, 2007 14:47 UTC (Thu)
by wjhenney (guest, #11768)
[Link] (7 responses)
Posted Dec 6, 2007 16:14 UTC (Thu)
by Cato (guest, #7643)
[Link] (3 responses)
Posted Dec 6, 2007 16:57 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Dec 6, 2007 21:45 UTC (Thu)
by Frej (guest, #4165)
[Link] (1 responses)
Posted Dec 7, 2007 0:12 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
Posted Dec 6, 2007 17:29 UTC (Thu)
by tjc (guest, #137)
[Link]
I also discovered that removing an icon from the dock uninstalls the associated application! It makes a nice second system (I bought it to run Logic Express), but if I had to use it all the time I'd soon be as grumpy as our editor.
Posted Dec 6, 2007 17:07 UTC (Thu)
by AJWM (guest, #15888)
[Link]
Posted Dec 13, 2007 13:00 UTC (Thu)
by endecotp (guest, #36428)
[Link]
Posted Dec 6, 2007 9:59 UTC (Thu)
by markc (guest, #4419)
[Link] (3 responses)
Posted Dec 6, 2007 21:07 UTC (Thu)
by khim (subscriber, #9252)
[Link] (2 responses)
Just the guy who still will be remembered as the "guy who started it all" long after QT4 will be a history... And no, I have nothing against Qt4 or KDE (even if I personally use GNOME)...
Posted Dec 9, 2007 2:31 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
No, "RMS did start it all" is just his own revision of history. He took what by then was an at least 30-odd year tradition of source-sharing, and codified it through a legally sound license. Sure, it was an important step, but nowhere near earth-shattering.
Posted Dec 16, 2007 12:28 UTC (Sun)
by man_ls (guest, #15091)
[Link]
Posted Dec 6, 2007 15:18 UTC (Thu)
by cruff (subscriber, #7201)
[Link]
Posted Dec 7, 2007 13:24 UTC (Fri)
by DRBaldock (guest, #30881)
[Link]
Posted Dec 7, 2007 16:53 UTC (Fri)
by zooko (guest, #2589)
[Link]
Posted Dec 13, 2007 10:37 UTC (Thu)
by RobLucid (guest, #49530)
[Link]
Posted Dec 14, 2007 0:52 UTC (Fri)
by pm101 (guest, #3011)
[Link]
Development process latency
If you switch to Ubuntu, you can get emacs xft packages from here:
deb http://ppa.launchpad.net/avassalotti/ubuntu gutsy main
deb-src http://ppa.launchpad.net/avassalotti/ubuntu gutsy main
No need to compile, they're stable, and he updates them pretty frequently.
Development process latency
That's just like saying: "use an external yum source" (or apt, or whatever) for Fedora.
Should mostly work. Hopefully.
But does not get the level of QA as the stuff in the main tree.
Development process latency
Gentoo Linux ships official live ebuilds (the latest CVS state is build on YOUR system) for
years now...if you want the really latest from upstream CVS, just switch to Gentoo. :)
No need to wait ten years for a new Emacs major release.
Christian Faulhammer, part of the Emacs maintaining team in Gentoo
But good enough
3rd party repos are great ways to track the latest greatest tools for things like emacs. Sure
it may break but on my Ubuntu system I have emacs21 and emacs22 to fall back to if my snapshot
breaks.
Obviously I wouldn't be quite so caviler with system components like the kernel or filesystem
tools. Having said that at home I run Gentoo which does allow me to build a system where I can
make a choice between testing and stable for which packages I want.
Development process latency
Perhaps do everybody a flavor and make a request for package in the distribution you love
most? It really only takes one devoted maintainer in each of Fedora and Debian to make the
package and then everybody could be using that special version of Emacs, no need to wait for
Emacs 23.
Development process latency
I ordered one of the Dell Ubuntu boxes a while back. The website let me pick Intel graphics,
but the invoice email I got said it had Nvidia graphics. Dell customer service swore it was
Nvidia only, so I just waited for the box to arrive as the nv driver would have been fine for
my needs anyway. When it got here, it had Intel graphics.
Seems for those boxes the Nvidia and Intel on-board graphics have the same part number.
Development process latency
The 1420n notebook does have the Intel X3100 graphics by default, but
from what I can see, the desktop 530n does not have intel graphics as an
option. Aparenly our editor didn't need a new notebook.
Development process latency
My E1505 laptop has Intel graphics.
My main gripe with the system was that they preinstalled a 32-bit Ubuntu
on a 64-bit processor. Other than that, everything pretty much Just
Worked.
Development process latency
This actually makes a lot of sense. Lots of software don't have pre-compiled 64-bit versions,
such as Flash, Eclipse, etc. If you know what packages to install, it's easy to work around
this for Flash. But, with Eclipse, it's simply painful (you can't use your distro's
prepackaged Eclipse because then you can't install third-party plugins).
So, in the interest of keeping support calls to a minimum, I personally would ship a 32-bit OS
as well. If the user is smart enough to care, the user is smart enough to wipe and reinstall
anyway. :)
Development process latency
Did I mention that the x86-64 Ubuntu transparently runs 32-bit apps?
Just exec them and they run.
So you can install a 32-bit version of Eclipse no problem.
Rob
I find it hard to look at the Xft snapshot. The blur around the m's, especially. It makes me strain my eyes - I can't get a "focus lock" on it.
For better or worse, I'm still using "fixed" after all these years:
snapshot.
The goggles do nothing!
The goggles do nothing!
Seconded! A classic fixed-width X font is what I like for coding as well. And please, no
anti-aliasing on it!
The goggles do nothing!
I completely agree. I can't stand this Anti Aliasing craze.
You get a slightly better looking font by smoothing the edges (hiding the rasterization) with
the expense of crisp delineation between the background and foreground, and subpixel details
such as serifs descending into eyestrain-inducing smudges.
The "improved" example there makes me cringe.
So toss them, then
Antialiased fonts did require some time to get used to them for me too, but after that? No
contest. For me, I'm far more comfortable with smaller fonts when they're antialiased -- when
more code fits onto a page I work faster. ;-)
The goggles do nothing!
Yeah, the strokes on the m are uneven. There was a great article linked from LWN a few months
ago about font rendering which basically concluded with "almost everyone gets it wrong" and
"just wait for 600dpi displays".
The goggles do nothing!
http://antigrain.com/research/font_rasterization/index.html i think.
must read.
The goggles do nothing!
The goggles do nothing!
I personally prefer the Terminus fonts--available in Ubuntu (and Debian, I believe) as the
xfonts-terminus package. They're bitmap fonts that work extremely well for me--very readable
and in various sizes.
The goggles do nothing!
I agree. I've been using this font on emacs for two years and I'm still completely satisfied.
It works best on a black emacs background, or maybe it's just my eyes :).
The goggles do nothing!
terminus is indeed a visual high-quality bitmap font (terminus-medium-12,-14,-16,-20,-24
suffer from the 1-pixel struts I have mentioned, all others are fine).
If you want to see "tosh" in action (just one size since it was a VGA ROM import), see the
picture of http://en.wikipedia.org/wiki/PINE
Thanks for bringing terminus to my attention!
The goggles do nothing!
This is slightly incorrect.
The bytecode is used to perform customized hinting, the process of aligning the features of
the font to the pixel grid.
This is separate issue from the antialiasing itself, although in most cases the customized
hinting happens to reduce visible antialising, because perfectly aligned horizontal or
vertical stems just plain do not need any antialiasing.
The goggles do nothing!
The goggles do nothing!
The other option is to want the single quote to be its own mirror, for ease in 'quoting'. In
my experience, this is actually more common than `balanced' quoting -- the only place I
encounter `balanced' quotes is in the output from old GNU tools; newer releases don't do this
anymore. (Making single-quote its own mirror also preserves parallelism to the ascii
double-quote, which is also its own mirror.). Then you have the backquote, which suffers a
similar problem -- should it be a grave accent, or an opening quote?
Anyway, some decisions had to be made, and Unicode made them:
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Whether one likes it or not, the only way to get predictable display of one's words on other
people's computers is if all the computers are using the same standard, and for text
standards, Unicode is the only game in town. MS has nothing to do with it.
The goggles do nothing!
Count me in: another dedicated and happy 'fixed' (6x13) user. It was always good on a CRT,
but it's incredibly clear on my LCDs. Don't program without it.
Modern fonts in Emacs
One can easily get all the advantages of the modern font infrastructure in any version of
Emacs that can be build. Just use it from a terminal window :).
Development process latency
There was a buffer display refresh bug (when using multiple frames) in emacs 21 that caused me
no end of trouble. To RMS's credit, he committed a fix for the bug shortly after I reported
it in 2002. However, by 2005, still with no emacs 22 release in sight, I was sick of building
a custom emacs binary for every new Linux or FreeBSD system I installed, so after over a
decade of heavy emacs use, I switched to vim.
So, this is my very personal view of what happens when development cycles are ridiculously
long: users find other options.
Development process latency
Development process latency
>What i think rms does not realize is that the extreme control that he exerts over Emacs
becomes its own essential limit on freedom.
A possible refutation:
http://www.emacswiki.org/cgi-bin/emacs-en/EmacsImplementa...
Development process latency
how is this a refutation? I consider it more of a confirmation of my points.
Development process latency
If you look at the package list of any distribution then the percentage of gnu.org managed code is miniscule (even if you weigh them by size, complexity and importance), and that percentage is getting smaller with every new release. It's in the low single digits percentage range.
GNU-managed code may be less than 10M lines, but they remain an essential part of any free software operating system. I would say that, after the Linux kernel, it is the most important contribution even to Linux desktops. There are things in there which are used virtually by everybody: GCC, glibc, the Bash shell or GNU fileutils. It is probably just because they got there first, but no other organization can match its importance (not even the almighty Red Hat), and that is as well because otherwise we would be reinventing the wheel all the time.
Development process latency
Development process latency
Ingo, I agree with the bulk of your comment, but you throw in a couple of petty accusations which are really out of place:
Development process latency
The real reason why these GNU projects have not been replaced yet, despite all the political fuss from Stallman is simply because silly politics is not yet causing enough problems on the technical side for people to care.
So there is not enough "political fuss" to matter? So it is not very important?
I suspect this would change if someone on the GNU side tried to do some stupid political move, such as force-licensing them to GPLv3 only - a GPLv2 fork outside of gnu.org might happen in a heartbeat.
I rather suspect that most people would not care a bit. Where is the GPLv2 fork of Samba or those other 1341 projects as of today?
Linux just happened as a practical replacement - despite all the huffing and puffing from Stallman.
All I have seen from Stallman is support to the Linux kernel. The only "huffing and puffing" I see is from Stallman detractors, witness the comments right here on this page ladies and gentlemen.
Development process latency
I switched from Emacs to Vim just for the fonts. Emacs looks like a relic from the
paleolithic.
Development process latency
...and I switched from linux to OS X for my laptop just to get a better emacs :) For me, the
editor is more important than the OS. I still make heavy use of linux servers, though, so
please don't excommunicate me.
Development process latency
Was it really easier to install and use a whole new OS just to get a newer version of Emacs?
Surely just building Emacs from source would have been quicker and easier.
Development process latency
Well, installing the new OS takes less time than starting Emacs anyway. ;}
(hey, I'm an XEmacs user and it's even worse.)
Development process latency
Textmate really is a better emacs. (or vim). I went back to linux after 4 months though ;).
Having spent at least 4? years with (g)vim, I could do more with textmate after 3 months. Vim
might be more powerfull, but I would learned how to use all that power.
Amazingly there are better/more addins for textmate (bundles) than for emacs/vim - even
though gvim/emacs have existed for many many years....
Development process latency
I'll need to buy a laptop next year and I'm leaning towards a Mac for one reason only:
Textmate. It sucks that a $1500 purchase can be swayed by a $50 program but what can I do?
After using Textmate for a few weeks, I've become spoiled. Emacs now looks hostile and
antiquated. And every time Vim blocks my flow with "E325: ATTENTION, Found a swap file by the
name file.c" I want to kick its teeth right down its ugly throat. How old are you, Vim?
I use Vim every day, and Eclipse for the big projects. But, if Linux editors don't start
catching up, I could very well find myself defecting soon. It's truly heinous.
I'm finding OS X to be somewhat frustrating to work with. The window manager is amazingly primitive in operation; it doesn't seem to have changed much since 1984. There are additions such as Expose, but that's like a full-on Broadway production every time I want to switch to another window. That got to be tiresome in less than 15 minutes. I could never use it as my primary development system, at least not without finding some keyboard shortcuts.Development process latency
Development process latency
> Emacs looks like a relic from the paleolithic.
Come now, don't exaggerate. You can't use emacs with punched cards. Neolithic, surely.
Development process latency
> I switched from Emacs to Vim just for the fonts
For a while I used Emacs on Windows, which has decent fonts. On returning to Linux, I
abandoned Emacs and now use Nano in a terminal.
Kate from KDE4
Qt4 has superb font rendering. I use Kate on a KDE4 desktop at HDTV
resolutions with a 18pt font and it's simply breathtaking. Welcome to the
21st century... RMS who?
RMS ?
RMS ?
No, "RMS did start it all" is just vonbrand's own revision of Stallman's account of history. He writes:
vonbrand?
The GNU Project was conceived in 1983 as a way of bringing back the cooperative spirit that prevailed in the computing community in earlier days [...]
And then he elaborates. Read it sometime; first-hand accounts are interesting. Richard has many defects but revisionism is not one of them.
Fonts
I use Bitstream Vera Sans Mono for my monospace font of choice on both Linux and OS X. I
wouldn't switch back to a bitmap font unless nothing else was available.
The new PC?
Jonathan Corbet wrote, "...So it seemed like maybe a good time to put a bit of money where the
keyboard was and have a look at those Ubuntu-based systems being sold by Dell.
That plan did not go too far, unfortunately; it would seem that those systems, while seeming
like nice boxes, contain NVIDIA graphics adapters. Buying hardware which needs proprietary
drivers was most emphatically not on the agenda. Fortunately, it was not necessary to look too
far to find a no-system-installed box with integrated Intel graphics. Said box is now being
used to write this article..."
So, who did you buy your new PC from - one of the LWN advertisers? Was it a Laptop or
Desktop? There are motherboards with integrated Intel graphics available from one online shop
for prices that range from $48 to $140. They may not keep up with the latest ATI or Nvidia
systems for gaming, but they're probably just fine for general purpose use.
Take Care,
David Baldock
Development process latency
I've been using XEmacs for about 10 years now because I wanted nice fonts.
However, a few days ago I switched from XEmacs to GNU Emacs on my Mac OS X laptop, because the
unsupported, beta, contributed port of XEmacs to Carbon has serious performance flaws and the
beta port of GNU Emacs to NeXTStep doesn't.
Development process latency
mingo "What i think rms does not realize is that the extreme control that
he exerts over Emacs becomes its own essential limit on freedom. Free
software concepts should permeate everything, including planning and
contribution structure.
As Linux has shown, it's far more important to freedom to increase the
developer base than to exert control over the codebase.
Lets look at some hard data: rms's approach has resulted in less than 10
million lines of gnu.org managed GNU code (gcc, glibc, binutils, gdb,
etc.)."
It's worse than that. His strident antagonistic approach has also led to
millions & millions of lines of code, duplicating other efforts that were
outside of his control. That later lead to fork in GNU/Linux user base,
making standardisation more difficult, and detering ISV's from supporting
the FOSS market.
For example, rather than solving KDE's reliance on non-Free library, by
solely promoting the development of the Harmony "qt" clone as pressure on
trolltech to go GPL, we've ended up with GNOME and KDE. Ironically, GNOME
still was too big to be kept under RMS's control. KDE's popularity
despite much greater commercial enterprise investment in GNOME desktop and
much Free campaigning years ago, supports the original KDE developer's
arguments that the qt library was technically superior.
Whilst making life difficult for ISV's peddling binaries, may be regarded
as a "feature"; making life difficult for FOSS projects to, limitting
their user & contributor base cannot be desirable.
The LSB has failed to make the impact that was hoped. Mac's OS X has got
the applications, very rapidly, that many potential Linux users hope for.
There's another chance, with the lightweight cheap notepad/desktop
machines, to get significant market share, and reduce the advantages of
certain Monopolists due to what economist's call the "Network Effect".
Yet, the dynamics that held back the multi-vendor UNIX's in 80's and early
90's now exist with the major Linux distro's and judging my recent
stories, the competition between RedHat/Novell/Canonical is going to get
nastier.
This will mean that many who could contribute FOSS sofware, will remain
trapped by a proprietary eco-system, which appears to be delivering
advanced "cool" things.
If it ain't broken, don't fix it
I think I have a counterpoint. Slow Emacs releases, slow Debian releases, and in general,
slow, stable release help a lot of people, myself included. A lot of people want computers to
Just Work. I am in that category. The professor for whom I did my Ph.D (whom most of you have
heard of) is in that category. His wife (who has written or edited computer science texts that
you have almost certainly heard of) is also in that category. Knuth, famously, froze TeX, for
perfect backwards compatibility. The only new releases are bug fixes. He is also in this
category.
Emacs worked fine for me a decade ago. Debian did too. So did the kernel. If not for security
holes, file format compatibility issues (especially with ever-evolving HTML), and drivers for
new hardware, I would have left my system from 1996 as it was, and not futzed with it further.
I had it configured the way I wanted, and everything worked. Each time a new version comes
out, something breaks. Configuration file formats change. Debian makes me upgrade. Apache gets
a security hole. The new Apache requires a new glibc. The new glibc makes me upgrade
everything else. Then, I spend many hours working with the new release.
For people like me, releases every 5 years are about right. Releases every year? No thanks. I
suspect Richard runs into a lot more people like me than people like you (although I suspect a
lot more LWN readers are like you, and actually enjoy futzing with their computers).
Debian/late-90s was also nicer, orthogonally to this, in that the system was simple enough and
clean enough to where I could understand everything. Debian '07 does hardware detection, and
has all sorts of fancy scripts doing fancy things that make it much harder to understand the
underlying system.
