On 9/19/2014 4:02 AM, David Brown wrote:> On 19/09/14 12:10, Don Y wrote: >> On 9/19/2014 2:53 AM, David Brown wrote: >> >>> The differences in license is, for almost everybody, irrelevant. The >>> difference in the development model and focus is key. >> >> Because, for almost everybody, you aren't designing products >> that you do NOT want encumbered with GPL. I surely don't care >> to invest my time updating sources -- that I will then NOT >> be able to distribute sans GPL! >> >> Especially when there are unencumbered alternatives! > > Almost everybody who /is/ designing products will choose Linux over BSD. > This is because almost everybody who is designing an embedded *nix > system does not care about keeping the code for the kernel secret, nor > the code for the base system or the libraries. They didn't write it - > why should they keep it secret? At most, they will have made a couple > of drivers for the kernel - and by making them open they can get others > to help maintain them.Because the kernel IN THOSE SYSTEMS is just a "checkoff item". I.e., a "free" QNX, VxWorks, etc. license would suffice equally well. There's nothing inherently special about a Linux kernel that you can't also find elsewhere. It's not real-time, isn't resource sensitive, has no provisions for fault tolerance, no support for namespaces nor capabilities, no support for distributed processing nor dynamic process migration, centralized configuration management, enhanced security, thorough documentation, etc. You can *add* that support -- by layering it on with varying degrees of success. And, at a performance and resource cost. If you're not concerned with having gobs of RAM or loads of MIPS "to burn", then that cost is hidden from you -- until a competitor comes out with a product that costs less and performs better. *Then* what do you do? Appeal to the Linux community to give you a smaller, faster, more reliable kernel -- without all this support for devices and features that you may not *use*/need?? If, instead, you have a product that exploits those features and leverages them for a cost/performance/reliability advantage, why would you want to "taint" it by "borrowing" code from a GPL'd kernel? Esp when you can borrow functionally similar code from an "open" kernel!> Of course, people making embedded Linux systems will generally have > plenty of their own code in the system - and that will often be under > closed licenses with secret code. But that's perfectly fine - the GPL > applies to the kernel, not programs running with it. > > And once you get beyond the kernel itself to the libraries and common > utilities, most of these are exactly the same programs in BSD and Linux > systems. Some (such as ssh) are basically from the BSD world, others > (such as the gnu utilities) come originally as Unix alternatives, and > others come from the Linux world. It's all open source, it's all freely > available, and it is all usable on different systems despite license > differences. > >> "For almost everybody", the only difference between a FOSS license >> and a Windows/OSX license is some dollars. How many folks do you >> know who lament NOT being able to patch the Windows/OSX/iOS/etc. >> sources? They just want to use apps supported ON that OS. >> >> [If the cost of a Windows/OSX/etc. license is an impediment, >> then I suspect they truly misunderstand the cost and value >> *of* the product they are using. Or, are just plain "cheap". >> Yet, probably would cringe at the idea of not being compensated >> for *their* work!] > > In many cases, the cost of /administering/ Windows licenses (especially > embedded ones) outweighs the cost of the licenses themselves!Do you discount the costs of maintaining a Linux system? How often is the kernel revised? How often do folks have to upgrade an installed package -- or, a dependency on an installed package? No system has "free" maintenance. Linux users may be more willing to tinker with adding/removing/configuring apps -- especially because they are "free" -- but that doesn't make the cost of doing so go away! They simply choose to value their time as "free".> People choose embedded Linux for their products because it is a better > system for many uses than embedded Windows. You are right that the > license cost is (or should be!) a minor issue. A telephone manufacturer > must pay MS more for their patent protection racket when they use > Android than they would pay to use Windows Phone - but they use Android > because it is a better system.
Intel Atom: pros/cons/hazzards?
Started by ●September 17, 2014
Reply by ●September 19, 20142014-09-19
Reply by ●September 19, 20142014-09-19
On 19/09/14 13:26, Don Y wrote:> On 9/19/2014 4:02 AM, David Brown wrote: >> On 19/09/14 12:10, Don Y wrote: >>> On 9/19/2014 2:53 AM, David Brown wrote: >>> >>>> The differences in license is, for almost everybody, irrelevant. The >>>> difference in the development model and focus is key. >>> >>> Because, for almost everybody, you aren't designing products >>> that you do NOT want encumbered with GPL. I surely don't care >>> to invest my time updating sources -- that I will then NOT >>> be able to distribute sans GPL! >>> >>> Especially when there are unencumbered alternatives! >> >> Almost everybody who /is/ designing products will choose Linux over BSD. >> This is because almost everybody who is designing an embedded *nix >> system does not care about keeping the code for the kernel secret, nor >> the code for the base system or the libraries. They didn't write it - >> why should they keep it secret? At most, they will have made a couple >> of drivers for the kernel - and by making them open they can get others >> to help maintain them. > > Because the kernel IN THOSE SYSTEMS is just a "checkoff item". > I.e., a "free" QNX, VxWorks, etc. license would suffice equally > well. There's nothing inherently special about a Linux kernel > that you can't also find elsewhere.No, that is not even remotely close to being correct. There are many differences between the Linux kernel and its closest cousins, the BSD kernels - and even more differences from QNX, vxworks, and any other kernel you can think of.> > It's not real-time, isn't resource sensitive, has no provisions > for fault tolerance, no support for namespaces nor capabilities, > no support for distributed processing nor dynamic process migration, > centralized configuration management, enhanced security, thorough > documentation, etc.Of the features you mention, Linux has more than any others - it has soft real-time (and hard real-time extensions exist), it has plenty of support for some kinds of fault tolerance (and most fault-tolerance stuff is user-space anyway), it has namespaces and capabilities, you can do distributed processing and process migration (have you really never heard of Linux clusters?), you can manage configuration any way you want, there are many security enhancements you can enable, and there are piles of documentation. A basic Linux system will take more disk space and more ram than a QNX or VxWorks system - but it will do /far/ more. And a QNX or VxWorks system will take far more space and ram than a FreeRTOS system, and so on. So what? I will certainly agree that many embedded Linux systems could also have worked using QNX or even VxWorks - but there are also many that could not. I can also imagine that most embedded Linux systems could also have worked with a BSD kernel - assuming it had the right hardware support - but there are still many that could not.> > You can *add* that support -- by layering it on with varying degrees > of success. And, at a performance and resource cost. If you're > not concerned with having gobs of RAM or loads of MIPS "to burn", > then that cost is hidden from you -- until a competitor comes out > with a product that costs less and performs better. *Then* what > do you do? Appeal to the Linux community to give you a smaller, > faster, more reliable kernel -- without all this support for > devices and features that you may not *use*/need??I think you misunderstood everything I wrote about modules. The /only/ cost is in disk space - and if you do not need them, you are free to delete them from your packaging and/or disable the build if you are doing your own kernel configuration and build (it's /your/ choice). So if you want SELinux or AppArmour for added security, you can use it. If you don't want it, don't use it. If you want capabilities and namespaces, use them. If you want a minimal Linux kernel without these features, you can have that too. Where's the problem?> > If, instead, you have a product that exploits those features and > leverages them for a cost/performance/reliability advantage, why > would you want to "taint" it by "borrowing" code from a GPL'd > kernel? Esp when you can borrow functionally similar code > from an "open" kernel!You don't "taint" anything - just enable or disable them in the kernel build (for features that are too highly integrated to work as modules), or load or ignore the modules.> >> Of course, people making embedded Linux systems will generally have >> plenty of their own code in the system - and that will often be under >> closed licenses with secret code. But that's perfectly fine - the GPL >> applies to the kernel, not programs running with it. >> >> And once you get beyond the kernel itself to the libraries and common >> utilities, most of these are exactly the same programs in BSD and Linux >> systems. Some (such as ssh) are basically from the BSD world, others >> (such as the gnu utilities) come originally as Unix alternatives, and >> others come from the Linux world. It's all open source, it's all freely >> available, and it is all usable on different systems despite license >> differences. >> >>> "For almost everybody", the only difference between a FOSS license >>> and a Windows/OSX license is some dollars. How many folks do you >>> know who lament NOT being able to patch the Windows/OSX/iOS/etc. >>> sources? They just want to use apps supported ON that OS. >>> >>> [If the cost of a Windows/OSX/etc. license is an impediment, >>> then I suspect they truly misunderstand the cost and value >>> *of* the product they are using. Or, are just plain "cheap". >>> Yet, probably would cringe at the idea of not being compensated >>> for *their* work!] >> >> In many cases, the cost of /administering/ Windows licenses (especially >> embedded ones) outweighs the cost of the licenses themselves! > > Do you discount the costs of maintaining a Linux system? How often > is the kernel revised? How often do folks have to upgrade an > installed package -- or, a dependency on an installed package?Oh, there is plenty of time and effort needed for working with any system - whether it is Linux, BSD, Windows, or something else. I did not suggest anything to the contrary. My point is just that administering /licences/ for embedded Windows can cost more than the licenses themselves. The cost for development, updates, maintenance, etc., for a system is another matter, and varies enormously.> > No system has "free" maintenance. Linux users may be more willing > to tinker with adding/removing/configuring apps -- especially > because they are "free" -- but that doesn't make the cost of > doing so go away! They simply choose to value their time as "free". > >> People choose embedded Linux for their products because it is a better >> system for many uses than embedded Windows. You are right that the >> license cost is (or should be!) a minor issue. A telephone manufacturer >> must pay MS more for their patent protection racket when they use >> Android than they would pay to use Windows Phone - but they use Android >> because it is a better system. >
Reply by ●September 19, 20142014-09-19
On Fri, 19 Sep 2014 11:53:40 +0200, David Brown <david.brown@hesbynett.no> Gave us:>A kernel has to be built - but it certainly doesn't have to be built by >the user.Something in your logic is missing or askew.
Reply by ●September 19, 20142014-09-19
On Fri, 19 Sep 2014 11:53:40 +0200, David Brown <david.brown@hesbynett.no> Gave us:> I don't know much about building kernels in the BSD world, >but in the Linux world it is a very long time since it was common to >bother building your own kernel.Out of touch much?
Reply by ●September 19, 20142014-09-19
On 9/19/2014 4:50 AM, David Brown wrote:> On 19/09/14 13:26, Don Y wrote:>>> Almost everybody who /is/ designing products will choose Linux over BSD. >>> This is because almost everybody who is designing an embedded *nix >>> system does not care about keeping the code for the kernel secret, nor >>> the code for the base system or the libraries. They didn't write it - >>> why should they keep it secret? At most, they will have made a couple >>> of drivers for the kernel - and by making them open they can get others >>> to help maintain them. >> >> Because the kernel IN THOSE SYSTEMS is just a "checkoff item". >> I.e., a "free" QNX, VxWorks, etc. license would suffice equally >> well. There's nothing inherently special about a Linux kernel >> that you can't also find elsewhere. > > No, that is not even remotely close to being correct. There are many > differences between the Linux kernel and its closest cousins, the BSD > kernels - and even more differences from QNX, vxworks, and any other > kernel you can think of.Because there are differences doesn't mean that the choice to USE a Linux kernel is related to those differences! There are TECHNICAL differences between Windows and FOSS OS's but that is seldom the reason one is chosen over the other!>> It's not real-time, isn't resource sensitive, has no provisions >> for fault tolerance, no support for namespaces nor capabilities, >> no support for distributed processing nor dynamic process migration, >> centralized configuration management, enhanced security, thorough >> documentation, etc. > > Of the features you mention, Linux has more than any others - it has > soft real-time (and hard real-time extensions exist), it has plenty of > support for some kinds of fault tolerance (and most fault-tolerance > stuff is user-space anyway), it has namespaces and capabilities, you can > do distributed processing and process migration (have you really never > heard of Linux clusters?), you can manage configuration any way you > want, there are many security enhancements you can enable, and there are > piles of documentation. > > A basic Linux system will take more disk space and more ram than a QNX > or VxWorks system - but it will do /far/ more. And a QNX or VxWorks > system will take far more space and ram than a FreeRTOS system, and so > on. So what? > > I will certainly agree that many embedded Linux systems could also have > worked using QNX or even VxWorks - but there are also many that could > not. I can also imagine that most embedded Linux systems could also > have worked with a BSD kernel - assuming it had the right hardware > support - but there are still many that could not.No, you are missing the point. It's not a question of whether or not a feature set CAN be supported on Linux. You can implement all of the above on single-threaded DOS! The difference is whether the features ARE supported on Linux AND whether the kernel itself plays by the same rules! This goes to the nature of my "bolt on" comment (below). EVERY TASK (process) created in my system is capabilities based, has its own namespace, uses RT scheduling constructs to govern access to the resources that it consumes/supplies, is fault tolerant, can be dynamically migrated to another processor in another location, can seemlessly talk to other processes on other hosts, uses the same security mechanisms, etc. INCLUDING THE KERNEL ITSELF! E.g., the network stack implementation uses the same RT scheduler as "userland" tasks. Demands on the network by (any -- including kernel tasks) are satisfied by examining the RT characteristics of the "network consumer". If the task that handles disk I/O dies (perhaps because the disk interface on this host fails), it is migrated to another host and the connections to it are preserved -- even though it is no longer "local". The task that handles the network can't in any way, access the hardware OR THE SERVICE that handles the disk drive. And vice versa. They have no concept (name) for each other! Given the ability to load its own firmware off disk (because it has been provided with an appropriate name in its namespace: e.g., "/firmware"), a motor controller can't MODIFY that disk image -- nor access any other "stuff" on that medium (because the capabilities that the motor driver have been given preclude that operation). etc. The kernel doesn't do things one way while userland has to abide by a different set of rules. The fact that these are loadable modules ("bolt ons") acknowledges the fact that the kernel can't rely on any of them in its operation. I.e., that it only *emulates* those services at userland level but wasn't designed to operate within those same confines.>> You can *add* that support -- by layering it on with varying degrees >> of success. And, at a performance and resource cost. If you're >> not concerned with having gobs of RAM or loads of MIPS "to burn", >> then that cost is hidden from you -- until a competitor comes out >> with a product that costs less and performs better. *Then* what >> do you do? Appeal to the Linux community to give you a smaller, >> faster, more reliable kernel -- without all this support for >> devices and features that you may not *use*/need?? > > I think you misunderstood everything I wrote about modules. The /only/ > cost is in disk space - and if you do not need them, you are free to > delete them from your packaging and/or disable the build if you are > doing your own kernel configuration and build (it's /your/ choice).That's my point (above)! The kernel doesn't embrace those features and present a unified API to ALL of userland AND ITSELF! It doesn't treat "memory" as a resource whose access is governed by RT parameters -- first come, first served! It doesn't schedule packet transmission over the network based on the RT criteria of the individual tasks requesting their delivery. It doesn't protect the disk driver from the network driver by appropriate namespace and capability entities. It *can't*. Because it can't count on support for any of those "bolt on" features! (and you surely don't mean to claim the kernel rewrites itself based on which userland support features are loaded? So that it suddenly resolves ITS INTERNAL mutex conflicts with a different strategy based on whether RT support is present at userland...)> So if you want SELinux or AppArmour for added security, you can use it. > If you don't want it, don't use it. If you want capabilities and > namespaces, use them. If you want a minimal Linux kernel without these > features, you can have that too. Where's the problem?See above. If the kernel is doing things "different ways" for itself and for userland, then there is duplication of effort and the potential for unintended consequences -- because the same rules don't apply throughout. The kernel decides it doesn't have to behave the same way that it forces others to behave -- like old monolithic kernels that decide they don't need to be bothered with the constructs that applied to userland tasks (htose constructs created to enhance the reliability and ease of programming of those userland tasks!)>> If, instead, you have a product that exploits those features and >> leverages them for a cost/performance/reliability advantage, why >> would you want to "taint" it by "borrowing" code from a GPL'd >> kernel? Esp when you can borrow functionally similar code >> from an "open" kernel! > > You don't "taint" anything - just enable or disable them in the kernel > build (for features that are too highly integrated to work as modules), > or load or ignore the modules.So, it's all or nothing. I can't clip some code fragment from the GPL'd kernel and benefit from its use. I have to embrace the entire GPL'd module -- and the GPL'd kernel onto which it bolts -- to benefit from this "code fragment". So, I've got to "fix" the kernel so that it uses all of these features *internally*... just to be able to use them "externally". And, encumber it with the GPL in the process. And, this is going to take LESS effort than starting from scratch and borrowing code from "unencumbered" sources? Remember, I don't care if you support 5000 different network adapters. There will be exactly *one* in any product I design. Ditto for video, disk, etc. And, the choice as to "which one" will probably not be made based on "available sources" but, rather, availability of *silicon* at the desired price point and with the necessary hardware capabilities. Where's the competitive advantage in that??
Reply by ●September 19, 20142014-09-19
On 9/19/2014 7:58 AM, DecadentLinuxUserNumeroUno wrote:> On Fri, 19 Sep 2014 11:53:40 +0200, David Brown > <david.brown@hesbynett.no> Gave us: > >> A kernel has to be built - but it certainly doesn't have to be built by >> the user. > > Something in your logic is missing or askew.I think his point is that most users can tolerate a "generic" kernel -- one that has every possibility accounted for. In a desktop environment, that may well be the case. OTOH, if you're designing a cost-sensitive "appliance", you probably DON'T want to accommodate every possibility -- because your hardware simply can't take advantage of them! In that case, why include support for something -- even "loadable modules" -- if it will never be used? In high reliability software, there is a concept called "dead code"; code that is never executed. It's presence in a product is seen as a flaw. It represents added complexity that is not used. And, added potential for flaws. E.g., *something* in the live CD kernel that I recently booted (elsewhere this thread) is causing the system to crash before it can even go single-user. Likewise, a Linux kernel on another live CD also caused the video to go wacky. Whatever that is, it represents a liability of those particular kernels. OTOH, when the live CD was built, I'm sure they reasoned that they wanted to include support for everything imaginable *on* that CD (even if some of that stuff tickles hardware that has not yet been imagined -- or, perhaps completely validated). That's the consequence of using a kernel that was NOT built by THIS user (for this hardware). Note that this is far less of a problem now (esp in the desktop machine world) than it was years ago. Because modern busses make it much easier to identify/probe particular hardware. OTOH, rolling your own hardware doesn't afford you this same level of protection. E.g., you can locate a particular peripheral wherever *you* deem fit in the address space; you can scramble the address or data lines to that peripheral; you can locate *other* peripherals in places where the probe for some other device can cause that other peripheral to lock up; etc. Hence the apparent value of building my own live CD with a set of progressively more capable kernels. So, booting the default kernel doesn't even try to go looking for devices and capabilities that aren't needed TO EXAMINE THE MACHINE'S HARDWARE (dmesg output). Just make sure the interface to the CD, text display and keyboard are operational. (alternatively, USB *instead* of -- not in ADDITION to -- the CD. "Minimalism") I suspect that is the approach folks like MS take. They settle on some basic set of capabilities that they REQUIRE from the hardware in the early stages of installation. So, they can at least communicate with the user to explain problems, etc.
Reply by ●September 19, 20142014-09-19
On 2014-09-19, Don Y <this@is.not.me.com> wrote:>>> >>> [If the cost of a Windows/OSX/etc. license is an impediment, >>> then I suspect they truly misunderstand the cost and value >>> *of* the product they are using. Or, are just plain "cheap". >>> Yet, probably would cringe at the idea of not being compensated >>> for *their* work!] >> >> In many cases, the cost of /administering/ Windows licenses (especially >> embedded ones) outweighs the cost of the licenses themselves! > > Do you discount the costs of maintaining a Linux system? How often > is the kernel revised? How often do folks have to upgrade an > installed package -- or, a dependency on an installed package? > > No system has "free" maintenance. Linux users may be more willing > to tinker with adding/removing/configuring apps -- especially > because they are "free" -- but that doesn't make the cost of > doing so go away! They simply choose to value their time as "free".If the part being upgraded is from the distro it basically costs nothing no more than the microsoft updates stuff does for windows users, but with oput the licence key issues. -- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply by ●September 20, 20142014-09-20
On Fri, 19 Sep 2014 01:17:51 -0700, Don Y <this@is.not.me.com> wrote:> >>>> When I say Linux, I am referring to all of those collectively. When you >>>> say you don't run Linux, you mean... whatever... this can be >>>> exasperating sometimes. >>> >>> That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, >>> etc. >> >> Sometimes you make no sense. You just said Linux is the kernal for all >> of those systems. Now you are saying it is the kernal for Windows >> too... ok > >No! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM... >for Linux Distros -- and ONLY for Linux Distros!Umm, No. DOS command.com is like one of the shell languages sh, csh, ash, bash, etc., The underlying system is in things like io.sys and dos.sys. ?-)
Reply by ●September 20, 20142014-09-20
On Fri, 19 Sep 2014 01:27:38 -0700, Don Y <this@is.not.me.com> wrote:>On 9/19/2014 12:36 AM, Boudewijn Dijkstra wrote: >> Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>: >>> On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >>>> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>>>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>>>> >>>>> [...] I tried booting >>>>> a NetBSD system and the video quickly scrambled (hard to see >>>>> the dmesg output to determine which device was probed at the >>>>> time). I'll have to make some time to investigate... >>>> >>>> *BSD supports serial console for headless boxen. If graphics probing >>>> causes problems, then you can disable the relevant drivers without >>>> rebuilding the kernel. >>> >>> Yes, the problem is figuring out *what* is causing the box to "hang". >>> Note that it could be "something else" that just happens to tickle >>> some graphics I/O, etc. >> >> My point was that you should be able to see this when using a serial >> console. > >No, it seems that the machine is locking up when this happens. > >In the past, I've always just built a GENERIC kernel, partitioned >the new disk, newfs(1) all partitions, filled fstab(5) and copied >all the file system from a "template" system onto the new disk... >all from within that "template system". > >Then, unplug the disk and install it in the new machine. EXPECT >the network not to work and other devices to need to be tweeked. >But, copy the GENERIC kernel configuration to NEWMACHINE, drop >into vi(1) and edit NEWMACHINE to add/remove/change the appropriate >lines. Build new kernel (now I am *on* the new machine!) and >install it. > >This is the first time that I have *had* to rely on a live CD. >Lesson learned: build a live cd that has a barebones kernel >(which tries to be the least of all worlds) instead of GENERIC >(which tries to be all things to all machines). I.e., instead >of trying to have a running system on a live CD, try for a >DEBUGGABLE system.Don, this whole fufarah has impressed with NetBSD and its adaptability. I must really give it another look soon. ?-)
Reply by ●September 20, 20142014-09-20
On 19/09/14 19:16, Don Y wrote:> On 9/19/2014 4:50 AM, David Brown wrote: >> On 19/09/14 13:26, Don Y wrote: > > >>>> Almost everybody who /is/ designing products will choose Linux over >>>> BSD. >>>> This is because almost everybody who is designing an embedded *nix >>>> system does not care about keeping the code for the kernel secret, nor >>>> the code for the base system or the libraries. They didn't write it - >>>> why should they keep it secret? At most, they will have made a couple >>>> of drivers for the kernel - and by making them open they can get others >>>> to help maintain them. >>> >>> Because the kernel IN THOSE SYSTEMS is just a "checkoff item". >>> I.e., a "free" QNX, VxWorks, etc. license would suffice equally >>> well. There's nothing inherently special about a Linux kernel >>> that you can't also find elsewhere. >> >> No, that is not even remotely close to being correct. There are many >> differences between the Linux kernel and its closest cousins, the BSD >> kernels - and even more differences from QNX, vxworks, and any other >> kernel you can think of. > > Because there are differences doesn't mean that the choice to > USE a Linux kernel is related to those differences! There are > TECHNICAL differences between Windows and FOSS OS's but that > is seldom the reason one is chosen over the other! >Now you are talking nonsense. Most people who have Windows on a machine have not /chosen/ at all - it was forced upon them. But are you really saying that when people /chose/ an OS, it is seldom for technical reasons? Do you really think that I chose to run Linux because it saves me a couple of dollars on the license few? Or do you think I chose Linux because it is "cool"? There are /many/ reasons why people choose particular OS's, for desktops, servers, embedded systems, etc. Some of these are technical, some are non-technical (such as an arbitrary dislike for an OS). You insult everyone who has ever made an informed decision about their OS with your claims here, and you show your ignorance when you suggest that the only major differences between VxWorks, QNX, Linux, BSD and Windows are non-technical. This is exactly the sort of fight I wanted to avoid - I tried to give you a few /technical/ pointers to why Linux might do a better job for you, and in trying to battle ignorance and myths I have stupidly let myself get drawn in. And for every point I correct, you post another three paragraphs of new imagined issues. I simply don't have the time and energy to spend battling such determined fixed positions - this is why I and a good many others usually avoid many of your threads. If you are happy with BSD, that's great. I am genuinely pleased that you are content with what you have. And I hope you will forgive my misguided attempts at making new suggestions that I thought might have made things easier for you - it was an attempt to help, not a call for battle.
