I understand the usual time initialization process, having closely studied init scripts. Nonetheless, this depends on a time server being available (DSL, Cable, etc.) Many home users still don't have these even if they are available in their area.
I concur on the wear and tear of shutdowns and restarts-- but that doesn't mean you're going to get granny to stop doing it. And in general, your comparison to driving can only be taken so far-- as far as it pertains to hurting others. Granny's computer won't be much of a threat as long as it is firewalled off and not running Outlook.
And, even the worst Windows zombies don't do as much damage as a single intoxicated driver can do. Let's keep some perspective.
Back to my main point. If we simply tear down Michael Robertson's method without examining why he's doing it, we won't convince him to use a better method. It would be better to make some concessions and get Linspire to run most things as a non-root user, than to have a bunch of grannies running as root, becoming zombies, and dragging the reputation of Linux in the mud.
You're still thinking in server or workstation terms, always on, always connected, etc. Linspire is a *Desktop* system.
Yes, I know messing with the date can screw up compilation trees (timestamps dependencies), daemons, and many other things. But, desktop users are going to want to do it. Put them behind a firewall, then let them do what they want with their system.
I'm assuming you actually want to attract dumb users (as Linspire is trying to do). In that case, requiring a password to change the date is going to turn them off. Especially if it is not the one they normally use. If any password must be given, at least sudo should be used, so the password can be the user's own password.
As for the kid changing the clock, this points to the need for greater privilege granularity. I believe most users would want newly created accounts to, by default, allow dates to be changed without a password. But, as you point out, a parent might want accounts with even more restricted privileges. For that matter, a parent may want a kid's account to not be able to download and run software, even as their own user. Or not be able to listen on a port (not even a non-privileged port). Thus, the need for greater granularity.
Another post mentioned that SELinux is working on this. Hopefully it comes to general Linux soon.
Eventually SELinux will be applied to desktop apps too, and then Linux will be an extremely secure system. It will be a while, however, because it's very difficult to define exactly what a program is allowed to do; the goal is to restrict anything it doesn't need to do while letting it do anything it does need to do. If you err on one side it's a security hole (though admittedly small compared to today's apps) and if you err on the other side the app will fail when it tries to perform some action.
Ideally, the system would suspend the application while the user received a descriptive message of what the program was trying to do, at a high level. The administrator could then configure the app by running it with no privileges initially, but clicking "Allow Always" for each allowed operation, exercising each feature of the program that the users need, then capture that configuration and apply it to all users.
Users could (if allowed by their own account) also grant privileges (up to what their account had) for functions the system admin may have neglected to exercise. However, they would probably soon get annoyed by clicking dialogs and ignore what they said, so admins would in that case do well to make sure the user had few privileges and the app was already preconfigured properly.
I haven't seen a rebuttal that gives a good solution yet. Michael Robertson is right about data being the most important, but seems to think that having users run as non-root means that changing the date will require a password (which is a "no no" for ease of use).
This problem can easily be solved by making all non-critical configuration tasks (e.g. setting the date) run using sudo behind the scenes. Changing the date as a non-root user shouldn't require a root password (unless you're real paranoid about bugs in your date setting code allowing crackers to exploit date-triggered viruses, or something...)
As for requiring a password, the only real solution is biometric, and that will be a while in coming. But most grannies aren't going to be changing hardware settings unless they are comfortable entering passwords. And if they aren't, they shouldn't be changing hardware settings anyway...
It's not OSS, but there are many inexpensive (or free) websites which provide tax services, and work on open source browsers. I personally use Tax ACT, which is free for paper-based taxes and $8-$10 for e-filing.
My generalized JScript library was created for in-house use, but is languishing unused at the moment. It might be possible to get it released, though it would take some cleanup to make it truly generalized. If you're still interested, email me at DownsWE at muni dot org. I could at least give you some more details how I went about it.
I had seen this a few months ago, and had put together a system using a java-based JScript implementation on the server, so JSON could be evaluated both ways. It was pretty slick, being able to write a web app in entirely JScript (which is a pretty powerful language once you get to know it, naysayers notwithstanding). I had a generalized JScript library loaded client side which could produce menus and set form values from the server automatically.
On the other hand, if your page is mostly data which will be changing (e.g. a database-backed web form), the vaunted performance isn't that much better than just slimming your HTML using CSS. And if you just use simple HTML (with CSS), you can have something which also works on lynx or older browsers, while still looking sharp on Firefox/IE/Safari/Opera/etc.
The ideal palmtop for me needs to have a VGA port able to output at least 640x480 or greater (for presentations, without having to carry a laptop) and at least one, preferably two mini-USB ports for keyboard and mouse (and also usable for charging and data transfer).
I would expect to be able to hook up external VGA, keyboard and mouse and start using it like a desktop. Ideally, with bluetooth+ and appropriate software, future versions could automatically connect to your handheld environment when you walk up to a desktop computer, but that's probably a way off.
The palmtop should have a mini-keyboard with clamshell case design and mini-VGA (at least 640x480) color screen usable for watching movies. It should have built in speaker, mic, and separate headphone and microphone jacks. The audio jacks should be accessible with the case closed (e.g. for jogging). The screen should power off when the case is closed but leave the CPU running. A separate power button inside the clamshell case should suspend/instant resume.
Storage should preferably be solid state to avoid motion damage, at least 10 Gb built in, with option to extend with CF and SD.
CPU should be fast enough to handle speech synthesis and recognition but able to scale back power when heavy processing is not being done.
The device should be rugged enough to withstand a drop from 3-4 feet (pocket to waist level), and water resistant to e.g. rain while jogging. It should have a (possibly removable) belt-clip on the back.
Battery life should be at least 24 hours continuous use, but a week of day use (e.g. 80+ hours in blocks of 12 or so) would be nice.
All this should be crammed into a device at least as small as the zaurus 5500, which I carry with me regularly. Phone capability should be built in (with microphone and speaker positioned conveniently for such), and Wi-Fi would be nice, but could be an add-on using the CF slot.
I don't expect to see this device in the near future, but it is the direction I hope to see palmtops heading. When it does arrive, it will probably be out of my price range for a while, but if a device like this cost around $200, it would sell. Don't expect to see it manufactured at that (or any) price until significantly more miniaturization occurs, though.
So, to summarize, The palmtop should be small enough to carry all the time, but have all the capacity needed for multimedia files and a complete set of desktop software, and all the CPU needed to run it. When desktop computers or projectors are available, the handheld should be able to interface with them using standard ports (instead of having to have a docking station).
Regarding your sig, "If you don't like it, ignore it. All negative mods are meta-moderated 'unfair'. ALL OF THEM." I would just like to point out why I think your meta-moderation is misguided.
The current moderation system has a top limit of +5. However, since slashdot has so many posters these days, there can easily be 50+ posts moderated at that level. For this reason, I ALWAYS moderate down, never up, so as to reduce the number of +5 moderations. As such, I'm not usually moderating because I don't like something, just because I think it is less qualified to be +5 than some of the other posts which made it to that level.
are the competition even if they have low marketshare, because they aim for the kinds of user Linspire aims for, and have many similarities feature-wise.
However, in my personal comparison of all three, Xandros with integrated Crossover Office is the only real competition (Lycoris had quite a few issues, and a very limited selection of software, not being debian-based).
Advantages of Xandros were auto-run of Windows install CDs with easy integration of Windows apps (at least those that work under Crossover Office), and the Xandros file manager (with integrated CD ripping and burning, which is really cool and nicer than Windows XPs).
Disadvantages of Xandros were, it hung when a Dell Axim PocketPC was plugged in (during KDE startup), and it couldn't get through my corporate firewall to download updates (though browsing through the firewall works fine).
Long story short: Xandros was slightly easier to use (when it works) but Linspire's CNR is nicer, has a wider selection of software (yes, this could change), and works through a firewall (though it had some hassle getting that set up as well).
* The bird came from inside the ark. A shoot of an olive tree would have had time to sprout after the water receded (200 days or so). Of course, some marine life lived through the flood. Only basic types of animal, bird and insect life would have been taken into the ark. (e.g. one pair of a prototypical dog-like animal containing all the genetic information necessary to create modern dogs, wolves, coyotes, dingoes, etc.) The genetic diversity we see in animals today doesn't mean there wasn't a single prototypical ancestor for many of them, which was taken into the ark. The only issue is how fast the diversification could have occurred, within one type of animal/bird/insect.
* Prior to the flood, most likely all continents were contiguous land. Large amounts of water may have been under the earth's crust acting as a fluid coolant and heat carrier to the earth's radioactive core. This would also have warmed the surface of the earth more evenly, explaining why we find tropical fossils at the polar regions. Perhaps an asteroid hit caused major damage to the earth's crust. The Bible refers to the "fountains of the great deep" breaking up, so rain wasn't the only source of water.
* As for time required for plate tectonics, that is assuming current constant rates without a catastrophe occuring, which could significantly accelerate rates of plate drift, erosion, etc.
* High temperatures/low humidity, I assume you are referring to current climate in the Ararat region. A catastrophe of this magnitude, and the ensuing ice ages which occurred (yes, after the flood), would have changed the climate drastically. Most likely, the biblical reference to lack of rain prior to the flood indicates a change in the weather system from what we currently have as well. A high-altitude canopy around the earth may have reduced solar penetration and water evaporation. No large oceans from which water would have evaporated would also contribute to this. Instead, more evenly distributed water in smaller lakes and rivers, and more even temperature distribution over the earth and throughout a given day, would have produced the much milder misting effect (dew) described in the Bible.
* The salty sea is an artifact saline concentration as salt is disolved from the earth and washed into the seas. It's possible the (smaller) pre-flood seas were much fresher, and the saline concentration of the sea developed in the aftermath of the flood. Also, in the less than a year the land was covered, it wouldn't be as heavily salted.
Actually, WINE implements the Win32 API, as do various versions of Windows, to varying degrees of compatibility. The fact that WINE's implementation is slightly less compatible than, say, Win95's, doesn't mean it is an emulator. Programs make direct calls to WINE just as they would to Win32. Or, they can be recompiled to use winelib, and actually become native Unix apps which happen to use another library.
Actually, you were right the first time. Luke presents Mary's lineage. See commentaries below:
http://www.christnotes.org/commentary.asp?ViewCo mm entary=Luke+3&Version=WES http://www.christnotes. org/commentary.asp?ViewComm entary=Luke+3&Version=MHC
From Wesley's commentary, "The son of Heli -- That is, the son-in-law: for Heli was the father of Mary. So St. Matthew writes the genealogy of Joseph, descended from David by Solomon; St. Luke that of Mary, descended from David by Nathan. In the genealogy of Joseph (recited by St. Matthew) that of Mary is implied, the Jews being accustomed to marry into their own families."
God is big enough to let you disagree with him-- Job, and the Psalms, show people who did. Unfortunately, many professed Christians aren't so tolerant.
As for the evidence for creationism and/or the flood, and discussion of God's methods in the O.T., email me if you are interested, as this thread has become off-topic (wdowns-nospam@iglooware-nospam.com, remove dashes and nospam)
I am well aware of the slaughter of entire tribes in certain cases. The fact that it was the exception rather than the rule (e.g. God condemned wholesale slaughter in many other cases) led me to try to determine why certain cases were not just allowed, but required.
I have concluded that in these cases, God was punishing these tribes for their long-term unrepented of sins. These tribes were known for their violence, human sacrifice (including innocent children), debasement and idolatry, etc., and had continued it so long that God apparently saw there was no longer any hope for them, and they would spread their black arts to the rest of humanity if left unchecked.
The example of the burning of Sodom, Gomorrah, and two other cities of the plain by God himself, is often looked at as an anti-homosexual act by God, but the Bible lists many other problems with those cities, among which were their own violence and disregard for human life.
Emulation doesn't have to take away from the native market. Buy native if it is available, but leave us with the choice of emulation for when it isn't.
This argument has been used many times against WINE. However, the existance of WINE for the last 10 years hasn't slowed the growth of native Linux applications. If anything it has helped.
In the case of drivers, very few hardware manufacturers provide native Linux drivers. I could probably count the chipsets on my fingers and toes. Most native drivers were written by enthusiasts, either with tacit approval of manufacturers, limited support (e.g. documentation), or reverse engineering.
Yes, companies may claim Linux compatibility where they had none before (and without lifting a finger to help). But that's better than the previous absense of support from that company. Companies don't make money on drivers, so there's no reason for them to add Linux support, unless they have Linux users. Once they gain users, they may consider making native drivers for the next generation of their hardware (to make the users happier). But unless they have some users, they won't bother.
Rather than coming using a proprietary DRM solution thought up by Microsoft, we would all be better off using PGP to encrypt your documents. That way, you can protect your information, without locking out other *authorized* users who happen to be using OpenOffice instead of MS Office.
If you actually read the rebuttal, you would see that though it does have a biased author, the rebuttal actually makes sense-- the flaws it points out in the original report clearly do exist. It doesn't matter whether the rebuttal's author is biased if the resulting rebuttal is factual.
Linux distributions try to interoperate with Windows-- but Microsoft's undocumented protocols make that hard to achieve. See the halloween documents for their motivations...
To get a Linux box on that same network, I need
to install SAMBA, configure the.conf file, run
some command line utils to join the domain,
configure PAM, get the init files working
Or use Mandrake, which automates all of the above steps. It appears from the description of the problems that the ZDNet people hadn't joined the domain, which Mandrake would have done automatically for them.
However, when you get to that step, you'll find you need the domain admin's password (same as joining a domain in Windows), and that's when you'll run into problems-- you'll have to let them know you're running Linux, installing your own OS, rather than letting them "reimage" your box for you as usual. Then you'll be running into political issues.
But that shouldn't be a problem for the ZDNet people, because they're not doing this "under the table".
Slashdot Mirror
I understand the usual time initialization process, having closely studied init scripts. Nonetheless, this depends on a time server being available (DSL, Cable, etc.) Many home users still don't have these even if they are available in their area.
I concur on the wear and tear of shutdowns and restarts-- but that doesn't mean you're going to get granny to stop doing it. And in general, your comparison to driving can only be taken so far-- as far as it pertains to hurting others. Granny's computer won't be much of a threat as long as it is firewalled off and not running Outlook.
And, even the worst Windows zombies don't do as much damage as a single intoxicated driver can do. Let's keep some perspective.
Back to my main point. If we simply tear down Michael Robertson's method without examining why he's doing it, we won't convince him to use a better method. It would be better to make some concessions and get Linspire to run most things as a non-root user, than to have a bunch of grannies running as root, becoming zombies, and dragging the reputation of Linux in the mud.
You're still thinking in server or workstation terms, always on, always connected, etc. Linspire is a *Desktop* system.
Yes, I know messing with the date can screw up compilation trees (timestamps dependencies), daemons, and many other things. But, desktop users are going to want to do it. Put them behind a firewall, then let them do what they want with their system.
I'm assuming you actually want to attract dumb users (as Linspire is trying to do). In that case, requiring a password to change the date is going to turn them off. Especially if it is not the one they normally use. If any password must be given, at least sudo should be used, so the password can be the user's own password.
As for the kid changing the clock, this points to the need for greater privilege granularity. I believe most users would want newly created accounts to, by default, allow dates to be changed without a password. But, as you point out, a parent might want accounts with even more restricted privileges. For that matter, a parent may want a kid's account to not be able to download and run software, even as their own user. Or not be able to listen on a port (not even a non-privileged port). Thus, the need for greater granularity.
Another post mentioned that SELinux is working on this. Hopefully it comes to general Linux soon.
Ideally, the system would suspend the application while the user received a descriptive message of what the program was trying to do, at a high level. The administrator could then configure the app by running it with no privileges initially, but clicking "Allow Always" for each allowed operation, exercising each feature of the program that the users need, then capture that configuration and apply it to all users.
Users could (if allowed by their own account) also grant privileges (up to what their account had) for functions the system admin may have neglected to exercise. However, they would probably soon get annoyed by clicking dialogs and ignore what they said, so admins would in that case do well to make sure the user had few privileges and the app was already preconfigured properly.
I haven't seen a rebuttal that gives a good solution yet. Michael Robertson is right about data being the most important, but seems to think that having users run as non-root means that changing the date will require a password (which is a "no no" for ease of use).
This problem can easily be solved by making all non-critical configuration tasks (e.g. setting the date) run using sudo behind the scenes. Changing the date as a non-root user shouldn't require a root password (unless you're real paranoid about bugs in your date setting code allowing crackers to exploit date-triggered viruses, or something...)
As for requiring a password, the only real solution is biometric, and that will be a while in coming. But most grannies aren't going to be changing hardware settings unless they are comfortable entering passwords. And if they aren't, they shouldn't be changing hardware settings anyway...
It's not OSS, but there are many inexpensive (or free) websites which provide tax services, and work on open source browsers. I personally use Tax ACT, which is free for paper-based taxes and $8-$10 for e-filing.
JSON is the notation-- you can use a hidden IFRAME instead, for better compatibility with older browsers.
My generalized JScript library was created for in-house use, but is languishing unused at the moment. It might be possible to get it released, though it would take some cleanup to make it truly generalized. If you're still interested, email me at DownsWE at muni dot org. I could at least give you some more details how I went about it.
I had seen this a few months ago, and had put together a system using a java-based JScript implementation on the server, so JSON could be evaluated both ways. It was pretty slick, being able to write a web app in entirely JScript (which is a pretty powerful language once you get to know it, naysayers notwithstanding). I had a generalized JScript library loaded client side which could produce menus and set form values from the server automatically.
On the other hand, if your page is mostly data which will be changing (e.g. a database-backed web form), the vaunted performance isn't that much better than just slimming your HTML using CSS. And if you just use simple HTML (with CSS), you can have something which also works on lynx or older browsers, while still looking sharp on Firefox/IE/Safari/Opera/etc.
The ideal palmtop for me needs to have a VGA port able to output at least 640x480 or greater (for presentations, without having to carry a laptop) and at least one, preferably two mini-USB ports for keyboard and mouse (and also usable for charging and data transfer).
I would expect to be able to hook up external VGA, keyboard and mouse and start using it like a desktop. Ideally, with bluetooth+ and appropriate software, future versions could automatically connect to your handheld environment when you walk up to a desktop computer, but that's probably a way off.
The palmtop should have a mini-keyboard with clamshell case design and mini-VGA (at least 640x480) color screen usable for watching movies. It should have built in speaker, mic, and separate headphone and microphone jacks. The audio jacks should be accessible with the case closed (e.g. for jogging). The screen should power off when the case is closed but leave the CPU running. A separate power button inside the clamshell case should suspend/instant resume.
Storage should preferably be solid state to avoid motion damage, at least 10 Gb built in, with option to extend with CF and SD.
CPU should be fast enough to handle speech synthesis and recognition but able to scale back power when heavy processing is not being done.
The device should be rugged enough to withstand a drop from 3-4 feet (pocket to waist level), and water resistant to e.g. rain while jogging. It should have a (possibly removable) belt-clip on the back.
Battery life should be at least 24 hours continuous use, but a week of day use (e.g. 80+ hours in blocks of 12 or so) would be nice.
All this should be crammed into a device at least as small as the zaurus 5500, which I carry with me regularly. Phone capability should be built in (with microphone and speaker positioned conveniently for such), and Wi-Fi would be nice, but could be an add-on using the CF slot.
I don't expect to see this device in the near future, but it is the direction I hope to see palmtops heading. When it does arrive, it will probably be out of my price range for a while, but if a device like this cost around $200, it would sell. Don't expect to see it manufactured at that (or any) price until significantly more miniaturization occurs, though.
So, to summarize, The palmtop should be small enough to carry all the time, but have all the capacity needed for multimedia files and a complete set of desktop software, and all the CPU needed to run it. When desktop computers or projectors are available, the handheld should be able to interface with them using standard ports (instead of having to have a docking station).
Regarding your sig, "If you don't like it, ignore it. All negative mods are meta-moderated 'unfair'. ALL OF THEM." I would just like to point out why I think your meta-moderation is misguided.
The current moderation system has a top limit of +5. However, since slashdot has so many posters these days, there can easily be 50+ posts moderated at that level. For this reason, I ALWAYS moderate down, never up, so as to reduce the number of +5 moderations. As such, I'm not usually moderating because I don't like something, just because I think it is less qualified to be +5 than some of the other posts which made it to that level.
are the competition even if they have low marketshare, because they aim for the kinds of user Linspire aims for, and have many similarities feature-wise.
However, in my personal comparison of all three, Xandros with integrated Crossover Office is the only real competition (Lycoris had quite a few issues, and a very limited selection of software, not being debian-based).
Advantages of Xandros were auto-run of Windows install CDs with easy integration of Windows apps (at least those that work under Crossover Office), and the Xandros file manager (with integrated CD ripping and burning, which is really cool and nicer than Windows XPs).
Disadvantages of Xandros were, it hung when a Dell Axim PocketPC was plugged in (during KDE startup), and it couldn't get through my corporate firewall to download updates (though browsing through the firewall works fine).
Long story short: Xandros was slightly easier to use (when it works) but Linspire's CNR is nicer, has a wider selection of software (yes, this could change), and works through a firewall (though it had some hassle getting that set up as well).
* The bird came from inside the ark. A shoot of an olive tree would have had time to sprout after the water receded (200 days or so). Of course, some marine life lived through the flood. Only basic types of animal, bird and insect life would have been taken into the ark. (e.g. one pair of a prototypical dog-like animal containing all the genetic information necessary to create modern dogs, wolves, coyotes, dingoes, etc.) The genetic diversity we see in animals today doesn't mean there wasn't a single prototypical ancestor for many of them, which was taken into the ark. The only issue is how fast the diversification could have occurred, within one type of animal/bird/insect.
* Prior to the flood, most likely all continents were contiguous land. Large amounts of water may have been under the earth's crust acting as a fluid coolant and heat carrier to the earth's radioactive core. This would also have warmed the surface of the earth more evenly, explaining why we find tropical fossils at the polar regions. Perhaps an asteroid hit caused major damage to the earth's crust. The Bible refers to the "fountains of the great deep" breaking up, so rain wasn't the only source of water.
* As for time required for plate tectonics, that is assuming current constant rates without a catastrophe occuring, which could significantly accelerate rates of plate drift, erosion, etc.
* High temperatures/low humidity, I assume you are referring to current climate in the Ararat region. A catastrophe of this magnitude, and the ensuing ice ages which occurred (yes, after the flood), would have changed the climate drastically. Most likely, the biblical reference to lack of rain prior to the flood indicates a change in the weather system from what we currently have as well. A high-altitude canopy around the earth may have reduced solar penetration and water evaporation. No large oceans from which water would have evaporated would also contribute to this. Instead, more evenly distributed water in smaller lakes and rivers, and more even temperature distribution over the earth and throughout a given day, would have produced the much milder misting effect (dew) described in the Bible.
* The salty sea is an artifact saline concentration as salt is disolved from the earth and washed into the seas. It's possible the (smaller) pre-flood seas were much fresher, and the saline concentration of the sea developed in the aftermath of the flood. Also, in the less than a year the land was covered, it wouldn't be as heavily salted.
Just some thoughts, theories, and observations...
Someone else already mentioned it, but use aumix to set the volume (command line utility). For some reason, other mixers sometimes fail.
Actually, WINE implements the Win32 API, as do various versions of Windows, to varying degrees of compatibility. The fact that WINE's implementation is slightly less compatible than, say, Win95's, doesn't mean it is an emulator. Programs make direct calls to WINE just as they would to Win32. Or, they can be recompiled to use winelib, and actually become native Unix apps which happen to use another library.
Apparently mozilla.org got tired of the Slashdot effect. You can work around it by copying the original link and pasting it in a new window.
Actually, you were right the first time. Luke presents Mary's lineage. See commentaries below:
o mm entary=Luke+3&Version=WES. org/commentary.asp?ViewComm entary=Luke+3&Version=MHC
http://www.christnotes.org/commentary.asp?ViewC
http://www.christnotes
From Wesley's commentary, "The son of Heli -- That is, the son-in-law: for Heli was the father of Mary. So St. Matthew writes the genealogy of Joseph, descended from David by Solomon; St. Luke that of Mary, descended from David by Nathan. In the genealogy of Joseph (recited by St. Matthew) that of Mary is implied, the Jews being accustomed to marry into their own families."
So your second point in your first post stands.
God is big enough to let you disagree with him-- Job, and the Psalms, show people who did. Unfortunately, many professed Christians aren't so tolerant.
As for the evidence for creationism and/or the flood, and discussion of God's methods in the O.T., email me if you are interested, as this thread has become off-topic (wdowns-nospam@iglooware-nospam.com, remove dashes and nospam)
I just now finally read this response.
I am well aware of the slaughter of entire tribes in certain cases. The fact that it was the exception rather than the rule (e.g. God condemned wholesale slaughter in many other cases) led me to try to determine why certain cases were not just allowed, but required.
I have concluded that in these cases, God was punishing these tribes for their long-term unrepented of sins. These tribes were known for their violence, human sacrifice (including innocent children), debasement and idolatry, etc., and had continued it so long that God apparently saw there was no longer any hope for them, and they would spread their black arts to the rest of humanity if left unchecked.
The example of the burning of Sodom, Gomorrah, and two other cities of the plain by God himself, is often looked at as an anti-homosexual act by God, but the Bible lists many other problems with those cities, among which were their own violence and disregard for human life.
Emulation doesn't have to take away from the native market. Buy native if it is available, but leave us with the choice of emulation for when it isn't.
Choice is a good thing.
This argument has been used many times against WINE. However, the existance of WINE for the last 10 years hasn't slowed the growth of native Linux applications. If anything it has helped.
In the case of drivers, very few hardware manufacturers provide native Linux drivers. I could probably count the chipsets on my fingers and toes. Most native drivers were written by enthusiasts, either with tacit approval of manufacturers, limited support (e.g. documentation), or reverse engineering.
Yes, companies may claim Linux compatibility where they had none before (and without lifting a finger to help). But that's better than the previous absense of support from that company. Companies don't make money on drivers, so there's no reason for them to add Linux support, unless they have Linux users. Once they gain users, they may consider making native drivers for the next generation of their hardware (to make the users happier). But unless they have some users, they won't bother.
Rather than coming using a proprietary DRM solution thought up by Microsoft, we would all be better off using PGP to encrypt your documents. That way, you can protect your information, without locking out other *authorized* users who happen to be using OpenOffice instead of MS Office.
If you actually read the rebuttal, you would see that though it does have a biased author, the rebuttal actually makes sense-- the flaws it points out in the original report clearly do exist. It doesn't matter whether the rebuttal's author is biased if the resulting rebuttal is factual.
Linux distributions try to interoperate with Windows-- but Microsoft's undocumented protocols make that hard to achieve. See the halloween documents for their motivations...
Or use Mandrake, which automates all of the above steps. It appears from the description of the problems that the ZDNet people hadn't joined the domain, which Mandrake would have done automatically for them.
However, when you get to that step, you'll find you need the domain admin's password (same as joining a domain in Windows), and that's when you'll run into problems-- you'll have to let them know you're running Linux, installing your own OS, rather than letting them "reimage" your box for you as usual. Then you'll be running into political issues.
But that shouldn't be a problem for the ZDNet people, because they're not doing this "under the table".