Right. You also get logging of the commands executed which can be nice, or can itself be a security problem.
However, unless you carefully restrict the commands, you can do what I do: "sudo bash" (or, if you prefer, "sudo -i")
A lot of companies aren't interested in full disk encryption and the like without key escrow. Basically, they don't want an employee to be able to lock them out without clearly displaying malicious intent (i.e. no "I forgot the password" defense).
This is entirely true. Apple is content to let the Nokia's of the world go out of business serving a market segment that pays less.
Is this socially irresponsible? Possibly. However, survival trumps social responsibility (in business as much as life). Apple almost died once, its success is effectively built on that core lesson.
Arguments about proprietary screws being a sign of corporate malcontent are as old as time. I, for one, don't see what's wrong about establishing a basic line of defense against casual intrusion. Having sat at the table with the lawyers and product guys, I recognize that no ulterior motive is necessary once the lawyers realize that an idiot with a screwdriver can dump a few ounces of lithium acid in his lap. They might actually request proprietary screws just to plausibly say that they tried to keep them out.
Said another way, this is like an ISP port-blocking the default telnet port. It doesn't stop people from hacking, but it does stop the dumbest and it makes it look like you tried.
TL;DR Perverse incentives are perverse.
Density. Most Apple machines are difficult to repair for the same reasons that Japanese cars are hard to repair. Once you hit a certain density, you just have to give up on making it easy to disassemble. To be fair to Apple, they just decided to go full out. If it's going to be hard to repair at the desired component density, embrace that fact and build it like it's not going to be repaired.
Now, recycling is another matter, but in terms of repairability, if you want a reparable Mac, get the desktops. They're perfectly easy to work on. If you want a mobile device, where weight, size, and battery-life are king--expect it to be hard to repair.
Relevant: http://www.dhmo.org/msdsdhmo.html
Others have addressed many reasons on which road should take. I'd like to chime in on some important factors on which road you can take. Specifically:
If you have written anything already, your boss may already own it.
This shocks people sometimes, but it's entirely true. If you wrote it on work time, with work equipment, or even over work bandwidth; (in the USA) it legally belongs to them under federal copyright law. As soon as you're being paid to do it, they have a claim. Interestingly, this is why you always here about companies refusing to pay for something to negotiate a lower price, then being all shocked that the author sold it to someone else (or just gave it away). This sword cuts both ways. As soon as someone can squint sideways and see some way you were compensated to produce this software, then that benefactor has a claim.
That said, even if you've done it clean-room, on your own time, and entirely with your own resources; can you afford to defend it? Owning it doesn't mean much if they can just ignore you. Have a lawyer friend that will help you keep your ownership clear and is willing to send scary lawyer letters. This also means you must be willing to lose your job. It further means that your boss must have enough assets that, should they fire you, it's worth suing them.
Most importantly, try to do a better job selling it. Very few bosses will turn down a good opportunity. Even bad ones, when convinced of the savings, will go for it. Don't assume it's their job to know this stuff. It's their job to hire and manage people who know this stuff--that's a two-way street. If you want an opportunity to write some serious software, understand that you need to give them an opportunity to identify talent that can do so. Until you've both helped each other take that step (and both benefited from it), there's no way anyone can benefit. They're taking a risk--so sell them on it.
You'll find that you can do amazing things when your boss trusts in your judgement and will give you freedom. A lot of times the difference between a job and a career is finding management that you can interface with. Being a successful programmer or architect is entirely a people skill--establish trust, find a good boss, and you can make good money writing code without the BS. Alas, that might mean leaving your current job.
Finally (in case I haven't made this obvious yet), don't get so attached to your job. Really. If you're this concerned about how "your" job is going to take advantage of (or fail to take advantage of) your skills, I humbly suggest that you should mistrust your attachment to it. Working is like dating in a disturbing number of ways. It doesn't matter how "great" the place is, and it doesn't matter how much they "deserve" your "help". Find a partner that will appreciate you, or you're just going to be in a dead-end relationship and you won't realize it until you're way out of your prime. There are other fish in the sea (even in this market), and you should keep getting what you need from this one until you can trade up. If you feel dirty doing it, that's great--just don't settle for less than you should.
This is why I really like Minecraft. Fun stuff can slide in without concerns about it interfering with it being a "sport".
Every one? Even the abbreviated list is pretty long.
Are you making a Hasty Generalization? Then have you committed the Fallacist's Fallacy. For added fun, explain how your use of a fallacy doesn't mean you're wrong--which kind of defeats your point.
Proofs must be constructive. Without a counter-example, this is just doubt. Proof (and consequently counter-proof) generates certainty. This is the mechanic of science.
It is easier to write an incorrect program than understand a correct one.
