Note that if you want to get Amazon's 70% royalty instead of 35%, you can't offer it somewhere else for cheaper. I am not certain if that means you can't give it away as well, but I'd make sure.
And 35% in my view is a bit low to offer it as a way of donating. Although of course the volume of sales may be larger and you probably reach customers you'd otherwise not reach.
The way I understood it is that the liability shift does not work that way. The least secure is liable. See http://en.wikipedia.org/wiki/EMV
The supposed increased protection from fraud has allowed banks and credit card issuers to push through a 'liability shift' such that merchants are now liable (as from 1 January 2005 in the EU region) for any fraud that results from transactions on systems that are not EMV capable.[2]
If a merchant does not support chip and the issuer (your bank) and the acquirer (bank of the merchant do), the merchant is liable. If the acquirer does not support EMV (aka Chip and pin), that bank is liable. Etc.
So only when the merchant keeps an old terminal that only supports magswipe despite his bank and the bank (/card issuer) of the customer supporting EMV and the chip, is the merchant liable.
hard to tell, but to me it seems that the big difference is that with netboot, you boot from the network, whereas this boots locally, gets a boot image, puts it to local disk and boots that. So you boot locally, just first get the bootimage over the network and store it.
It looks in my view similar to http://simpc.nl/ Although SimPC (at least way back, when I worked on it) always booted locally and just got a new new image when a it was newer. Considering that they mention it may be 'synchronized version of a locally cached version' it may be argued that it is similar.
I would say, hard to defend this patent. But I am not really an expert in patent laws
Cool, the software we have to implement hardly has any documentation, so this must mean hardly any bugs;-) Knew there had to be a reason why the documentation is hardly existing...
I have been a test manager for years, that includes doing intakes with new testers. Whilst I highly value development skills, the worst testers are those that just do it because there is a need for testers right now. I always look for that the tester: really chose to be a tester, and did not make that choice just because they couldn't land a contract as a developer. There will be exceptions, but most are either gone the moment they do get a better offer or worse, when they find flaws in the software, they try to fix it.
So my tip would be: either simply do not go for this contract, or come up with some real good explanation that you really want to test. The good explanation should not include anything that is based on money/bad market etc.
A more pressing question is how to get developers to stop ignoring bug reports.
You'd be surprised how much proper bug reports have to do with developers solving your issues quickly in stead of ingore it.
I'm a test manager and new testers in my team are trained to to follow strict rules for bug reporting. I find proper bug reports possibly more important deliverables then test plans and test reports. Since we started adhering to strict rules the developers started to handle our issues much faster as well as much better. Not only are they much more inclined to help you if you take the effort to make proper report, but also they have to spend _much_ less time on it. I've once calculated that a bad report can esaily cost more then 8 times the time it would have cost. And also they often otherwise fix the wrong thing. Why does it take so much more time? Because they first waste time to find out what's wrong, then they contact a designer, who does the same, wasting more time. Then they contact you again and as you probably logged it days or weeks ago, you do the same again. And before you know it, something that takes 30 minutes to fix caused 10 hours in work. If you're the only doing it right, you may see your developers picking yours up asap as the cherries.
Basic rules for reporting: - always provide steps performed (bulleted!) - always provide expected result - always provide actual result + the base for expecting this (i.e. see design page x or this is not right because...). - if not plain obviuos explain why actual result is not correct - alway provide test data used (i.e. username, customername, results such as logs xml messages)
If applicable (nearly always) - provide a screenshot
NEVER: - never try to their work and tell the developer things like: the code is probably wrong so and so or the database should do this and that. Describe the behaviour, not the cause. The biggest problem with this is that they may take you seriously and could fix it in the wrong place. They are better suited to determine what the cause is for certain behaviour.
Years ago I worked on product that put Linux on low power devices with a very simple user interface (mainly for older people that wanted to be able to just use internet etc.) The interface we created was very much like Unity, albeit with a lot less eyecandy. Big buttons on the side with just the applications we thought they needed and if you clicked again it would not open another session, just put your open session upfront.
I liked seeing that Unity went the same way and tried using it for a while. But in the end it annoyed me too much and reverted back to Gnome.
As the product we worked on is still being sold I guess the approach is ok, unless you want to do more then just using the basic apps
2) When I do need to run cable, such as telephone wire for my fax machine, I put the cable in the middle of the room. Then I buy a big rug, and place it over the top of the cable.
Slashdot Mirror
and bringing just an apple for the trip... yes, Darwin
Note that if you want to get Amazon's 70% royalty instead of 35%, you can't offer it somewhere else for cheaper. I am not certain if that means you can't give it away as well, but I'd make sure.
And 35% in my view is a bit low to offer it as a way of donating. Although of course the volume of sales may be larger and you probably reach customers you'd otherwise not reach.
So politics is really hard? Explains the quality of the candidates this year. . .
At least both candidates can read.....
Let us know when you successfully run the largest software company on the planet.
Let us know when Ballmer does _successfully_....
Wow, first this thread goes on and on about which fast food restaurant everyone prefers, then people complain about the obese women.
I just love this about Slashdot :-)
The way I understood it is that the liability shift does not work that way. The least secure is liable. See http://en.wikipedia.org/wiki/EMV
The supposed increased protection from fraud has allowed banks and credit card issuers to push through a 'liability shift' such that merchants are now liable (as from 1 January 2005 in the EU region) for any fraud that results from transactions on systems that are not EMV capable.[2]
If a merchant does not support chip and the issuer (your bank) and the acquirer (bank of the merchant do), the merchant is liable.
If the acquirer does not support EMV (aka Chip and pin), that bank is liable. Etc.
So only when the merchant keeps an old terminal that only supports magswipe despite his bank and the bank (/card issuer) of the customer supporting EMV and the chip, is the merchant liable.
So Mitt Romney will get us to Mars first? Color me confused :)
Sending Mitt Romney to Mars: Brilliant plan! The benefits to the economy will even outweigh the cost of the trip
hard to tell, but to me it seems that the big difference is that with netboot, you boot from the network, whereas this boots locally, gets a boot image, puts it to local disk and boots that. So you boot locally, just first get the bootimage over the network and store it.
It looks in my view similar to http://simpc.nl/ Although SimPC (at least way back, when I worked on it) always booted locally and just got a new new image when a it was newer. Considering that they mention it may be 'synchronized version of a locally cached version' it may be argued that it is similar.
I would say, hard to defend this patent. But I am not really an expert in patent laws
don't read it, you don't have to agree with everything on the internet
pfew...
Slashdot, where geeks who do not know or understand economics talk about it, and sound like idiots doing so.
And this differs from any financial forum, financial institution, TV news show how?
Just substitute bus by Ford F150 or Hummer, that's all
Then again, the iFB are the only federal agents that may catch you
Cool, the software we have to implement hardly has any documentation, so this must mean hardly any bugs ;-) Knew there had to be a reason why the documentation is hardly existing...
I think it was rocket 88...
don't have a girlfriend, wife won't let me have one ;-)
Well my GF always wants me to rub devices on her pussy
Sorry to hear your natural equipment doesn't do it for her.
Chuck Norris will be 100 then. But he then can still piss it back into orbit!
Very nice!, nonetheless I'd rather see it run on my Notion Ink Adam. I like the hardware, but somehow still grab my laptop more often.
I have been a test manager for years, that includes doing intakes with new testers. Whilst I highly value development skills, the worst testers are those that just do it because there is a need for testers right now. I always look for that the tester: really chose to be a tester, and did not make that choice just because they couldn't land a contract as a developer.
There will be exceptions, but most are either gone the moment they do get a better offer or worse, when they find flaws in the software, they try to fix it.
So my tip would be: either simply do not go for this contract, or come up with some real good explanation that you really want to test. The good explanation should not include anything that is based on money/bad market etc.
My tips:
Hardware
- Get a tower with a lot of 5,25 inch slots (there are midi towers with 9 slots available)
- Get passive harddisk coolers that you screw on the drive and then need a 5,25 inch slot such as: http://www.akasa.com.tw/update.php?tpl=product/product.detail.tpl&no=181&type=Cooling%20solutions&type_sub=HDD%20Cooler&model=AK-HD-03BK
- Get a highly efficient PSU (I got good results with Enermax 87+ series)
- Get 1 or 2 silent and high quality 12cm fans
- Get a CPU cooler that is mostly cooling block with on top a 12cm FAN
I did this and have a system so silent I need the leds to see that is on. Also allows for massive amounts of storage.
For software, you may want to take a look at http://www.nexentastor.org/projects/site/wiki/CommunityEdition
I don't yet have personal experience with this, but it is often used now in professional hosting.
And then put it in the basement and use something like a popcorn hour to connect to it over NFS to use the content :-)
^Ì
^D^C^C^B+%W>^Z^ß^@a`É
^Ã^D^N£CÏQ6×ïbvH×4^Ãå$^Ò~`OñõfËg/^ÝÂmÝÒ^\¼^Ô^W^X-
y$ä&*½^ÏoÚ^Ã^Õ
So when I email my wife, I'll write, "Don't meet me at the 5:10pm train and don't pick up my shirts at the laundry." Neat, huh?
You're probably one of the very few dudes that has a wife that listens..
A more pressing question is how to get developers to stop ignoring bug reports.
You'd be surprised how much proper bug reports have to do with developers solving your issues quickly in stead of ingore it.
I'm a test manager and new testers in my team are trained to to follow strict rules for bug reporting. I find proper bug reports possibly more important deliverables then test plans and test reports.
Since we started adhering to strict rules the developers started to handle our issues much faster as well as much better. Not only are they much more inclined to help you if you take the effort to make proper report, but also they have to spend _much_ less time on it. I've once calculated that a bad report can esaily cost more then 8 times the time it would have cost. And also they often otherwise fix the wrong thing. Why does it take so much more time? Because they first waste time to find out what's wrong, then they contact a designer, who does the same, wasting more time. Then they contact you again and as you probably logged it days or weeks ago, you do the same again. And before you know it, something that takes 30 minutes to fix caused 10 hours in work.
If you're the only doing it right, you may see your developers picking yours up asap as the cherries.
Basic rules for reporting:
- always provide steps performed (bulleted!)
- always provide expected result
- always provide actual result + the base for expecting this (i.e. see design page x or this is not right because...).
- if not plain obviuos explain why actual result is not correct
- alway provide test data used (i.e. username, customername, results such as logs xml messages)
If applicable (nearly always)
- provide a screenshot
NEVER:
- never try to their work and tell the developer things like: the code is probably wrong so and so or the database should do this and that. Describe the behaviour, not the cause. The biggest problem with this is that they may take you seriously and could fix it in the wrong place. They are better suited to determine what the cause is for certain behaviour.
Years ago I worked on product that put Linux on low power devices with a very simple user interface (mainly for older people that wanted to be able to just use internet etc.) The interface we created was very much like Unity, albeit with a lot less eyecandy. Big buttons on the side with just the applications we thought they needed and if you clicked again it would not open another session, just put your open session upfront.
I liked seeing that Unity went the same way and tried using it for a while. But in the end it annoyed me too much and reverted back to Gnome.
As the product we worked on is still being sold I guess the approach is ok, unless you want to do more then just using the basic apps
2) When I do need to run cable, such as telephone wire for my fax machine, I put the cable in the middle of the room. Then I buy a big rug, and place it over the top of the cable.
so 5 cables later you've got 5 rugs piled up?