That 0.04% still represents a good chunk of distance to be covered. A fall is still fatal even if only the lower 0.0001% of the cable fails due to weather.
The nice thing is that any capsules that are going up the hypothetical elevator are likely to be able to deploy parachutes without much problem. Sure, the 'chutes will hit the same weather as what hit the cable, but presumably they wouldn't deploy a mission if there was weather that looked like it'd cause a problem around.
And yes the on off switch we have next to each socket saves a lot of wear and tear on plugging/unplugging - you know - to save the planet.
What?
What sort of usage patters do you have that you regularly unplug something to turn it off? Almost exclusively when I unplug something, it's because (1) I want to move it somewhere else or (2) I need to free up an outlet for something else, neither of which a switch on the outlet helps with. I'm struggling to see a real use case for a switch on an outlet.
The language which had interfaces but no inheritance nor mixins...
Look, I'm not saying it's a great language, but I can come up with a similar list of why C++ is a crappy language. Would you like me to?
How about the fact that there was absolutely no way, out of the box, to create a console application?
So? If you want a console application, use a different language. C++ doesn't have a way "out of the box" to create a GUI application. Python doesn't have a way out of the box to create embedded applications. Does that mean those languages are dumb?
And yeah, you're right on the money about Delphi. I unfortunately never used it (except maybe once or twice to play around briefly), but from what I know it sounded good. But I still think that if you turned the unwashed masses that used VB onto Delphi instead, application quality wouldn't have changed much.
Imagine how much further ahead we'd be now if the 1990's Microsoft RAD IDE were C++ instead of Basic, and Microsoft Office Scripting were Lua or Perl instead of VBA?...probably about in the same place. The biggest problem with VB was the fact that a bunch of noobs who didn't know much about programming were using it. The language really wasn't particularly inhibiting, even if it's not quite expressive as C++. That problem would have remained.
So our lesson here is... don't run any scripts we don't fully understand as root.
You can scratch the "as root" in there... for most users, the added problems of running untrusted stuff as root barely accounts for the damage that can be done to your system.
Right, I totally intended to mention that and just forgot, because I find that extremely annoying as well. (And actually now that I am reminded of that issue, I take back about what I said about the non-caching of passwords being the most annoying UAC-related thing.) The only way I've found to deal with it is to start a whole new elevated command prompt... anyone have a better solution? (I've also tried runas without success, but maybe I was just being stupid with the syntax or not typing my password correctly or something.)
Not to begrudge them too too much, but 7 *years* is a pretty long time. That's longer than the XP -> Vista cycle, and that has bigger changes than this should have been. And lots of/. people (and I) begrudge MS for how long that took. (Granted, MS's Windows team is bigger.)
However, other developers have fixed issues that I've opened. Having some issues fixed because of my feedback is better than none.
I agree, but closed source vendors will fix bugs too. I haven't filed any that I can think of, but I have almost done so. I found a bug w/ Visual Studio's auto_ptr implementation, and looked on MS comment. Someone else had already submitted it, MS had acknowledged it, and it was fixed next version.
I can easily contact the developers. I can submit bugs.......and have them ignored. (Request for feature in OpenOffice. Has 215 votes and 30 printed pages of comments, the vast majority of which are "the lack of this feature is the only thing keeping me from using OO." Been open over 7 years now, and we don't have anything even remotely like a timeline. I chose that one because I've had 2 votes (the max for a single issue) sitting on it for a couple years now.)
I'll echo the above to a large extent. Here's my take on UAC, as compared to sudo.
First the similarities: they function in much the same way.They have similar (though not completely overlapping) goals, and they protect more or less the same stuff. Back when I first switched to Vista (about six months after it came out), there was still a lot of flap going on about UAC. I decided to keep a log of every UAC prompt I received, and did so for a month. I don't have it handy, but IIRC here is roughly how it came out. There were bascially three reasons I got prompted: (1) I was making an expected administrative change that would have required root on Linux (most of them), (2) there was a bit of the UI that was designed poorly, or (3) I was first logging on and this hardware monitoring piece of software was starting. The second category is the most interesting; almost all (or maybe all) of these were because I wanted to change my environment variables. Even though I was just changing my user's variables the dialog where you do that is also where you change system-wide environment variables; the fact that you could do the latter mean you needed elevation. (Win 7 fixes this dialog so you don't need elevation to change your own environment.) In addition, while I didn't get it for this reason, some people got UAC prompts for things like start menu and desktop changes. The desktop thing wouldn't happen on Linux because neither KDE nor Gnome have the idea off a global "all users" desktop in addition to the per-user one. The changes that caused these UAC prompts were because the change had to affect the all users desktop. I'm not sure how Gnome and KDE store the equivalent of the start menu soo I'm not sure hoow sudo would behave there.
Now the differencees:
1. UAC behaves more like 'su' than sudo. You need the password of the admin user, not your own. For enterprise users, this could be a big deal. For a home user, I doubt it matters much. For a single-user computer, it doesn't really matter in the slightest.
2. UAC doesn't cache its permission. If you need to elevate twice in a row, you have to explicitly elevate twice. At least on a typical desktop configuration, gksudo will cache its permission for a couple minutes. This is the main respect in which, IMO, UAC is more annoying. That said, this rarely happened in my month of UAC logging.
3. UAC is on-demand: a running program can ask for elevation. This is in contrast to sudo, where you need to start with said user's rights. This isn't very different from the end user's perspective as compared to stuff like GkSudo, but is pretty nice as compared to running sudo from the command line, where at least I often found myself going "oops, I needed to start that as root."
4. Even admin users need to elevate, but root doesn't need to sudo. A little annoying if you're doing a loot of admin stuff. Then again, you only need to click 'yes' as opposed to type your password, so it's not too bad. This is important for Windows users where most people are an admin anyway (and hence sudo as-such wouldn't do anything). Speaks more about the Windows architecture and programs than UAC in that respect. (Win 7 changes this; admin users don't have to explicitly elevate as much. Icons with the UAC logo elevate without a prompt. Programs that just want elevation, like installers, still cause a prompt.)
5. UAC checks the program's digital signature, and displays either the confirmed source or a warning about a missing signature; sudo doesn't do any of that. In theory this is a nice win on UAC's part, but in practice I doubt it matters much. A lot of programs (esp. OSS apps) aren't signed, so the presence of that warning usually isn't surprising so I just click through anyway, and (1) you need to a lot of thee time and (2) I even know all about what it's talking about it.
All Microsoft did in 7 is reduce the security, since many users will blindly click through whatever is shown anyways, and power users turn it off.
When I was in school, there were less than a half dozen women in all of the CS classes I took, combined, and while it may not be 50/50 yet, there are still some pretty goodly numbers of women.
I am still in (grad) school. The highest female-to-male ratio I have ever seen in any CS class at either my undergrad institution (attended 2002-2006) or my grad one (both are large state institutions) was 3 or 4 in a class of 20-some. That was an honors class and most of the CS girls in my year were in the honors program. In most classes it was 4 or 55 in a class of 50. It's entirely possible that the total number of females I had a CS class with while an undergrad is less than a dozen.
I went through the grad student directory for my current school. There are 250 names listed; 217 people have pictures. Of those, fewer than 40 are female; that's about 16%. Even if every one of the pictureless people were female, it would still be less than 1/3 of the dept.
So no, my experience is that there aren't goodly numbers of women; the ratios in school are still terrible.
Granted, industry seems to be doing a little better, and maybe numbers are higher at smaller privatee institutions, but it's still pretty bad.
Actually since costs are relatively fixed for online distribution of games that are already written, revenue probably varies basically directly with profit, so either one should be a decent indicator of the other.
Package managers require root, sure, but I already said that. But there are other ways to install most OSS software. In particular, the configure/make/make install sequence works for almost everything where you have source. Sure it can be a pain, but I already said that too.
The problem is that most Windows programs don't have any installation method other than the installer, so if Windows decides the installer needs admin rights, there's usually no way to do it without them.
Under a typical Unix philosophy anyway, which I actually agree with in this case, there's no reason to prohibit the user from installing software locally to their home directory, which is why I'm surprised there's not more support. This is why I was decrying the state of user-mode installations in the first place. Under Windows XP it was actually okay (many things you actually could install without admin rights), under Linux it's a PITA but possible, and on Vista it often impossible.
How does the absolute intake compare to what it was before the experiment though?
I'm reminded of a sale Valve had for L4D a few months after it was released; Jeff Atwood relayed the results. In short, Valve cut the price of L4D in half, and the result brought in more money (not just more sales!) than the launch day.
So how did World of Goo's experiment do in absolute numbers? Did the revenue increase or decrease from before the experiment? Certainly sales increased, but that's a far cry from revenue increasing.
You may not like it but MS finally got smart with that and followed OS X and other Unices like Linux by requiring admin privileges to install software.
It's news to me that Linux requires admin privileges to install software. I have a couple gigs stored in ~/.packages at work, where I don't have admin privileges.
(The problem is that since Windows autostupidly wants to elevate all installers, it's impossible to install most things with the permissions of a non-admin user, even if you just want to install it to a location that the user has write permission to and even if the program & installers are well-behaved and don't need to write to HKLM or anything like that.)
If you don't have root, why not just ask the admin to install something for you through the package manager if you need it? Most will. Doesn't hurt to at least ask, you may be putting yourself through the frustration for nothing.
By the way, to answer this, it's usually not much of a pain to do the installation, and just the configure/make/make install cycle works. And while the IT support people would probably install it locally with RHEL's package manager (actually I could probably get root if I really wanted), me doing it and putting it in ~ means its on the network and visible anywhere. (I could ask them to make it available on the network too, but with some of the stuff I have I doubt they would. It wouldn't be "run a package manager" simple for them either because they support a number of different platforms and configurations.) So basically me doing the work is usually easy and has benefits beyond "I don't have to bug the support people."
There have just been a couple of times where it's become a huge pain in the ass. One of them was some GTK program that started transitively requiring probably a dozen and a half libraries (e.g. the Gnome-related lib*mm ones) before I got done. That time I actually started keeping the stack of "a requires b requires c requires d" so that when I was done installing d I could go back to c's configure and see if it worked.
The problem is there's no any real indication of when you'll wind up in a situation like that.
That asde, to use that as an example is a bit disingenuous. You're presenting a serious edge case as the norm.
I don't buy it's that much of an edge case. Sure it is for home use, but how many corporate users don't have admin rights to their desktop box at work? I'm not sure, but I bet it's a sizable percentage. I'm sure at least some of them have software they'd like to use. (There's also the question of kids who have non-admin accounts on their home computer and don't want to go running to mom or dad; this I suspect happens very infrequently though.)
Of course, this discussion is becoming more and more moot; with Vista, Windows assumes that any installer should be run with admin rights even if it would run OK without, which means that non-admins can't install stuff any more either. IMO this was a really stupid decision on MS's part, and it's the main problem I have with Vista's UAC.
(I also disagree that I presented it as the norm, but whatever.)
I for one use PDF export, Flash export, and other similar features missing from Microsoft Office
Office has had PDF export for... a couple years? I'm not sure if it was in the first pressings of Office 2007 and may have been in it's SP1 (I think it has an SP1), but I definitely have a PDF export option in my Office installation, and it's definitely at least a plugin from MS.
The difference between the two though is MS Office 2007 changed for the worse- not the better.
My experience is that the changes of Office 2007 were very polarizing. A lot of people (often technically inclined) hate the changes, a lot of people really like them. Now that I'm done saying that, I'm pretty indifferent; time to adjust for me was pretty low, but I don't find myself feeling more productive either. (I'm not a heavy Office user; I was using PowerPoint a lot a few months ago, but that's about it.)
There is nothing innately harder about learning to use a couple command line tools than learning to use some third party wizard.
I don't want to argue that GUIs are superior to the command line -- command lines have a ton of benefits (they are quick for knowledgeable users and are scriptable) -- but I disagree here. GUIs have discoverable features. You can learn enough about the GUI to get going, or even often figure it out just by playing around, and then start to pick up more things you can just along the way by noticing what's in the menus and such. That sort of thing is just not possible with command line tools. (I'm assuming traditional Unix utilities here, not interactive text-mode programs which can have the same benefits as a real GUI but have the same drawbacks too of potentially being slower to use and not being scriptable.)
Take a case study: grep's --include option. There's basically no way that you can just happen across the existence of that flag except by reading the man page or output of grep --help. By contrast, a GUI search tool would likely have a text box for file name and one for the text you were searching for in the file. (Actually it'd probably be sort of the reverse; you might have to click an "additional options" tab or something to get text search in a file.) Easily discoverable how to do this sort of thing.
But this difference gets deeper. The --include option is far newer than the grep command itself; it was added about 8 1/2 years ago. (To be honest I thought it was much less, more like 3 or 4.) This means that if you were proficient at grep before that point in time and didn't read the change log, there is almost no way that you would have noticed that change. Since you were proficient you probably don't look at the man page much at all, and almost no one reads the changelogs between release, so how would you discover it? By contrast, with a new version of a GUI program, new options can be very obvious, especially if you know the old interface well. (At least assuming they don't mask it behind meaningless changes like Office 2002->2003, or unrelated changes like 2003->2007.)
What I'm trying to say is that learning a command line program is pretty heavily based on documentation (anything but the simplest command line programs you're probably going to be unable to guess how to use) while many GUI programs you can get away with not reading any documentation for a long time. (How much documentation have you read on how to use Firefox for instance?)
You could argue whether that means that the GUI program is innately easier, but I at least would claim that it is.
Slashdot Mirror
That 0.04% still represents a good chunk of distance to be covered. A fall is still fatal even if only the lower 0.0001% of the cable fails due to weather.
The nice thing is that any capsules that are going up the hypothetical elevator are likely to be able to deploy parachutes without much problem. Sure, the 'chutes will hit the same weather as what hit the cable, but presumably they wouldn't deploy a mission if there was weather that looked like it'd cause a problem around.
And yes the on off switch we have next to each socket saves a lot of wear and tear on plugging/unplugging - you know - to save the planet.
What?
What sort of usage patters do you have that you regularly unplug something to turn it off? Almost exclusively when I unplug something, it's because (1) I want to move it somewhere else or (2) I need to free up an outlet for something else, neither of which a switch on the outlet helps with. I'm struggling to see a real use case for a switch on an outlet.
The language which had interfaces but no inheritance nor mixins...
Look, I'm not saying it's a great language, but I can come up with a similar list of why C++ is a crappy language. Would you like me to?
How about the fact that there was absolutely no way, out of the box, to create a console application?
So? If you want a console application, use a different language. C++ doesn't have a way "out of the box" to create a GUI application. Python doesn't have a way out of the box to create embedded applications. Does that mean those languages are dumb?
And yeah, you're right on the money about Delphi. I unfortunately never used it (except maybe once or twice to play around briefly), but from what I know it sounded good. But I still think that if you turned the unwashed masses that used VB onto Delphi instead, application quality wouldn't have changed much.
Imagine how much further ahead we'd be now if the 1990's Microsoft RAD IDE were C++ instead of Basic, and Microsoft Office Scripting were Lua or Perl instead of VBA? ...probably about in the same place. The biggest problem with VB was the fact that a bunch of noobs who didn't know much about programming were using it. The language really wasn't particularly inhibiting, even if it's not quite expressive as C++. That problem would have remained.
The US has been doing it for decades too. But new rocket designs are always at least a bit dicey.
Wait, why's that good news? Why bother to pay it off if the world's just going to end?
So our lesson here is... don't run any scripts we don't fully understand as root.
You can scratch the "as root" in there... for most users, the added problems of running untrusted stuff as root barely accounts for the damage that can be done to your system.
Actually one of the points of full disk encryption is that it gives you a measure of protection even when physical security is compromised.
Why on earth would do you do it otherwise?
WTF was going through my mind when I wrote that? I blame it on being low on sleep.
I meant IBM of course, though you know that. ;-)
Right, I totally intended to mention that and just forgot, because I find that extremely annoying as well. (And actually now that I am reminded of that issue, I take back about what I said about the non-caching of passwords being the most annoying UAC-related thing.) The only way I've found to deal with it is to start a whole new elevated command prompt... anyone have a better solution? (I've also tried runas without success, but maybe I was just being stupid with the syntax or not typing my password correctly or something.)
You've got it slightly wrong (mostly, but not entirely, correct) regarding the "reduced security" thing.
Ah, I didn't realize all that. I had heard the MS-signed programs automatically get elevation, but forgot about it/didn't put two-and-two together.
Not to begrudge them too too much, but 7 *years* is a pretty long time. That's longer than the XP -> Vista cycle, and that has bigger changes than this should have been. And lots of /. people (and I) begrudge MS for how long that took. (Granted, MS's Windows team is bigger.)
However, other developers have fixed issues that I've opened. Having some issues fixed because of my feedback is better than none.
I agree, but closed source vendors will fix bugs too. I haven't filed any that I can think of, but I have almost done so. I found a bug w/ Visual Studio's auto_ptr implementation, and looked on MS comment. Someone else had already submitted it, MS had acknowledged it, and it was fixed next version.
I can easily contact the developers. I can submit bugs.... ...and have them ignored. (Request for feature in OpenOffice. Has 215 votes and 30 printed pages of comments, the vast majority of which are "the lack of this feature is the only thing keeping me from using OO." Been open over 7 years now, and we don't have anything even remotely like a timeline. I chose that one because I've had 2 votes (the max for a single issue) sitting on it for a couple years now.)
I'll echo the above to a large extent. Here's my take on UAC, as compared to sudo.
First the similarities: they function in much the same way.They have similar (though not completely overlapping) goals, and they protect more or less the same stuff. Back when I first switched to Vista (about six months after it came out), there was still a lot of flap going on about UAC. I decided to keep a log of every UAC prompt I received, and did so for a month. I don't have it handy, but IIRC here is roughly how it came out. There were bascially three reasons I got prompted: (1) I was making an expected administrative change that would have required root on Linux (most of them), (2) there was a bit of the UI that was designed poorly, or (3) I was first logging on and this hardware monitoring piece of software was starting. The second category is the most interesting; almost all (or maybe all) of these were because I wanted to change my environment variables. Even though I was just changing my user's variables the dialog where you do that is also where you change system-wide environment variables; the fact that you could do the latter mean you needed elevation. (Win 7 fixes this dialog so you don't need elevation to change your own environment.) In addition, while I didn't get it for this reason, some people got UAC prompts for things like start menu and desktop changes. The desktop thing wouldn't happen on Linux because neither KDE nor Gnome have the idea off a global "all users" desktop in addition to the per-user one. The changes that caused these UAC prompts were because the change had to affect the all users desktop. I'm not sure how Gnome and KDE store the equivalent of the start menu soo I'm not sure hoow sudo would behave there.
Now the differencees:
1. UAC behaves more like 'su' than sudo. You need the password of the admin user, not your own. For enterprise users, this could be a big deal. For a home user, I doubt it matters much. For a single-user computer, it doesn't really matter in the slightest.
2. UAC doesn't cache its permission. If you need to elevate twice in a row, you have to explicitly elevate twice. At least on a typical desktop configuration, gksudo will cache its permission for a couple minutes. This is the main respect in which, IMO, UAC is more annoying. That said, this rarely happened in my month of UAC logging.
3. UAC is on-demand: a running program can ask for elevation. This is in contrast to sudo, where you need to start with said user's rights. This isn't very different from the end user's perspective as compared to stuff like GkSudo, but is pretty nice as compared to running sudo from the command line, where at least I often found myself going "oops, I needed to start that as root."
4. Even admin users need to elevate, but root doesn't need to sudo. A little annoying if you're doing a loot of admin stuff. Then again, you only need to click 'yes' as opposed to type your password, so it's not too bad. This is important for Windows users where most people are an admin anyway (and hence sudo as-such wouldn't do anything). Speaks more about the Windows architecture and programs than UAC in that respect. (Win 7 changes this; admin users don't have to explicitly elevate as much. Icons with the UAC logo elevate without a prompt. Programs that just want elevation, like installers, still cause a prompt.)
5. UAC checks the program's digital signature, and displays either the confirmed source or a warning about a missing signature; sudo doesn't do any of that. In theory this is a nice win on UAC's part, but in practice I doubt it matters much. A lot of programs (esp. OSS apps) aren't signed, so the presence of that warning usually isn't surprising so I just click through anyway, and (1) you need to a lot of thee time and (2) I even know all about what it's talking about it.
All Microsoft did in 7 is reduce the security, since many users will blindly click through whatever is shown anyways, and power users turn it off.
I don't buy this stat
When I was in school, there were less than a half dozen women in all of the CS classes I took, combined, and while it may not be 50/50 yet, there are still some pretty goodly numbers of women.
I am still in (grad) school. The highest female-to-male ratio I have ever seen in any CS class at either my undergrad institution (attended 2002-2006) or my grad one (both are large state institutions) was 3 or 4 in a class of 20-some. That was an honors class and most of the CS girls in my year were in the honors program. In most classes it was 4 or 55 in a class of 50. It's entirely possible that the total number of females I had a CS class with while an undergrad is less than a dozen.
I went through the grad student directory for my current school. There are 250 names listed; 217 people have pictures. Of those, fewer than 40 are female; that's about 16%. Even if every one of the pictureless people were female, it would still be less than 1/3 of the dept.
So no, my experience is that there aren't goodly numbers of women; the ratios in school are still terrible.
Granted, industry seems to be doing a little better, and maybe numbers are higher at smaller privatee institutions, but it's still pretty bad.
Actually since costs are relatively fixed for online distribution of games that are already written, revenue probably varies basically directly with profit, so either one should be a decent indicator of the other.
Package managers require root, sure, but I already said that. But there are other ways to install most OSS software. In particular, the configure/make/make install sequence works for almost everything where you have source. Sure it can be a pain, but I already said that too.
The problem is that most Windows programs don't have any installation method other than the installer, so if Windows decides the installer needs admin rights, there's usually no way to do it without them.
Under a typical Unix philosophy anyway, which I actually agree with in this case, there's no reason to prohibit the user from installing software locally to their home directory, which is why I'm surprised there's not more support. This is why I was decrying the state of user-mode installations in the first place. Under Windows XP it was actually okay (many things you actually could install without admin rights), under Linux it's a PITA but possible, and on Vista it often impossible.
How does the absolute intake compare to what it was before the experiment though?
I'm reminded of a sale Valve had for L4D a few months after it was released; Jeff Atwood relayed the results. In short, Valve cut the price of L4D in half, and the result brought in more money (not just more sales!) than the launch day.
So how did World of Goo's experiment do in absolute numbers? Did the revenue increase or decrease from before the experiment? Certainly sales increased, but that's a far cry from revenue increasing.
You may not like it but MS finally got smart with that and followed OS X and other Unices like Linux by requiring admin privileges to install software.
It's news to me that Linux requires admin privileges to install software. I have a couple gigs stored in ~/.packages at work, where I don't have admin privileges.
(The problem is that since Windows autostupidly wants to elevate all installers, it's impossible to install most things with the permissions of a non-admin user, even if you just want to install it to a location that the user has write permission to and even if the program & installers are well-behaved and don't need to write to HKLM or anything like that.)
If you don't have root, why not just ask the admin to install something for you through the package manager if you need it? Most will. Doesn't hurt to at least ask, you may be putting yourself through the frustration for nothing.
By the way, to answer this, it's usually not much of a pain to do the installation, and just the configure/make/make install cycle works. And while the IT support people would probably install it locally with RHEL's package manager (actually I could probably get root if I really wanted), me doing it and putting it in ~ means its on the network and visible anywhere. (I could ask them to make it available on the network too, but with some of the stuff I have I doubt they would. It wouldn't be "run a package manager" simple for them either because they support a number of different platforms and configurations.) So basically me doing the work is usually easy and has benefits beyond "I don't have to bug the support people."
There have just been a couple of times where it's become a huge pain in the ass. One of them was some GTK program that started transitively requiring probably a dozen and a half libraries (e.g. the Gnome-related lib*mm ones) before I got done. That time I actually started keeping the stack of "a requires b requires c requires d" so that when I was done installing d I could go back to c's configure and see if it worked.
The problem is there's no any real indication of when you'll wind up in a situation like that.
That asde, to use that as an example is a bit disingenuous. You're presenting a serious edge case as the norm.
I don't buy it's that much of an edge case. Sure it is for home use, but how many corporate users don't have admin rights to their desktop box at work? I'm not sure, but I bet it's a sizable percentage. I'm sure at least some of them have software they'd like to use. (There's also the question of kids who have non-admin accounts on their home computer and don't want to go running to mom or dad; this I suspect happens very infrequently though.)
Of course, this discussion is becoming more and more moot; with Vista, Windows assumes that any installer should be run with admin rights even if it would run OK without, which means that non-admins can't install stuff any more either. IMO this was a really stupid decision on MS's part, and it's the main problem I have with Vista's UAC.
(I also disagree that I presented it as the norm, but whatever.)
What you say is true, but it's not contradictory. MS is very pro-Linux, they are just pro-Linux because they think it's good for business.
I for one use PDF export, Flash export, and other similar features missing from Microsoft Office
Office has had PDF export for... a couple years? I'm not sure if it was in the first pressings of Office 2007 and may have been in it's SP1 (I think it has an SP1), but I definitely have a PDF export option in my Office installation, and it's definitely at least a plugin from MS.
The difference between the two though is MS Office 2007 changed for the worse- not the better.
My experience is that the changes of Office 2007 were very polarizing. A lot of people (often technically inclined) hate the changes, a lot of people really like them. Now that I'm done saying that, I'm pretty indifferent; time to adjust for me was pretty low, but I don't find myself feeling more productive either. (I'm not a heavy Office user; I was using PowerPoint a lot a few months ago, but that's about it.)
There is nothing innately harder about learning to use a couple command line tools than learning to use some third party wizard.
I don't want to argue that GUIs are superior to the command line -- command lines have a ton of benefits (they are quick for knowledgeable users and are scriptable) -- but I disagree here. GUIs have discoverable features. You can learn enough about the GUI to get going, or even often figure it out just by playing around, and then start to pick up more things you can just along the way by noticing what's in the menus and such. That sort of thing is just not possible with command line tools. (I'm assuming traditional Unix utilities here, not interactive text-mode programs which can have the same benefits as a real GUI but have the same drawbacks too of potentially being slower to use and not being scriptable.)
Take a case study: grep's --include option. There's basically no way that you can just happen across the existence of that flag except by reading the man page or output of grep --help. By contrast, a GUI search tool would likely have a text box for file name and one for the text you were searching for in the file. (Actually it'd probably be sort of the reverse; you might have to click an "additional options" tab or something to get text search in a file.) Easily discoverable how to do this sort of thing.
But this difference gets deeper. The --include option is far newer than the grep command itself; it was added about 8 1/2 years ago. (To be honest I thought it was much less, more like 3 or 4.) This means that if you were proficient at grep before that point in time and didn't read the change log, there is almost no way that you would have noticed that change. Since you were proficient you probably don't look at the man page much at all, and almost no one reads the changelogs between release, so how would you discover it? By contrast, with a new version of a GUI program, new options can be very obvious, especially if you know the old interface well. (At least assuming they don't mask it behind meaningless changes like Office 2002->2003, or unrelated changes like 2003->2007.)
What I'm trying to say is that learning a command line program is pretty heavily based on documentation (anything but the simplest command line programs you're probably going to be unable to guess how to use) while many GUI programs you can get away with not reading any documentation for a long time. (How much documentation have you read on how to use Firefox for instance?)
You could argue whether that means that the GUI program is innately easier, but I at least would claim that it is.