Be very clear on this: as far as their immediate management were concerned, these security and officers made the _right_ decision. This sort of skew between the people on the jobsite and the top management is absolutely normal where you have too many layers of management: the policies at the lower levels skew from the legal standards or the top layer's public policies to serve the convenience of the lower layers. This is partly what bureaucracy is for: to adapt the principles to fit the local situations. But it can also lead to policies convenient to the lower management (no photography) and in direct contravention of law and high level policy (First Amendment).
Oh, dear. Like sexual harassment policies, the policies on the use of physical force are sufficiently vage, confusing, and even contradictory that the officer on the spot can interpret them with tremendous flexibility. There are actually some good reasons for this: a very strict set of guidelines can be used by a "street lawyer" to manipulate the officer into very serious danger, and an officer does need some flexibility to escalate the situation beyond the detainee's ability to threaten the officer or the public.
The result, however, is sometimes a serious nightmare for reasonable people trying to record or passively demonstrate at a public event, or for very reasonable people who do not understand the rules. Arguing with a policeman is potentially awward: they have to deal with some nasty situations for which a nightstick, or handcuffs, or a taser, is the right response and may be needed in milliseconds.
And by the way, "paid suspension" hurts them surprisingly. They can't do the "officer on site" details that make up a large piece of a normal policeman's salary, and they can't do overtime. For many police, these are a big chunk of their take-home pay, so it can be a surprisingly harge hit in the pocketbook. Like tips for a waitress, it's factored into their salary negotiations, even if the city isn't paying it. And it doesn't count towards a pension, but it sure helps pay the rent and the bills for families of police.
Most cops, in my experience, work their tails off at often boring, often confusing, and sometimes very dangerous work. It's unfair to those police to tar them with the brush of those who are jerks or who are confused by the mixed messages from different layers of management (such as this event seems to show).
ID cards would have cost money: that's a no-brainer of a political move that can be revisited in 10 years, and for most purposes can be replaced by monitoring of bank cards and public transit passes, especially the "Oyster card" for London transit which is being phased in for nationwide public transit and unified with bank cards for some customers (http://www.pocket-lint.com/news/5883/barclays-put-oyster-debit-cards).
Why pay for a national ID card when the bank cards are tappable without warrants, reveal public transit use and gasoline stops for car use, and are already accepted broadly?
There are various kinds of intelligence: people on the ground can report details of events in a way that electronic monitoring cannot hope to discover, but electronic monitoring can present bulks of data that can be analyzed for privileged information unlikely to reach someone not in the inner circle of a government or business group, so it's a fascinating tradeoff.
Material that is organized and the debris filtered out is like trying to get detailed Linux network support from a telecom's call center: it takes competent personnel to filter out all the debris, obtain, and confirm the relevant data. And material that is clear enough to override a really, really bad move being planned by your political leaders is incredibly valuable and wildly underappreciated. It took Dick Cheney weeks to rewrite the CIA reports on Iraq enough to amass the flimsy, even fraudulent evidence of Iraq weapons of mass destruction enough to get Colin Powell up in front of the UN to present the fraud.
It does keep me paid, to remember the last time someone tried doing things that way and all the steps we had to take to make things work well and what wasn't worth wasting resources on.
Yes, we do. OS upgrades, storage and backup and network and source control and patch management and authentication and hardware cluster and disaster recovery and VPN and modem and fax and monitoring, all need release management. If you're not doing some sort of planning for these things, you're very vulnerable to changes in untested components destroying core services. And sadly, this happens all the time in small companies (where you call Ingrid the Engineer and she dials in and fixes the problem), and big environments (where the VP who's drinking buddies with the corporate partner mandates the use of a particular hardware technology, and you you have to replace 5 years of work in a 2-week switchover because no one explained to the VP before committing the company's money that the new technology is actually quite old, uses UDP, and was discarded by anyone competent years ago.)
Release cycles provide some time in IT to plan and schedule switchovers.
Except that in very powerful legal senses, you do "own" your children. Ask any parent who loses a custody battle and has to negotiate to take the child on an overseas trip, or what happens if you take the child out of the state and refuse to return them.
Oh, dear. *Property* is a statutory construction. Take a careful look at land ownership, human slavery, and pet ownership to verify that "property" can mean some very strange things that are not merely a physical object. And take a very good look at the history of copyright related to religious texts to understand that it's not merely about sales: it's also about making sure that the copies match the original work according to the owner's wishes, or the use of copyright on private correspondence to preserve its confidentiality.
As things stand, copyright infringement is legally close enough to theft that its penalties reflect the loss of revenues from the objects copied. The criminal code is at http://www.copyright.gov/title17/92chap5.html: do take a look, it's fascinating materlal.
I'm basing it on the last 5 years of very painful experience with unstable "Java" graphical applications. I suspect, and observed in two cases, that the developers were excited and believed that it worked. In most of these cases, the actual clients became increasingly unhappy, and I'm working with two major projects right now to throw out the Java client and make it a clean, web-based interface.
And before you applaud its use for bio-chemical simulations, I strongly urge you to speak to some of the programmers who actually understand programming, not merely biologists who took a course in programming, to find out what sort of absurdities are occurring. There's a tremendous amount of biological number crunching for with software that cost incredible hardware and computing time resources to run, but are so buggy that they should never have been released. There are numerous reasons for this, but the essentially mistaken or sometimes even fraudulent claim that Java run on two different machines or on two different days with normal Java updates will produce the same data is at the root of much of it.
Java's multiple layers of inheritance and localized re-interpretation of basic functions creates a stunning stability problem for reliable number crunching, one which I just don't see as addressable.
If this is true, then good. I'm afraid I don't have a Windows 7 box to test in front of me. But Windows Vista certainly does do it by default. Simply type \\hostname\c$ in order to see it. It's not something you "enable": It's on by default. It does require privileges to access, but it should never have been enabled in the first place without explicitly turning it on.
No, I got your point. My point is that it is far, far more difficult to "administer right" a Windows system due to its overburdening with unremovable services. For example, a core authentication server (such as an Active Directory server) shouldn't have a web browser running as an administrator user, especially a browser as security vulnerable as Internet Explorer. Yet doing ordinary patch detection and downloads can only be done with Internet Explorer. This is extremely and unnecessarily difficult to "administer right".
One can invest in some rather expensive management systems to do this instead of using IE, just as there are ways to turn off the automatic sharing of the \\hostname\C$\ share, but the cost of doing so is beyond what most small shops can afford. Thus, the threshold for Windows servers to "adminster them right" is far, far higher than that for most other OS's.
No, the number of unnecessary and undesirable services automatically deployed with Windows operating systems is quite profound. The automatic sharing of the C: drive as \\hostname\c$\, for example, has been nearly impossible to turn off for even a competent systems administrator without ripping out parts of the operating system you may want.
Shall we review the security risks of the almost mandatory use of dynamic DNS associated with Active Directory? Or the very poor security models of overburdening the Kerberos server underlying Active Directory with graphical and non-security related tools which have _nothing_ to do with that absolutely critical security service, yet are mandatory with the Windows "Server" releases required to run an Active Directory server? Or the denial of service attacks possible against an Internet-exposed Exchange server because it simply cannot handle a reasonable amount of direct SMTP traffic, especially broadly distributed spambots?
The Linux boxes simply do not run all these services and have all these vulnerabilities when they come out of the box because they don't _activate_ such services without giving the owner a patch to patch their systems. And users are not forced to run "Internet Explorer", that festering cesspool of security vulnerabilities, because someone locked the software update mechanism to a web browser with too many "features" to possibly secure.
It may not be fraudulent. He or she may be actually picking up clues, from experience, that a local farmer may not notice. Plant growth is certainly a useful indicator: layout of rock and hills may indicate where water from upstream or uphill is likely to channel into a particularly effective and reliable aquifer, effectively funneled by the underlying rock. That sort of expertise takes actual travel and study and practice that a local resident wouldn't have until pretty recently in history, so a traveling expert could be well worth the cost, even if they don't realize what they're an expert _in_.
There is a tremendous amount of research. Much of it is complete scientific balderdash, a few papers written on a few case studies without double blind technique or with very vague, interview based evaluation of the results. This is, sadly, very common in medical science.
For an example, review this article on the famous "acupuncture appendectomy" during the Nixon administration.
Except that most of the best evidence shows that the "chi energy", the use of needles rather than pressure, and the use of it for treatment of body parts that are nowhere near the needle are complete nonsense. So scienctific testing shows that even the stopped clock of the magical thinking surrounding acupuncture can be right twice a day, and can even predict now what that twice a day will be.
I once spent a long, sad hour with an MD who tried to tell me that acupuncture worked because the nerves it stimulates are faster than pain nerves. I tried to explain to her the concepts of phase delays: if the pain came first by more than a matter of milliseconds, the pain signal was already present in the upstream nerve junctions or in the brain, and it doesn't matter how "swift" the signal is from the acupuncture needle, so the explanation is nonsensical.
Oh, dear, yes. This is why I _hate_ when developers start plugging in their own versions of system tools built in their "personal" development systems, and try to hand them off to me to install on active systems without ever cleaning them up to build in a "standard" environment. It's also why I think that gentoo will never be stable enough for industry use. Very small differences in build tools concatenate to generate tremendous incompatibilities.
GPLv3 is an evolution of GPL, particularly GPLv2, against abuses which RMS predicted and which have now verified, most particularly patent issues. If you've not encountered patent software issues in the last 5 years, good for you, but they've been an increasing burden for people I work with.
The GPL is not merely "philosophical". While RMS may have a minority viewpoint, it's a minority viewpoint of someone with insight and a strange but effective brand of leadership, and the GPLv3 was developed openly with a _lot_ of community input and involvement. And GPLv3 was aimed squarely at a very real problem, the Novell/Microsoft patent licensing deal, which left Novell in a place to use and publish "GPL" code that was nonetheless patent encumbered by Microsoft and no one else could modify. If this seems unclear, the Wikipedia article is quite good, and the
GPLv3 was also written to be compatible with the Apache license. That is a big and heavily reviewed step, one which RMS wasn't completely thrilled about but which a lot of open source contributors were. So please don't claim that it's purely RMS's ideas.
I understood that Jeremy and his peers were doing funded, real Samba development work and enhancing SuSE with it: this made SuSe a very good candidate for mixed network servers until the Microsoft cross-licensing debacle, and Jeremy left. And didn't the rest of Jeremy's group leave shortly thereafter?
I believe I saw some demos of that awful Netware/Linux toolkit. The packaging and installation of it, alone, was so bad that it should never have been released from alpha: compared to simply installing Samba under Linux, it was an absolute joke.
IBM has no reason to pour more money into Novell's failed "big dreams", dreams that have been skewered by details Novell mishandled.
Netware worked quite well, for example, but was displaced by Microsoft's networking tools and their free inclusion in Windows, even though investing the money in Netware tools justified itself in a real IT environment very, very quickly. Novell wisely sold off AT&T based UNIX, but failed to nail down the sales contracts in clear enough language to prevent wasting millions of dollars in legal fees and real damage to their Linux business due to SCO's clearly fraudulent lawsuits against Linux users. And Novell at first _cooperated_ with the idea of corporate indemnification for "free software" by engaging in the Microsoft licensing deal with SuSE. Worse, there is no actual business or development reason to use other than the incomplete and mostly useless "indemnification".
Worse, they lost their Samba development leadership when Jeremy Allison left Novell in protest. That, alone, was worth the resources that Microsoft used for the Novell deal: they interfered with Samba development for years while Jeremy got his new job in line and lost the Samba-devoted resources at Novell that he used to have in hand to work with.
I'm sorry, but the sense of sight certainly affects the experience of a meal as much as the appearance of a date affects a date. While something that is awful may not overcome its physical taste with appearance, a mediocre dish will taste better if presented well. And a fabulous dish prepared poorly loses some of its savor if presented poorly. It's as true of children as it is of adults. Give a child their meal on their favorite froggy face plate, with the bread cut into squares (not triangles, mom, you know how I like it!) and their new sippy glass (not the bottle, that's for babies!) and they may appreciate the meal far more, even if it contains corn.
And poker and backgammon are "just luck". But drawing to an inside straight is still likely to lose you the hand, if not help you lose your whole hand, and it's clear that some people do far, far better at it by understanding the risks and the odds and learning how to _lie_ to the others involved. That's how pump and dump stock manipulation works, and as nasty as it can be, it takes it into the realm of skill.
This isn't a "delay" in the classical analog sense. It's a checkpoint. And "low pass filters" are based on negative feedback, which this is. It's just not very _good_ negative feedback.
Unfortunately, there are many, many different feedback loops in this complex miss, and tuning one of them for stability can trigger a feedback with 180 degrees of phase delay in another well tuned local feedback loop. Adventures can ensue, especially when people are selling, and others are relying on, extremely low latency transactions to benefit their very expensive services as stock salespeople. And the push to minimize delays there are amazing: I've just spent a long conversation with an engineer explaining how some stock information is now sent via rather expensive, low-latency multicast feeds, but they've so tagged and checksummed the transmitted information that it is actually less reliable and slower than if they'd used a stack of TCP based streaming servers in the first place. But they daren't change now because it would throw out 10 years of expensive in-house expertise and management buy-in, and would make all the managers who invested in it look like complete idiots to have to start over.
In this case, though, the low latency work is destabilizing. The data is going through easily hundreds of different feedback loops in different corporate hands, all with different phase delays, some of which have tremendous amounts of gain because they can sell or buy a _lot_ of stock in millisends. The only choice at this point is to put hard stops in the system for when oscillation or excess positive feedback begins.
Slashdot Mirror
Be very clear on this: as far as their immediate management were concerned, these security and officers made the _right_ decision. This sort of skew between the people on the jobsite and the top management is absolutely normal where you have too many layers of management: the policies at the lower levels skew from the legal standards or the top layer's public policies to serve the convenience of the lower layers. This is partly what bureaucracy is for: to adapt the principles to fit the local situations. But it can also lead to policies convenient to the lower management (no photography) and in direct contravention of law and high level policy (First Amendment).
Oh, dear. Like sexual harassment policies, the policies on the use of physical force are sufficiently vage, confusing, and even contradictory that the officer on the spot can interpret them with tremendous flexibility. There are actually some good reasons for this: a very strict set of guidelines can be used by a "street lawyer" to manipulate the officer into very serious danger, and an officer does need some flexibility to escalate the situation beyond the detainee's ability to threaten the officer or the public.
The result, however, is sometimes a serious nightmare for reasonable people trying to record or passively demonstrate at a public event, or for very reasonable people who do not understand the rules. Arguing with a policeman is potentially awward: they have to deal with some nasty situations for which a nightstick, or handcuffs, or a taser, is the right response and may be needed in milliseconds.
And by the way, "paid suspension" hurts them surprisingly. They can't do the "officer on site" details that make up a large piece of a normal policeman's salary, and they can't do overtime. For many police, these are a big chunk of their take-home pay, so it can be a surprisingly harge hit in the pocketbook. Like tips for a waitress, it's factored into their salary negotiations, even if the city isn't paying it. And it doesn't count towards a pension, but it sure helps pay the rent and the bills for families of police.
Most cops, in my experience, work their tails off at often boring, often confusing, and sometimes very dangerous work. It's unfair to those police to tar them with the brush of those who are jerks or who are confused by the mixed messages from different layers of management (such as this event seems to show).
ID cards would have cost money: that's a no-brainer of a political move that can be revisited in 10 years, and for most purposes can be replaced by monitoring of bank cards and public transit passes, especially the "Oyster card" for London transit which is being phased in for nationwide public transit and unified with bank cards for some customers (http://www.pocket-lint.com/news/5883/barclays-put-oyster-debit-cards).
Why pay for a national ID card when the bank cards are tappable without warrants, reveal public transit use and gasoline stops for car use, and are already accepted broadly?
There are various kinds of intelligence: people on the ground can report details of events in a way that electronic monitoring cannot hope to discover, but electronic monitoring can present bulks of data that can be analyzed for privileged information unlikely to reach someone not in the inner circle of a government or business group, so it's a fascinating tradeoff.
Material that is organized and the debris filtered out is like trying to get detailed Linux network support from a telecom's call center: it takes competent personnel to filter out all the debris, obtain, and confirm the relevant data. And material that is clear enough to override a really, really bad move being planned by your political leaders is incredibly valuable and wildly underappreciated. It took Dick Cheney weeks to rewrite the CIA reports on Iraq enough to amass the flimsy, even fraudulent evidence of Iraq weapons of mass destruction enough to get Colin Powell up in front of the UN to present the fraud.
It does keep me paid, to remember the last time someone tried doing things that way and all the steps we had to take to make things work well and what wasn't worth wasting resources on.
Yes, we do. OS upgrades, storage and backup and network and source control and patch management and authentication and hardware cluster and disaster recovery and VPN and modem and fax and monitoring, all need release management. If you're not doing some sort of planning for these things, you're very vulnerable to changes in untested components destroying core services. And sadly, this happens all the time in small companies (where you call Ingrid the Engineer and she dials in and fixes the problem), and big environments (where the VP who's drinking buddies with the corporate partner mandates the use of a particular hardware technology, and you you have to replace 5 years of work in a 2-week switchover because no one explained to the VP before committing the company's money that the new technology is actually quite old, uses UDP, and was discarded by anyone competent years ago.)
Release cycles provide some time in IT to plan and schedule switchovers.
Or run it through a Brita filter first, to remove the aftertaste. http://kwc.org/mythbusters/2006/04/episode_50_bullets_fired_up_vo.html
Except that in very powerful legal senses, you do "own" your children. Ask any parent who loses a custody battle and has to negotiate to take the child on an overseas trip, or what happens if you take the child out of the state and refuse to return them.
Oh, dear. *Property* is a statutory construction. Take a careful look at land ownership, human slavery, and pet ownership to verify that "property" can mean some very strange things that are not merely a physical object. And take a very good look at the history of copyright related to religious texts to understand that it's not merely about sales: it's also about making sure that the copies match the original work according to the owner's wishes, or the use of copyright on private correspondence to preserve its confidentiality.
As things stand, copyright infringement is legally close enough to theft that its penalties reflect the loss of revenues from the objects copied. The criminal code is at http://www.copyright.gov/title17/92chap5.html: do take a look, it's fascinating materlal.
I'm basing it on the last 5 years of very painful experience with unstable "Java" graphical applications. I suspect, and observed in two cases, that the developers were excited and believed that it worked. In most of these cases, the actual clients became increasingly unhappy, and I'm working with two major projects right now to throw out the Java client and make it a clean, web-based interface.
And before you applaud its use for bio-chemical simulations, I strongly urge you to speak to some of the programmers who actually understand programming, not merely biologists who took a course in programming, to find out what sort of absurdities are occurring. There's a tremendous amount of biological number crunching for with software that cost incredible hardware and computing time resources to run, but are so buggy that they should never have been released. There are numerous reasons for this, but the essentially mistaken or sometimes even fraudulent claim that Java run on two different machines or on two different days with normal Java updates will produce the same data is at the root of much of it.
Java's multiple layers of inheritance and localized re-interpretation of basic functions creates a stunning stability problem for reliable number crunching, one which I just don't see as addressable.
Because "mature" or not, Java is a resource pig and inherently unstable. The "Wrote Once, Run Anywhere" model has never worked for Java.
If this is true, then good. I'm afraid I don't have a Windows 7 box to test in front of me. But Windows Vista certainly does do it by default. Simply type \\hostname\c$ in order to see it. It's not something you "enable": It's on by default. It does require privileges to access, but it should never have been enabled in the first place without explicitly turning it on.
If by "1999" you mean "cleaning the mess on other people's systems last week", then yes, it was 1999.
No, I got your point. My point is that it is far, far more difficult to "administer right" a Windows system due to its overburdening with unremovable services. For example, a core authentication server (such as an Active Directory server) shouldn't have a web browser running as an administrator user, especially a browser as security vulnerable as Internet Explorer. Yet doing ordinary patch detection and downloads can only be done with Internet Explorer. This is extremely and unnecessarily difficult to "administer right".
One can invest in some rather expensive management systems to do this instead of using IE, just as there are ways to turn off the automatic sharing of the \\hostname\C$\ share, but the cost of doing so is beyond what most small shops can afford. Thus, the threshold for Windows servers to "adminster them right" is far, far higher than that for most other OS's.
No, the number of unnecessary and undesirable services automatically deployed with Windows operating systems is quite profound. The automatic sharing of the C: drive as \\hostname\c$\, for example, has been nearly impossible to turn off for even a competent systems administrator without ripping out parts of the operating system you may want.
Shall we review the security risks of the almost mandatory use of dynamic DNS associated with Active Directory? Or the very poor security models of overburdening the Kerberos server underlying Active Directory with graphical and non-security related tools which have _nothing_ to do with that absolutely critical security service, yet are mandatory with the Windows "Server" releases required to run an Active Directory server? Or the denial of service attacks possible against an Internet-exposed Exchange server because it simply cannot handle a reasonable amount of direct SMTP traffic, especially broadly distributed spambots?
The Linux boxes simply do not run all these services and have all these vulnerabilities when they come out of the box because they don't _activate_ such services without giving the owner a patch to patch their systems. And users are not forced to run "Internet Explorer", that festering cesspool of security vulnerabilities, because someone locked the software update mechanism to a web browser with too many "features" to possibly secure.
It may not be fraudulent. He or she may be actually picking up clues, from experience, that a local farmer may not notice. Plant growth is certainly a useful indicator: layout of rock and hills may indicate where water from upstream or uphill is likely to channel into a particularly effective and reliable aquifer, effectively funneled by the underlying rock. That sort of expertise takes actual travel and study and practice that a local resident wouldn't have until pretty recently in history, so a traveling expert could be well worth the cost, even if they don't realize what they're an expert _in_.
There is a tremendous amount of research. Much of it is complete scientific balderdash, a few papers written on a few case studies without double blind technique or with very vague, interview based evaluation of the results. This is, sadly, very common in medical science.
For an example, review this article on the famous "acupuncture appendectomy" during the Nixon administration.
Except that most of the best evidence shows that the "chi energy", the use of needles rather than pressure, and the use of it for treatment of body parts that are nowhere near the needle are complete nonsense. So scienctific testing shows that even the stopped clock of the magical thinking surrounding acupuncture can be right twice a day, and can even predict now what that twice a day will be.
I once spent a long, sad hour with an MD who tried to tell me that acupuncture worked because the nerves it stimulates are faster than pain nerves. I tried to explain to her the concepts of phase delays: if the pain came first by more than a matter of milliseconds, the pain signal was already present in the upstream nerve junctions or in the brain, and it doesn't matter how "swift" the signal is from the acupuncture needle, so the explanation is nonsensical.
Oh, dear, yes. This is why I _hate_ when developers start plugging in their own versions of system tools built in their "personal" development systems, and try to hand them off to me to install on active systems without ever cleaning them up to build in a "standard" environment. It's also why I think that gentoo will never be stable enough for industry use. Very small differences in build tools concatenate to generate tremendous incompatibilities.
GPLv3 is an evolution of GPL, particularly GPLv2, against abuses which RMS predicted and which have now verified, most particularly patent issues. If you've not encountered patent software issues in the last 5 years, good for you, but they've been an increasing burden for people I work with.
The GPL is not merely "philosophical". While RMS may have a minority viewpoint, it's a minority viewpoint of someone with insight and a strange but effective brand of leadership, and the GPLv3 was developed openly with a _lot_ of community input and involvement. And GPLv3 was aimed squarely at a very real problem, the Novell/Microsoft patent licensing deal, which left Novell in a place to use and publish "GPL" code that was nonetheless patent encumbered by Microsoft and no one else could modify. If this seems unclear, the Wikipedia article is quite good, and the
GPLv3 was also written to be compatible with the Apache license. That is a big and heavily reviewed step, one which RMS wasn't completely thrilled about but which a lot of open source contributors were. So please don't claim that it's purely RMS's ideas.
I understood that Jeremy and his peers were doing funded, real Samba development work and enhancing SuSE with it: this made SuSe a very good candidate for mixed network servers until the Microsoft cross-licensing debacle, and Jeremy left. And didn't the rest of Jeremy's group leave shortly thereafter?
I believe I saw some demos of that awful Netware/Linux toolkit. The packaging and installation of it, alone, was so bad that it should never have been released from alpha: compared to simply installing Samba under Linux, it was an absolute joke.
IBM has no reason to pour more money into Novell's failed "big dreams", dreams that have been skewered by details Novell mishandled.
Netware worked quite well, for example, but was displaced by Microsoft's networking tools and their free inclusion in Windows, even though investing the money in Netware tools justified itself in a real IT environment very, very quickly. Novell wisely sold off AT&T based UNIX, but failed to nail down the sales contracts in clear enough language to prevent wasting millions of dollars in legal fees and real damage to their Linux business due to SCO's clearly fraudulent lawsuits against Linux users. And Novell at first _cooperated_ with the idea of corporate indemnification for "free software" by engaging in the Microsoft licensing deal with SuSE. Worse, there is no actual business or development reason to use other than the incomplete and mostly useless "indemnification".
Worse, they lost their Samba development leadership when Jeremy Allison left Novell in protest. That, alone, was worth the resources that Microsoft used for the Novell deal: they interfered with Samba development for years while Jeremy got his new job in line and lost the Samba-devoted resources at Novell that he used to have in hand to work with.
I'm sorry, but the sense of sight certainly affects the experience of a meal as much as the appearance of a date affects a date. While something that is awful may not overcome its physical taste with appearance, a mediocre dish will taste better if presented well. And a fabulous dish prepared poorly loses some of its savor if presented poorly. It's as true of children as it is of adults. Give a child their meal on their favorite froggy face plate, with the bread cut into squares (not triangles, mom, you know how I like it!) and their new sippy glass (not the bottle, that's for babies!) and they may appreciate the meal far more, even if it contains corn.
And poker and backgammon are "just luck". But drawing to an inside straight is still likely to lose you the hand, if not help you lose your whole hand, and it's clear that some people do far, far better at it by understanding the risks and the odds and learning how to _lie_ to the others involved. That's how pump and dump stock manipulation works, and as nasty as it can be, it takes it into the realm of skill.
This isn't a "delay" in the classical analog sense. It's a checkpoint. And "low pass filters" are based on negative feedback, which this is. It's just not very _good_ negative feedback.
Unfortunately, there are many, many different feedback loops in this complex miss, and tuning one of them for stability can trigger a feedback with 180 degrees of phase delay in another well tuned local feedback loop. Adventures can ensue, especially when people are selling, and others are relying on, extremely low latency transactions to benefit their very expensive services as stock salespeople. And the push to minimize delays there are amazing: I've just spent a long conversation with an engineer explaining how some stock information is now sent via rather expensive, low-latency multicast feeds, but they've so tagged and checksummed the transmitted information that it is actually less reliable and slower than if they'd used a stack of TCP based streaming servers in the first place. But they daren't change now because it would throw out 10 years of expensive in-house expertise and management buy-in, and would make all the managers who invested in it look like complete idiots to have to start over.
In this case, though, the low latency work is destabilizing. The data is going through easily hundreds of different feedback loops in different corporate hands, all with different phase delays, some of which have tremendous amounts of gain because they can sell or buy a _lot_ of stock in millisends. The only choice at this point is to put hard stops in the system for when oscillation or excess positive feedback begins.