There is nothing precluding natural selection from being compatible with 'Intelligent Design'. All Intelligent Design requires that at the ultimate end of the chain of events is set in motion by a higher power. Random mutations become planned mutations. Random meteor strike changing environment drastically is no longer a random misfortune. Etc. At least in theory it doesn't necessarily preclude anything scientific.
Essentially, Intelligent Design is more in the realm of a philosophy/theology that can never be disproven/proven due to its very nature of being incredibly abstracted from anything remotely quantifiable. Ok, so I guess theoretically it could be proven if the higher power chose to intervene rather obviously, so it is only impossible to disprove. Regardless, it is almost certainly going to forever remain in the realm outside of the pursuit of science.
From a scientific perspective, I would say they can mention all they want about philosophy so long as the terms are abstract for different religions and do not teach people to disbelieve the actual scientific theory in favor of 'God spoke, and bang, it happened'. For a scientist to be upset about discussions on a level where scientific evidence doesn't play a role is not a defensible, objective position. Whether you believe in God, randomness, The FSM, or anything else, that is a personal belief choice and not a scientific thought.
As much as I would love to embrace that line of logic, it simply doesn't make sense. It has the central assumption that the standard quality of living is equal in the two countries. The assumption is false, and the whole argument falls apart. The average life in America is somewhat cushier than the average life in India.
Apple is announcing it's *fourth* quarter results? That's quite amazing, seeing as how fiscal third quarters ended recently and fourth has barely begun. Must be nice knowing what will happen so far in advance.
While distros of the UnitedLinux family were not the same, they were so similar as to be near pointless. If they did differentiate too much, they would pose dilemmas to third-party developers in how to proceed.
Let's use the example of Xandros and the additional features. To a great extent, many of the features you described *should* be transparent. But let's say some enterprise application releases, which could make sense to deal with AD, but not a hard requirement. They face the dilemma of whether to hook into the Xandros-specific ADC support or to skip the feature and be DCC compliant. If they are DCC compliant, they are viewed as lacking a useful feature in Xandros. If they write to Xandros, users will complain they are Xandros-specific when there is the DCC. So third-party development will still be stuck with very similar dilemmas they face today (I don't think the DCC will impact commercial ISV adoption btw, the combined market share of all the members with respect to the professional engineering workspace is too small, sadly). Whatever the case, while simple applications sacrifice nothing to be DCC-compliant, overwhelmingly applications are becoming more complex than the base DCC dare restrict distributions.
The fact also remains that despite your examples of things Xandros can do without deviating, you don't address the point that there are some potentially significant things to particular distributions would want to do that would be impossible when adhering to such a standard, such as a hypothetical GCC release with ObjC++ support that would only matter for an oddball distro that wants to do something aggressive with GNUstep and open source OSX apps. This is just an example I'm familiar with, I'm sure there are many more. In short, if the glibc/GCC/etc choices don't really matter in defining the user experience and should therefore be considered a choice easily given up by distros, why is there any development going on there? The answer is the development is justified and yields end-user experience benefits.
In short, the dilemma to third-party developers is not sufficiently reduced to yield high benefit, while at the same time the restrictions can impact significantly the ability to differentiate depending on the distribution's goals. While all this is going on, effort has to be exerted by the developers to ensure adherence, slowing progress. Ubuntu's choice to abstain from DCC is pretty defensible, and with precendent, UnitedLinux suffered and fell apart, at least partially because of the same reasons Shuttleworth predicts DCC will fail. Best case it degenerates into the top market share member calling the shots anyway, so the practice of cloning with respect for backward compatibility ultimately acheives the same goal as the consortium anyway.
I don't think the distribution people are ignorant to these points, I just think they are overly optimistic about how it will work out. There was a reason in the first place they wanted their own distro, so they obviously have some difference in opinion with core Debian that has a decent chance of conflicting with the DCC at some point.
I'm glad to see that explanation. A lot of people gave Ubuntu flak for not being part of it.
Honestly, I agree with him. It has marginal chance of success over the attempt that was UnitedLinux, by not having the commercial interest muddying the waters. However, the crux of the problem is that it flies somewhat in the face of the whole point of different distributions. The theory may be that distros distinguish themselves at a higher level and by forcing common underpinnings doesn't impact the ability to differentiate, but if that were truly the case, there wouldn't be such variation today.
For example, let's assume a member of the DCC is a tad more enthusiastic about GNUstep than the others. Hypothetically, GCC 4.2 releases with ObjC++ support as a significant feature. That distro may want to break with the conservative members to provid the GCC that would allow easier porting of a wider range of OSX apps. What's perceived commonly as a 'boring underpinning' becomes a potential significant factor in differentiation for a distro, but requires breaking compatibility with the rest of DCC.
Just as UnitedLinux made it impossible for the members to meaningly be different, everything ending up essentially being SuSE with different artwork and corporate propoganda, the DCC just simply can't occur and preserve meaningfully unique identies of member distributions.
Debian has always been about open source, and by not even having the illusion of binary compatibility amongst them, it perhaps encourages practices of distributing description files, tarballs, and diffs rather than binary.deb packages...
Most people seem to be assuming he is dismissing software design specs, which has nothing to do with his discussion.
His puported viewpoint is to be taken in the context of a hardware vendor spec on how to interface with hardware. There is a significant amount of truth in this. Hardware vendors will live by specs when they need to. I.e. they adhere to PCI specs, they adhere to drive-controller specs. They are careful about areas where they communicate on a bus or channel to arbitrary other vendor hardware.
However, the interface between the OS and the piece of equipment will almost always have poor specs. They are usually designed at the start of the design of things, and then while working the reality shifts from the spec. Unless going for some sort of standardization (i.e. IETF and such), the spec is rarely updated even in the face of significant change. At that point the reference implementation is the only thing anyone is maintaining and the only thing that particularly matters.
On the other hand, at least you know where they are coming from. Ultimately, an ideal world has a vendor releasing both specs and their reference implementation.
SuSE/Novell and RedHat Enterprise products (and derivatives), among other goals, aim to do exactly what you describe, grab some arbitrary, yet recent kernel and only take bugfixes.
Ugh, nothing but gaim with meanwhile for me: http://meanwhile.sourceforge.net/plugins/ (The plugin to interface with the IBM employee directory is nice thing to find on the internal web). NotesBuddy is just another piece of Windows crap.
Now if they could only give me a way to read my friggin' mail under linux without wine, and, even more importantly, without notes.
The point is not to clone all aspects or to have the expectation of universally simply recompiling complex apps, but to provide a development environment and user environment with a lot of the features. Despite a great deal of work on Apples side, there is still a great deal of common API, so that if the community wrote their apps as much as possible to the common APIs, GNUstep would be able to offer a great deal while simultaneously giving those Apps the opportunity to run in OSX. Focus on GNUstep/Cocoa common API and there is still a great deal of flexibility to be had.
From the end-user's perspective, they aren't as drastically different as one would think at first glance. Make GNUstep shiny, change the menus to shiny and horizontal, tack a shelf feature onto a dock with a little enhancement visually, and you are actually relatively close. Most important aspect is the feel more than the look, and conceptually nextstep/gnustep apps are similar to arbitrary Mac apps (persistant menu, HIG standards, etc).
Could large application with huge codebase written with only in OSX be simply recompiled with GNUstep? Almost certainly not, for the reasons mentioned, but it does not mean that those who feel the Apple OS design are without options in alternatives.
BTW, I think comparing version numbers at all is relatively silly, but particularly Darwin vs. OpenStep seems silly, since most of the meat of the Step-like stuff from an API/user perspective is at a different layer anyway.
The bottom line for me is that it moderately frustrates me that GNOME and KDE receive so much effort and attention, which falls more in the area of the MS Windows interface paradigm, while GNUstep is a path to a really interesting alternative. I am not claiming GNOME or KDE to be Windows clones, just that the way applications/windows/menus in general are managed is far more Windows-like than Mac-like.
There seems to be a lot of excitement of cracking OSX to run on generic hardware. Seems like a painful waste of effort fighting Apple to keep OSX running on the hardware of your choice again and again before any shiplevel software is to be seen.
For those that really want to hack OSX in a meaningful way, don't pursue the developer builds in any public way. Feel free to privately figure out, but know that as soon as you try to cash in and brag and demonstrate your hack, the next developer build will just overcome it and obsolete previous builds (since no non-developer end-users are supposed to have it they can do it). If everyone managed to hold back their hacks until a publicly available release with real end-users was out, they couldn't so readily break compatiblity.
But if the developers want to scratch their itch in a more constructive way long term without having to fight a company with conflicting goals over the platform, GNUstep is certainly a project that could benefit from the effort. I use a GNUstep based environment as much as possible, and with some TLC, you could have a relatively OSX-like environment complete with mostly compatible API for applications. Their are some little rough spots, but primarily it lacks in a sophisticated look (improve camaelon) and some nicely-fitting aplications (using GNUStep apps is nice, but jarring when you go to an appl like firefox or gaim that doesn't behave GNUstep-ish.
Sure if most people had lethal weapons handy all the time, the occasional shocking anomaly of a single person or small group of people killing many people because no one was equipped to stop them.
However, at the same time, the huge number of altercations that given a handly lethal weapon would become homicide would take a horrid turn for the worse. Even mild fear that normally pass without incident may result in violent escalation from people getting weapons ready, 'just in case'.
The sad truth is that, by large, individual people just can't be relied upon to handle overtly lethal weapons responsibly. If you compare the number of people killed in Columbine and 9/11 circumstances to people killed in violent altercations where lethal weapons were convenient in the heat of the moment, by far people should be more cautious of omnipresent weapons.
9/11 happened not because the terrorists were able to have particularly lethal weapons and that the passengers were ill-equipped to handle them. It happened because the people aboard the plane had no idea of the plan or the stakes, or even the possibility of the plane being used on a suicide mission. Before then, people hijacking planes were seeking to use them to get themselves to safety. With that perceived plan in mind, the most safe plan was to acquiesce to their demands. Same situation occurs today, some passenger/passengers will react with less conservative responses and a plane full of people unarmed will not let a handful of blade-wielding people succeed anymore.
Columbine happened, in part, due to ready availibity of firearms. If they had been only able to acquire, say, knives, they would've accomplished a much less sever atrocity. Granted, people determined in such a way to commit such an atrocity may not have been stopped by gun control laws, but in acquiring them they might have been caught earlier. I'm not saying they obtained the firearms legally, just that they legally got much closer to them and made them more accessible than they might have otherwise been with much less visibility to law enforcement agencies.
Anyway, the reduction in freedoms as spelled out in the PATRIOT act and in the UK are particularly intrusive and ineffective against the puported target, so your point is in general valid. It is just that encouraging universal lethal wepon proliferation is not a net good idea for ensuring better security.
The article's point was that things are more disastarous because humanity has such density. This means that while the insurance cost was high to the insurance companies, the insurance companies at the same time have a larger customer base to support these situations. The article didn't conclude that over the long haul natural disasters have increased in power or frequency, simply that more people and property are in the way and produce horrificly worse numbers.
I wouldn't have the nets in a way that could be tangled up in unless being deployed (maybe in recessies that come open on deployment but stay closed and mostly smooth otherwise.
Particularly if you don't immediately use such an exchange to send anything sensitive, and you connect a day later while both are at different locations, the probablity that someone was eavesdropping is reduced.
But the true strength would be over some independent, hard to modify channel verify the key fingerprints. You make a phone call or skype session and validate the key that made it all the way unmolested. Hard to change a voice convincingly on the fly to say something completely different. Even sending the text as payload would be enough for most things, but it would then be feasible for it to anylze IM payload to try to detect and modify such challenges.
In the long run, I've never relied on gaim-encryption for much important, but it would be highly difficult to keep hijacked an even moderately mobile set of people who use multiple machines with the same key without them noticing..
There is no full proof way to do it really. With a CA or web of trust, it can be falsified, so long as any one member of the 'web of trust' or one CA can be duped, the system becomes flawed, and gives false sense of security.
There isn't some magical 'talking about logical fallacy' mode of conversation. There are occasionally opportunities to use it in normal speech in which confusion could ensue. One example recently when talking to a developer about a feature in their project: Him:It doesn't matter that the feature doesn't perfectly work right, it's being removed in the next version. Me:The problem is that people use that feature a lot and will be unhappy it'll be gone. Him:They shouldn't be using it and therefore they shouldn't miss it. Me:Why is that? Him:Because it is going to be gone in the next release Me:You're begging the question. Him:What question is that?
Here, I used correctly the phrase begging the question, but he entirely missed the point assuming the 'common usage'.
It is not unheard of to have words with multiple distinct meanings (bat being a prime example), but usually the meanings are used in fairly distinct contexts. For example, bat as in something to hit things with versus a flying rodent, the contexts tend to be different, however if you used the word ball to describe something to hit things with, then baseball would be uselessly confusing.
That is my most *hated* expansion of acronym RAID.
Adminittedly, there is no suitable expansion for RAID when you consider RAID-0 (unless you make it recursive...).
Who says they are the least bit inexpensive? There is nothing about the technology that is inherently tied to expense in that sort of way.... However, the technology does involved things that are *I*ndependent of each other and the concept is central to the points of RAID....
While I'm at it, there is nothing particularly disk-specific either. I've never seen anyone but me question this, but strictly speaking the D would be better expanded as 'Devices' than 'Disks'.
Which leaves R for Redundant, which doesn't apply to RAID-0, but it is descriptive for everything but RAID-0, and I can't think of a better fit, so:
Redundant Array of Independent Devices
Is a much more relevant description of RAID... Just my two cents.
Though diskless workstations were very very common in *nix networks of the late 80s/early 90s (disks were *huge* physically and the only feasible approach was to have them somewhere far from the workstations and share them), the amount of the base system that ran in memory was typically just the kernel, which had the network support built in and booted nfsroot. As constrained hard drives were, memory was even tighter back then, consuming it as a ramdisk would've made the systems much less powerful.
Ahh, the days of running systems nfs off of 10base5 hub networks connecting to the huge servers with the 540 meg hard drives that took more than 4U (been so long, cant remember) each.
Slashdot Mirror
There is nothing precluding natural selection from being compatible with 'Intelligent Design'. All Intelligent Design requires that at the ultimate end of the chain of events is set in motion by a higher power. Random mutations become planned mutations. Random meteor strike changing environment drastically is no longer a random misfortune. Etc. At least in theory it doesn't necessarily preclude anything scientific.
Essentially, Intelligent Design is more in the realm of a philosophy/theology that can never be disproven/proven due to its very nature of being incredibly abstracted from anything remotely quantifiable. Ok, so I guess theoretically it could be proven if the higher power chose to intervene rather obviously, so it is only impossible to disprove. Regardless, it is almost certainly going to forever remain in the realm outside of the pursuit of science.
From a scientific perspective, I would say they can mention all they want about philosophy so long as the terms are abstract for different religions and do not teach people to disbelieve the actual scientific theory in favor of 'God spoke, and bang, it happened'. For a scientist to be upset about discussions on a level where scientific evidence doesn't play a role is not a defensible, objective position. Whether you believe in God, randomness, The FSM, or anything else, that is a personal belief choice and not a scientific thought.
As much as I would love to embrace that line of logic, it simply doesn't make sense. It has the central assumption that the standard quality of living is equal in the two countries. The assumption is false, and the whole argument falls apart. The average life in America is somewhat cushier than the average life in India.
Can it make the Kessel run in less than 12 parsecs?
Today would be the day I actually try to RTFA.... *shudder*
Apple is announcing it's *fourth* quarter results? That's quite amazing, seeing as how fiscal third quarters ended recently and fourth has barely begun. Must be nice knowing what will happen so far in advance.
While distros of the UnitedLinux family were not the same, they were so similar as to be near pointless. If they did differentiate too much, they would pose dilemmas to third-party developers in how to proceed.
Let's use the example of Xandros and the additional features. To a great extent, many of the features you described *should* be transparent. But let's say some enterprise application releases, which could make sense to deal with AD, but not a hard requirement. They face the dilemma of whether to hook into the Xandros-specific ADC support or to skip the feature and be DCC compliant. If they are DCC compliant, they are viewed as lacking a useful feature in Xandros. If they write to Xandros, users will complain they are Xandros-specific when there is the DCC. So third-party development will still be stuck with very similar dilemmas they face today (I don't think the DCC will impact commercial ISV adoption btw, the combined market share of all the members with respect to the professional engineering workspace is too small, sadly). Whatever the case, while simple applications sacrifice nothing to be DCC-compliant, overwhelmingly applications are becoming more complex than the base DCC dare restrict distributions.
The fact also remains that despite your examples of things Xandros can do without deviating, you don't address the point that there are some potentially significant things to particular distributions would want to do that would be impossible when adhering to such a standard, such as a hypothetical GCC release with ObjC++ support that would only matter for an oddball distro that wants to do something aggressive with GNUstep and open source OSX apps. This is just an example I'm familiar with, I'm sure there are many more. In short, if the glibc/GCC/etc choices don't really matter in defining the user experience and should therefore be considered a choice easily given up by distros, why is there any development going on there? The answer is the development is justified and yields end-user experience benefits.
In short, the dilemma to third-party developers is not sufficiently reduced to yield high benefit, while at the same time the restrictions can impact significantly the ability to differentiate depending on the distribution's goals. While all this is going on, effort has to be exerted by the developers to ensure adherence, slowing progress. Ubuntu's choice to abstain from DCC is pretty defensible, and with precendent, UnitedLinux suffered and fell apart, at least partially because of the same reasons Shuttleworth predicts DCC will fail. Best case it degenerates into the top market share member calling the shots anyway, so the practice of cloning with respect for backward compatibility ultimately acheives the same goal as the consortium anyway.
I don't think the distribution people are ignorant to these points, I just think they are overly optimistic about how it will work out. There was a reason in the first place they wanted their own distro, so they obviously have some difference in opinion with core Debian that has a decent chance of conflicting with the DCC at some point.
That not all of the hardware is usable under the included OS, FreeDOS.
I'm glad to see that explanation. A lot of people gave Ubuntu flak for not being part of it.
.deb packages...
Honestly, I agree with him. It has marginal chance of success over the attempt that was UnitedLinux, by not having the commercial interest muddying the waters. However, the crux of the problem is that it flies somewhat in the face of the whole point of different distributions. The theory may be that distros distinguish themselves at a higher level and by forcing common underpinnings doesn't impact the ability to differentiate, but if that were truly the case, there wouldn't be such variation today.
For example, let's assume a member of the DCC is a tad more enthusiastic about GNUstep than the others. Hypothetically, GCC 4.2 releases with ObjC++ support as a significant feature. That distro may want to break with the conservative members to provid the GCC that would allow easier porting of a wider range of OSX apps. What's perceived commonly as a 'boring underpinning' becomes a potential significant factor in differentiation for a distro, but requires breaking compatibility with the rest of DCC.
Just as UnitedLinux made it impossible for the members to meaningly be different, everything ending up essentially being SuSE with different artwork and corporate propoganda, the DCC just simply can't occur and preserve meaningfully unique identies of member distributions.
Debian has always been about open source, and by not even having the illusion of binary compatibility amongst them, it perhaps encourages practices of distributing description files, tarballs, and diffs rather than binary
Most people seem to be assuming he is dismissing software design specs, which has nothing to do with his discussion.
His puported viewpoint is to be taken in the context of a hardware vendor spec on how to interface with hardware. There is a significant amount of truth in this. Hardware vendors will live by specs when they need to. I.e. they adhere to PCI specs, they adhere to drive-controller specs. They are careful about areas where they communicate on a bus or channel to arbitrary other vendor hardware.
However, the interface between the OS and the piece of equipment will almost always have poor specs. They are usually designed at the start of the design of things, and then while working the reality shifts from the spec. Unless going for some sort of standardization (i.e. IETF and such), the spec is rarely updated even in the face of significant change. At that point the reference implementation is the only thing anyone is maintaining and the only thing that particularly matters.
On the other hand, at least you know where they are coming from. Ultimately, an ideal world has a vendor releasing both specs and their reference implementation.
http://www.nytimes.com/2005/09/28/science/28squid. html?8hpib
SuSE/Novell and RedHat Enterprise products (and derivatives), among other goals, aim to do exactly what you describe, grab some arbitrary, yet recent kernel and only take bugfixes.
Ugh, nothing but gaim with meanwhile for me:
http://meanwhile.sourceforge.net/plugins/
(The plugin to interface with the IBM employee directory is nice thing to find on the internal web). NotesBuddy is just another piece of Windows crap.
Now if they could only give me a way to read my friggin' mail under linux without wine, and, even more importantly, without notes.
The point is not to clone all aspects or to have the expectation of universally simply recompiling complex apps, but to provide a development environment and user environment with a lot of the features. Despite a great deal of work on Apples side, there is still a great deal of common API, so that if the community wrote their apps as much as possible to the common APIs, GNUstep would be able to offer a great deal while simultaneously giving those Apps the opportunity to run in OSX. Focus on GNUstep/Cocoa common API and there is still a great deal of flexibility to be had.
From the end-user's perspective, they aren't as drastically different as one would think at first glance. Make GNUstep shiny, change the menus to shiny and horizontal, tack a shelf feature onto a dock with a little enhancement visually, and you are actually relatively close. Most important aspect is the feel more than the look, and conceptually nextstep/gnustep apps are similar to arbitrary Mac apps (persistant menu, HIG standards, etc).
Could large application with huge codebase written with only in OSX be simply recompiled with GNUstep? Almost certainly not, for the reasons mentioned, but it does not mean that those who feel the Apple OS design are without options in alternatives.
BTW, I think comparing version numbers at all is relatively silly, but particularly Darwin vs. OpenStep seems silly, since most of the meat of the Step-like stuff from an API/user perspective is at a different layer anyway.
The bottom line for me is that it moderately frustrates me that GNOME and KDE receive so much effort and attention, which falls more in the area of the MS Windows interface paradigm, while GNUstep is a path to a really interesting alternative. I am not claiming GNOME or KDE to be Windows clones, just that the way applications/windows/menus in general are managed is far more Windows-like than Mac-like.
There seems to be a lot of excitement of cracking OSX to run on generic hardware. Seems like a painful waste of effort fighting Apple to keep OSX running on the hardware of your choice again and again before any shiplevel software is to be seen.
For those that really want to hack OSX in a meaningful way, don't pursue the developer builds in any public way. Feel free to privately figure out, but know that as soon as you try to cash in and brag and demonstrate your hack, the next developer build will just overcome it and obsolete previous builds (since no non-developer end-users are supposed to have it they can do it). If everyone managed to hold back their hacks until a publicly available release with real end-users was out, they couldn't so readily break compatiblity.
But if the developers want to scratch their itch in a more constructive way long term without having to fight a company with conflicting goals over the platform, GNUstep is certainly a project that could benefit from the effort. I use a GNUstep based environment as much as possible, and with some TLC, you could have a relatively OSX-like environment complete with mostly compatible API for applications. Their are some little rough spots, but primarily it lacks in a sophisticated look (improve camaelon) and some nicely-fitting aplications (using GNUStep apps is nice, but jarring when you go to an appl like firefox or gaim that doesn't behave GNUstep-ish.
Your examples are kind of frightening tradeoffs.
Sure if most people had lethal weapons handy all the time, the occasional shocking anomaly of a single person or small group of people killing many people because no one was equipped to stop them.
However, at the same time, the huge number of altercations that given a handly lethal weapon would become homicide would take a horrid turn for the worse. Even mild fear that normally pass without incident may result in violent escalation from people getting weapons ready, 'just in case'.
The sad truth is that, by large, individual people just can't be relied upon to handle overtly lethal weapons responsibly. If you compare the number of people killed in Columbine and 9/11 circumstances to people killed in violent altercations where lethal weapons were convenient in the heat of the moment, by far people should be more cautious of omnipresent weapons.
9/11 happened not because the terrorists were able to have particularly lethal weapons and that the passengers were ill-equipped to handle them. It happened because the people aboard the plane had no idea of the plan or the stakes, or even the possibility of the plane being used on a suicide mission. Before then, people hijacking planes were seeking to use them to get themselves to safety. With that perceived plan in mind, the most safe plan was to acquiesce to their demands. Same situation occurs today, some passenger/passengers will react with less conservative responses and a plane full of people unarmed will not let a handful of blade-wielding people succeed anymore.
Columbine happened, in part, due to ready availibity of firearms. If they had been only able to acquire, say, knives, they would've accomplished a much less sever atrocity. Granted, people determined in such a way to commit such an atrocity may not have been stopped by gun control laws, but in acquiring them they might have been caught earlier. I'm not saying they obtained the firearms legally, just that they legally got much closer to them and made them more accessible than they might have otherwise been with much less visibility to law enforcement agencies.
Anyway, the reduction in freedoms as spelled out in the PATRIOT act and in the UK are particularly intrusive and ineffective against the puported target, so your point is in general valid. It is just that encouraging universal lethal wepon proliferation is not a net good idea for ensuring better security.
The article's point was that things are more disastarous because humanity has such density. This means that while the insurance cost was high to the insurance companies, the insurance companies at the same time have a larger customer base to support these situations. The article didn't conclude that over the long haul natural disasters have increased in power or frequency, simply that more people and property are in the way and produce horrificly worse numbers.
I wouldn't have the nets in a way that could be tangled up in unless being deployed (maybe in recessies that come open on deployment but stay closed and mostly smooth otherwise.
Could have nets, less chance of pushing the drowning person aside than bringing them up.
Particularly if you don't immediately use such an exchange to send anything sensitive, and you connect a day later while both are at different locations, the probablity that someone was eavesdropping is reduced.
But the true strength would be over some independent, hard to modify channel verify the key fingerprints. You make a phone call or skype session and validate the key that made it all the way unmolested. Hard to change a voice convincingly on the fly to say something completely different. Even sending the text as payload would be enough for most things, but it would then be feasible for it to anylze IM payload to try to detect and modify such challenges.
In the long run, I've never relied on gaim-encryption for much important, but it would be highly difficult to keep hijacked an even moderately mobile set of people who use multiple machines with the same key without them noticing..
There is no full proof way to do it really. With a CA or web of trust, it can be falsified, so long as any one member of the 'web of trust' or one CA can be duped, the system becomes flawed, and gives false sense of security.
Counterbalance that global warming with some nuclear winters! Works every time.
There isn't some magical 'talking about logical fallacy' mode of conversation. There are occasionally opportunities to use it in normal speech in which confusion could ensue. One example recently when talking to a developer about a feature in their project:
Him:It doesn't matter that the feature doesn't perfectly work right, it's being removed in the next version.
Me:The problem is that people use that feature a lot and will be unhappy it'll be gone.
Him:They shouldn't be using it and therefore they shouldn't miss it.
Me:Why is that?
Him:Because it is going to be gone in the next release
Me:You're begging the question.
Him:What question is that?
Here, I used correctly the phrase begging the question, but he entirely missed the point assuming the 'common usage'.
It is not unheard of to have words with multiple distinct meanings (bat being a prime example), but usually the meanings are used in fairly distinct contexts. For example, bat as in something to hit things with versus a flying rodent, the contexts tend to be different, however if you used the word ball to describe something to hit things with, then baseball would be uselessly confusing.
That is my most *hated* expansion of acronym RAID.
Adminittedly, there is no suitable expansion for RAID when you consider RAID-0 (unless you make it recursive...).
Who says they are the least bit inexpensive? There is nothing about the technology that is inherently tied to expense in that sort of way.... However, the technology does involved things that are *I*ndependent of each other and the concept is central to the points of RAID....
While I'm at it, there is nothing particularly disk-specific either. I've never seen anyone but me question this, but strictly speaking the D would be better expanded as 'Devices' than 'Disks'.
Which leaves R for Redundant, which doesn't apply to RAID-0, but it is descriptive for everything but RAID-0, and I can't think of a better fit, so:
Redundant Array of Independent Devices
Is a much more relevant description of RAID... Just my two cents.
Though diskless workstations were very very common in *nix networks of the late 80s/early 90s (disks were *huge* physically and the only feasible approach was to have them somewhere far from the workstations and share them), the amount of the base system that ran in memory was typically just the kernel, which had the network support built in and booted nfsroot. As constrained hard drives were, memory was even tighter back then, consuming it as a ramdisk would've made the systems much less powerful.
Ahh, the days of running systems nfs off of 10base5 hub networks connecting to the huge servers with the 540 meg hard drives that took more than 4U (been so long, cant remember) each.
Congratulations, you officially close the discussion in defeat.
I seem to remember that at one point AOL for DOS was essentially GEOS with only AOL..