The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it. In commercial development a whole slew of contractual issues come in.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code.
Yes - it happens all the time (changing projects, rejecting code and terminating employment). We don't need contracts that specify the quality of the code - but they do exist e.g. secure code standards.
OK. Now I'm confused:
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
We don't need contracts that specify the quality of the code
If you're saying that at some point during the contract you realise it's not working out, pay for the time spent and terminate early then that's fine. If you're saying that you'll pay based on some evaluation of the end product then the criteria for success need to be very clearly defined at the outset so that the contractor can assess the risk of failure and decide whether to take the contract.
Don't know what planet you live on where that doesn't happen (Planet Couch?).
I don't have any direct experience, I've just chatted to people who are contractors on other projects in our office and the people who hired them. They have been hired because there's an immediate need and no one available with either the time or skills required. The specification is written as well as it can be under the circumstances but it's never perfect. There are some very good contractors who keep getting rehired because they're trusted to deliver without a lot of management and there are some who are over their heads who get let go early. In the middle are the people who delivered as well as could be expected under the circumstances but the results aren't perfect and that's where it gets messy. There's a hard deadline to be met and so something has to be shipped, if the project gets funded for the next stage then they'll try to fix the bugs later, otherwise they'll stay.
The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it. In commercial development a whole slew of contractual issues come in.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code. You could also look over all their code, reject it for an arbitrary reason and then write your own implementation using all their best ideas.
The only way to enforce it would be to have objective criteria such as having the requirements completely specified in fine detail, QA tests to cover all situations and required coding conventions written into the contract before starting but most of the time that's not practical.
"In October 2007, the Swiss Federal Council decided that the distribution of ammunition to soldiers shall stop and that all previously issued ammo shall be returned. By March 2011, more than 99% of the ammo has been received. Only special rapid deployment units and the military police still have ammunition stored at home today.."
Wow, someone in the governent actually put 2+2 together.
I asked myself why they weren't piggy-backing a proper Public Key Infrastructure onto the ID scheme.
The main issue with PKS12 certificates is actually certifying who the end-user is. That normally involves physically going to someone and showing them some ID. This would elminate that step.
Once you have a.p12 file and that chain of trust then there's a well developed infrastructure to build on.
The government wouldn't be snooping on anything because they'd just be the Certificate Authority who would be verifying your identity as happens when you visit any SSL website.
It would open up many possible applications where you really need to make sure you know who the end-user is.
However my faith in the government getting it right are minimal and they are a bit fiddly to use so in the hands of an inexperienced web user they would probably either be not used or insecurely used.
The sensible solution is for the BBC to set up media caching servers within each ISP, which will save the ISP's bandwidth fees, and also the BBC's uplink.
This is the entire point of the argument. The ISPs are reselling BT Wholesale and have no equipment in the exchanges. As it's set up at the moment any ISP cache would be before it goes down BT's cable and before they get charged.
It requires BT Wholesale to put the CDN in their exchanges which will both cost them money and decrease their revenue. Suprisingly I don't think they're that keen to pay which is why everyone is arguing.
Windows update will randomly decide that it will restart the system that I've left running overnight to finish a compile. If you install Microsoft's PowerToys package then TweakUI will allow you to turn this off:
http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
If you modify DTrace so you can use it to break the DRM on iTunes then you wouldn't run into the anti-circumvention provision of the Digital Millenium Copyright.
So the lawyers don't care if the workaround is relatively trivial as long as you have to do "something".
Yes, this is a good thing but the problem isn't really the specification, it's the discrepancy between what the spec says and what the actual code in that version of Office actually does.
From what I've read before the big headache for developers of other office suites was to work around the bugs which behaved in unexpected ways.
Also when writing documents people were only interested in the WYSIWYG nature of the document and didn't care about the underlying markup language and metadata. They did things like pressing return a few times to get to a new page rather than inserting a page-break, creating a list by typing the actual numbers 1, 2, 3 etc. rather than using the proper list structure. These things are tricky to convert sensibly.
The only way to really see the document as it was written is to run the same versions of Office and Operating System in a virtual machine. This is what is being done in big digital archives http://news.bbc.co.uk/1/hi/technology/6265976.stm.
Hopefully with Microsoft's backing the converters will get better but I'm not expecting miracles.
I can see a lot of work for outsourced sweatshops manually verifying and tidying up converted documents for companies as they try and deal with their archives.
It's not a big issue and as long as programmers are aware then hopefully it will be avoided.
But there are pitfalls out there now which naive programming may fall into.
I came across this one at http://www.2038bug.com/. We hit the 31st bit of POSIX time in 2004. That means that if you add together any two current times, for example when taking an average, then you will overflow a 32 bit signed integer.
Apologies for code quality but this artificial example hopefully shows the issue:
I looked at the picture in the abstract again more closely and it's not what I thought.
I now agree with the AC post above that energetically it's a very bad crystal structure. I thought it was just the perspective but there are some unstable bond lengths and angles which will introduce too much strain.
Someone will feed the structure into a good materials modelling program and get an estimate of how stable it is. My guess is that it will be very unstable with a very low barrier for rearrangement to one of the stable known forms.
I haven't RTFA as I could only read the abstract (which I just about understood being a former chemist).
I couldn't tell whether he's just re-discovered Lonsdaleite, which is similar to diamond but based on hexagonal close packing rather than cubic close packing:
The idea of turning all emails into actions made a lot of sense to me
The point about not using your Inbox as a ToDo list and having it completely empty really motivates me to deal with the email rather than letting it hide with the others.
Fundamentally it's a bad idea anyway. As programmers we need to stop thinking we're clever and start thinking about operational issues. If you've got a bunch of applications on your system all consuming invisible data, how can you choose which one to kill to resolve an out of space situation? Yes, I know there are ways to figure it out by inspecting private kernel data structures with tools like lsof, or waddling around in/proc, or even just loading up your favorite debugger. But get real.
I agree it's not ideal but sometimes it might be handy.
I used to work on a software package which deletes it's temporary files. On occasion it can use many gigabytes of scratch files and was originally developed back in the eighties when disk space was at a premium.
The most common cause of the software filling up a disk was the user being too ambitious in their input and naively starting a job which would need terabytes of disk space (and decades of CPU time). It would happily churn away until the disk filled up and then fall over. As this was normally in the middle of the night it was much better for the unlinked files to disappear when the job crashed rather than everyone arriving in the morning and not be able to do anything until either the sysadmin or user did something about it.
I'm guessing that all the various ways the code could exit, crash or be killed could have been trapped and the scratch files dealt with but this was deemed the simplest and most surefire way to make sure they didn't hang around.
Nowadays an intelligent queueing system can have separate scratch directories for each job and clean up afterwards but you can't always rely on that.
YMMV with this syntax. In bash on my machine it didn't redirect the stderr and gave:
-bash: article: command not found
whereas article >/dev/null 2>&1 gives the expected result. With pipes it's the other way round so article 2>&1 | cat >/dev/null works (although obviously with a different exit code).
I agree that it's not free money but there should be a price point where everyone's happy.
When the UK government auctioned the 3G mobile phone spectrum in 2000 the operators ended up paying so much money (22 billion pounds) that they had none left to set up the network at a reasonable tariff and it bombed.
The point isn't in the energy *WON* - it's in the energy *NOT USED*. I don't know if you've ever hooked a kill-a-watt (current measuring device) to a treadmill, but those suckers suck powah!
It is energy "won" because they're not using treadmills. The article says that he uses stair-masters and elliptical trainers, neither of which use any mains electricity. They do contain a small motion-based generator to power the display which was modified to output the extra electricity generated.
Treadmills are inherently inefficient because they keep going round even if you're not on it. The green solution would be to throw out the powered treadmill and get an unpowered one.
Slashdot Mirror
The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it. In commercial development a whole slew of contractual issues come in.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code.
Yes - it happens all the time (changing projects, rejecting code and terminating employment). We don't need contracts that specify the quality of the code - but they do exist e.g. secure code standards.
OK. Now I'm confused:
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
We don't need contracts that specify the quality of the code
If you're saying that at some point during the contract you realise it's not working out, pay for the time spent and terminate early then that's fine. If you're saying that you'll pay based on some evaluation of the end product then the criteria for success need to be very clearly defined at the outset so that the contractor can assess the risk of failure and decide whether to take the contract.
Don't know what planet you live on where that doesn't happen (Planet Couch?).
I don't have any direct experience, I've just chatted to people who are contractors on other projects in our office and the people who hired them. They have been hired because there's an immediate need and no one available with either the time or skills required. The specification is written as well as it can be under the circumstances but it's never perfect. There are some very good contractors who keep getting rehired because they're trusted to deliver without a lot of management and there are some who are over their heads who get let go early. In the middle are the people who delivered as well as could be expected under the circumstances but the results aren't perfect and that's where it gets messy. There's a hard deadline to be met and so something has to be shipped, if the project gets funded for the next stage then they'll try to fix the bugs later, otherwise they'll stay.
The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it. In commercial development a whole slew of contractual issues come in.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code. You could also look over all their code, reject it for an arbitrary reason and then write your own implementation using all their best ideas.
The only way to enforce it would be to have objective criteria such as having the requirements completely specified in fine detail, QA tests to cover all situations and required coding conventions written into the contract before starting but most of the time that's not practical.
"In October 2007, the Swiss Federal Council decided that the distribution of ammunition to soldiers shall stop and that all previously issued ammo shall be returned. By March 2011, more than 99% of the ammo has been received. Only special rapid deployment units and the military police still have ammunition stored at home today.."
Serves me right for not RTFA.
Looks like they're slapping Chip&PIN on it.
Probably a more sensible option, but not the one I'd prefer.
Because you clone a mobile phone. It's trickier with newer GSM phones but not impossible (and there would be suddenly much more incentive to do so)
SMS messages just don't have the level of security a bank would require.
Wow, someone in the governent actually put 2+2 together.
I asked myself why they weren't piggy-backing a proper Public Key Infrastructure onto the ID scheme.
The main issue with PKS12 certificates is actually certifying who the end-user is. That normally involves physically going to someone and showing them some ID. This would elminate that step.
Once you have a .p12 file and that chain of trust then there's a well developed infrastructure to build on.
The government wouldn't be snooping on anything because they'd just be the Certificate Authority who would be verifying your identity as happens when you visit any SSL website.
It would open up many possible applications where you really need to make sure you know who the end-user is.
However my faith in the government getting it right are minimal and they are a bit fiddly to use so in the hands of an inexperienced web user they would probably either be not used or insecurely used.
It was not his official government email account, it was his constituency email account.
This is the entire point of the argument. The ISPs are reselling BT Wholesale and have no equipment in the exchanges. As it's set up at the moment any ISP cache would be before it goes down BT's cable and before they get charged.
It requires BT Wholesale to put the CDN in their exchanges which will both cost them money and decrease their revenue. Suprisingly I don't think they're that keen to pay which is why everyone is arguing.
Won't a byproduct of IPv6 be that everything will have a unique IP address and so become even more of a unique identifier.
And because there will be so many addresses I'm guessing that they won't get recycled very much at all.
D'oh. Bad typo in parent completely inverts meaning. Please change "you wouldn't" to "wouldn't you"
If you modify DTrace so you can use it to break the DRM on iTunes then you wouldn't run into the anti-circumvention provision of the Digital Millenium Copyright.
So the lawyers don't care if the workaround is relatively trivial as long as you have to do "something".
Yes, this is a good thing but the problem isn't really the specification, it's the discrepancy between what the spec says and what the actual code in that version of Office actually does.
From what I've read before the big headache for developers of other office suites was to work around the bugs which behaved in unexpected ways.
Also when writing documents people were only interested in the WYSIWYG nature of the document and didn't care about the underlying markup language and metadata. They did things like pressing return a few times to get to a new page rather than inserting a page-break, creating a list by typing the actual numbers 1, 2, 3 etc. rather than using the proper list structure. These things are tricky to convert sensibly.
The only way to really see the document as it was written is to run the same versions of Office and Operating System in a virtual machine. This is what is being done in big digital archives http://news.bbc.co.uk/1/hi/technology/6265976.stm.
Hopefully with Microsoft's backing the converters will get better but I'm not expecting miracles.
I can see a lot of work for outsourced sweatshops manually verifying and tidying up converted documents for companies as they try and deal with their archives.
It's very unlikely that there will be any problems on Saturday.
It's taking advantage of the anniversary to basically do a Public Service Announcement for programmers.
If everyone's aware of the problem then they will have it in the back of their mind and take precautions when doing time-related coding.
It's a lot easier to take care of it when we're actually writing the code rather than panicking about it when it's only a few years away.
It's not a big issue and as long as programmers are aware then hopefully it will be avoided.
But there are pitfalls out there now which naive programming may fall into.
I came across this one at http://www.2038bug.com/. We hit the 31st bit of POSIX time in 2004. That means that if you add together any two current times, for example when taking an average, then you will overflow a 32 bit signed integer.
Apologies for code quality but this artificial example hopefully shows the issue:
gives the following on my x86 Linux system:
It's easy to fix by casting to 64 bit or dividing first but there may be similar examples hiding away in old code which are less easy to spot.
I looked at the picture in the abstract again more closely and it's not what I thought.
I now agree with the AC post above that energetically it's a very bad crystal structure. I thought it was just the perspective but there are some unstable bond lengths and angles which will introduce too much strain.
Someone will feed the structure into a good materials modelling program and get an estimate of how stable it is. My guess is that it will be very unstable with a very low barrier for rearrangement to one of the stable known forms.
I haven't RTFA as I could only read the abstract (which I just about understood being a former chemist).
I couldn't tell whether he's just re-discovered Lonsdaleite, which is similar to diamond but based on hexagonal close packing rather than cubic close packing:
http://en.wikipedia.org/wiki/Lonsdaleite
Can anyone who's read (and understood) the whole article comment on that?
What if finding extra terrestial intelligence brought about a cure for cancer?
Perhaps the little green men solved the problem aeons ago and are quite happy to help ;)
.
.
.
I'll get my coat
Yes, slide rules have been superceded, but that's not the point.
They encourage you to actually think about the problem you're dealing with.
Computers are a low point of entry, brute force approach which encourage GIGO: Garbage In Garbage Out.
Owning a slide rule means you recognize that computers can't do your thinking for you.
I agree.
The idea of turning all emails into actions made a lot of sense to me
The point about not using your Inbox as a ToDo list and having it completely empty really motivates me to deal with the email rather than letting it hide with the others.
I agree it's not ideal but sometimes it might be handy.
I used to work on a software package which deletes it's temporary files. On occasion it can use many gigabytes of scratch files and was originally developed back in the eighties when disk space was at a premium.
The most common cause of the software filling up a disk was the user being too ambitious in their input and naively starting a job which would need terabytes of disk space (and decades of CPU time). It would happily churn away until the disk filled up and then fall over. As this was normally in the middle of the night it was much better for the unlinked files to disappear when the job crashed rather than everyone arriving in the morning and not be able to do anything until either the sysadmin or user did something about it.
I'm guessing that all the various ways the code could exit, crash or be killed could have been trapped and the scratch files dealt with but this was deemed the simplest and most surefire way to make sure they didn't hang around.
Nowadays an intelligent queueing system can have separate scratch directories for each job and clean up afterwards but you can't always rely on that.
YMMV with this syntax. In bash on my machine it didn't redirect the stderr and gave:
-bash: article: command not found
whereas article > /dev/null 2>&1 gives the expected result. With pipes it's the other way round so article 2>&1 | cat > /dev/null works (although obviously with a different exit code).
[/pedantry]
The more important issue is that there is no force between the runner and the treadmill so you have to be strapped down http://www.nasa.gov/mission_pages/station/science/ eZLS_treadmill_010306.html
I agree that it's not free money but there should be a price point where everyone's happy.
When the UK government auctioned the 3G mobile phone spectrum in 2000 the operators ended up paying so much money (22 billion pounds) that they had none left to set up the network at a reasonable tariff and it bombed.
It is energy "won" because they're not using treadmills. The article says that he uses stair-masters and elliptical trainers, neither of which use any mains electricity. They do contain a small motion-based generator to power the display which was modified to output the extra electricity generated.
Treadmills are inherently inefficient because they keep going round even if you're not on it. The green solution would be to throw out the powered treadmill and get an unpowered one.