But why should I as a developer limit my development workstation to only the device the end-user's going to use? Why shouldn't I take full advantage of better hardware and software for the development tasks that the end-user won't need to ever do?
Doing development on an iPad just because the end-user will run it on an iPad would be as silly as avoiding my dual-27"-monitor desktop with KDE and all the fancy graphical tools to do my development just because the code I'm writing will run on a headless server in a rack somewhere.
Your keyboard is bigger because it's got more keys on it, not because the keys are bigger.
It's the standard QWERTY main keyboard (note: I am not counting the editing keys, numeric keypad or function keys when I'm measuring) so I don't see how you can take any keys away without removing letters of the alphabet, numbers or the common symbols present on every typewriter keyboard and pretty much required for writing any modern language (try programming without quote marks, square brackets, braces, the semicolon, period and comma and the like, it's not pretty).
I seriously doubt that. I just measured my (standard) keyboard. The main key section is 11" wide by 3.5" tall. The whole 3rd-generation iPad is only 9.5" by 7.3". In landscape orientation the keyboard will almost fit the width, but it'd eating literally half the screen height. In portrait orientation the keyboard would only eat about a third of the screen height but there's no way you can fit 11" worth of keys into a 7" width and maintain size. And if you cut down the key size to make them fit, they end up so small and bunched-together that I can't get all 8 typing fingers onto the home keys without scrunching them up uncomfortably and making typing hideous.
Let's face it, when writing a significant app you do a lot of typing. So. Are the iPad's keys roughly the size of a normal keyboard's? That size is significant because it's a comfortable size for human fingers. Much larger and it's awkward to reach between keys, while much smaller and it's awkward to hit just the key you want. Does the iPad's screen allow for keys to be depressed and provide gradual resistance? Those mechanical aspects are important because they provide tactile feedback and avoid having the typist hammering the tips of their fingers on a solid surface (which hurts after a while). Can I keep the iPad's on-screen keyboard only slightly inclined (so it's in line with the plane my fingers occupy while typing) while angling it's display 45 degrees or more up (so it's perpendicular to my line of vision)? That's so I can type comfortably without having to crane my neck or maintain an uncomfortable position to see the screen clearly. As far as I can tell the answer to all of those is "Not without external devices.". So if I'm going to tie myself down to a stand to hold the iPad itself plus a big keyboard and mouse to do my typing on, why wouldn't I go for the conventional desktop with it's larger monitors and more horsepower so I can run builds faster?
Because there are degrees of sharing. I want to share in the sense of letting you see the code. If you find it useful for personal use, fine by me. That's not something you'd ever pay me for anyway. But when your company wants to use my code in a commercial product that they're going to make money selling? I don't want to share that much.
I've noticed a theme from the corporate side of things: that anything that isn't completely locked up and proprietary must be completely public-domain with no strings attached and no control over it. The problem the corporate side has is that the majority of people don't agree with that. I find it fairly reasonable that there's degrees of sharing between "completely proprietary" and "completely public-domain". To say for instance "I'm willing to let people use my code for their personal projects, but I'm not doing contract programming for your company's product for free.". I know a lot of corporate development shops don't like that because it limits what they can pick up cheap, but I've long since grown tired of arguing with them and simply give them a "No. It doesn't work that way.".
I think I'm not the only one who just skips any ND or NC licenses. Is it what you want? Why to share your work in the first place?
Maybe because I want to showcase my work, but I don't want to let you just go and use that code as the heart of your own work. If you want to do that, if you want to take my work as the basis for building something of your own and profiting from it? Come talk to me and we'll negotiate how many dollars you'll pay me for the rights to do what you need to do. You're even getting an advantage, you've already seen the source code and you know you can extend it the way you need to. You don't want to pay? Well and good, go write your own version from scratch.
Oh, you wanted to take my stuff and use it to save yourself a lot of work and money but you don't want to pay me for it? Well, you're entitled to want that, but that doesn't obligate me to give it to you. There's I suspect a large number of programmers who'd like to be able to show off their code, show potential customers in the clearest way possible why their products are better, without in the process handing out a license to do anything with the code. ND and NC provide a standardized way of doing that. It may annoy certain commercial types that there's all this tantalizing stuff that's just what they need but that they can't just take, but lesson #1: life's tough, deal.
OTOH a professional engineer differs from a software developer in one key way: he can't legally be overridden on safety matters. If management orders him to use steel that doesn't meet spec for the bridge's designed load, he can refuse to sign off on the plans and if the company tries to fire him the company is the one who'll end up in legal hot water after he reports them. If you want to make software developers responsible in that same way, you need to give them the same authority and immunity to repercussions for using that authority.
There's some remarkably general regulations in there. I dealt more with MSHA than OSHA, but there's not a huge difference. If the inspector considers it a hazard to employee health and safety they can do anything from write up a warning to shut the entire site down completely until it's cleared up to their satisfaction, and the burden's on the company to argue to a review board why it doesn't constitute a health or safety hazard. And in California the inspectors probably have an easier time of it than in other states.
And of course the inspector can always do a walk-through of the entire site looking for any other violations while he's there. How picky he gets depends on what kind of mood he's in, which will be heavily influenced by how the company reps reacted to his initial write-up. Even the most obnoxious foremen knew that when the MSHA inspector came through you nodded and took notes and got people right on fixing any problems he found because if he got the impression you were blowing him off he would shut the entire mine site down just to teach you a lesson. You might get away with cutting a lot of corners normally, but never on a day the inspectors were on-site.
One word: OSHA. Much as Google may not like it, they're not exempt from workplace health and safety regulations. If those truly are the working conditions, the contractors need to have a good sit-down with one of the local OSHA inspectors complete with show-and-tell. Note: being a contractor doesn't change things, the regulations apply to the workplace and not just the employees.
Not a problem on my LAN. Those hosts are blocked in the main DNS server. And don't even bother trying to bypass DHCP DNS assignment. My firewall rules don't forward destination port 53 packets to the WAN interface. You either use my DNS server or you get ICMP administratively-prohibited errors. Problem solved. Next!
CPU horsepower isn't the problem. How do you attach that keyboard and mouse, though? Tablets and smartphones don't come with USB ports, and Bluetooth pairing is more complicated. Not to mention the interference problems when you've got 100+ tablets in close proximity, and the added support costs when IT has to go fix pairing gone wonky (USB cables rarely go bad). And how about network? I haven't seen a tablet or smartphone with a gigabit Ethernet port on it, and inside the building the wireless infrastructure isn't going to handle taking over 100% of the load from the wired Ethernet. If nothing else, simply the contention for channel space with that many devices in that small an area causes intolerable performance problems that're made all the worse by tablets/smartphones having to depend on network storage for things a conventional desktop could use it's internal hard drive for. Add in the cost of replacing all that hardware and the cost/benefit analysis has you so far into the red that you'll be needing IR goggles to see that color.
Bluntly put, tablets make sense as an adjunct device for support staff, engineers and others who spend a lot of time out of their offices working on things but still need a certain amount of access to their stuff. They make sense for outside sales people or support staff who spend most of their time at customer sites (although in most cases a netbook would make data entry easier). They make no sense at all for employees whose systems are firmly nailed down to their desks and offices because their jobs are.
And as a software developer? I can't see a tablet ever replacing the dual 27" monitors, Unicomp buckling-spring keyboard and high-quality trackball that go along with the 2 terabytes of (sorely needed and heavily abused) disk storage in my workstation. And I don't see 95% of my workload disappearing any time soon, which is what would need to happen before I could scale back to the kind of setup a tablet could handle.
The problem is that the paradigm isn't shifting to mobile. There's certainly a lot of mobile use being added, but in the corporate world especially the vast majority of computer use is conventional desktops. Tablets and phones don't work well for data entry, or for typing up long documents, or for doing complex spreadsheets with lots of math and data entry. And mobile doesn't seem very compelling when the employee's going to be at his desk anyway.
Home users on the other hand seem to be adding mobile instead of replacing their desktops. They already have a desktop, and they aren't inclined to throw it out while it's still working. I don't see my artist friends throwing out their big Cintiq graphics tablets for a 10" screen, I don't see college students throwing out keyboards and trying to type long papers on a smartphone, and I don't see my gamer friends abandoning their high-performance gaming machines for a 1GHz system with a 7" screen and no custom keyboard commands because there's no keyboard.
Mobile and tablets are just as likely to replace the desktop as the desktop PC is to replace the corporate mainframe.
I know the Russian alphabet. That doesn't mean I speak or read Russian.
In one day, you're picking up the programming equivalent of the alphabet: what the letters in the language mean. Learning what the words mean, and how to string them together into coherent sentences, that takes a lot longer. Becoming fluent in it at the high-school level... that takes pretty much what it took for you to become fluent in whatever your native language is at the same level: 15 or so years of 24-hours-a-day immersion in it. Good luck cramming that into a single day.
First off I'll say for "next time", don't store personal information on company gear. Anything you've ever put on there is arguably company property. Any backups they've ever mare are also theirs. You shouldn't be in this situation to begin with.
You can't avoid it, there's always work-related personal information around. For instance, the passwords to my 401K account, health insurance website, prescription drug fulfillment site and so on. All that's work-related, in fact work provides my insurance etc. and expects me to manage it. It's entirely legitimate for me to be accessing those sites from the work machine, as they're part of my benefits package. At the same time, the company doesn't really have any need to know my passwords and should in fact never have access to them. They run the health plan, they don't need my account password to get access to my insurance plan information. I think it's entirely legitimate to want to wipe that kind of sensitive information from a work PC so it doesn't end up in the hands of people who have no need to have it and in fact no right to have it (access to the insurance site would be covered by HIPPA for instance, and the 401K would be covered by financial privacy laws once my employment ends and my employer no longer has any need to interact with that account).
What's the big deal about that? Tier 1 helpdesk doesn't need a degree. A high-school education (even a US one) is more than enough to understand and speak English at a high-school level and follow a script and checklist. You don't need to be a cordon bleu chef to cook burgers at McDonald's either.
Sites don't want to (can't afford to) trust their security to a third party. SSO means that if the SSO operator gets hacked, your user's accounts are compromised. No site operator wants to be on the hook because someone else screwed up. Especially if they want to store credit-card information etc. where being "on the hook" means being financially responsible for the failure.
Sites want to control the information about their users. SSO means that someone else has the personal information. It means the site has less visibility into personal information, and makes it harder for the site to track it's own users. It also means sharing that information with every other site that uses the same SSO. That's anathema to a lot of marketing/sales types who're conditioned to treat customer behavior information as "top secret, eyes-only, burn before reading".
Users are nervous about putting all their passwords in one basket. Every site compromise (eg. the LinkedIn compromise) pounds home the fact that if every site has it's own account and password then when (not if) they get compromised the user doesn't have to worry about all his other accounts being compromised. Many gamers got bit by this when compromises at several game companies resulted in game accounts on unaffected games being compromised because the gamers used the same passwords on multiple games. That made a real impact on people when they realized that a problem on an account they hadn't used in years could mess them up here and now.
Well then, if "the internet is down", I suppose I should go check on the routers and if they're all running fine and packets are flowing I can dismiss your complaint, because "the internet" is up and running fine. Even the HTTP and HTTPS protocols are working fine, at least from the Unix servers which're allowed unfiltered outbound access to those protocols to make it easier to retrieve updates and communicate with remote services via SOAP etc..
Of course the Web proxy/filter box is dead, which means your Web browser won't be able to do anything. But you asked about our Internet connectivity, not Web connectivity, and since you're so adamant that it's the Internet that's down and it's provably not it must be something you're doing wrong. I'm going to close your ticket, I've got a ton of complaints that people's desktop Web browsing isn't working and I really need to tend to that. Everything except the Web seems to be working fine, so it's probably the Web filter malfing again.
Yes, I know exactly what I'm being. And you deserve it. You go telling your mechanic he needs to stop correcting you about the difference between a tire and a suspension and go fix your suspension so the car handles right again, not point at the flat tire and tell you you need to go to the tire shop and get a new tire. See what kind of reaction you get from him. I'll be over here with the popcorn.
The form makes sense. For a portable computer usable for typing you've got a few requirements:
You have to have a keyboard and screen.
The screen needs to have a working position around 90-135 degrees "up" from the plane of the keyboard. That's so the keyboard can be flat (preferred typing position) while the screen's at roughly a right angle to the line of vision.
When not in use you want the surface of the screen covered in some way, to prevent scratching or damage.
Any connection between the keyboard and screen portions needs to be physically robust (not prone to breakage) and provide a good path for reliable electrical connections.
When you combine the two, a hinged clamshell design's the simplest one that satisfies the requirements. The twistable ones for convertible tablets isn't as physically tough as a simple hinge, and the electrical connection's more complex with more chance of breakage or glitches. Single-piece tablets either lack a keyboard or have a poor angle on either the screen or the keyboard, plus they expose the entire screen to damage and have to be physically large to provide the surface area for both the screen and keyboard in a single housing. Wireless keyboards alleviate some of those problems, but now you've got two pieces to keep track of and keep recharged and potentially get lost.
Given all that, I don't see the basic clamshell design fading any time soon. Certainly not as long as we need a portable device we can type significant amounts of text on.
With that under our belt, the next thing to realize is that we can't expect the entire population to become computer experts. Cars are a necessary evil as well, but we don't expect the entire population to become a mechanic, either.
We do, though, expect people who drive to know the basics about cars. If for instance you insist on driving on bald tires, when they inevitably blow out on the freeway we don't provide free towing and free replacement tires. And if the blow-out caused you to hit another car, the cops aren't going to cut you any slack just because you don't want to be an expert on cars. They're going to ticket you heavily, and tell you that it's your job to have your car in a safe operating condition and how you do it's your problem. If you trash your engine because the oil light was lit for the last thousand miles and you decided you didn't need to worry about it because the car was still running, the mechanic isn't going to give you a free new engine and your friends will be laughing at you for being that stupid and nobody's going to be at all sympathetic to your plight because you should've known better and oil changes (or even just a couple of quarts of oil to top it up) aren't that expensive. If you go putting #2 diesel fuel in a car that runs on gasoline, the gas station isn't going to be responsible for fixing the damage and getting your car running again. That'll be your job.
So why do we not expect the same minimum level of knowledge of the basics when it comes to computers?
I'd disagree. I think it's more a question of whether it's a commodity skillset or not. For instance, janitorial work, or cable pulling. Both are commodities: the work's the same no matter who it's being done for. One's long-term while the other's a one-time project, but in both cases you're probably better off contracting the work out.
OTOH, a database conversion's going to require specific skills and is likely a one-time thing, but you're well advised to have at least the top people running it be your own in-house people. If the conversion isn't done exactly right it's going to hose your entire operation, so it's probably not safe to leave it in the hands of people who don't have any financial stake in it being done right, only in it being done in conformance with a contract written by people unfamiliar with what the work's going to require (lawyers aren't database developers, nor should they generally be).
Out-source monkey work. If it's something you can write instructions for that're sufficiently clear and detailed that a moderately-housebroken monkey can follow them successfully, it's a candidate for outsourcing.
In-source anything requiring intelligence, business knowledge or judgement. If you're depending on the people doing the job to know what they're doing and do it well then you want people that you have control over, you don't want people who answer to someone else. To find out who they answer to, ask one question: "Who signs their paycheck?". That's who they answer to.
Regardless of the above, in-source anything where a failure will cause a business interruption. If it's going to stop your business from operating if it's not working right, you want the people responsible for it under your control and answering to you. That way you can decide whether it's worth the overtime to keep them in until it's fixed. You do not want that decision left in the hands of someone whose business isn't being impacted by the problem and who won't suffer if the problem continues.
It's not a matter of age. I know a lot of 20-something engineers who're the same way, they aren't interested in knowing anything about what's under the hood. Myself, I'm pushing 50 and want to know all the details and pick up the newest stuff (even if it's not useful, it's helpful to know it so I can provide solid examples to managers of why it's not useful). Some people like to learn and experiment and investigate, some don't.
I'm also guilty of the same attitude at times. I treat my Windows 7 work desktop as a tool: it exists to run Visual Studio and various other development tools and the Cygwin environment and PuTTY that give me access to the Unix boxes. IT (supposedly) owns the system, IT (supposedly) manages it, I keep my fingers out of all of it outside the tools I work with. If it breaks I don't mess with it, I call IT and let them sort it out. I'll experiment all day on my home machines, but the work desktop's IT's turf and I'm not going mucking about with it making a mess they'll have to clean up. (Although oddly enough the development tools and related stuff like SQL Server and IIS, the bits I do mess with, are the things that rarely if ever have problems. It's usually the parts IT maintains that go pear-shaped.)
That's the thing, though: the OEM can't exempt themselves from copyright law by signing a contract with someone who isn't the copyright holder. The OEMs can make any agreement they want with Canonical, it simply isn't relevant to the license terms for GRUB since the FSF, not Canonical, is the copyright holder. I can sign an agreement with my neighbor allowing me to make additional copies of the Harry Potter books for free, and it's so much waste paper because unless my neighbor's J.K. Rowling they aren't the copyright holder and the copyright holder simply doesn't need to care about them.
I'm sure the SFLC did tell him that a mistake by an OEM could force disclosure of the signing key. But notice he doesn't say explicitly that they told him it could force disclosure of Canonical's signing key. That's because I'm pretty sure they didn't tell him that. Think about it. The logic here is that an action that breaches the GPLv3 by a downstream distributor (the OEM) could force the upstream to correct the breach. Now, suppose I put that in the context of code: I distribute a GPLv3'd piece of software, you receive it from me, modify it and distribute the modified version. If Shuttleworth's argument is correct, then I am in breach of the GPLv3 because I'm not distributing the source code to your modifications as required by the GPLv3. But that's obvious nonsense, since I'm only required to distribute the source code to the software I'm distributing and I'm not distributing your modifications at all. Only you're doing that, and the only way you can pass your obligations back to me is if you're me in the legal sense (ie. a wholly-owned subsidiary company or a division of my company) or if I've signed a contract with you to take on those obligations for you.
So I suspect that while Canonical would be required to distribute any tools needed to create signed bootloaders and the keys needed for the BIOS to boot them, unless they're distributing the actual hardware it'd be on the OEM (who selected the hardware) to take any steps necessary to comply with the GPLv3 as regards the hardware (ie. either choose a BIOS that allowed keys to be enrolled or Secure Boot to be disabled, or distribute their own signing keys). Of course that could place the OEMs in a bind: if they used Canonical's signed binaries and keys then the OEM would be obliged to provide the signing key, but Canonical is not obliged to provide it to them. Which I think is exactly the situation the FSF desires: OEMs placed in a position where to use a very desirable bit of software in their equipment requires selecting a BIOS that permits user control over the Secure Boot process and keys.
Slashdot Mirror
But why should I as a developer limit my development workstation to only the device the end-user's going to use? Why shouldn't I take full advantage of better hardware and software for the development tasks that the end-user won't need to ever do?
Doing development on an iPad just because the end-user will run it on an iPad would be as silly as avoiding my dual-27"-monitor desktop with KDE and all the fancy graphical tools to do my development just because the code I'm writing will run on a headless server in a rack somewhere.
Your keyboard is bigger because it's got more keys on it, not because the keys are bigger.
It's the standard QWERTY main keyboard (note: I am not counting the editing keys, numeric keypad or function keys when I'm measuring) so I don't see how you can take any keys away without removing letters of the alphabet, numbers or the common symbols present on every typewriter keyboard and pretty much required for writing any modern language (try programming without quote marks, square brackets, braces, the semicolon, period and comma and the like, it's not pretty).
I seriously doubt that. I just measured my (standard) keyboard. The main key section is 11" wide by 3.5" tall. The whole 3rd-generation iPad is only 9.5" by 7.3". In landscape orientation the keyboard will almost fit the width, but it'd eating literally half the screen height. In portrait orientation the keyboard would only eat about a third of the screen height but there's no way you can fit 11" worth of keys into a 7" width and maintain size. And if you cut down the key size to make them fit, they end up so small and bunched-together that I can't get all 8 typing fingers onto the home keys without scrunching them up uncomfortably and making typing hideous.
Let's face it, when writing a significant app you do a lot of typing. So. Are the iPad's keys roughly the size of a normal keyboard's? That size is significant because it's a comfortable size for human fingers. Much larger and it's awkward to reach between keys, while much smaller and it's awkward to hit just the key you want. Does the iPad's screen allow for keys to be depressed and provide gradual resistance? Those mechanical aspects are important because they provide tactile feedback and avoid having the typist hammering the tips of their fingers on a solid surface (which hurts after a while). Can I keep the iPad's on-screen keyboard only slightly inclined (so it's in line with the plane my fingers occupy while typing) while angling it's display 45 degrees or more up (so it's perpendicular to my line of vision)? That's so I can type comfortably without having to crane my neck or maintain an uncomfortable position to see the screen clearly. As far as I can tell the answer to all of those is "Not without external devices.". So if I'm going to tie myself down to a stand to hold the iPad itself plus a big keyboard and mouse to do my typing on, why wouldn't I go for the conventional desktop with it's larger monitors and more horsepower so I can run builds faster?
Because there are degrees of sharing. I want to share in the sense of letting you see the code. If you find it useful for personal use, fine by me. That's not something you'd ever pay me for anyway. But when your company wants to use my code in a commercial product that they're going to make money selling? I don't want to share that much.
I've noticed a theme from the corporate side of things: that anything that isn't completely locked up and proprietary must be completely public-domain with no strings attached and no control over it. The problem the corporate side has is that the majority of people don't agree with that. I find it fairly reasonable that there's degrees of sharing between "completely proprietary" and "completely public-domain". To say for instance "I'm willing to let people use my code for their personal projects, but I'm not doing contract programming for your company's product for free.". I know a lot of corporate development shops don't like that because it limits what they can pick up cheap, but I've long since grown tired of arguing with them and simply give them a "No. It doesn't work that way.".
I think I'm not the only one who just skips any ND or NC licenses. Is it what you want? Why to share your work in the first place?
Maybe because I want to showcase my work, but I don't want to let you just go and use that code as the heart of your own work. If you want to do that, if you want to take my work as the basis for building something of your own and profiting from it? Come talk to me and we'll negotiate how many dollars you'll pay me for the rights to do what you need to do. You're even getting an advantage, you've already seen the source code and you know you can extend it the way you need to. You don't want to pay? Well and good, go write your own version from scratch.
Oh, you wanted to take my stuff and use it to save yourself a lot of work and money but you don't want to pay me for it? Well, you're entitled to want that, but that doesn't obligate me to give it to you. There's I suspect a large number of programmers who'd like to be able to show off their code, show potential customers in the clearest way possible why their products are better, without in the process handing out a license to do anything with the code. ND and NC provide a standardized way of doing that. It may annoy certain commercial types that there's all this tantalizing stuff that's just what they need but that they can't just take, but lesson #1: life's tough, deal.
OTOH a professional engineer differs from a software developer in one key way: he can't legally be overridden on safety matters. If management orders him to use steel that doesn't meet spec for the bridge's designed load, he can refuse to sign off on the plans and if the company tries to fire him the company is the one who'll end up in legal hot water after he reports them. If you want to make software developers responsible in that same way, you need to give them the same authority and immunity to repercussions for using that authority.
There's some remarkably general regulations in there. I dealt more with MSHA than OSHA, but there's not a huge difference. If the inspector considers it a hazard to employee health and safety they can do anything from write up a warning to shut the entire site down completely until it's cleared up to their satisfaction, and the burden's on the company to argue to a review board why it doesn't constitute a health or safety hazard. And in California the inspectors probably have an easier time of it than in other states.
And of course the inspector can always do a walk-through of the entire site looking for any other violations while he's there. How picky he gets depends on what kind of mood he's in, which will be heavily influenced by how the company reps reacted to his initial write-up. Even the most obnoxious foremen knew that when the MSHA inspector came through you nodded and took notes and got people right on fixing any problems he found because if he got the impression you were blowing him off he would shut the entire mine site down just to teach you a lesson. You might get away with cutting a lot of corners normally, but never on a day the inspectors were on-site.
One word: OSHA. Much as Google may not like it, they're not exempt from workplace health and safety regulations. If those truly are the working conditions, the contractors need to have a good sit-down with one of the local OSHA inspectors complete with show-and-tell. Note: being a contractor doesn't change things, the regulations apply to the workplace and not just the employees.
Not a problem on my LAN. Those hosts are blocked in the main DNS server. And don't even bother trying to bypass DHCP DNS assignment. My firewall rules don't forward destination port 53 packets to the WAN interface. You either use my DNS server or you get ICMP administratively-prohibited errors. Problem solved. Next!
CPU horsepower isn't the problem. How do you attach that keyboard and mouse, though? Tablets and smartphones don't come with USB ports, and Bluetooth pairing is more complicated. Not to mention the interference problems when you've got 100+ tablets in close proximity, and the added support costs when IT has to go fix pairing gone wonky (USB cables rarely go bad). And how about network? I haven't seen a tablet or smartphone with a gigabit Ethernet port on it, and inside the building the wireless infrastructure isn't going to handle taking over 100% of the load from the wired Ethernet. If nothing else, simply the contention for channel space with that many devices in that small an area causes intolerable performance problems that're made all the worse by tablets/smartphones having to depend on network storage for things a conventional desktop could use it's internal hard drive for. Add in the cost of replacing all that hardware and the cost/benefit analysis has you so far into the red that you'll be needing IR goggles to see that color.
Bluntly put, tablets make sense as an adjunct device for support staff, engineers and others who spend a lot of time out of their offices working on things but still need a certain amount of access to their stuff. They make sense for outside sales people or support staff who spend most of their time at customer sites (although in most cases a netbook would make data entry easier). They make no sense at all for employees whose systems are firmly nailed down to their desks and offices because their jobs are.
And as a software developer? I can't see a tablet ever replacing the dual 27" monitors, Unicomp buckling-spring keyboard and high-quality trackball that go along with the 2 terabytes of (sorely needed and heavily abused) disk storage in my workstation. And I don't see 95% of my workload disappearing any time soon, which is what would need to happen before I could scale back to the kind of setup a tablet could handle.
The problem is that the paradigm isn't shifting to mobile. There's certainly a lot of mobile use being added, but in the corporate world especially the vast majority of computer use is conventional desktops. Tablets and phones don't work well for data entry, or for typing up long documents, or for doing complex spreadsheets with lots of math and data entry. And mobile doesn't seem very compelling when the employee's going to be at his desk anyway.
Home users on the other hand seem to be adding mobile instead of replacing their desktops. They already have a desktop, and they aren't inclined to throw it out while it's still working. I don't see my artist friends throwing out their big Cintiq graphics tablets for a 10" screen, I don't see college students throwing out keyboards and trying to type long papers on a smartphone, and I don't see my gamer friends abandoning their high-performance gaming machines for a 1GHz system with a 7" screen and no custom keyboard commands because there's no keyboard.
Mobile and tablets are just as likely to replace the desktop as the desktop PC is to replace the corporate mainframe.
I know the Russian alphabet. That doesn't mean I speak or read Russian.
In one day, you're picking up the programming equivalent of the alphabet: what the letters in the language mean. Learning what the words mean, and how to string them together into coherent sentences, that takes a lot longer. Becoming fluent in it at the high-school level... that takes pretty much what it took for you to become fluent in whatever your native language is at the same level: 15 or so years of 24-hours-a-day immersion in it. Good luck cramming that into a single day.
First off I'll say for "next time", don't store personal information on company gear. Anything you've ever put on there is arguably company property. Any backups they've ever mare are also theirs. You shouldn't be in this situation to begin with.
You can't avoid it, there's always work-related personal information around. For instance, the passwords to my 401K account, health insurance website, prescription drug fulfillment site and so on. All that's work-related, in fact work provides my insurance etc. and expects me to manage it. It's entirely legitimate for me to be accessing those sites from the work machine, as they're part of my benefits package. At the same time, the company doesn't really have any need to know my passwords and should in fact never have access to them. They run the health plan, they don't need my account password to get access to my insurance plan information. I think it's entirely legitimate to want to wipe that kind of sensitive information from a work PC so it doesn't end up in the hands of people who have no need to have it and in fact no right to have it (access to the insurance site would be covered by HIPPA for instance, and the 401K would be covered by financial privacy laws once my employment ends and my employer no longer has any need to interact with that account).
What's the big deal about that? Tier 1 helpdesk doesn't need a degree. A high-school education (even a US one) is more than enough to understand and speak English at a high-school level and follow a script and checklist. You don't need to be a cordon bleu chef to cook burgers at McDonald's either.
Well then, if "the internet is down", I suppose I should go check on the routers and if they're all running fine and packets are flowing I can dismiss your complaint, because "the internet" is up and running fine. Even the HTTP and HTTPS protocols are working fine, at least from the Unix servers which're allowed unfiltered outbound access to those protocols to make it easier to retrieve updates and communicate with remote services via SOAP etc..
Of course the Web proxy/filter box is dead, which means your Web browser won't be able to do anything. But you asked about our Internet connectivity, not Web connectivity, and since you're so adamant that it's the Internet that's down and it's provably not it must be something you're doing wrong. I'm going to close your ticket, I've got a ton of complaints that people's desktop Web browsing isn't working and I really need to tend to that. Everything except the Web seems to be working fine, so it's probably the Web filter malfing again.
Yes, I know exactly what I'm being. And you deserve it. You go telling your mechanic he needs to stop correcting you about the difference between a tire and a suspension and go fix your suspension so the car handles right again, not point at the flat tire and tell you you need to go to the tire shop and get a new tire. See what kind of reaction you get from him. I'll be over here with the popcorn.
The form makes sense. For a portable computer usable for typing you've got a few requirements:
When you combine the two, a hinged clamshell design's the simplest one that satisfies the requirements. The twistable ones for convertible tablets isn't as physically tough as a simple hinge, and the electrical connection's more complex with more chance of breakage or glitches. Single-piece tablets either lack a keyboard or have a poor angle on either the screen or the keyboard, plus they expose the entire screen to damage and have to be physically large to provide the surface area for both the screen and keyboard in a single housing. Wireless keyboards alleviate some of those problems, but now you've got two pieces to keep track of and keep recharged and potentially get lost.
Given all that, I don't see the basic clamshell design fading any time soon. Certainly not as long as we need a portable device we can type significant amounts of text on.
We do, though, expect people who drive to know the basics about cars. If for instance you insist on driving on bald tires, when they inevitably blow out on the freeway we don't provide free towing and free replacement tires. And if the blow-out caused you to hit another car, the cops aren't going to cut you any slack just because you don't want to be an expert on cars. They're going to ticket you heavily, and tell you that it's your job to have your car in a safe operating condition and how you do it's your problem. If you trash your engine because the oil light was lit for the last thousand miles and you decided you didn't need to worry about it because the car was still running, the mechanic isn't going to give you a free new engine and your friends will be laughing at you for being that stupid and nobody's going to be at all sympathetic to your plight because you should've known better and oil changes (or even just a couple of quarts of oil to top it up) aren't that expensive. If you go putting #2 diesel fuel in a car that runs on gasoline, the gas station isn't going to be responsible for fixing the damage and getting your car running again. That'll be your job.
So why do we not expect the same minimum level of knowledge of the basics when it comes to computers?
I'd disagree. I think it's more a question of whether it's a commodity skillset or not. For instance, janitorial work, or cable pulling. Both are commodities: the work's the same no matter who it's being done for. One's long-term while the other's a one-time project, but in both cases you're probably better off contracting the work out.
OTOH, a database conversion's going to require specific skills and is likely a one-time thing, but you're well advised to have at least the top people running it be your own in-house people. If the conversion isn't done exactly right it's going to hose your entire operation, so it's probably not safe to leave it in the hands of people who don't have any financial stake in it being done right, only in it being done in conformance with a contract written by people unfamiliar with what the work's going to require (lawyers aren't database developers, nor should they generally be).
I have a simple rule:
Out-source monkey work. If it's something you can write instructions for that're sufficiently clear and detailed that a moderately-housebroken monkey can follow them successfully, it's a candidate for outsourcing.
In-source anything requiring intelligence, business knowledge or judgement. If you're depending on the people doing the job to know what they're doing and do it well then you want people that you have control over, you don't want people who answer to someone else. To find out who they answer to, ask one question: "Who signs their paycheck?". That's who they answer to.
Regardless of the above, in-source anything where a failure will cause a business interruption. If it's going to stop your business from operating if it's not working right, you want the people responsible for it under your control and answering to you. That way you can decide whether it's worth the overtime to keep them in until it's fixed. You do not want that decision left in the hands of someone whose business isn't being impacted by the problem and who won't suffer if the problem continues.
The post-PC world will look much like the post-paper office does... how long ago did they predict the paperless office again?
It's not a matter of age. I know a lot of 20-something engineers who're the same way, they aren't interested in knowing anything about what's under the hood. Myself, I'm pushing 50 and want to know all the details and pick up the newest stuff (even if it's not useful, it's helpful to know it so I can provide solid examples to managers of why it's not useful). Some people like to learn and experiment and investigate, some don't.
I'm also guilty of the same attitude at times. I treat my Windows 7 work desktop as a tool: it exists to run Visual Studio and various other development tools and the Cygwin environment and PuTTY that give me access to the Unix boxes. IT (supposedly) owns the system, IT (supposedly) manages it, I keep my fingers out of all of it outside the tools I work with. If it breaks I don't mess with it, I call IT and let them sort it out. I'll experiment all day on my home machines, but the work desktop's IT's turf and I'm not going mucking about with it making a mess they'll have to clean up. (Although oddly enough the development tools and related stuff like SQL Server and IIS, the bits I do mess with, are the things that rarely if ever have problems. It's usually the parts IT maintains that go pear-shaped.)
That's the thing, though: the OEM can't exempt themselves from copyright law by signing a contract with someone who isn't the copyright holder. The OEMs can make any agreement they want with Canonical, it simply isn't relevant to the license terms for GRUB since the FSF, not Canonical, is the copyright holder. I can sign an agreement with my neighbor allowing me to make additional copies of the Harry Potter books for free, and it's so much waste paper because unless my neighbor's J.K. Rowling they aren't the copyright holder and the copyright holder simply doesn't need to care about them.
I'm sure the SFLC did tell him that a mistake by an OEM could force disclosure of the signing key. But notice he doesn't say explicitly that they told him it could force disclosure of Canonical's signing key. That's because I'm pretty sure they didn't tell him that. Think about it. The logic here is that an action that breaches the GPLv3 by a downstream distributor (the OEM) could force the upstream to correct the breach. Now, suppose I put that in the context of code: I distribute a GPLv3'd piece of software, you receive it from me, modify it and distribute the modified version. If Shuttleworth's argument is correct, then I am in breach of the GPLv3 because I'm not distributing the source code to your modifications as required by the GPLv3. But that's obvious nonsense, since I'm only required to distribute the source code to the software I'm distributing and I'm not distributing your modifications at all. Only you're doing that, and the only way you can pass your obligations back to me is if you're me in the legal sense (ie. a wholly-owned subsidiary company or a division of my company) or if I've signed a contract with you to take on those obligations for you.
So I suspect that while Canonical would be required to distribute any tools needed to create signed bootloaders and the keys needed for the BIOS to boot them, unless they're distributing the actual hardware it'd be on the OEM (who selected the hardware) to take any steps necessary to comply with the GPLv3 as regards the hardware (ie. either choose a BIOS that allowed keys to be enrolled or Secure Boot to be disabled, or distribute their own signing keys). Of course that could place the OEMs in a bind: if they used Canonical's signed binaries and keys then the OEM would be obliged to provide the signing key, but Canonical is not obliged to provide it to them. Which I think is exactly the situation the FSF desires: OEMs placed in a position where to use a very desirable bit of software in their equipment requires selecting a BIOS that permits user control over the Secure Boot process and keys.