I don't trust the government as far as I could spit but the advantages afforded by 100mbit fibre to the home is worth picking the lesser of two evils (or incompetents as the case may be. BTW, my election preferences go way beyond fast internet, although it is a consideration)
Also, even though a government may be inefficient it takes a government with no expectation (or requirement) to make a profit to implement a scheme such as this. A private company needs to make money to survive and can't bear the debt an initial rollout requires to implement (case in point, the fibre rollout in the ACT by TransACT). Once the infrastructure is in place then it, or portions thereof, can be privatised if needed.
Honestly, I'm sick of technological advances being blocked because it hurts someones bottom line. Something something stock whip makers.
If the NBN affects his business then his business is archaic and newscorp can adjust or die...preferably the latter
If someone is using an iPhone, at some point it was connected to iTunes to activate it (or it wouldn't be working).
That used to be the case but you can activate and iPhone or iPad without iTunes these days and never ever hook it up to a host computer.
What the hell?
How can anyone say, with a straight face, that you need to run AV software on a goddamn phone? A PHONE! What manner of circumstances lead to this being considered something that is perfectly normal?
If anything it just shows what a logistical clusterfuck Google created with the first few editions of Android and letting all and sundry create hardware without at least enforcing some form of automatic patching regime. Don't get me wrong, I think ICS is a wonderful OS for a phone, but to birthed straight into the world expecting to have to run AV software??? Look at yourself in the mirror and tell yourself that's a perfectly normal and rational thing.
I'd accept "I know right where to find it" as an answer if someone showed me how they'd find it... something like this:
echo "The $port port is `grep $port
Some things that are found in manuals are so key to the field that it still makes sense to ask. For example, another poster complained that Google asked him how many bytes were in a MAC address. Well, if I'm hiring a senior network admin, I'd expect him to know the basics of common layer 2 transports (which might be just ethernet for a LAN engineer, but would encompass much more for a WAN engineer). I'd expect him to be able to describe an ethernet frame. Maybe not down to the last bit, but he should at least know the major parts and I'd certainly expect him to know how big a MAC address is
Oh I fully agree. For stuff that is day to day then yeah, knowing your key functions off the bat is going to be handy. Most of the time I write code that includes functions that I have no idea about unless I look them up. I know 'where' to find the info if I need it but just don't ask me to do it without referencing something. It's funny when I look back at my own code and realise just how complex it can be. It's easy to look at that and think "this guy knows his stuff" but what you can't see is the stumbles, hurdles, google searches etc that went into it. That's what they need to be able to test. Anyone can get the desired result given enough time. How you go about it though is the key.
There were two parts to it. One was a set of about 20 questions that I maybe had an inkling of the answer. It was a warm day, I was wearing a suit and stuffed into a room by myself to see how many I could answer. Are they testing my abilities or my tolerance to being in an uncomfortable environment? Most of the questions were ones that only someone with OCD would be able to answer off the top of their head. Information like what protocol goes with what port is stuff that I don't use on a daily basis, but I know perfectly well where to look for it when I do need to find out. That's what reference material is for.
the second part was "here's a problem, how would you code the solution". In this case the language could be anything, so I wrote in pseudo code and even went back over one of them because I though of a more efficient solution.
Things that can be looked up in a reference manual or on the internet should be left out of interviews (unless the question is along the lines of "How would you determine XYZ?"). Keep it to methods used to solve a problem and you'll get a good understanding of how a particular person works and how they will work for you.
Most people I know that are nostalgic about their Amiga's (and C24's etc) have a perfectly capable emulation environment available to them that runs orders of magnitude faster than the original hardware, on even moderately powered netbooks.
But even if they get new hardware out and AmigaOS is fantastic, where are the apps? What's the draw to get people to buy this thing other than the nostalgia of having a computer with the Amiga stamp on it? It can be the best damn OS in the world but if it hasn't got apps then it hasn't got anything.
BeOS was pretty cool back in the day and kicked Windows to the curb in terms of performance but it died because it didn't have apps. Making an AmigaOS laptop today makes about as much sense as making a dedicated BeOS laptop (yes, I'm aware of various efforts to resurrect BeOS...still makes no sense)
Archivists might be worried but you can't say there wasn't enough warning. Production houses have been switching to digital since at least the 90's.
Having said that I wouldn't go 100% telecommute either. One day a week or maybe two at most. More than that and you lose face to face interaction with co-workers and supervisors/managers. I could have done a recent project completely at home with no supervision but all anyone would have seen would be the end result. It's just as important to be able to physically present the process you go through in order to be appreciated for the work you do. No appreciation for the work = you don't get appreciated as an employee and you'll be passed up on opportunities.
Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker