Weekly Edition
Return to the Front page
| |||||||||||||
Development process latency
Your editor recently reached a point where a replacement of his main
desktop system became imperative. The old one was showing certain signs of
hardware flakiness, coupled with a basic inability to run some of the
software your editor is trying to play with for a future article. Let's
just say that the grumpy editor was becoming more so than usual. But,
being a good US citizen, your editor knows how to deal with a bad mood: go
shopping. 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; 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 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:
And here is what the Xft-enabled version can do instead:
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. (Log in to post comments)
Development process latency Posted Dec 6, 2007 2:08 UTC (Thu) by ll (guest, #4404) [Link] 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 Posted Dec 6, 2007 6:56 UTC (Thu) by tzafrir (subscriber, #11501) [Link] 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 Posted Dec 6, 2007 7:50 UTC (Thu) by V-Li (subscriber, #48321) [Link] 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 Posted Dec 6, 2007 11:08 UTC (Thu) by alex (subscriber, #1355) [Link] 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 Posted Dec 6, 2007 11:14 UTC (Thu) by IkeTo (subscriber, #2122) [Link] 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 Posted Dec 6, 2007 2:15 UTC (Thu) by jwboyer (guest, #23296) [Link] 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 Posted Dec 6, 2007 2:46 UTC (Thu) by yokem_55 (subscriber, #10498) [Link] 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 Posted Dec 6, 2007 21:21 UTC (Thu) by landley (guest, #6789) [Link] 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 Posted Dec 6, 2007 23:53 UTC (Thu) by bronson (subscriber, #4806) [Link] 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 Posted Dec 7, 2007 4:08 UTC (Fri) by landley (guest, #6789) [Link] 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
The goggles do nothing! Posted Dec 6, 2007 3:36 UTC (Thu) by guinan (subscriber, #4644) [Link] 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! Posted Dec 6, 2007 4:19 UTC (Thu) by cdarroch (guest, #26812) [Link] 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! Posted Dec 7, 2007 7:08 UTC (Fri) by jordanb (guest, #45668) [Link] 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 Posted Dec 6, 2007 7:47 UTC (Thu) by smurf (subscriber, #17840) [Link] 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! Posted Dec 6, 2007 11:11 UTC (Thu) by ms (subscriber, #41272) [Link] 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! Posted Dec 7, 2007 0:15 UTC (Fri) by dirtyepic (subscriber, #30178) [Link] http://antigrain.com/research/font_rasterization/index.html i think. must read.
The goggles do nothing! Posted Dec 6, 2007 15:50 UTC (Thu) by jengelh (subscriber, #33263) [Link] 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.
The goggles do nothing! Posted Dec 6, 2007 18:41 UTC (Thu) by allesfresser (subscriber, #216) [Link] 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! Posted Dec 12, 2007 16:00 UTC (Wed) by darwish07 (subscriber, #49520) [Link] 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! Posted Dec 13, 2007 21:46 UTC (Thu) by jengelh (subscriber, #33263) [Link] 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! Posted Dec 7, 2007 15:10 UTC (Fri) by alankila (subscriber, #47141) [Link] 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! Posted Dec 7, 2007 9:30 UTC (Fri) by rwmj (subscriber, #5474) [Link] 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.
The goggles do nothing! Posted Dec 7, 2007 18:39 UTC (Fri) by njs (guest, #40338) [Link] 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! Posted Dec 12, 2007 1:27 UTC (Wed) by da4089 (subscriber, #1195) [Link] 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 Posted Dec 6, 2007 4:01 UTC (Thu) by ibukanov (subscriber, #3942) [Link] 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 Posted Dec 6, 2007 4:29 UTC (Thu) by jasone (guest, #2423) [Link] 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 Posted Dec 6, 2007 12:49 UTC (Thu) by mingo (subscriber, #31122) [Link] 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.
Development process latency Posted Dec 6, 2007 15:57 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] >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 Posted Dec 6, 2007 16:03 UTC (Thu) by mingo (subscriber, #31122) [Link] how is this a refutation? I consider it more of a confirmation of my points.
Development process latency Posted Dec 6, 2007 20:43 UTC (Thu) by bfields (subscriber, #19510) [Link] 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. Surely the same would be true if you replaced "gnu.org" by any other organization?
Development process latency Posted Dec 16, 2007 12:24 UTC (Sun) by man_ls (subscriber, #15091) [Link] 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.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.
Development process latency Posted Dec 16, 2007 15:24 UTC (Sun) by mingo (subscriber, #31122) [Link] 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.
Development process latency Posted Dec 16, 2007 17:55 UTC (Sun) by man_ls (subscriber, #15091) [Link] Ingo, I agree with the bulk of your comment, but you throw in a couple of petty accusations which are really out of place: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. 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.
Development process latency Posted Dec 6, 2007 6:13 UTC (Thu) by charris (subscriber, #13263) [Link] I switched from Emacs to Vim just for the fonts. Emacs looks like a relic from the paleolithic.
Development process latency Posted Dec 6, 2007 14:47 UTC (Thu) by wjhenney (guest, #11768) [Link] ...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 Posted Dec 6, 2007 16:14 UTC (Thu) by Cato (subscriber, #7643) [Link] 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 Posted Dec 6, 2007 16:57 UTC (Thu) by nix (subscriber, #2304) [Link] 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 Posted Dec 6, 2007 21:45 UTC (Thu) by Frej (subscriber, #4165) [Link] 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 Posted Dec 7, 2007 0:12 UTC (Fri) by bronson (subscriber, #4806) [Link] 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.
Development process latency Posted Dec 6, 2007 17:29 UTC (Thu) by tjc (subscriber, #137) [Link] 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.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.
Development process latency Posted Dec 6, 2007 17:53 UTC (Thu) by leoc (subscriber, #39773) [Link] Yeah, but a better emacs is still worse than vi. ;)
VI ? Posted Dec 6, 2007 21:05 UTC (Thu) by khim (subscriber, #9252) [Link] ANY emacs is better then Vi. VIM is different, of course...
Development process latency Posted Dec 6, 2007 17:07 UTC (Thu) by AJWM (guest, #15888) [Link] > 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 Posted Dec 13, 2007 13:00 UTC (Thu) by endecotp (guest, #36428) [Link] > 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 Posted Dec 6, 2007 9:59 UTC (Thu) by markc (subscriber, #4419) [Link] 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 ? Posted Dec 6, 2007 21:07 UTC (Thu) by khim (subscriber, #9252) [Link] 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)...
RMS ? Posted Dec 9, 2007 2:31 UTC (Sun) by vonbrand (subscriber, #4458) [Link] 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.
vonbrand? Posted Dec 16, 2007 12:28 UTC (Sun) by man_ls (subscriber, #15091) [Link] No, "RMS did start it all" is just vonbrand's own revision of Stallman's account of history. He writes: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 Posted Dec 6, 2007 15:18 UTC (Thu) by cruff (subscriber, #7201) [Link] 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? Posted Dec 7, 2007 13:24 UTC (Fri) by DRBaldock (subscriber, #30881) [Link] 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 Posted Dec 7, 2007 16:53 UTC (Fri) by zooko (subscriber, #2589) [Link] 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 Posted Dec 13, 2007 10:37 UTC (Thu) by RobLucid (guest, #49530) [Link] 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 Posted Dec 14, 2007 0:52 UTC (Fri) by pm101 (guest, #3011) [Link] 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.
|
|||||||||||||
![[emacs with bitmapped font]](/images/ns/grumpy/emacs-bitmap.png)
![[emacs with Deja Vu font]](/images/ns/grumpy/emacs-dejavu.png)
