I have a top notch stereo/Dolby/whatever sound field u need system (All Sony for compatibility), beats anything I could hope to put together again. It's sitting in storage as the introduction of HDMI made it obsolete.
I have a HDMI to optical switch, works quite well.
What I am proposing is that "1.2.3.4" is by definition a valid IPv6 address. But it isn't. IPv6 not only uses a crazy mapping-scheme (which is not automatic) but also a completely different format.
If IPv4 addresses were also valid IPv6 addresses, you could run your server with just ONE configuration for both IPv4 and IPv6.
So, I did a test on my Windows PC. I turned off IPv4 support on the network adapter, had it use the IPv6 network only (which has a NAT for IPv4 addressing). I was able to connect to IPv4 websites using IPv4 addresses and telnet just fine.
The problem is older routers have ASICs hard coded for IPv4.
Considering the average high-traffic router gets replaced every seven years (roughly), I have my doubts this is even a problem.
They can't 'route' IPv6 in hardware like they can with IPv4 so they use their CPU to forward IPv6 which is much slower.
I would imagine such routers aren't handling significant amounts of traffic and even so, without the need for running checksums, no fragmentation validations/calculations, jumbograms, no TTL field validations/calculation, I have doubts this really is an issue.
It does unfortunately, specifically when it comes to rule management.
The routes are several times larger, but there's 10x fewer routes because of reduced route table fragmentation.
That's really only an issue with routers that are handling routing in circumstances like connections to internet exchanges, most of those have a tendency to get replaced roughly around every seven years. I don't think the circulation of old routers in such scenarios without IPv6 support is that common any more.
Besides, since we're talking NAT if we are describing hard coded private IPs
I don't think it matters if it's private IPs or not, you control your network.
can't the OSs just read out those addresses, use IPv4-compatible IPv6 addresses
That was what I was suggested. There are deprecated variants in RFC 4291, I forget what the new method was which involved reserving a IPv6 subnet internally for it though.
Hard coded IPs in old software mean many companies will not change until forced.
Such things can be trivially handled on both Windows and Linux on a IPv6-only network. As an example, Windows could use the built in address translation for IPv4 addresses to IPv6 and merely assigning that IPv6 address to the server makes it a non-issue. Meanwhile on Linux, you could do some trivial iptables rules to point it to whatever address you like.
Older routers can't handle routing IPv6 in hardware so it puts a higher CPU load on the router. Nobody wants to spend the money to replace them.
Actually IPv4 is more CPU intensive due to where the checksum was implemented. IPv6's issue with hardware is more about memory.
Because of the above 2 items, residential ISP's rarely offer IPv6.
At least in the UK, numerous residential ISPs, while they may not have IPv6 offerings yet have certainly been only providing routers that have IPv6 support for the last few years.
You can buy an upgrade on Skype that only costs a few dollars a month that lets you call any phone number in the continental US.
I still have the old world subscription that provides me three Skype-in numbers and international calls as part of my subscription. So far, no local carrier available to me in the UK is beating it.
It provides international VOIP telephony fairly reliable and free. Works around most networking issues too. It's a shame the current generations of the software are quite slow.
But is this really the Jira software, or does it have to do with the client's sysadmin team?
The software can be a pain at times, but it's certainly not problematic as you described usually and this is JIRA experience taken from large multi-national firms.
Good luck with that, automation has a place but it does not include the replacement of thinking testing performed by informed humans. You must have an incredibly simple system if you think all relevant testing can be executed by a computer.
You've clearly not worked with companies where the standard is only step-by-step testing with linking to requirements and no other sort of sort of testing is allotted or even considered to be part of your work. You are either lucky or don't really have much testing experience across multiple firms.
When I last used TestRail, it did not actually expose it's data to JIRA directly, therefore making anything like JQL queries useless which made JIRA dashboard and JIRA reporting integration non-existent.
My major gripe with automated testing is that it is just regression testing. It does not give you new information.
You are correct and it has other flaws such as pesticide paradox.
And management wants pretty reports and test case numbers and so carve out little time for exploratory testing.
Take a look at session based testing, which provides lots of pretty metrics that are understandable. James Bach wrote a considerable amount of information on why reporting things like test case numbers and relying on how many have been tested etc. do not actually mean much of anything.
If developers were handling unit testing properly, with code coverage, making use of test/behaviour driven development (as in, they are the ones developing the automation as they develop the solution), the testers would be spending time on quality aspects like session based testing rather than step-by-step testing.
This requires a mind set change, where developers can get instant feedback when something does not have the expected out come and fix it before actually doing a release (ensure a failure of a unit test, fails the build and unit tests are always executed when building on the CI env).
Test cases have little to no place in Agile development.
But they do when certain auditing requirements are involved. I do believe that any step based tests should be automated however and a better approach where auditing requirements are not involved would be to make use of developers doing unit testing and coverage using methodology like test/behaviour driven development.
While I do advocate some Scenario based testing, which usually are a single line like "Can you place an order", traditional test cases are convoluted and difficult to maintain.
Scenario testing doesn't deliver reasonable metrics consumption and can leave to numerous auditing issues. This is why I prefer session based testing and take methodologies like scenario testing and include it as part of session testing. There is sense in using certain manual methodologies outside of step-by-step test cases, since they counter issues such as pesticide paradox.
My teams have been using Google Docs for 3-4 years to track scenario based testing, while not perfect it gets the job down, is lightweight, multiple people can be in there, and just gets the job done.
Google Docs is an extremely flexible environment and makes it hard to determine what is really being done. I will say as someone that has used a numerous amount of test management solutions (usually involving large projects with multiple teams) that JIRA certainly does fine for scenario and session based testing. JIRA does have the advantage that using JQL, you can trivially find holes in your data for organisational issues.
I will admit, for step-by-step test cases, JIRA is a bit lacking, but I'd still rather use it over solutions like HP Quality Center which were designed for test cases.
Get automation plugged into a Continuous Integrated system, so it runs all the time.
It's disappointing to hear Agile projects not running like this from the get-go.
Slashdot Mirror
I have a HDMI to optical switch, works quite well.
Do it on Windows 7+ (using Cygwin), you will find it works fine. Windows is smart enough to handle IPv4 and IPv6 simultaneously.
So, I did a test on my Windows PC. I turned off IPv4 support on the network adapter, had it use the IPv6 network only (which has a NAT for IPv4 addressing). I was able to connect to IPv4 websites using IPv4 addresses and telnet just fine.
I couldn't tell you about the routing table portion, not something I investigated or played with.
There is actually another one, which was meant to be used for dealing with multiple IPv4 networks translated over IPv6. I forgot what it was called.
Considering the average high-traffic router gets replaced every seven years (roughly), I have my doubts this is even a problem.
I would imagine such routers aren't handling significant amounts of traffic and even so, without the need for running checksums, no fragmentation validations/calculations, jumbograms, no TTL field validations/calculation, I have doubts this really is an issue.
It does unfortunately, specifically when it comes to rule management.
That's really only an issue with routers that are handling routing in circumstances like connections to internet exchanges, most of those have a tendency to get replaced roughly around every seven years. I don't think the circulation of old routers in such scenarios without IPv6 support is that common any more.
Which was in particular only necessary by design for the checksum which isn't necessary in IPv6.
I don't think it matters if it's private IPs or not, you control your network.
That was what I was suggested. There are deprecated variants in RFC 4291, I forget what the new method was which involved reserving a IPv6 subnet internally for it though.
Such things can be trivially handled on both Windows and Linux on a IPv6-only network. As an example, Windows could use the built in address translation for IPv4 addresses to IPv6 and merely assigning that IPv6 address to the server makes it a non-issue. Meanwhile on Linux, you could do some trivial iptables rules to point it to whatever address you like.
Actually IPv4 is more CPU intensive due to where the checksum was implemented. IPv6's issue with hardware is more about memory.
At least in the UK, numerous residential ISPs, while they may not have IPv6 offerings yet have certainly been only providing routers that have IPv6 support for the last few years.
Yes it is, there are numerous methods supported through IPv6 for NATing to IPv4 addresses transparently just fine.
Skype does not discriminate against TLDs that are a length of two characters.
You'll have to rename if you want it to create a link from a hostname.
I followed RFC 3986 (the standard for handling URLs) to point to a resource and every time, Skype parsed it correctly.
When Google Hangouts was a little popular in my friends, the common theme was that other friends hated Google+, so they would not use it, ever.
I believe in my friend circles, Google Hangouts is used much less.
Meanwhile, Telegram is certainly more popular than Skype in my friend circles for text communications and media sharing now.
I still have the old world subscription that provides me three Skype-in numbers and international calls as part of my subscription. So far, no local carrier available to me in the UK is beating it.
The same reason why people use the Internet and landlines where every thing they say and do is recorded too.
It provides international VOIP telephony fairly reliable and free. Works around most networking issues too. It's a shame the current generations of the software are quite slow.
Not particularly. CIFS/SMBFS is better suited for enforcing file locking however.
You pretty much answered what I was going to answer.
Does this mean I can use JQL with the test cases and produce pretty reports and graphs using JIRA's regular built in dashboards?
The software can be a pain at times, but it's certainly not problematic as you described usually and this is JIRA experience taken from large multi-national firms.
You've clearly not worked with companies where the standard is only step-by-step testing with linking to requirements and no other sort of sort of testing is allotted or even considered to be part of your work. You are either lucky or don't really have much testing experience across multiple firms.
When I last used TestRail, it did not actually expose it's data to JIRA directly, therefore making anything like JQL queries useless which made JIRA dashboard and JIRA reporting integration non-existent.
You are correct and it has other flaws such as pesticide paradox.
Take a look at session based testing, which provides lots of pretty metrics that are understandable. James Bach wrote a considerable amount of information on why reporting things like test case numbers and relying on how many have been tested etc. do not actually mean much of anything.
If developers were handling unit testing properly, with code coverage, making use of test/behaviour driven development (as in, they are the ones developing the automation as they develop the solution), the testers would be spending time on quality aspects like session based testing rather than step-by-step testing.
This requires a mind set change, where developers can get instant feedback when something does not have the expected out come and fix it before actually doing a release (ensure a failure of a unit test, fails the build and unit tests are always executed when building on the CI env).
But they do when certain auditing requirements are involved. I do believe that any step based tests should be automated however and a better approach where auditing requirements are not involved would be to make use of developers doing unit testing and coverage using methodology like test/behaviour driven development.
Scenario testing doesn't deliver reasonable metrics consumption and can leave to numerous auditing issues. This is why I prefer session based testing and take methodologies like scenario testing and include it as part of session testing. There is sense in using certain manual methodologies outside of step-by-step test cases, since they counter issues such as pesticide paradox.
Google Docs is an extremely flexible environment and makes it hard to determine what is really being done. I will say as someone that has used a numerous amount of test management solutions (usually involving large projects with multiple teams) that JIRA certainly does fine for scenario and session based testing. JIRA does have the advantage that using JQL, you can trivially find holes in your data for organisational issues.
I will admit, for step-by-step test cases, JIRA is a bit lacking, but I'd still rather use it over solutions like HP Quality Center which were designed for test cases.
It's disappointing to hear Agile projects not running like this from the get-go.