Someone mentioned above that Oracle's groupware suite is among the best options for large installations -- perhaps something to consider. I understand that they have "Oracle Calendar Sync" available for PDA integration. Can't comment about their webmail.
BTW, I'm not recommending it by any means, but OpenGroupware supports drag-and-drop in the webmail client.
That used to be the case. Copyright infringement is now a crime even if it's done with the expectation of receiving not cash or equivalents but anything of value, explicitly including copies of other copyrighted works.
Whether copyright infringement is a criminal offense or not (and, IIRC, it has recently become one), it certainly isn't dangerous to human life, and consequently is beyond the circumstances in which proponents of the USAPATRIOT act claimed it would apply. Remember, the claim was that terrorist behaviour would be defined to only include behaviour which violates the law and is dangerous to human life, not violates the law or is dangerous to human life.
Civil disobedience my nutsack, this was done for profits.
So? Does the intent make a good gesture bad?
Humans, yes, it is unkind; corporations, no, they're not people and do not have feelings. If you for a second believe that a corporation has done or will do ANYTHING to benefit you, you have become a tool for that amount of time.
See, there's this concept called "enlightened self-interest". Please look it up.
Much easier to be anti-corporate if you forget they're made of people, isn't it?
Harm the corporation and you're harming its stockholders, its employees -- harm it bad enough and you're harming its customers as well. Perhaps those stockholders include a mutual fund holding peoples' retirement money; certainly, they'll include a bunch of geeks who worked for years in startup conditions in the hopes that maybe they, too, could own their own home and start their own businesses.
I'm not arguing that corporations should be treated as sacred or upheld when they do wrong. Rather, I take the position that harming a corporate entity without just cause is as morally bankrupt as harming another individual, as such harm *does* affect individuals -- albiet being spread over a number of them, making it harder to see the individual impact.
I don't want Real to get hurt -- that serves no purpose. I just want the DMCA weakened or repealed. If damage done to Real helps to bring that about, well and good! -- but otherwise, it's quite unkind to wish for another to be harmed.
As far as I'm concerned, far from a big mistake, Real did the right thing; think of it as civil disobediance on a corporate scale. Let's just hope some good comes of it.
Go ahead and create you own, say, Debian- or Gentoo-based distro with them. See how much you can run. Report back...
Nope. Don't have the time. Just because compatibility is good enough doesn't mean software written against glibc (not POSIX, mind you, glibc) will run out-of-the-box unmodified. I spent a few years of my life on about a 4-person team (all the heavy resources were devoted to kernelspace work) building a linux distro for embedded development that needed to run under almost every architecture Linux supported at the time. There was nothing hard about it, just time-consuming -- but it got done. That's the scale I'm talking about when I say "good enough" -- sure, it may need a commercial backer to have enough of a need for it to happen to pay some people full-time for a while, but if enough utility can be demonstrated then that will come. (BTW, *one* reason they aren't everywhere is that one of them [don't recall which] is licensed under the GPL, not the LGPL, restricting its applicability quite substantially. I don't recall if this is the one with the better application compatibility).
Why, again, hasn't the HURD been kicked out the door with POSIX support only?
I just told you. Is this a rhetoric question or are you just being tiresome?
No, you told me why having more than just POSIX support for the HURD is considered a Good Thing -- rather a different thing than why it hasn't been kicked out the door without it. There's a practice out in the Real World calling trimming requirements to meet a production schedule. Sometimes being able to ignore that practice is a benefit for Free Software. Sometimes it isn't.
In any event, I don't think we're likely to come to any agreement (and am finding the conversation to get a bit boring myself), so I propose to end this thread here (or, if you prefer, after your reply). As you'll notice, I left a few subthreads unanswered -- consider the points ceded.
It is a common mistake to think you have something faster just because you haven't yet designed in all you'll eventually need or want.
But it's also a mistake to think that all you'll eventually need or want needs to be designed in right now. It's also a mistake to put things at a more deeper layer than they need to be.
Sure the GNU libc is huge. But that's POSIX, and that's where the Hurd will bridge us from.
Funny, I'm pretty darned sure I've seen smallerimplementations. Certainly, application compatibility for them isn't perfect -- but it's certainly Good Enough.
You yourself point out that the quick-and-dirty but real solution is often the one that wins in the market. Why, again, hasn't the HURD been kicked out the door with POSIX support only?
How is it saner? Because it's less ambitious -- and the amount of time it's taken for the HURD to become release-ready demonstrates its overambition.
How is it less ambitious? Weren't you the one talking a while about all the Nifty Features that the HURD has and is working on that the other microkernel-based OSes don't have?
Won't that make it less useful? Not necessarily. Almost all the really important things for an OS to do can be done with nothing more than proper application of the simple abstractions provided by VSTa and its libc (and accompanying libraries, since support for building servers has been split off from the libc proper). Sure, actually applying those abstractions may be left as an exercise for the reader -- but that's a fair sight better than waiting for a development team to say "come and get it!" for decades on end.
In general, a microkernel can get away with having only a minimum of functionality -- and, for that matter, should do so to the maximum extent possible (and no more). After all -- what does it need to do? The entire job of a microkernel boils down to message passing, task switching and memory allocation -- simple jobs that should be done in a minimal amount of tight, well-written, scalable code. Also included in the job of writing a microkernel-based OS is building a sane libc and userland interface for writing servers and doing namespace handling. Everything after (graphics, networking, device drivers, etc etc etc) is just writing userspace code, and the world is full of people who do that. VSTa is near the point where all it needs is servers to be written -- where the kernel+libc&friends layer is finished and stable and small and performant and all that's left is getting the servers written to provide interfaces to more hardware. The HURD, by contrast, has a lot more features being stuffed into the libc+friends -- hence massive changes to glibc -- so it takes much longer to get to the point where the reader is invited to do their thing.
Worse, depending on a heavyweight libc means that you can't scale down as easily without having a lightweight one also available -- and writing a light libc for a microkernel (where much more functionality is implemented inside that layer) is a much harder thing than implementing the many cut-down libcs that are available for Linux. On the other hand, adding more functionality for a microkernel OS with a light libc and well-written core is easy -- because that functionality can all be written in userspace, in servers that the folks who don't need the functionality can choose not to run. It means you need to have some dicipline in keeping features out of your libc, but the long-run return is well worth it.
(Funny you mention the HURD as a replacement for Linux, since it's the longer-running project of the two).
VSTa networks right now. X will be available after the Linux framebuffer code is written into a VSTa server -- I'm told by one of the developers (who, back at MontaVista, spent much of his time writing Linux framebuffer code) that it should be a very quick task.
That's just a matter of writing servers for more hardware, though -- nothing that requires changes to the kernel itself. The HURD may be further along, but look how many man-hours were required to get it there! By being a smaller, lighter, less ambitious, saner design, VSTa can make up for the time it lost as Andy Valencia's personal project. (And speaking of Andy -- he did a proprietary MIPS port for Cisco back when he was sole copyright holder and was quite well compensated for it, which would seem to imply that that it's found use as more than a toy).
Part of my point earlier is that a kernel that fills one niche well will have people working hard to apply it to others -- see Linux being used in embedded space, even though that's far from its native environment.
VSTa, given currently planned development (completion of POSIX compatibility, a port of the Linux framebuffer drivers, etc), will be able to be used as a desktop OS. Will it be "designed with the same ultimate goals as the HURD"? Absolutely not. Will it be good enough, and (more likely to be) finished in a sane amount of time? Yes.
Given the choice between good-enough and on-time versus theoretically perfect and never-quite-finished, good-enough wins.
Now if QNX or whatever was free software and had a roadmap to take on Linux and Hurd goals, that would be very interesting... only that they would face the same problem as the Hurd, to wit lack of critical mass.
Ahh -- but for a leaner project, it takes less to go critical. I think The HURD's overambition is part of why it hasn't.
Fill a niche, do it well, grow from there. I have high hopes for VSTa.
And why shouldn't a kernel be generic enough to function in a desktop environment as well as a deeply embedded one?
Sure, things like POSIX support are needed in the former (and, as I mentioned, adding and enhancing it is an ongoing process for VSTa) -- but for a microkernel, these can all be userland changes, and quite confined ones at that. Quite a few folks in the embedded field have seen fit to go out of their way to use a kernel that's frankly unfit for what they're trying to do for the explicit purpose of being able to share development between that embedded environment and the rest of the world. Given an opportunity to make a kernel that's unfit neither in embedded space or the rest of the world, why ruin it with bloat -- particularly when that bloat, while it may be in the name of "easier development", brings it further from the very image of simplicity that a microkernel OS has the ability to be?
VSTa hasn't traditionally aimed for full POSIX compatibility, but now that Andy Valencia is no longer effectively in charge of development, that's changing. As for Linux fitting on floppies if trimmed -- my previous job was at an embedded Linux company which employs primarily kernel hackers on its engineering team; I learned a thing or two while there about exactly why a cut-down Linux kernel *isn't* as well-suited to particularly small embedded environments as QNX, VSTa or their kin. (That said, I'll stipulate that my knowledge of the HURD itself is a bit sketchy).
I'll take a kernel that's small and easy to hack on over one which has been bloated to add extra layers of infrastructure in order to implement some "level of development flexibility" any day.
Too complex, certainly. Time for microkernels? If there were a good one with servers for all the relevant hardware ready? Sure! The HURD? HELL, NO!
Compared to its peers (QNX, VSTa), the HURD is tremendously bloated and slow. Its development involved massive (and performance-reducing) changes to its libc (which have had negative impacts on *other* OSes that use that same libc). Compare to QNX, which runs on tiny embedded devices and which has a demo disk available with massive hardware support and a full web browser all fitting on a single floppy, or to VSTa, which last I heard fit the kernel into 28K (and shrinking) and outperforms some popular macrokernels.
Microkernels are a great idea -- I absolutely look forward to writing and debugging filesystem code and hardware drivers with my usual userland tools. But the HURD? I'll keep my macrokernel, thank you.
Hrm? The HURD sucks as much as any; it's one of the easy examples to use when arguing (wrongly) that microkernels are slow and inefficient exercises suitable only to academia. (And do I know you?)
See Plan 9, or QNX, or VSTa (still a toy for most purposes -- but very small and fast, and generally considered quite promising by a group of kernel developers I happen to know, a group which includes some folks who are considering building it into an OS suitable for real-life deeply embedded work).
So? Yes, the growth medium is humans motivated by challenge, or maliciousness, or *whatever* -- but if you take it as a given that somesuch growth medium exists, computer virii behave in several biological ways.
They combine their "genes" as folks splice the new, most effective payloads and mechanisms together; they mutate whenever someone comes up with a new and previously nonexistant technique... etc.
In short -- just because they're made by folks whom society would, generally speaking, be better without doesn't mean that they can't have biological charactristics.
(That said, I'd hesitate to call the folks who made this one "sadistic" -- not only is there no harmful payload, they *ASK THE USER* if it's allowed to spread!)
You missed one: Leaving whichever high-expense metropolitan area you happen to live in, and finding a job elsewhere.
The.ca.us bay area, the big cities in the eastern US -- the living expenses there are considered completely ridiculous by everyone else.
I'm right now living in Austin, widely considered the most expensive part of Texas, and looking to buy a reasonably nice house. Prices are in the $120-130K area (3-4 bedroom, big kitchen, that sort of thing; one someone got before my mortgage was approved had a pool, a hot tub, a professionally landscaped yard, and a vast number of other goodies). These are *in town* (or max 15 minutes out) prices. And there are tech jobs here, albiet we're still recovering from the bust.
The thread so far has been not about "open source" equivalents, but rather "runs on Linux" equivalents -- not at all the same thing.
Just to pick one of your examples: Photoshop runs on Linux (officially supported via Crossover Office), and does so because some big companies paid a lot of money to make it that way.
I can't speak for GNOME, but KDE has a central registry of URL handlers. The downside to implementing it at this layer, of course, is that it isn't usable (or, at least, used in practice) by non-KDE apps.
(Incidentally, I use neither GNOME nor KDE -- I find that ion, while less than newbie-friendly, lets me work most efficiently).
I think you misspelt it, it's actually spelt VI:-)
Heh. I actually use vim myself (have a window open right now with some code I'm working on), but it's a bit much to try to push on a Windows user -- and some of the bloat^Wfeatures available to Emacs really can come in handy on occasion, or at least sound like they can to folks brought up on "more features => better". (Are there extensions to vi* available to match each of the items I mentioned in the parent -- in-editor debugging (where one frame follows the location in the source which the debugger, in another frame, is currently at), class browsing, comments-only spellchecking, and so forth) presently available?
Hrm? Just because you have your own set of ethics (which may include helping yourself to my beer) doesn't mean that my own ethics need to include granting strangers access to that beer.
That said, if we're trying to relate to the surrounding discussion, you're more than welcome to use your matter-replicator to make yourself a free copy of anything in my fridge, including the results from my somewhat experimental Irish cream cheesecake recipe -- and the one beer I have you can make as many copies of as you like.
Oh, you don't have a matter replicator? Perhaps you shouldn't speak about copyright violation and removal of physical property as if they were the same thing.
Personally, I only use software with license agreements I'm willing to actually agree to -- those being almost universally Free ones. My concern in this discussion is what standard of behavious I apply to others: Thieves I consider immoral people on their face (to the point that I wish none among my friends), whereas those that break contracts or violate government-imposed monopolies (copyrights, patents) are not necessarily such bad people -- though I may be hesitant to contract with the former.
Remember, the better of the Unix editors have been ported there. They may not be "Windowsy" -- but if you want a text editor that can read the DTD for the XML document you're editing and show you what tags are valid in the spot the cursor's at, or edit files on a remote server and upload them whenever you hit 'save', or spell-check only the comments in the source code you're working on, act as an IDE (host your debugger, jump from compiler errors to the appropriate spots in your code, put up a class-browser window, integrate with even the newer and less-heard-of revision control systems) or do hundreds of other things I can't remember -- it's all about Emacs.
And Emacs is not just freeware, but Free Software with a capitol F. Care to go find another example of best-in-class shareware?
Slashdot Mirror
Someone mentioned above that Oracle's groupware suite is among the best options for large installations -- perhaps something to consider. I understand that they have "Oracle Calendar Sync" available for PDA integration. Can't comment about their webmail.
BTW, I'm not recommending it by any means, but OpenGroupware supports drag-and-drop in the webmail client.
That used to be the case. Copyright infringement is now a crime even if it's done with the expectation of receiving not cash or equivalents but anything of value, explicitly including copies of other copyrighted works.
Whether copyright infringement is a criminal offense or not (and, IIRC, it has recently become one), it certainly isn't dangerous to human life, and consequently is beyond the circumstances in which proponents of the USAPATRIOT act claimed it would apply. Remember, the claim was that terrorist behaviour would be defined to only include behaviour which violates the law and is dangerous to human life, not violates the law or is dangerous to human life.
Civil disobedience my nutsack, this was done for profits.
So? Does the intent make a good gesture bad?
Humans, yes, it is unkind; corporations, no, they're not people and do not have feelings. If you for a second believe that a corporation has done or will do ANYTHING to benefit you, you have become a tool for that amount of time.
See, there's this concept called "enlightened self-interest". Please look it up.
I am not a corporation.
Much easier to be anti-corporate if you forget they're made of people, isn't it?
Harm the corporation and you're harming its stockholders, its employees -- harm it bad enough and you're harming its customers as well. Perhaps those stockholders include a mutual fund holding peoples' retirement money; certainly, they'll include a bunch of geeks who worked for years in startup conditions in the hopes that maybe they, too, could own their own home and start their own businesses.
I'm not arguing that corporations should be treated as sacred or upheld when they do wrong. Rather, I take the position that harming a corporate entity without just cause is as morally bankrupt as harming another individual, as such harm *does* affect individuals -- albiet being spread over a number of them, making it harder to see the individual impact.
...the rules get changed.
I don't want Real to get hurt -- that serves no purpose. I just want the DMCA weakened or repealed. If damage done to Real helps to bring that about, well and good! -- but otherwise, it's quite unkind to wish for another to be harmed.
As far as I'm concerned, far from a big mistake, Real did the right thing; think of it as civil disobediance on a corporate scale. Let's just hope some good comes of it.
In any event, I don't think we're likely to come to any agreement (and am finding the conversation to get a bit boring myself), so I propose to end this thread here (or, if you prefer, after your reply). As you'll notice, I left a few subthreads unanswered -- consider the points ceded.
It is a common mistake to think you have something faster just because you haven't yet designed in all you'll eventually need or want.
But it's also a mistake to think that all you'll eventually need or want needs to be designed in right now. It's also a mistake to put things at a more deeper layer than they need to be.
Sure the GNU libc is huge. But that's POSIX, and that's where the Hurd will bridge us from.
Funny, I'm pretty darned sure I've seen smaller implementations. Certainly, application compatibility for them isn't perfect -- but it's certainly Good Enough.
You yourself point out that the quick-and-dirty but real solution is often the one that wins in the market. Why, again, hasn't the HURD been kicked out the door with POSIX support only?
How is it saner? Because it's less ambitious -- and the amount of time it's taken for the HURD to become release-ready demonstrates its overambition.
How is it less ambitious? Weren't you the one talking a while about all the Nifty Features that the HURD has and is working on that the other microkernel-based OSes don't have?
Won't that make it less useful? Not necessarily. Almost all the really important things for an OS to do can be done with nothing more than proper application of the simple abstractions provided by VSTa and its libc (and accompanying libraries, since support for building servers has been split off from the libc proper). Sure, actually applying those abstractions may be left as an exercise for the reader -- but that's a fair sight better than waiting for a development team to say "come and get it!" for decades on end.
In general, a microkernel can get away with having only a minimum of functionality -- and, for that matter, should do so to the maximum extent possible (and no more). After all -- what does it need to do? The entire job of a microkernel boils down to message passing, task switching and memory allocation -- simple jobs that should be done in a minimal amount of tight, well-written, scalable code. Also included in the job of writing a microkernel-based OS is building a sane libc and userland interface for writing servers and doing namespace handling. Everything after (graphics, networking, device drivers, etc etc etc) is just writing userspace code, and the world is full of people who do that. VSTa is near the point where all it needs is servers to be written -- where the kernel+libc&friends layer is finished and stable and small and performant and all that's left is getting the servers written to provide interfaces to more hardware. The HURD, by contrast, has a lot more features being stuffed into the libc+friends -- hence massive changes to glibc -- so it takes much longer to get to the point where the reader is invited to do their thing.
Worse, depending on a heavyweight libc means that you can't scale down as easily without having a lightweight one also available -- and writing a light libc for a microkernel (where much more functionality is implemented inside that layer) is a much harder thing than implementing the many cut-down libcs that are available for Linux. On the other hand, adding more functionality for a microkernel OS with a light libc and well-written core is easy -- because that functionality can all be written in userspace, in servers that the folks who don't need the functionality can choose not to run. It means you need to have some dicipline in keeping features out of your libc, but the long-run return is well worth it.
(Funny you mention the HURD as a replacement for Linux, since it's the longer-running project of the two).
VSTa networks right now. X will be available after the Linux framebuffer code is written into a VSTa server -- I'm told by one of the developers (who, back at MontaVista, spent much of his time writing Linux framebuffer code) that it should be a very quick task.
That's just a matter of writing servers for more hardware, though -- nothing that requires changes to the kernel itself. The HURD may be further along, but look how many man-hours were required to get it there! By being a smaller, lighter, less ambitious, saner design, VSTa can make up for the time it lost as Andy Valencia's personal project. (And speaking of Andy -- he did a proprietary MIPS port for Cisco back when he was sole copyright holder and was quite well compensated for it, which would seem to imply that that it's found use as more than a toy).
Part of my point earlier is that a kernel that fills one niche well will have people working hard to apply it to others -- see Linux being used in embedded space, even though that's far from its native environment.
VSTa, given currently planned development (completion of POSIX compatibility, a port of the Linux framebuffer drivers, etc), will be able to be used as a desktop OS. Will it be "designed with the same ultimate goals as the HURD"? Absolutely not. Will it be good enough, and (more likely to be) finished in a sane amount of time? Yes.
Given the choice between good-enough and on-time versus theoretically perfect and never-quite-finished, good-enough wins.
Now if QNX or whatever was free software and had a roadmap to take on Linux and Hurd goals, that would be very interesting... only that they would face the same problem as the Hurd, to wit lack of critical mass.
Ahh -- but for a leaner project, it takes less to go critical. I think The HURD's overambition is part of why it hasn't.
Fill a niche, do it well, grow from there. I have high hopes for VSTa.
And why shouldn't a kernel be generic enough to function in a desktop environment as well as a deeply embedded one?
Sure, things like POSIX support are needed in the former (and, as I mentioned, adding and enhancing it is an ongoing process for VSTa) -- but for a microkernel, these can all be userland changes, and quite confined ones at that. Quite a few folks in the embedded field have seen fit to go out of their way to use a kernel that's frankly unfit for what they're trying to do for the explicit purpose of being able to share development between that embedded environment and the rest of the world. Given an opportunity to make a kernel that's unfit neither in embedded space or the rest of the world, why ruin it with bloat -- particularly when that bloat, while it may be in the name of "easier development", brings it further from the very image of simplicity that a microkernel OS has the ability to be?
VSTa hasn't traditionally aimed for full POSIX compatibility, but now that Andy Valencia is no longer effectively in charge of development, that's changing. As for Linux fitting on floppies if trimmed -- my previous job was at an embedded Linux company which employs primarily kernel hackers on its engineering team; I learned a thing or two while there about exactly why a cut-down Linux kernel *isn't* as well-suited to particularly small embedded environments as QNX, VSTa or their kin. (That said, I'll stipulate that my knowledge of the HURD itself is a bit sketchy).
I'll take a kernel that's small and easy to hack on over one which has been bloated to add extra layers of infrastructure in order to implement some "level of development flexibility" any day.
Too complex, certainly. Time for microkernels? If there were a good one with servers for all the relevant hardware ready? Sure! The HURD? HELL, NO!
Compared to its peers (QNX, VSTa), the HURD is tremendously bloated and slow. Its development involved massive (and performance-reducing) changes to its libc (which have had negative impacts on *other* OSes that use that same libc). Compare to QNX, which runs on tiny embedded devices and which has a demo disk available with massive hardware support and a full web browser all fitting on a single floppy, or to VSTa, which last I heard fit the kernel into 28K (and shrinking) and outperforms some popular macrokernels.
Microkernels are a great idea -- I absolutely look forward to writing and debugging filesystem code and hardware drivers with my usual userland tools. But the HURD? I'll keep my macrokernel, thank you.
Hrm? The HURD sucks as much as any; it's one of the easy examples to use when arguing (wrongly) that microkernels are slow and inefficient exercises suitable only to academia. (And do I know you?)
Meant to reply to one of your children, not your post directly. Mea culpa.
Yes, some microkernel OSes *suck*.
And then, some of them don't.
See Plan 9, or QNX, or VSTa (still a toy for most purposes -- but very small and fast, and generally considered quite promising by a group of kernel developers I happen to know, a group which includes some folks who are considering building it into an OS suitable for real-life deeply embedded work).
So? Yes, the growth medium is humans motivated by challenge, or maliciousness, or *whatever* -- but if you take it as a given that somesuch growth medium exists, computer virii behave in several biological ways.
They combine their "genes" as folks splice the new, most effective payloads and mechanisms together; they mutate whenever someone comes up with a new and previously nonexistant technique... etc.
In short -- just because they're made by folks whom society would, generally speaking, be better without doesn't mean that they can't have biological charactristics.
(That said, I'd hesitate to call the folks who made this one "sadistic" -- not only is there no harmful payload, they *ASK THE USER* if it's allowed to spread!)
Hi, David! Been a while.
.ca.us bay area, the big cities in the eastern US -- the living expenses there are considered completely ridiculous by everyone else.
You missed one: Leaving whichever high-expense metropolitan area you happen to live in, and finding a job elsewhere.
The
I'm right now living in Austin, widely considered the most expensive part of Texas, and looking to buy a reasonably nice house. Prices are in the $120-130K area (3-4 bedroom, big kitchen, that sort of thing; one someone got before my mortgage was approved had a pool, a hot tub, a professionally landscaped yard, and a vast number of other goodies). These are *in town* (or max 15 minutes out) prices. And there are tech jobs here, albiet we're still recovering from the bust.
Compare to what that would cost where you live.
The thread so far has been not about "open source" equivalents, but rather "runs on Linux" equivalents -- not at all the same thing.
Just to pick one of your examples: Photoshop runs on Linux (officially supported via Crossover Office), and does so because some big companies paid a lot of money to make it that way.
I can't speak for GNOME, but KDE has a central registry of URL handlers. The downside to implementing it at this layer, of course, is that it isn't usable (or, at least, used in practice) by non-KDE apps.
(Incidentally, I use neither GNOME nor KDE -- I find that ion, while less than newbie-friendly, lets me work most efficiently).
I think you misspelt it, it's actually spelt VI :-)
Heh. I actually use vim myself (have a window open right now with some code I'm working on), but it's a bit much to try to push on a Windows user -- and some of the bloat^Wfeatures available to Emacs really can come in handy on occasion, or at least sound like they can to folks brought up on "more features => better". (Are there extensions to vi* available to match each of the items I mentioned in the parent -- in-editor debugging (where one frame follows the location in the source which the debugger, in another frame, is currently at), class browsing, comments-only spellchecking, and so forth) presently available?
Yup, I'm poly-editor.
Hrm? Just because you have your own set of ethics (which may include helping yourself to my beer) doesn't mean that my own ethics need to include granting strangers access to that beer.
That said, if we're trying to relate to the surrounding discussion, you're more than welcome to use your matter-replicator to make yourself a free copy of anything in my fridge, including the results from my somewhat experimental Irish cream cheesecake recipe -- and the one beer I have you can make as many copies of as you like.
Oh, you don't have a matter replicator? Perhaps you shouldn't speak about copyright violation and removal of physical property as if they were the same thing.
Personally, I only use software with license agreements I'm willing to actually agree to -- those being almost universally Free ones. My concern in this discussion is what standard of behavious I apply to others: Thieves I consider immoral people on their face (to the point that I wish none among my friends), whereas those that break contracts or violate government-imposed monopolies (copyrights, patents) are not necessarily such bad people -- though I may be hesitant to contract with the former.
Textpad the best editor for Windows -- really?
Remember, the better of the Unix editors have been ported there. They may not be "Windowsy" -- but if you want a text editor that can read the DTD for the XML document you're editing and show you what tags are valid in the spot the cursor's at, or edit files on a remote server and upload them whenever you hit 'save', or spell-check only the comments in the source code you're working on, act as an IDE (host your debugger, jump from compiler errors to the appropriate spots in your code, put up a class-browser window, integrate with even the newer and less-heard-of revision control systems) or do hundreds of other things I can't remember -- it's all about Emacs.
And Emacs is not just freeware, but Free Software with a capitol F. Care to go find another example of best-in-class shareware?