I sat in on a router design meeting for IPv6. It took me 20 minutes to stop laughing when I heard them seriously say that it was acceptable for the system to crash if it encountered a router loop, because users will "just be careful and that won't happen". Then I took the copy of the presentation and my notes to my stock analyst and pointed out "these people ar bozos, do not invest in them or trust anyone who has invested in them". I didn't make money, but it helped keep me from *losing* a good chunk of money when their "Cisco-killer" failed miserably.
As it stands, your carier does NAT themselves and gives your router one IP address, typically in the 10.0.0.0/8 address space. Your home router then does another layouer of NAT, and gives internal devices their own IP address range in the 1902.168.1.0/16 address space. The advantagie is that one can support a _tremendous_ backend infrastructure without public IP addresses. This is also a tremendous security advantage: it reduces the exposed attack surface for script kiddies and casual network scanners to attack your home devices, they have to successfully gain control of the router or another device inside your network to pass along their attack.
The disadvantage, which dismays some people, is that NAT channels _publication_ of services through those NAT enabled routers or through externally hosted web space. It effectively makes the allocation of IP addresses and ports for exposed services require more thought, and allows easier throttling or monitoring of traffic at those NAT routers. I've found it to be a tremendous security and network management improvement: it makes firewall and routing design _much_ more stable and helps prevent people from running dangerous, unauthorized services from office networks, such as running public NFS servers without telling anyone aware of the security implications.
I'd consider GPL a considerable licensing _improvement_. Its language is more clear and it protects better against the "proprietization" and secretive changes of standards or API's associated with licenses that are "business friendly". The clarity and thoughtfulness of its language has helped me, repeatedly, solve time wasting arguments at software planning meetings about if and how we need to publish our modifications.
This does not indicate what Canonical actually wrote to Mint. That would be a very _reasonable_ concern. But without seeing the lette to Mint, or one from Mint about the issue, it could be about the standards for white space indentation of source code in Ubuntu software that is _not_ under a well known open source license. Some open source licenses have been known to have very, very foolish restrictions: the old "DJB" license had a restriction that modifying a single line of the code meant that you could only publish Dan Bernstein's source code, and diffs to apply your differences. You could not publish binaries.
Canonical's licensing has also gotten odd, and itself deserves suspicion. The new MIR display system is "sort of" licensed under GPLv3 but contributors are required to sign an agreement that "grants Canonical the right to relicense your contribution under their choice of license. Given Canonical's recent history of inserting spyware into their distribution, sending all search results of your local disk back to their upstream servers, Canonical and their Ubuntu software have earned the considerable suspicion they are being treated with.
RHEL also includes quite a lot of Apache and BSD and Perl licensed software. There are components, such as the older Sun Java that had more restrictive licenses, and which CentOS therefore could not include, and numerous programs with patent or security implicaitons such MPEG players and the libdvdcss for DVD decoding which Red Hat also could not include for patent or other legal restrictions. Red Hat definitely deserves credit for helping bring proprietary software into the open source or free software world wherever possible: their help with the creation of openjdk has helped improve Java quality, and licensing, from the onerous and individually signed end uear license agreements that Sun used to insist on.
I'm afraid I deal with the debris of those "best programmers" on a weekly basis. They sometimes write brilliant, insightful, paradigm shifting core projects. Unfortunately, they then abandon supporting them or get switched to another task.
It's up to the rest of us to unfurl the unnecessary recursion which is throttling performance, spot the hidden assumptions about data formats, reduce the unnecessary footprint due to writing custom subroutines to perform tasks built into the language as standard library calls, activate security tracking, enable the ability to reliably restore from backup, or activate debugging to figure out just where that "I'll fix it later" bug came from. This is compounded by the often stellar documentation, which too often consists of "read the code" because the workflow is not actually charted anywhere. It's completely clear to them as they write it, but six months later, even they don't remember it.
The ability to "pick up a language quickly" is quite common. Anyone who's learned PHP or Perl or Python or Ruby can generally read the code of the other languages, and learning C++, Java,, or even Fortran for we older programmers can certainly allow some insights into other languages. But as soon as it gets more complex, such as migrating 32-bit or 64-bit software to the other architecture, or scaling up an application from 10 QA userrs to 1000 customers, actually communicating efficiently with a backend database, poorly learned code from "brilliant developers" is the bane of programmers or systems personnel whose job title does not include "architect".
Clear language and being able to refer people to the Apache Foundation or the FSF for clarification on the license has certainly helped _me_, and my clients, deal with patent trolls. It also helps deal with patent fear mongering and corporate lawyers who have not been well educated on these licenses.
Few of the open source patents do not address patents. GPLv3, which is a genuinely "free as in speech" license, and the recent Apache icenses, do deal with patents.
The MIT license and most of the BSD licenses *do not* handle patents well. The FreeBSD license, funded now by Apple, now very specifically does *)not* grant patent protection, to protect Apple's patents from encroachment.
From a conversation with a developer last week, who refused to allow QA to be applied to code: "show me how this software could break something, and I will run it through QA". Yet his workgroup was trying to blame _my_ personnel for applying their new code incorrectly, and make us spend the weekend time to fix it on the live systems.
Sometimes the problem is not the contractor who assembled the wall, it's the employer who wouldn't pay for, or allow, the contrtactor to use the right procedures.
With aging populations, rising fuel prices due to crude oil depletion, population growth, and the improvement of rail roads and bus services, and effective telecommuting: why is hte reduction of personal aircraft in any way a surprise?
[ Still using Slashdot until beta takes over, then I'll dump it. ]
It's an interesting ruling. While Steam's lack of support for re-sale of games may run into legal issues, their willingness to keep games available at lower and lower price points as games get older shows that they're not abusing the privilege. If you can wait a while, the price will come down to a reasonable point and the game is available for people who'd have otherwise needed to buy the game used. And I've been delighted to see old games that I've enjoyed, such as the original Doom or Thief or X-com games, be available on Steam. It's helped me avoid having to recover and old games and simply pray that they'd be playable on modern operating systems: I'm very pleased with Steam for making older games available at very reasonable prices. We're actually getting something from them in return for their exclusive licensing.
Oh, I do see the revisions in http://en.wikipedia.org/wiki/U.... It's therefore still a messy business to decide what is considered wetlands under EPA protection.
Ahh, a bit of digging points out the 2006 Supreme Court that you seem to be misinterpreting, http://en.wikipedia.org/wiki/U.... That case upheld the protection of wetlands that intermingle with navigable waterways. I'm afraid that if you wish to cite the Supreme Court decision as "unauthorizied expansion by overzeaolous" bureaucrats, I can only wish you good luck with that.
It can actually work. The advent of cheap tests for lead and other toxins, of GPS for home survey work, and of cell phones for photographing criminal behavior have all altered what people or companies can do without detection and prosecution.
Deducing gravity by noticing what has fallen and how fast is "a bunch of data points and an opinion". It's also falsifiable: you predict what the data will be for other, related circumstances you haven't measured yet. A lot of astronomy, chemistry, biology, and social sciences are done this way because strictly controlled experiments are very difficult.
The ability to make precise predictions, or to give accurate and verifiable _ranges_ for results, seems to be a very good basis for both engineering and science.
It's a fascinating case. It has _nothing_ do with navigable waters, it has to do with wetlands, which are federally protected in various ways, and the Clean Waters Act, which involves protecting water supplies. If you're going to cite an example of bureaucratic abuse because of "navigable waters" that only exist for a day, cite one they're actually guilty of, please. Please don't cite cases that have no direct relevance to your claim of abuse.
And I call it "straw man argument" when someone cites bureaucratic foibles with what are demonstrably nonexistent examples.
Kindly cite the cases of "navigable waters" including "any puddle that lasts more than 24 hours". The Supreme Court guidelines are fascinating, and seem to be extensible to include waterways large enough to handle a canoe, depending on whether it's connected to another waterway. But they're workable, and discharging the waste into a creek that _feeds into_ a lake or ocean could certainly make such discharges relevant to public safety.
In the US, the separation of different doctor office and health insurance systems helps isolate the data from centralized universal access. Continuing to protect and isolate patient data is large concern for doctors who treat terminal cancer, mental health patients, STD's, or pregnancy in juveniles. It's led to some fascinating conflicts between HIPAA, which is supposed to ease sharing and reliability of medical records in the age of digital records, and doctor/patient confidentiality practices that may be in favor of patient confidentiality than HIPAA allows.
HIPAA also has guidelines to _protect_ patient data, but make no mistake about its results. It's being used to make patient data more consistently and easily accessible among all interested personnel, and its protections against government snooping are effectively non-existent.
It could be abused, to force the EPA to include "meta-analyses" of scientific results and use them to discredit reliable results compared to large sets of industry published, fraudulent results. Let's not forget the tobacco industry scientific fraud, for decades, about the poisonous effects of cigarette smoke on humans.
It's also theoretically possible that this kind of law could be used to expose the "industry analyses" to review. That's what I'd hope for, right now: too many analyses are published under extensive non-disclosure agreements that prevent the EPA from being able to publish them. I've certainly seen that kind of restraint of publication about groundwater and soil toxicity analyses for new construction. The project leaders wanted even the existence of the analysis kept secret unless it was favorable to construction.
I never mentioned the ADA in my post. So you obviously know that the relevant law is the American with Disabilities Act, since you inferred its mention without my having written it.
May I assume that such a mis-aimed, ill-founded troll was written by someone whose paycheck relies on the slashdot beta? The presence of irrelevant and distracting matierial based on a need that was invented out of misunderstood references and now leads to confused publication by someone who has failed to address any genuinely relevant issue does sound like the Slashdot Beta.
The unnecessarily complex and excessively indented layout interferes with text->speech tools, and actually reduces legibility for people who heavily expand their screens due to visual problems. The current clean, well ordered, linear layout is easy to use, intuitive, and doesn't insert painful, confusing, or unnecessary complexity. The slashdot readers, and contributors, are here for the stories, not for the exciting newness of the GUI.
Does anyone know who actually _wrote_, or demanded, the Slashddot Beta? I'd like their names so we can warn our clients and colleagues _against_ their work.
It's impossible to _prevent_ jinking at high speed: minor changes in atmospheric density are multiplied in effect by the force needed to continue at high mach speeds, as even minute differences exert enormously differential forces in the shock wave.
Slashdot Mirror
I sat in on a router design meeting for IPv6. It took me 20 minutes to stop laughing when I heard them seriously say that it was acceptable for the system to crash if it encountered a router loop, because users will "just be careful and that won't happen". Then I took the copy of the presentation and my notes to my stock analyst and pointed out "these people ar bozos, do not invest in them or trust anyone who has invested in them". I didn't make money, but it helped keep me from *losing* a good chunk of money when their "Cisco-killer" failed miserably.
As it stands, your carier does NAT themselves and gives your router one IP address, typically in the 10.0.0.0/8 address space. Your home router then does another layouer of NAT, and gives internal devices their own IP address range in the 1902.168.1.0/16 address space. The advantagie is that one can support a _tremendous_ backend infrastructure without public IP addresses. This is also a tremendous security advantage: it reduces the exposed attack surface for script kiddies and casual network scanners to attack your home devices, they have to successfully gain control of the router or another device inside your network to pass along their attack.
The disadvantage, which dismays some people, is that NAT channels _publication_ of services through those NAT enabled routers or through externally hosted web space. It effectively makes the allocation of IP addresses and ports for exposed services require more thought, and allows easier throttling or monitoring of traffic at those NAT routers. I've found it to be a tremendous security and network management improvement: it makes firewall and routing design _much_ more stable and helps prevent people from running dangerous, unauthorized services from office networks, such as running public NFS servers without telling anyone aware of the security implications.
I'd consider GPL a considerable licensing _improvement_. Its language is more clear and it protects better against the "proprietization" and secretive changes of standards or API's associated with licenses that are "business friendly". The clarity and thoughtfulness of its language has helped me, repeatedly, solve time wasting arguments at software planning meetings about if and how we need to publish our modifications.
This does not indicate what Canonical actually wrote to Mint. That would be a very _reasonable_ concern. But without seeing the lette to Mint, or one from Mint about the issue, it could be about the standards for white space indentation of source code in Ubuntu software that is _not_ under a well known open source license. Some open source licenses have been known to have very, very foolish restrictions: the old "DJB" license had a restriction that modifying a single line of the code meant that you could only publish Dan Bernstein's source code, and diffs to apply your differences. You could not publish binaries.
Canonical's licensing has also gotten odd, and itself deserves suspicion. The new MIR display system is "sort of" licensed under GPLv3 but contributors are required to sign an agreement that "grants Canonical the right to relicense your contribution under their choice of license. Given Canonical's recent history of inserting spyware into their distribution, sending all search results of your local disk back to their upstream servers, Canonical and their Ubuntu software have earned the considerable suspicion they are being treated with.
RHEL also includes quite a lot of Apache and BSD and Perl licensed software. There are components, such as the older Sun Java that had more restrictive licenses, and which CentOS therefore could not include, and numerous programs with patent or security implicaitons such MPEG players and the libdvdcss for DVD decoding which Red Hat also could not include for patent or other legal restrictions. Red Hat definitely deserves credit for helping bring proprietary software into the open source or free software world wherever possible: their help with the creation of openjdk has helped improve Java quality, and licensing, from the onerous and individually signed end uear license agreements that Sun used to insist on.
I'm afraid I deal with the debris of those "best programmers" on a weekly basis. They sometimes write brilliant, insightful, paradigm shifting core projects. Unfortunately, they then abandon supporting them or get switched to another task.
It's up to the rest of us to unfurl the unnecessary recursion which is throttling performance, spot the hidden assumptions about data formats, reduce the unnecessary footprint due to writing custom subroutines to perform tasks built into the language as standard library calls, activate security tracking, enable the ability to reliably restore from backup, or activate debugging to figure out just where that "I'll fix it later" bug came from. This is compounded by the often stellar documentation, which too often consists of "read the code" because the workflow is not actually charted anywhere. It's completely clear to them as they write it, but six months later, even they don't remember it.
The ability to "pick up a language quickly" is quite common. Anyone who's learned PHP or Perl or Python or Ruby can generally read the code of the other languages, and learning C++, Java,, or even Fortran for we older programmers can certainly allow some insights into other languages. But as soon as it gets more complex, such as migrating 32-bit or 64-bit software to the other architecture, or scaling up an application from 10 QA userrs to 1000 customers, actually communicating efficiently with a backend database, poorly learned code from "brilliant developers" is the bane of programmers or systems personnel whose job title does not include "architect".
Clear language and being able to refer people to the Apache Foundation or the FSF for clarification on the license has certainly helped _me_, and my clients, deal with patent trolls. It also helps deal with patent fear mongering and corporate lawyers who have not been well educated on these licenses.
Few of the open source patents do not address patents. GPLv3, which is a genuinely "free as in speech" license, and the recent Apache icenses, do deal with patents.
The MIT license and most of the BSD licenses *do not* handle patents well. The FreeBSD license, funded now by Apple, now very specifically does *)not* grant patent protection, to protect Apple's patents from encroachment.
From a conversation with a developer last week, who refused to allow QA to be applied to code: "show me how this software could break something, and I will run it through QA". Yet his workgroup was trying to blame _my_ personnel for applying their new code incorrectly, and make us spend the weekend time to fix it on the live systems.
Sometimes the problem is not the contractor who assembled the wall, it's the employer who wouldn't pay for, or allow, the contrtactor to use the right procedures.
Oh, goodness, I said population growth twice. I meant to say urban sprawl the second time.
With aging populations, rising fuel prices due to crude oil depletion, population growth, and the improvement of rail roads and bus services, and effective telecommuting: why is hte reduction of personal aircraft in any way a surprise?
[ Still using Slashdot until beta takes over, then I'll dump it. ]
It's an interesting ruling. While Steam's lack of support for re-sale of games may run into legal issues, their willingness to keep games available at lower and lower price points as games get older shows that they're not abusing the privilege. If you can wait a while, the price will come down to a reasonable point and the game is available for people who'd have otherwise needed to buy the game used. And I've been delighted to see old games that I've enjoyed, such as the original Doom or Thief or X-com games, be available on Steam. It's helped me avoid having to recover and old games and simply pray that they'd be playable on modern operating systems: I'm very pleased with Steam for making older games available at very reasonable prices. We're actually getting something from them in return for their exclusive licensing.
Oh, I do see the revisions in http://en.wikipedia.org/wiki/U.... It's therefore still a messy business to decide what is considered wetlands under EPA protection.
Ahh, a bit of digging points out the 2006 Supreme Court that you seem to be misinterpreting, http://en.wikipedia.org/wiki/U.... That case upheld the protection of wetlands that intermingle with navigable waterways. I'm afraid that if you wish to cite the Supreme Court decision as "unauthorizied expansion by overzeaolous" bureaucrats, I can only wish you good luck with that.
It can actually work. The advent of cheap tests for lead and other toxins, of GPS for home survey work, and of cell phones for photographing criminal behavior have all altered what people or companies can do without detection and prosecution.
Congress. They leak _everything_.
Deducing gravity by noticing what has fallen and how fast is "a bunch of data points and an opinion". It's also falsifiable: you predict what the data will be for other, related circumstances you haven't measured yet. A lot of astronomy, chemistry, biology, and social sciences are done this way because strictly controlled experiments are very difficult.
The ability to make precise predictions, or to give accurate and verifiable _ranges_ for results, seems to be a very good basis for both engineering and science.
It's a fascinating case. It has _nothing_ do with navigable waters, it has to do with wetlands, which are federally protected in various ways, and the Clean Waters Act, which involves protecting water supplies. If you're going to cite an example of bureaucratic abuse because of "navigable waters" that only exist for a day, cite one they're actually guilty of, please. Please don't cite cases that have no direct relevance to your claim of abuse.
And I call it "straw man argument" when someone cites bureaucratic foibles with what are demonstrably nonexistent examples.
Kindly cite the cases of "navigable waters" including "any puddle that lasts more than 24 hours". The Supreme Court guidelines are fascinating, and seem to be extensible to include waterways large enough to handle a canoe, depending on whether it's connected to another waterway. But they're workable, and discharging the waste into a creek that _feeds into_ a lake or ocean could certainly make such discharges relevant to public safety.
In the US, the separation of different doctor office and health insurance systems helps isolate the data from centralized universal access. Continuing to protect and isolate patient data is large concern for doctors who treat terminal cancer, mental health patients, STD's, or pregnancy in juveniles. It's led to some fascinating conflicts between HIPAA, which is supposed to ease sharing and reliability of medical records in the age of digital records, and doctor/patient confidentiality practices that may be in favor of patient confidentiality than HIPAA allows.
HIPAA also has guidelines to _protect_ patient data, but make no mistake about its results. It's being used to make patient data more consistently and easily accessible among all interested personnel, and its protections against government snooping are effectively non-existent.
It could be abused, to force the EPA to include "meta-analyses" of scientific results and use them to discredit reliable results compared to large sets of industry published, fraudulent results. Let's not forget the tobacco industry scientific fraud, for decades, about the poisonous effects of cigarette smoke on humans.
It's also theoretically possible that this kind of law could be used to expose the "industry analyses" to review. That's what I'd hope for, right now: too many analyses are published under extensive non-disclosure agreements that prevent the EPA from being able to publish them. I've certainly seen that kind of restraint of publication about groundwater and soil toxicity analyses for new construction. The project leaders wanted even the existence of the analysis kept secret unless it was favorable to construction.
Perhaps it was "SANTA" ?
http://www.porcupine.org/satan...
I still remember the SATAN network scanning tool, which had a little script called "repent" to change the name and gifs to "SANTA"
Could there possibly be such a tool in place to "repent" the Slashdot Beta to something usable? We can only hope.
I never mentioned the ADA in my post. So you obviously know that the relevant law is the American with Disabilities Act, since you inferred its mention without my having written it.
May I assume that such a mis-aimed, ill-founded troll was written by someone whose paycheck relies on the slashdot beta? The presence of irrelevant and distracting matierial based on a need that was invented out of misunderstood references and now leads to confused publication by someone who has failed to address any genuinely relevant issue does sound like the Slashdot Beta.
The unnecessarily complex and excessively indented layout interferes with text->speech tools, and actually reduces legibility for people who heavily expand their screens due to visual problems. The current clean, well ordered, linear layout is easy to use, intuitive, and doesn't insert painful, confusing, or unnecessary complexity. The slashdot readers, and contributors, are here for the stories, not for the exciting newness of the GUI.
Does anyone know who actually _wrote_, or demanded, the Slashddot Beta? I'd like their names so we can warn our clients and colleagues _against_ their work.
It's impossible to _prevent_ jinking at high speed: minor changes in atmospheric density are multiplied in effect by the force needed to continue at high mach speeds, as even minute differences exert enormously differential forces in the shock wave.