I was worried about updates modifying config files; when it notices you modified a stock config file, though, at the update it allows you to stick with the old file, go with the new file, view the diffs between the two, and... a fourth option that I forget just now... for each file.
The fourth option would be dropping into a shell to get a better look.
Either replacing or not replacing the config file is pretty safe, though, because dpkg keeps the other version (the one you didn't install) around. See filename.dpkg-old or filename.dpkg-new . So you can easily merge in changes by hand, if you wish.
Whoever wrote dselect had no clue. apt and dpkg didn't exist.
dpkg was written before dselect.
Yeah, that bit of his post puzzled me as well. Is the guy trying to say that, as of a few years ago...
the 'dpkg' command-line interface was in any way worse than the 'rpm' command-line interface?
Red Hat had any tool at all that did the same job as dselect?
That second point is the pertinent one, for me. Many people have complained about the dselect UI over the years, but AFAIK, until a few years ago there was no way to do the same thing on any RPM-based distro. (Rather a strong statement, so I'm probably wrong, which goes to show that I don't use RPM-based distros.) From what I understand, back in the Red Hat 3.0 days, the only way to install and remove RPMs from your system was one at a time from the command line. dselect not only presents a menu of all packages, lets you browse package descriptions (and other maintenance fields), search for keywords, sort out all your dependency issues before starting an install run, etc. And the auto ftp download bit has been around for many many years. In short, most of the features for which APT is seen as so sexy these days -- were in dselect four years ago.
I guess rpmfind.net was considered a valid workaround for this fundamental tool lack. I never tried it so I can't say whether rpmfind or dselect had the more- or less-usable interface. (I've always found dselect quite usable, if quirky and unintuitive at first.)
Complaining about the poor UI of dselect when all you have is command-line RPM is rather like complaining about the poor UI of someone's web browser when your platform of choice only has a command-line FTP client.
Swap out the Xpert128 for a PCI All-In-Wonder Radeon, add a nice audio card like the Turtle Beach Santa Cruz, and I'm good to go. I figure it will cost me less than $400 all told.
That includes all software? You're using Windows 2000 - how much did you pay for that? And the various playback functions and formats, plus the UI to tie them all together into a coherent package - did you find all that for a reasonable price (or for free) or are you writing them yourself?
Keep in mind that even when you can download some components for free (realplayer, quicktime, etc), you won't be allowed to redistribute them for free. If you are claiming that you could "build a ZapStation for a lot less" you have to remember the licensing fees for whatever you didn't write yourself.
(Likely this is why they went with Linux, not for "geek brownie points". They still had to license some things like the Windows Media codec.)
OTOH, I'm not convinced that doing all of that would be particularly beneficial.
Well, there is one benefit: the Debian people would be able to take the same approach as the Debian GNU/FreeBSD people (yes there does exist such a port in development - though I don't know whether it's being actively worked on). That is, they port the base system libraries and kernel-related stuff, get dpkg and other basic Debian stuff working smoothly, and use the Linux compatibility layer for everything else. Thus, 95% of Debian doesn't need to be recompiled for FreeBSD.
For the most part, though, I agree with you: there is, in general, not a lot of use for Linux binary compatibility in Windows.
I didn't say "compile once, run anywhere", I said "write once, run anywhere". Yes, running linux apps might require a recompile
Pardon my confusion, then. Since you used Java as an example (including Sun's tag-line), I (mis)assumed that you were talking about binary compatibility.
I'm not talking about binary emulation. That would be silly since the underlying platform is the same.
Thinking about it some more, I'm not so sure it is silly. To get 90% of the way, all you really need is
Cygwin glibc support that supports most Unix syscalls with approximately the same semantics as they have in Linux - I figure glibc is most of the way there already. Note that these don't have to map 1-to-1 to win32 syscalls, they just need to work. Very few apps use syscalls "directly", they almost all go through the libc wrapper functions.
a Windows app that loads and executes ELF programs - I'm not sure how hard this is
dynamic linker support for ELF libraries. This could be part of the ELF-exe-loader app, or it could be integrated into glibc like it is on Linux
libdl dynamic library loading support - would probably be combined with the above
Note that XFree86 v4 has some whiz-bang technology to load multiple types of object files as server modules. They made a big deal out of being able to use a driver module for your X server in OS/2, FreeBSD, Linux, etc. without recompiling. (I didn't and don't see the point of this, except to benefit 3rd-party closed-source driver writers, but whatever.) I don't think this system supports Win32 (I believe), but it's the same concept.
I can't see any info about AES being adopted in the PGP framework. Anyone knows how this work is progressing?
You still use crypto software you have to pay for? [Yes, this was a joke, maybe you only use crypto "for personal use".]
GnuPG, on the other hand, developed AES capability less than 2 days after NIST originally approved Rijndael last year. The next public release wasn't for a week or two, but still.... (Well, NIST officially "approved" it just now, but they "recommended it for approval" just over a year ago.) I remember seeing a message from the GnuPG development list about an hour after the NIST announcement saying "I'm working on it."
GnuPG is similar to the command-line version of PGP and supports the same file formats / protocols, but is free for all uses and isn't affiliated with Phil Zimmerman or Computer Associates. I don't know if it has the same depth of plugin support for third-party apps, but hey, it's supported by all the Linux apps I need it for.
> Will I have to pay royalties if I intend to write AES-compliant programs then sell related services ?
Probably not.
Definitely not. This was an important consideration for defining the standard. NIST only accepted unencumbered submissions - meaning:
no patent restrictions
no restrictions the sample code provided (every submission had to come with working C code, IIRC).
So - not only can you use the algorithm, you can even use their implementation, no questions asked. They actually released two implementations, a "basic" and an "optimised" one. I don't remember whether having two versions was a NIST requirement.
One of the analysts (cant remember who) said that no matter who got choosen (from round 2) they would all be a excellent AES, but Rijndael would be the bold choice based on its pure/simple matematical base.
Bruce Schneier, author/submitter of Twofish (which made the top 5), cryptanalysed the top 5 and said that they all looked fine to him - though obviously he was biased toward Twofish.
It sounds like nobody really had any objections to Rijndael, or to one or two of the others, so the final selection truly was "best of breed" rather than "least worst".
For the 2.6 series to support "direct neural interfaces", much of the work will have to be done now, as 2.6x will be a "stable" version of 2.5x (which has just started.) So start coding now.
Ummm, I believe Linux already supports every direct neural interface on the market today. Of course, so do all the other OSes. (:
However, GUIs with $$$-driven appearances such as Apple's Aqua, Microsoft's Luna, Netscape's Mozilla Modern, and many X11 WM themes use bitmaps to store the rounded corners and shiny things that make the system not look butt-Motif ugly.
Not at the high levels of abstraction - the raster images are buried in the low levels and, as such, could be replaced with smarter "magnify-friendly" code without disrupting the high levels. In this case "low level" means Gtk+ and Xlib, and you may need some support from theme authors.
Certain things are raster even at the high levels - icon bitmaps are the notable example. But even icons can be vector-based - SGI did it years ago. For icons, though, it's probably easier to use the CDE solution of providing multiple sizes (an icon "file" in CDE is actually up to 4 distinct XPM files 48, 32, 24 and 16 pixels high) and optionally scale these as needed.
Also, new driver support for old versions of Windows will eventually be dropped, so users will also switch because it's free.
Or vice versa - old hardware support dropped in new versions of Windows. Granted, most hardware is probably fine, but try using a 3Com 3C590 network card in Windows 2000. I couldn't find a driver for love or money. Had to swap in a Realtek or something.
[If it had been my choice, I would have swapped in Linux instead (with its venerable 3c59x driver covering over 30 card models from EISA to PCMCIA CardBus), but anyway.....]
The server? Or the client libs? The X client libraries have been available for Windows for some time, but nobody seems to use them because nobody runs X servers on Windows except to talk to Unix boxes.
(Not quite true - today I installed Madymo, a crash test simulator app, on someone's box. It "requires Exceed", which is to say it is a direct port from the Unix version, complete with X11. At one point we didn't have Exceed running, so I set the DISPLAY variable to a nearby Unix box to verify that Madymo itself was working. Which it was. <g>)
Cygwin can be quite slow at times, especially if X is being used.
I wouldn't know about using X under cygwin, as I've never done it, but I've definitely noticed the speed difference! When emulating an API, there's a tradeoff between correctness and speed. Cygwin strives for 100% correctness, which means in many cases they can't just put a trivial wrapper around a win32 function, because the error return values are all different, etc.
XEmacs under Windows 2000 is painfully slow. I don't know why, specifically - I haven't profiled it or anything. (And no, it's not using an X11 client/server, it is using the win32 widgets directly.) I installed it on a quest for a usable IDE for MSVC work, but with the several-second keystroke lag of XEmacs at times, it's actually less painful to just use the VC++ IDE itself! (Coming from me, that means something.)
Wouldn't it be great to have compiled software that you can write once and run anywhere?
Debian != Linux. Newsflash for all you/.ers. This article is about porting the Debian user space tools to Windows, or to the win32 runtime environment to be precise. That doesn't mean you can run a Linux binary on Windows - it means you can run a Linux shell script on Windows, because the programs the shell script tries to call will be there and will behave as expected.
Linux binary emulation on Windows (with or without Cygwin) would be a major undertaking. Well... maybe not that major, depending on the completeness of the Cygwin libc implementation, and assuming the program doesn't try certain "verboten" things like doing its own syscalls without going through libc. But it's still a very different thing than what the Debian/w32 people are attempting.
WEll I've NEVER had any problems with it, but that's just me and my personal experience.
The main problems with the current code base are not user-visible - basically it is hard to maintain because of cruft, a difficult built process, wrong levels of abstraction, etc. That does not necessarily mean that the finished product will be buggy or quirky - just that the developers have to work much harder to insure that it is not.
The fact that you've never had problems suggests that the developers do in fact work hard.
Can someone PLEASE explain to me why the Debian people don't just take the Mandrake, or SuSE, or Red Hat installers and modify it to install Debian?
I have never installed Mandrake, but from what I hear, it's rather inflexible. They went and made it easy-to-perform basically the same way Microsoft did with Windows 2000 - by not offering you as many choices. The standard Win2000 install, unlike the NT4 one, doesn't ask if you want or need the Accessibility Options. Why not? I don't know, honestly I don't, but I suppose it does make the inst process "simpler" and "quicker". (I know, there are ways around this in win2k, that's not my point.)
I could be talking out my south end, but I think that's why the Debian people think they can do better. With Debian I feel like I have the freedom to configure my system any way I want - on most of my boxes, that means "without an X server". There are only a few packages that I ever need to uninstall after the initial bootstrap - emacs20, ae, and tetex spring to mind. From what I've heard, mdk puts a bunch of stuff on there you may or may not ever need.
The one major feature I'm missing from the current Debian installer is a record/playback mechanism for automated installs. Some other Linux distros can do this, I understand, and I think it's in the works for the Debian installer rewrite.
Doing the "change the sources file, then upgrade" thing is a surefire way to wind up with an assload of broken dependencies on a system.
That's because woody is not "released" yet - the QA related to making sure there are no upgrade issues like broken dependencies hasn't really been done yet.
A better way to do it is [...]
Probably true, for now. The middle step, forcing it to install a couple of key packages before anything else, is not hard to do and could easily be documented in release notes, even if the Debian people don't figure out a way to make it unnecessary in the final release.
(And, of course, the first step, "change/etc/apt/sources.list", will also be unnecessary once woody is released, assuming you use the default sources.list, with the release path "stable" rather than "potato".)
You have to admit, it's still a lot easier than "make notes or backups of all local configuration, install your new OS version from scratch, reconfigure everything" which used to be the only way to upgrade e.g. Red Hat. I don't know if recent releases are better about letting you do an incremental upgrade to a whole new release or not. Presumably they are - otherwise how could all the other players hope to compete with Debian?
Glad I don't live in the real world. My work commute is around 4.5 miles, takes me 20-30 minutes depending on whether I feel like tiring myself out. So, 9 MPH is leisurely for me. That's on a $450 bicycle.
So it could work. Of course you can get yourself a dang fine BIKE for thousands less, and its not much slower.
Indeed, not any slower. And it's the only exercise I get on any sort of regular basis, so that's a pro, not a con.
Re:Target market: college students
on
This is IT?
·
· Score: 2
Well, I
have a 10 minute walk from my dorm to my classrooms every day, and while I'm an avid biker, it isn't
always practical to haul out my 25-lb. mountain bike to dart to and from class.
Ummmm... so instead you will haul out your 40-lb. Ginger scooter? Note: I don't know how much it will eventually weigh, but the gyroscopes needed to keep a body from falling over (not to mention the lead-acid batteries!) have to weigh something.
So, in class, where will you put this thing? Lock it to the bike rack? Carry (excuse me, "lug") it with you?
Sorry, I just don't see this being more practical than a bike, except that it uses less human energy for the actual locomotion.
Re:Can we think of a good reason for this?
on
This is IT?
·
· Score: 2
It can last all day on a charge I believe, as they said a full day of use would only cost 5 cents of electricity.
That doesn't follow, you know. All that tells us is that it uses half a kilowatt-hour or so (depends on where they're buying the juice; presumably they cited this from the cheapest power market they could find) for a "full day's use", whatever that means. (And don't trust this number any more than you trust Detroit about their gas mileages.)
For all we know it may need to be recharged every couple of miles. Which would suck, but they never told us otherwise, right?
In other words, we'll see a graphical Debian installer around 2010 or so?
Yeah, they do have long release cycles, but why exactly do you want a graphical installer anyway?
I've never quite understood this point. Bringing up the GUI early in the install process adds a bunch of complexity and failure cases, and to my mind anyway, doesn't really add any functionality.
What features of an installer do you have in mind that can be accomplished within a GUI but not with a text-based UI? And don't say "to impress people who confuse pretty with advanced" - why the **** should we care about their opinions?
One thing might be "to fit a reasonable amount of information on one screen" - which is why I boot with "vga=1" meaning 80x50 cells, and I think this should be made the default on boot-floppies, although I understand why it isn't (it would screw over those.001% of users that don't have VGA-compatible video cards or BIOSes).
This is like those BIOS setup screens that come with icon boxes, scroll bars and PS/2 mouse support. Does anyone find them easier to use than the venerable text-based BIOS setup screens? I don't. I find them confusing. Easy-to-use does not imply graphical, or vice versa.
I'd also like to setup on my mail server a check where if the reply-to address != the from address, deny the message at the server.
Don't do this! There are many legitimate uses for Reply-To. Think about it. If Reply-To should always be the same as From, why did the standards even bother to define it?
Most commonly, some mailing lists set the Reply-To to the list address. This is Considered Harmful, partly because some users have other legit uses for the same field, but some list servers do it anyway.
Slashdot Mirror
The fourth option would be dropping into a shell to get a better look.
Either replacing or not replacing the config file is pretty safe, though, because dpkg keeps the other version (the one you didn't install) around. See filename.dpkg-old or filename.dpkg-new . So you can easily merge in changes by hand, if you wish.
Yeah, that bit of his post puzzled me as well. Is the guy trying to say that, as of a few years ago...
That second point is the pertinent one, for me. Many people have complained about the dselect UI over the years, but AFAIK, until a few years ago there was no way to do the same thing on any RPM-based distro. (Rather a strong statement, so I'm probably wrong, which goes to show that I don't use RPM-based distros.) From what I understand, back in the Red Hat 3.0 days, the only way to install and remove RPMs from your system was one at a time from the command line. dselect not only presents a menu of all packages, lets you browse package descriptions (and other maintenance fields), search for keywords, sort out all your dependency issues before starting an install run, etc. And the auto ftp download bit has been around for many many years. In short, most of the features for which APT is seen as so sexy these days -- were in dselect four years ago.
I guess rpmfind.net was considered a valid workaround for this fundamental tool lack. I never tried it so I can't say whether rpmfind or dselect had the more- or less-usable interface. (I've always found dselect quite usable, if quirky and unintuitive at first.)
Complaining about the poor UI of dselect when all you have is command-line RPM is rather like complaining about the poor UI of someone's web browser when your platform of choice only has a command-line FTP client.
I believe that RPM packages always have md5 checksums on all the files, whereas .deb packages, by default, do not.
That's probably what you heard.
That includes all software? You're using Windows 2000 - how much did you pay for that? And the various playback functions and formats, plus the UI to tie them all together into a coherent package - did you find all that for a reasonable price (or for free) or are you writing them yourself?
Keep in mind that even when you can download some components for free (realplayer, quicktime, etc), you won't be allowed to redistribute them for free. If you are claiming that you could "build a ZapStation for a lot less" you have to remember the licensing fees for whatever you didn't write yourself.
(Likely this is why they went with Linux, not for "geek brownie points". They still had to license some things like the Windows Media codec.)
Well, there is one benefit: the Debian people would be able to take the same approach as the Debian GNU/FreeBSD people (yes there does exist such a port in development - though I don't know whether it's being actively worked on). That is, they port the base system libraries and kernel-related stuff, get dpkg and other basic Debian stuff working smoothly, and use the Linux compatibility layer for everything else. Thus, 95% of Debian doesn't need to be recompiled for FreeBSD.
For the most part, though, I agree with you: there is, in general, not a lot of use for Linux binary compatibility in Windows.
Pardon my confusion, then. Since you used Java as an example (including Sun's tag-line), I (mis)assumed that you were talking about binary compatibility.
Thinking about it some more, I'm not so sure it is silly. To get 90% of the way, all you really need is
Note that XFree86 v4 has some whiz-bang technology to load multiple types of object files as server modules. They made a big deal out of being able to use a driver module for your X server in OS/2, FreeBSD, Linux, etc. without recompiling. (I didn't and don't see the point of this, except to benefit 3rd-party closed-source driver writers, but whatever.) I don't think this system supports Win32 (I believe), but it's the same concept.
You still use crypto software you have to pay for? [Yes, this was a joke, maybe you only use crypto "for personal use".]
GnuPG, on the other hand, developed AES capability less than 2 days after NIST originally approved Rijndael last year. The next public release wasn't for a week or two, but still.... (Well, NIST officially "approved" it just now, but they "recommended it for approval" just over a year ago.) I remember seeing a message from the GnuPG development list about an hour after the NIST announcement saying "I'm working on it."
GnuPG is similar to the command-line version of PGP and supports the same file formats / protocols, but is free for all uses and isn't affiliated with Phil Zimmerman or Computer Associates. I don't know if it has the same depth of plugin support for third-party apps, but hey, it's supported by all the Linux apps I need it for.
Definitely not. This was an important consideration for defining the standard. NIST only accepted unencumbered submissions - meaning:
So - not only can you use the algorithm, you can even use their implementation, no questions asked. They actually released two implementations, a "basic" and an "optimised" one. I don't remember whether having two versions was a NIST requirement.
Bruce Schneier, author/submitter of Twofish (which made the top 5), cryptanalysed the top 5 and said that they all looked fine to him - though obviously he was biased toward Twofish.
It sounds like nobody really had any objections to Rijndael, or to one or two of the others, so the final selection truly was "best of breed" rather than "least worst".
Ummm, I believe Linux already supports every direct neural interface on the market today. Of course, so do all the other OSes. (:
Not at the high levels of abstraction - the raster images are buried in the low levels and, as such, could be replaced with smarter "magnify-friendly" code without disrupting the high levels. In this case "low level" means Gtk+ and Xlib, and you may need some support from theme authors.
Certain things are raster even at the high levels - icon bitmaps are the notable example. But even icons can be vector-based - SGI did it years ago. For icons, though, it's probably easier to use the CDE solution of providing multiple sizes (an icon "file" in CDE is actually up to 4 distinct XPM files 48, 32, 24 and 16 pixels high) and optionally scale these as needed.
Score:-1, Offtopic
Or vice versa - old hardware support dropped in new versions of Windows. Granted, most hardware is probably fine, but try using a 3Com 3C590 network card in Windows 2000. I couldn't find a driver for love or money. Had to swap in a Realtek or something.
[If it had been my choice, I would have swapped in Linux instead (with its venerable 3c59x driver covering over 30 card models from EISA to PCMCIA CardBus), but anyway.....]
The server? Or the client libs? The X client libraries have been available for Windows for some time, but nobody seems to use them because nobody runs X servers on Windows except to talk to Unix boxes.
(Not quite true - today I installed Madymo, a crash test simulator app, on someone's box. It "requires Exceed", which is to say it is a direct port from the Unix version, complete with X11. At one point we didn't have Exceed running, so I set the DISPLAY variable to a nearby Unix box to verify that Madymo itself was working. Which it was. <g>)
I wouldn't know about using X under cygwin, as I've never done it, but I've definitely noticed the speed difference! When emulating an API, there's a tradeoff between correctness and speed. Cygwin strives for 100% correctness, which means in many cases they can't just put a trivial wrapper around a win32 function, because the error return values are all different, etc.
XEmacs under Windows 2000 is painfully slow. I don't know why, specifically - I haven't profiled it or anything. (And no, it's not using an X11 client/server, it is using the win32 widgets directly.) I installed it on a quest for a usable IDE for MSVC work, but with the several-second keystroke lag of XEmacs at times, it's actually less painful to just use the VC++ IDE itself! (Coming from me, that means something.)
Debian != Linux. Newsflash for all you /.ers. This article is about porting the Debian user space tools to Windows, or to the win32 runtime environment to be precise. That doesn't mean you can run a Linux binary on Windows - it means you can run a Linux shell script on Windows, because the programs the shell script tries to call will be there and will behave as expected.
Linux binary emulation on Windows (with or without Cygwin) would be a major undertaking. Well ... maybe not that major, depending on the completeness of the Cygwin libc implementation, and assuming the program doesn't try certain "verboten" things like doing its own syscalls without going through libc. But it's still a very different thing than what the Debian/w32 people are attempting.
The main problems with the current code base are not user-visible - basically it is hard to maintain because of cruft, a difficult built process, wrong levels of abstraction, etc. That does not necessarily mean that the finished product will be buggy or quirky - just that the developers have to work much harder to insure that it is not.
The fact that you've never had problems suggests that the developers do in fact work hard.
I have never installed Mandrake, but from what I hear, it's rather inflexible. They went and made it easy-to-perform basically the same way Microsoft did with Windows 2000 - by not offering you as many choices. The standard Win2000 install, unlike the NT4 one, doesn't ask if you want or need the Accessibility Options. Why not? I don't know, honestly I don't, but I suppose it does make the inst process "simpler" and "quicker". (I know, there are ways around this in win2k, that's not my point.)
I could be talking out my south end, but I think that's why the Debian people think they can do better. With Debian I feel like I have the freedom to configure my system any way I want - on most of my boxes, that means "without an X server". There are only a few packages that I ever need to uninstall after the initial bootstrap - emacs20, ae, and tetex spring to mind. From what I've heard, mdk puts a bunch of stuff on there you may or may not ever need.
The one major feature I'm missing from the current Debian installer is a record/playback mechanism for automated installs. Some other Linux distros can do this, I understand, and I think it's in the works for the Debian installer rewrite.
That's because woody is not "released" yet - the QA related to making sure there are no upgrade issues like broken dependencies hasn't really been done yet.
Probably true, for now. The middle step, forcing it to install a couple of key packages before anything else, is not hard to do and could easily be documented in release notes, even if the Debian people don't figure out a way to make it unnecessary in the final release.
(And, of course, the first step, "change /etc/apt/sources.list", will also be unnecessary once woody is released, assuming you use the default sources.list, with the release path "stable" rather than "potato".)
You have to admit, it's still a lot easier than "make notes or backups of all local configuration, install your new OS version from scratch, reconfigure everything" which used to be the only way to upgrade e.g. Red Hat. I don't know if recent releases are better about letting you do an incremental upgrade to a whole new release or not. Presumably they are - otherwise how could all the other players hope to compete with Debian?
No, that would be grammar checkers. Cant is a valid word, although nobody ever seems to use it.
Glad I don't live in the real world. My work commute is around 4.5 miles, takes me 20-30 minutes depending on whether I feel like tiring myself out. So, 9 MPH is leisurely for me. That's on a $450 bicycle.
Indeed, not any slower. And it's the only exercise I get on any sort of regular basis, so that's a pro, not a con.
Ummmm ... so instead you will haul out your 40-lb. Ginger scooter? Note: I don't know how much it will eventually weigh, but the gyroscopes needed to keep a body from falling over (not to mention the lead-acid batteries!) have to weigh something.
So, in class, where will you put this thing? Lock it to the bike rack? Carry (excuse me, "lug") it with you?
Sorry, I just don't see this being more practical than a bike, except that it uses less human energy for the actual locomotion.
That doesn't follow, you know. All that tells us is that it uses half a kilowatt-hour or so (depends on where they're buying the juice; presumably they cited this from the cheapest power market they could find) for a "full day's use", whatever that means. (And don't trust this number any more than you trust Detroit about their gas mileages.)
For all we know it may need to be recharged every couple of miles. Which would suck, but they never told us otherwise, right?
I don't understand it either ... and yet ... it does in fact look gay.
(:
Yeah, they do have long release cycles, but why exactly do you want a graphical installer anyway?
I've never quite understood this point. Bringing up the GUI early in the install process adds a bunch of complexity and failure cases, and to my mind anyway, doesn't really add any functionality.
What features of an installer do you have in mind that can be accomplished within a GUI but not with a text-based UI? And don't say "to impress people who confuse pretty with advanced" - why the **** should we care about their opinions?
One thing might be "to fit a reasonable amount of information on one screen" - which is why I boot with "vga=1" meaning 80x50 cells, and I think this should be made the default on boot-floppies, although I understand why it isn't (it would screw over those .001% of users that don't have VGA-compatible video cards or BIOSes).
This is like those BIOS setup screens that come with icon boxes, scroll bars and PS/2 mouse support. Does anyone find them easier to use than the venerable text-based BIOS setup screens? I don't. I find them confusing. Easy-to-use does not imply graphical, or vice versa.
Don't do this! There are many legitimate uses for Reply-To. Think about it. If Reply-To should always be the same as From, why did the standards even bother to define it?
Most commonly, some mailing lists set the Reply-To to the list address. This is Considered Harmful, partly because some users have other legit uses for the same field, but some list servers do it anyway.