" it was not just a few seeds from a passing truck". Really it's ok for a few seeds from a passing truck to contaminate your non-GMO crop? If you have a problem with that, perhaps because you're trying to grow crops that rely on organic/biodynamic principles where the soil biology is important as opposed to pouring pesticides/herbicides onto it, then you really just need to get over it. Hey we're having a gun fight over here and yeah there might be a few stray bullets but you just need to get over it.
You read the article? Holy shit, I thought people like you were extinct on slashdot. Do you know how many like you are left? I would ask if there are sufficient for a breeding population but this is slashdot after all.
I truly disagree with you. Having spent the best part of a year coding in Java and using the Java style with the open brace on the same line the best I can say is that I have gotten used to it. Code Complete has a section on indentation that recommends the Java/K&R style and it is one of the few sections I fundamentally disagree with. Later in the text there is a recommendation to comment closing braces with e.g.// end while (or similar) which to me highlights the problem. If opening and closing braces are vertically aligned with the controlling statement it is obvious which section of code the brace is closing (unless the code section is so long that the opening and closing braces aren't both visible in the code window but no-one codes like that any more right?).
I much prefer Allman style, and a little extra vertical spacing just helps code clarity - the days of needing to make the most of screen real-estate went out with the 80x24 green screens.
You have 4 servers, they need to be patched, (not) applying a patch is a risk. To mitigate the risk you first need to assign some metric to the risk. Typically this is a number from a table that assigns values to likelihood x impact. The likelihood of a patch breaking your server may be very low but the impact may be very high, resulting in a high risk. Having evaluated the risk you need to mitigate the risk appropriately. This might be as simple as maintaining a ghost image of the system prior to applying a patch. The next thing you need to do is to communicate this with the business. If a server breaks and the business is screaming for a resolution it helps if you can put some paper in front of them that shows exactly what was agreed. Not having time to do it correctly is not normally an acceptable excuse and name calling is not normally an acceptable form of argument.
Having a test environment is sysadmin 101. It doesn't even have to be equivalent hardware to get the benefit. $500 will buy you a test "server" and there are free/cheap virtualisation options that will allow you to run multiple test environments on a single machine, even your own desktop machine.
There are any number of hackneyed expressions I could roll out but if you're not testing stuff at some point you will come to grief. So this is an issue of risk and if you've evaluated the risk and communicated the risk to your organisation and the business is happy to carry the risk then that is a valid approach. If you haven't evaluated the risk and are calling other admins morons because they take a different approach your argument holds no water.
Actually I'm not sure what our immigration policy is towards German Mexican Norwegian Welshmen or do you have a passport for each nationality? We do quite like the Welsh because they like rugby too.
So the company where I've worked for the last 10 months hired me for an intermediate development position which I accepted because of the location. My prior position was as a senior developer working for a similar sized organisation in the same domain (banking). Not only did my current employer not take advantage of my carefully honed skills and considerable experience, I'm now leaving the organisation because their development practice is a shambles and it was made clear to me by the CIO that I would be unable to address issues I had raised (things as basic as software version control).
When I indicated I was taking a broken window approach to website changes I was told not to bother, "I'll probably just hire a student to do that one holidays".
A web person was hired to assist me with some basic website udpates, failed dreadfully, wasn't provided any training in an unfamiliar technology, and was then pushed out the door - he was the 8th person offered the position, the previous 7 turned it down because the pay was crap. Etc.
I'm leaving the position with some extraordinary examples of how not to do things, my self-respect, and just under a year of Java immersion.
Actually with Parallels there is no dual boot, Windows runs in a virtual machine. Besides, you know you're going to have to reinstall Windows at some stage right, doesn't it just make sense to do it in a VM.
Off topic but if I was purchasing a new machine I would seriously consider a Mac with a copy of Parallels. Why throw away that copy of XP just because you're upgrading your hardware.
I think it was more the stance that was at issue and not that the code of practice was actually being enforced. Kiwi banks are far more concerned that an incidence of fraud might damage their reputation and put customers off using what is a cheap and effective channel. Consequently they will tend to pay out any losses in order to keep below the media radar. Banks could quickly solve this problem by introducing secure challenge response tokens but the cost would be enormous and many users would struggle with the technology increasing the cost of support.
The internet is a cheap and effective channel for banks and a very convenient channel for customers to access their accounts 24/7. Compared to the losses associated with credit card fraud the losses due to internet banking fraud are generally considered fairly inconsequential (not long ago at the bank I worked in someone even managed to get a mortgage for a property that they didn't own and absconded with over $100K). For that reason it is more likely for a bank to pay up and shut up than risk drawing attention to an internet banking related incident. One of the reasons two factor authentication is not widespread is because banks consider it might put people off using the channel because of the inconvenience of carrying around some form of token.
There are also a wide variety of two factor schemes. Battleship cards are popular, cheap, and fairly easy to expoit. RSA challenge-response tokens are at the other end of the spectrum in terms of both cost and security. Even relatively secure tokens can still be open to man in the middle type attacks.
Plus the human factor is often a far greater risk. A bank cannot protect against a son/daughter/cousin/spouse "borrowing" a token after shoulder surfing the account/password.
Ultimately security is a tradeoff based on the perceived risk and this is true of security in general, not just banking over the internet. And as always we are very ready to hand over our personal responsibility to a faceless organisation in return for convenience and a sense of security and we get upset when there is any suggestion that some of the onus lies with us.
Ahem, of course having a Cube running OpenBSD as my webserver, support for FireWire is something I've wished was present in OpenBSD. But you know what they say, free, functional, secure, choose any three.
Let me tell you an easy way to do long passwords that you can remember. Everyone has some document attached to the wall next to their computer. Pick enough consecutive words near the beginning to meet minimum length requirements. Drop spaces. Add two or three digits at syllable breaks, not word breaks. Capitalise word breaks. Done. When your password expires choose the next consecutive words. No post-it's under the keyboard and even when you come back from holiday it shouldn't be difficult to figure out how to login.
The IE team is all over this one. To fix Vista, Microsoft simply needs to introduce a new meta tag at the operating system level similar that proposed for IE8. Without the tag, Vista and all future Microsoft operating systems would default to be XP, anyone wanting the full Vista experience could simply add the tag and viola, Windows Vista, 7, etc.
"Standard mode" remains the same as Windows XP, and compatible with current content.
If you really want the best experience Vista can give, you can get it by inserting a simple <meta> element
But what about those VeggieTales challenges, like figuring out how those vegetables get their clothes on when they don't have any hands? Aargh, I hate veggietales, must resist urge to smash vegetables. And don't talk to me about purple fucking dinosaurs.
My point is that I want to stop sniffing - let nature take its course, old browsers fall into disuse, I get to ditch the sniffing and hacks. Now Microsoft wants me to keep sniffing. This is not a good scenario for me.
Lets say:
I currently sniff out IE7 and apply some IE7-specific css or javascript.
IE8 comes out and fixes something that would allow me to discard my hack from #1.
Unfortunately to make use of that fix I have to alter my html to add the stupid meta-tag.
I discard my hack from #1 and add the stupid meta-tag.
Damn, now my site no longer works in IE7, what do I do?
Oh that's right, I add a sniffer to identify IE7 and apply some IE7-specific css etc
How is this an improvement on my current situation?
The point you are missing is this; let's say I decide to make changes to my site that allow it to render correctly in IE8, I then add the meta tag and publish. At that point my site stops rendering correctly for all my customers who use IE7/IE6/IE5 - unless I do some sniffing and css/script hacks. Say hello to 1999. Until this point I have been writing pages to conform to standards and this has been a really successful strategy. Going forward I expect more browsers to have better standards' support and so the few hacks I do currently use can ultimately be relegated to the trash. However Microsoft will use this meta tag to introduce new features that break standards and their marketing weasels will mendaciously suggest that if you don't want the feature then don't set the meta tag. Guess what, some marketing roid in my organisation will at some point require the new feature and now I'm back to browser sniffing to figure out which browser supports which feature. That sucks.
Yep, this sucks as a solution. Sure, get IE 8, change your site so that it works with it, do the meta tag, publish and then realise that your pages are now busted for all those customers still using IE 7/IE 6. The best solution is to keep using DOCTYPE switching and let web developers continue to sniff old versions of IE until they die of old age (the browsers that is, and hopefully not the developers). I've spent considerable time cursing IE in its various versions on both Windows and Mac but there was always that small glint of light discernible at the end of the tunnel where I can just turn off support for those old browsers.
The best approach is to check your logs people, see what browsers are being used to access your site, even log enough info to match a customer to a browser. When usage drops below a threshold turn off support and if your customer base is small enough, contact those users that will be impacted. This works, I've done it, and the affected users are normally happy to upgrade.
Also, providing consistent behaviour, correct capitalisation and spelling will give the user confidence they're using a professional tool and not something hastily cobbled together by a tool.
Yeah, any decent IDE can do syntax colouring so you can save space by putting more than one statement on the same line, your tabs vs. spaces comment is moot.
I've been on both sides of the interview table and there are as many idiots hiring as there are looking for jobs. The worst interviewers are the ones who are convinced of their own omniscience and feel the need to prove it. Then there are the ones who feel threatened by the possibility that you might be better than they are, definitely don't expect a job from these clowns. And the ones who put you on the spot by asking you to solve a stupid mensa riddle, give me a break.
It's a tough exercise either way and it's disappointing when you know that you could do the job but also know that it's not going to happen.
Slashdot Mirror
" it was not just a few seeds from a passing truck". Really it's ok for a few seeds from a passing truck to contaminate your non-GMO crop? If you have a problem with that, perhaps because you're trying to grow crops that rely on organic/biodynamic principles where the soil biology is important as opposed to pouring pesticides/herbicides onto it, then you really just need to get over it. Hey we're having a gun fight over here and yeah there might be a few stray bullets but you just need to get over it.
Sorry, what is that in gibitones?
Free, Functional, & Secure. Oh wait...
I read the article.
You read the article? Holy shit, I thought people like you were extinct on slashdot. Do you know how many like you are left? I would ask if there are sufficient for a breeding population but this is slashdot after all.
I truly disagree with you. Having spent the best part of a year coding in Java and using the Java style with the open brace on the same line the best I can say is that I have gotten used to it. Code Complete has a section on indentation that recommends the Java/K&R style and it is one of the few sections I fundamentally disagree with. Later in the text there is a recommendation to comment closing braces with e.g. // end while (or similar) which to me highlights the problem. If opening and closing braces are vertically aligned with the controlling statement it is obvious which section of code the brace is closing (unless the code section is so long that the opening and closing braces aren't both visible in the code window but no-one codes like that any more right?).
I much prefer Allman style, and a little extra vertical spacing just helps code clarity - the days of needing to make the most of screen real-estate went out with the 80x24 green screens.
You have 4 servers, they need to be patched, (not) applying a patch is a risk. To mitigate the risk you first need to assign some metric to the risk. Typically this is a number from a table that assigns values to likelihood x impact. The likelihood of a patch breaking your server may be very low but the impact may be very high, resulting in a high risk. Having evaluated the risk you need to mitigate the risk appropriately. This might be as simple as maintaining a ghost image of the system prior to applying a patch. The next thing you need to do is to communicate this with the business. If a server breaks and the business is screaming for a resolution it helps if you can put some paper in front of them that shows exactly what was agreed. Not having time to do it correctly is not normally an acceptable excuse and name calling is not normally an acceptable form of argument.
Having a test environment is sysadmin 101. It doesn't even have to be equivalent hardware to get the benefit. $500 will buy you a test "server" and there are free/cheap virtualisation options that will allow you to run multiple test environments on a single machine, even your own desktop machine.
There are any number of hackneyed expressions I could roll out but if you're not testing stuff at some point you will come to grief. So this is an issue of risk and if you've evaluated the risk and communicated the risk to your organisation and the business is happy to carry the risk then that is a valid approach. If you haven't evaluated the risk and are calling other admins morons because they take a different approach your argument holds no water.
Actually I'm not sure what our immigration policy is towards German Mexican Norwegian Welshmen or do you have a passport for each nationality? We do quite like the Welsh because they like rugby too.
So the company where I've worked for the last 10 months hired me for an intermediate development position which I accepted because of the location. My prior position was as a senior developer working for a similar sized organisation in the same domain (banking). Not only did my current employer not take advantage of my carefully honed skills and considerable experience, I'm now leaving the organisation because their development practice is a shambles and it was made clear to me by the CIO that I would be unable to address issues I had raised (things as basic as software version control).
When I indicated I was taking a broken window approach to website changes I was told not to bother, "I'll probably just hire a student to do that one holidays".
A web person was hired to assist me with some basic website udpates, failed dreadfully, wasn't provided any training in an unfamiliar technology, and was then pushed out the door - he was the 8th person offered the position, the previous 7 turned it down because the pay was crap. Etc.
I'm leaving the position with some extraordinary examples of how not to do things, my self-respect, and just under a year of Java immersion.
Actually with Parallels there is no dual boot, Windows runs in a virtual machine. Besides, you know you're going to have to reinstall Windows at some stage right, doesn't it just make sense to do it in a VM. Off topic but if I was purchasing a new machine I would seriously consider a Mac with a copy of Parallels. Why throw away that copy of XP just because you're upgrading your hardware.
Umm, QED?
I think it was more the stance that was at issue and not that the code of practice was actually being enforced. Kiwi banks are far more concerned that an incidence of fraud might damage their reputation and put customers off using what is a cheap and effective channel. Consequently they will tend to pay out any losses in order to keep below the media radar. Banks could quickly solve this problem by introducing secure challenge response tokens but the cost would be enormous and many users would struggle with the technology increasing the cost of support.
The internet is a cheap and effective channel for banks and a very convenient channel for customers to access their accounts 24/7. Compared to the losses associated with credit card fraud the losses due to internet banking fraud are generally considered fairly inconsequential (not long ago at the bank I worked in someone even managed to get a mortgage for a property that they didn't own and absconded with over $100K). For that reason it is more likely for a bank to pay up and shut up than risk drawing attention to an internet banking related incident. One of the reasons two factor authentication is not widespread is because banks consider it might put people off using the channel because of the inconvenience of carrying around some form of token.
There are also a wide variety of two factor schemes. Battleship cards are popular, cheap, and fairly easy to expoit. RSA challenge-response tokens are at the other end of the spectrum in terms of both cost and security. Even relatively secure tokens can still be open to man in the middle type attacks.
Plus the human factor is often a far greater risk. A bank cannot protect against a son/daughter/cousin/spouse "borrowing" a token after shoulder surfing the account/password.
Ultimately security is a tradeoff based on the perceived risk and this is true of security in general, not just banking over the internet. And as always we are very ready to hand over our personal responsibility to a faceless organisation in return for convenience and a sense of security and we get upset when there is any suggestion that some of the onus lies with us.
Come on, by then we'll have Flashblock for OLED's and you'll just have to press on the little triangle if it's something you really want to see.
Ahem, of course having a Cube running OpenBSD as my webserver, support for FireWire is something I've wished was present in OpenBSD. But you know what they say, free, functional, secure, choose any three.
Let me tell you an easy way to do long passwords that you can remember. Everyone has some document attached to the wall next to their computer. Pick enough consecutive words near the beginning to meet minimum length requirements. Drop spaces. Add two or three digits at syllable breaks, not word breaks. Capitalise word breaks. Done. When your password expires choose the next consecutive words. No post-it's under the keyboard and even when you come back from holiday it shouldn't be difficult to figure out how to login.
Damn now I'm going to need a different document.
The IE team is all over this one. To fix Vista, Microsoft simply needs to introduce a new meta tag at the operating system level similar that proposed for IE8. Without the tag, Vista and all future Microsoft operating systems would default to be XP, anyone wanting the full Vista experience could simply add the tag and viola, Windows Vista, 7, etc.
But what about those VeggieTales challenges, like figuring out how those vegetables get their clothes on when they don't have any hands? Aargh, I hate veggietales, must resist urge to smash vegetables. And don't talk to me about purple fucking dinosaurs.
My point is that I want to stop sniffing - let nature take its course, old browsers fall into disuse, I get to ditch the sniffing and hacks. Now Microsoft wants me to keep sniffing. This is not a good scenario for me.
Lets say:
- I currently sniff out IE7 and apply some IE7-specific css or javascript.
- IE8 comes out and fixes something that would allow me to discard my hack from #1.
- Unfortunately to make use of that fix I have to alter my html to add the stupid meta-tag.
- I discard my hack from #1 and add the stupid meta-tag.
- Damn, now my site no longer works in IE7, what do I do?
- Oh that's right, I add a sniffer to identify IE7 and apply some IE7-specific css etc
How is this an improvement on my current situation?The point you are missing is this; let's say I decide to make changes to my site that allow it to render correctly in IE8, I then add the meta tag and publish. At that point my site stops rendering correctly for all my customers who use IE7/IE6/IE5 - unless I do some sniffing and css/script hacks. Say hello to 1999. Until this point I have been writing pages to conform to standards and this has been a really successful strategy. Going forward I expect more browsers to have better standards' support and so the few hacks I do currently use can ultimately be relegated to the trash. However Microsoft will use this meta tag to introduce new features that break standards and their marketing weasels will mendaciously suggest that if you don't want the feature then don't set the meta tag. Guess what, some marketing roid in my organisation will at some point require the new feature and now I'm back to browser sniffing to figure out which browser supports which feature. That sucks.
Yep, this sucks as a solution. Sure, get IE 8, change your site so that it works with it, do the meta tag, publish and then realise that your pages are now busted for all those customers still using IE 7/IE 6. The best solution is to keep using DOCTYPE switching and let web developers continue to sniff old versions of IE until they die of old age (the browsers that is, and hopefully not the developers). I've spent considerable time cursing IE in its various versions on both Windows and Mac but there was always that small glint of light discernible at the end of the tunnel where I can just turn off support for those old browsers. The best approach is to check your logs people, see what browsers are being used to access your site, even log enough info to match a customer to a browser. When usage drops below a threshold turn off support and if your customer base is small enough, contact those users that will be impacted. This works, I've done it, and the affected users are normally happy to upgrade.
Also, providing consistent behaviour, correct capitalisation and spelling will give the user confidence they're using a professional tool and not something hastily cobbled together by a tool.
Yeah, any decent IDE can do syntax colouring so you can save space by putting more than one statement on the same line, your tabs vs. spaces comment is moot.
*sigh*
I've been on both sides of the interview table and there are as many idiots hiring as there are looking for jobs. The worst interviewers are the ones who are convinced of their own omniscience and feel the need to prove it. Then there are the ones who feel threatened by the possibility that you might be better than they are, definitely don't expect a job from these clowns. And the ones who put you on the spot by asking you to solve a stupid mensa riddle, give me a break. It's a tough exercise either way and it's disappointing when you know that you could do the job but also know that it's not going to happen.