> ending the absurd game of telephone we are all playing as to what the people using the software are actually wanting
Please, yes. Whenever I count too many layers between the clients who pay for a service, and the engineers who write it I become deeply concerned that they can and will confuse things at any intervening step. When possible, I try to get the engineers to spend at least some time every week manning the help desk. It doesn't have to be consistent, and ideally it's not so that customers don't get used to always getting the chief engineer.
> The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled
Your whole message makes much more system of you spell "systemd" instead of "systems". I'm sure that was a typo.
> Your reasoning is apparently that if something bad happens to a Muslim or African American, without any other evidence, it must be due to racism
That is a classic straw man argument, and no. I'm afraid your attempt to claim that no racism exists because there exist people who are not harassed is similarly poor logic. An illegal or mistaken racist policy can be broadly applied without all people experiencing it directly, and bad things can happen for reasons other than the racism.
Even a casual review, however, shows many well-done tests and scholarly studies demonstrating the racism and religious profiling by TSA personnel, their refusal to state reasons for denying entry to the USA, and their general incompetence in actually detecting dangerous people.
> The implication of the article is that somehow US authorities are discriminating against this family because of their faith. Obviously, that's false, since there are large numbers of Muslims traveling to the US every day.
There is nothing "obviously" false about this. Racism doesn't have to be applied 100% for it to be a very real force in American culture, any more than H1B visas have to be granted for every job in America to depress salaries for technology people in the USA.
> think the idea is that you have to take the tanks with you anyway
Exactly. Custom designing a "bulk payload launch systems with lightweight, almost passive cowl" system would seem to be unnecessary when these large shells nearly reach orbital velocity, anyway. Also note that it's very difficult to design something from scratch that will very leightweight but survive the launch to orbit. If it's light, even hollow, that can add a great deal of drag to the launch system.
> instead of falling into the sea and being recovered as no more than scrap.
They were originally designed for re-use. The abandonment of plans to use the external liquid tank as building materials in orbit, and the poor re-usability of the solid rocket boosters were parts of the tremendous expense and overall failure of the space shuttle program to provide "trucks to space".
> and they could just as easily used many other OS's in place of Linux, so long as they were capable of getting the job done.
I think not. The flexibility of the full "stack" with Linux allows freer modification of many core principles, with a broader range of drivers and alternative technological approaches for similar projects. MacOS would not run on the wide variety of hardware nor is it well supported for micro-instances, nor does it provide access to the same range of hardware CAD tools. Neither do any of the BSD UNIX releases, such as OpenBSD, nor do the registered and proprietary UNIX vresions like AIX.
> since external images would let you track every person that viewed them.
It's particularly crucial to Akamai and ad.doubleclick.net's collaborations. (http://motifcdn2.doubleclick.net/EMEA/ad-in-a-box/LiveStreaming/LiveStreaming_Build_Guide_EN.pdf ).
As a warning, don't be confused by those pseudo-random looking URL's for web images. Many of them do come from the same set of back-end services run by a relatively small set of companies, and they provide tremendous metadata about web use down to the individual purchaser level. Just because the data is "pseuonymized" does not protect it from analysis of the initial raw data, which is often poorly secured by the software companies themselves.
> Why would a VM be a security hole? Particularly if it's a jail, or a zone? It operates in its own space, separate from others, so if something else infects it, it can be closed from the parent OS.
The main reason is because very few environments bother to create, or to maintain such a restrictive environment. Such a system is, ideally, completely isolated from the rest of the network. Unfortunately, that also means it can no longer use network printers, it can no longer provide or collect information with worker's laptops, and it cannot be remotely logged into to run the designated critical business software.
Even if the systems personnel are competent to do so, they are often refused the permission or the resources to limit access in this way. Many environments follow the standard of "no one would bother us", and "we trust the people we work with", so they refuse to lock down potentially vulnerable resources. While it's theoretically possible to isolate a critical Windows based business application, it's very rarely done effectively, or as effectively and safely as running the application in Wine.
A Windows VM anywhere inside your network can be a profound security hole for a number of system architectural reasons. It can also create an undesired and unexpected maintenance cost to keep them active and secured. There are old programs, especially finance software, which may be business critical that run under Wine but not on modern Windows systems. Those programs are also particularly vulnerable to Windows support issues when the original programmers are out of business, or got bought by a company that discarded the software.
Except when they are not, especially in a RAID enclosure where identical drives are suffering similar rates of use. Some of us encountered the "Deathstar" series of drives, the IBM Deskstar 75GXP.
Live disk arrays are also vulnerable to accidental "rm -rf/" errors. Off-line backup is critical to recovery from such accidents.
By the time you get done activating security high availability, and integrity checking, you've often lowered the performance to below that of a more mature, well-tuned SQL database. There is a very amusing video that covers some of these issues in passing:
There is a simplistic but useful video at http://www.alicesastroinfo.com... that describes the issue. They're effectively high density star regions, much like the funnel of a tornado or of a hurricane will form spirals.
Until Joe Randomhacker steals it from poorly secured governmental resources. The same problem is built into the digatal rights management system called "Trusted Computing". The "Trusted Comting" key escrow, which basically puts private keys for software and hardware based encryption and access control in an screw repository held by Microsoft. The system has somewhat languished since it was discovered that one could virtualize the required hardware component, allowing parallel access on multiple virtual machines to the same data.
The idea that Sadam Hussein was tied to 9/11 was a popular and understandable one in the shock after 9/11 given the broad policy of lies. Unfortunately, it had no validity. Sadam and his regime knew much, much better than to allow a fundamentalist, radical Muslim group access to any weapons or significant political power in Iraq, or to compete with them for funding. They relied far too much on channeling fanatical fear of others into their own political powers to allow any competitors for such faith or such desperate action.
> then we need the FBI to put MUCH better accountability in place to ensure that THEY are not doing anything criminal.
The FBI has demonstrated that they can, and will, use their privileged access to monitoring to abuse and harass innocent people, and to perform criminal behavior to go after the "big fish" or the "kingpins". They've also demonstrated fundamental incompetence in handling chronic, lower level crime such as identity theft, "copyright violation", inter-state stalking of minors and domestic abuse escapees, and large scale online fraud. I've simply seen no evidence that they can do _anything_ competent that involves computer security. The few convictions they've gotten credit for were basically handed to them by informants or by aggrieved victims who were compelled to interact with the FBI to obtain subpoenas from other states.
I'm afraid they're just not competent at handling computer crime. The personnel in the department may be dedicated, they may even be technologically competent: whether the problem is one of skills or leadership _does not matter_. Expanding their mission by providing decryption tools for all traffic will simply deluge them with work they cannot handle.
Exporting the private keys is often done very poorly. I've certainly seen people email such certificates in plain text, and provide access to backups of load balancer backups with unencrypted local keys. Some web servers bother to require manual passwords at start time to unlock an encrypted private key, but I've seen only a very, very few high security sites do that.
Slashdot Mirror
> ending the absurd game of telephone we are all playing as to what the people using the software are actually wanting
Please, yes. Whenever I count too many layers between the clients who pay for a service, and the engineers who write it I become deeply concerned that they can and will confuse things at any intervening step. When possible, I try to get the engineers to spend at least some time every week manning the help desk. It doesn't have to be consistent, and ideally it's not so that customers don't get used to always getting the chief engineer.
Oh, that would have been much funnier if I'd said:
> Your whole message makes much more sense if you spell "systemd" instead of "systems". I'm sure that was a typo.
I do apologize for doing that joke so poorly. I'll try to avoid humor in this forum.
> The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled
Your whole message makes much more system of you spell "systemd" instead of "systems". I'm sure that was a typo.
> In this case, there isn't a deadline. It is a continuously supported product.
There are release dates, feature releases, and bug fix delivery dates. Those are also "deadlines".
They were afraid one device would get good pictures of them stealing the other.
https://www.youtube.com/watch?...
The TSA does not screen effectively, and never has. See http://www.cnn.com/2015/06/01/... and numerous other tests of TSA procedures.
They have no right to waste so many billions of American dollars, and so many hours out of so many people's lives, for such demonstrably poor results.
Indeed. I can only plead that I've met Americans who though we could just put a toolbooth on the border with Mexico.
> Your reasoning is apparently that if something bad happens to a Muslim or African American, without any other evidence, it must be due to racism
That is a classic straw man argument, and no. I'm afraid your attempt to claim that no racism exists because there exist people who are not harassed is similarly poor logic. An illegal or mistaken racist policy can be broadly applied without all people experiencing it directly, and bad things can happen for reasons other than the racism.
Even a casual review, however, shows many well-done tests and scholarly studies demonstrating the racism and religious profiling by TSA personnel, their refusal to state reasons for denying entry to the USA, and their general incompetence in actually detecting dangerous people.
> The implication of the article is that somehow US authorities are discriminating against this family because of their faith. Obviously, that's false, since there are large numbers of Muslims traveling to the US every day.
There is nothing "obviously" false about this. Racism doesn't have to be applied 100% for it to be a very real force in American culture, any more than H1B visas have to be granted for every job in America to depress salaries for technology people in the USA.
Please recheck your assumptions. There are many international airports in the USA: most large airports near US borders have international flights.
> think the idea is that you have to take the tanks with you anyway
Exactly. Custom designing a "bulk payload launch systems with lightweight, almost passive cowl" system would seem to be unnecessary when these large shells nearly reach orbital velocity, anyway. Also note that it's very difficult to design something from scratch that will very leightweight but survive the launch to orbit. If it's light, even hollow, that can add a great deal of drag to the launch system.
> instead of falling into the sea and being recovered as no more than scrap.
They were originally designed for re-use. The abandonment of plans to use the external liquid tank as building materials in orbit, and the poor re-usability of the solid rocket boosters were parts of the tremendous expense and overall failure of the space shuttle program to provide "trucks to space".
> and they could just as easily used many other OS's in place of Linux, so long as they were capable of getting the job done.
I think not. The flexibility of the full "stack" with Linux allows freer modification of many core principles, with a broader range of drivers and alternative technological approaches for similar projects. MacOS would not run on the wide variety of hardware nor is it well supported for micro-instances, nor does it provide access to the same range of hardware CAD tools. Neither do any of the BSD UNIX releases, such as OpenBSD, nor do the registered and proprietary UNIX vresions like AIX.
> since external images would let you track every person that viewed them.
It's particularly crucial to Akamai and ad.doubleclick.net's collaborations. (http://motifcdn2.doubleclick.net/EMEA/ad-in-a-box/LiveStreaming/LiveStreaming_Build_Guide_EN.pdf ).
As a warning, don't be confused by those pseudo-random looking URL's for web images. Many of them do come from the same set of back-end services run by a relatively small set of companies, and they provide tremendous metadata about web use down to the individual purchaser level. Just because the data is "pseuonymized" does not protect it from analysis of the initial raw data, which is often poorly secured by the software companies themselves.
> Why would a VM be a security hole? Particularly if it's a jail, or a zone? It operates in its own space, separate from others, so if something else infects it, it can be closed from the parent OS.
The main reason is because very few environments bother to create, or to maintain such a restrictive environment. Such a system is, ideally, completely isolated from the rest of the network. Unfortunately, that also means it can no longer use network printers, it can no longer provide or collect information with worker's laptops, and it cannot be remotely logged into to run the designated critical business software.
Even if the systems personnel are competent to do so, they are often refused the permission or the resources to limit access in this way. Many environments follow the standard of "no one would bother us", and "we trust the people we work with", so they refuse to lock down potentially vulnerable resources. While it's theoretically possible to isolate a critical Windows based business application, it's very rarely done effectively, or as effectively and safely as running the application in Wine.
A Windows VM anywhere inside your network can be a profound security hole for a number of system architectural reasons. It can also create an undesired and unexpected maintenance cost to keep them active and secured. There are old programs, especially finance software, which may be business critical that run under Wine but not on modern Windows systems. Those programs are also particularly vulnerable to Windows support issues when the original programmers are out of business, or got bought by a company that discarded the software.
> The discs are still good
Except when they are not, especially in a RAID enclosure where identical drives are suffering similar rates of use. Some of us encountered the "Deathstar" series of drives, the IBM Deskstar 75GXP.
Live disk arrays are also vulnerable to accidental "rm -rf /" errors. Off-line backup is critical to recovery from such accidents.
> Security seems to be almost an afterthought.
By the time you get done activating security high availability, and integrity checking, you've often lowered the performance to below that of a more mature, well-tuned SQL database. There is a very amusing video that covers some of these issues in passing:
http://www.mongodb-is-web-scal...
There is a simplistic but useful video at http://www.alicesastroinfo.com... that describes the issue. They're effectively high density star regions, much like the funnel of a tornado or of a hurricane will form spirals.
> It's not Joe Randomhacker in his basement.
Until Joe Randomhacker steals it from poorly secured governmental resources. The same problem is built into the digatal rights management system called "Trusted Computing". The "Trusted Comting" key escrow, which basically puts private keys for software and hardware based encryption and access control in an screw repository held by Microsoft. The system has somewhat languished since it was discovered that one could virtualize the required hardware component, allowing parallel access on multiple virtual machines to the same data.
They also claimed that Iraq had strong Al Queda ties. According to the US House of Representatives, they lied repeatedly about it.
http://web.archive.org/web/200...
The idea that Sadam Hussein was tied to 9/11 was a popular and understandable one in the shock after 9/11 given the broad policy of lies. Unfortunately, it had no validity. Sadam and his regime knew much, much better than to allow a fundamentalist, radical Muslim group access to any weapons or significant political power in Iraq, or to compete with them for funding. They relied far too much on channeling fanatical fear of others into their own political powers to allow any competitors for such faith or such desperate action.
> then we need the FBI to put MUCH better accountability in place to ensure that THEY are not doing anything criminal.
The FBI has demonstrated that they can, and will, use their privileged access to monitoring to abuse and harass innocent people, and to perform criminal behavior to go after the "big fish" or the "kingpins". They've also demonstrated fundamental incompetence in handling chronic, lower level crime such as identity theft, "copyright violation", inter-state stalking of minors and domestic abuse escapees, and large scale online fraud. I've simply seen no evidence that they can do _anything_ competent that involves computer security. The few convictions they've gotten credit for were basically handed to them by informants or by aggrieved victims who were compelled to interact with the FBI to obtain subpoenas from other states.
I'm afraid they're just not competent at handling computer crime. The personnel in the department may be dedicated, they may even be technologically competent: whether the problem is one of skills or leadership _does not matter_. Expanding their mission by providing decryption tools for all traffic will simply deluge them with work they cannot handle.
Exporting the private keys is often done very poorly. I've certainly seen people email such certificates in plain text, and provide access to backups of load balancer backups with unencrypted local keys. Some web servers bother to require manual passwords at start time to unlock an encrypted private key, but I've seen only a very, very few high security sites do that.
> they might _if they spent a lot of money / resources_ f
It's not that much money. This article was from 2010, with the resources available then.
http://www.geek.com/news/resea...
What makes you think you won't get a fake?