"Despite the efforts of ISPs and some institutions (heck even Comcast has an IPv6 pilot program) no significant number of end-users are going to turn on IPv6."
Of course not, because that's not what end users do.
End users will go IPv6 en masse as soon as the DSL "thingie" that their ISP installs on their homes and works magically to connect them to the intertubes goes IPv6.
"I have a hard time thinking that a secies more advanced than us would give/sell their technology. Maybe if we stopped trying to kill each other and live in peace that could happen but I aint holding my breath."
Klaatu barada nikto...
And then, for all the experience you have at hand, that surely would happen: "white people" had no problem selling guns to "red skins", so go figure.
"A man on foot maybe 20 [miles a day] if he's in top shape."
Quite a bit more. Unless Wikipedia is wrong Yiannis Kouros, from Greece, owns since 1997 the world record for a 24-hour run a bit over 20 miles: 188,590 miles to be precise.
20 miles a day, every day, can be acomplished by "normal" people since that's a typical daily stage for Way of St. James pilgrims (about 200.000 of them this year).
"I disagree that all sysadmins require programming knowledge [...] Some companies use almost entirely pre-canned, purchased software applications to run in their environment without an inhouse dev team and support is a phone call away."
That's not a system administrator, that a system operator. And, well, yeah, a system operator doesn't need programming knowledge.
"[your single server has died] How does that change with scripting?"
Scripting leads naturally to testing and automation. You will either promote temporarily your test box to production and/or you automate your installation so you just reapply the scripts in order to get your configuration in place again (think, i.e. Puppet or CFengine). Even without automation, CLI+text config files tends naturally to source management: you have your modified by hand config files within, say, Subversion, so you reapply your last config or, even if you lose the repo with the server you still have your current sandbox in your local PC.
As a general matter, CLI+config files makes config management so much easier it opens up a complete new world of possibilities that goes absolutly ignored by the GUI advocates. It's not only the obvious advantages but a lot of things they even don't hint (but due to this, you don't grasp all the CLI advantages from day one, you need to get accustomed to it and learn from experience).
"then having the GUI reset the file to a "consistent" state"
There's a "mental state" shared both by the GUI developer and the end user that "GUIs are so easy" nobody would want or need anything else so the developer, when facing the problem of supporting direct user edits naturally tends to *not* support them in an obvious manner: rewriting the file from scratch each time.
And it is not that the config file is dificult to parse, think that the app using the config is *already* parsing it properly (or it wouldn't work), it is that is more complex than just rewriting the file and, after all, using the GUI is so easy and desirable that nobody would want to hand edit it, wouldn't it?
"Net result: you end up locked in Suse.
Not if YaST doesn't do the job."
The problem here is the 80/20 law. YaST does the job... for the beginner, most of the time. It shares kind of a Windows user mentality: if it's not obviously doable from the GUI, is not doable; we will just need to buy that other app that will do it for us from its own shiny added GUI.
"great as they might be, can get just as inconsistent whenever dpkg-configure is thrown in the job. Why? Because unstructured text files is very human-friendly and very machine-unfriendly."
dpkg-configure and relatives, is *not* a config management tool no matter this issue rising from time to time. It is just a helper for first time configuration. And it works sanely most if not all of the time (if the config file has not been edited by hand, displace it with a new version; if it's been edited, tell the user).
And with the human/machine friendliness... well, if the text-based config file is so machine-unfriendly, how is it that the app itself manages to use it? And for the most part it is not unestructured: they are mostly idempotent variable->value or the same within a config block (after all, that's why quite a lot of programs have managed to use them as a configuration backend). No: the problem for the config GUI developer is usually not that it can't handle the config file but that the GUI developer is more insterested about the framework (say, YaST) than about the configured app, so he really doesn't want to deal with the miriad of the different config styles: it's easier to just stick with a limited subset of the config options, without having to write a more or less complex parser; I'll just rewrite it (and, by the way, wreaking havoc to any file system check tool you might happen to use: dare mind using something like Samhain on Suse and cry when most of the time you just fire YaST it will rise a ton of false positives because it will touch most of your config files).
"A happy middle ground that lets you edit configurations by hand if the system goes down but requires consistent grammar would solve a ton of those problems."
XML has the advantage that you can incorporate a grammar along the file (by means of the DTD definition). Such an advantage is *only* needed when two partners, unknowin
"If your GUI dosn't offer the same advantages than a console/terminal text interface, then your GUI is lacking some features and is a GUI for some but not all your needs, very common in the nix world btw"
Now, please, tell me how well a GUI-oriented environment copes with: * Repeatability (I want exactly the same you did yesterday on server A, now on server B) * Auditory (what did change in this server from yesterday, who did it?) * Automation (remember what you did yesterday on server A? I want you to do it again on server B; but do it tonight at 2AM -no, no extra hours payment allowed) * Conformance (now that we know how exactly it has to be done from our working on the test environment, let's do it -without mistakes, in our 100 production servers) * Orchestration (let's do changes a, b and c on servers A, B and C as fast as possible, without mistakes, in proper order and each step only after being sure the previous one is properly working -oh, and let's do it at 2AM -why do you ask it again? No, no extra hours payment allowed)
For I know all of them are virtually trivial on text-based CLI-oriented systems.
"I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL. Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script."
Yes. Then you upgrade the firmware because of a security-related bug and all your scripts fail at once.
URL managing is just slightly not as bad as screen scrapping.
Oh, and you probably don't POST the requests, you GET them.
"I've mentioned them above, but you can do damn-near anything that Windows can do via either LinuxConf (for older distros) or Webmin/Usermin."
No. Linuxconf, Webmin and any other GUI-based high level configuration abstraction tools in Linux have a big drawback that you won't find in Windows: The former are created on top of the tools to be managed while Microsoft controls theirs bottom up.
Take Jaques Gelinas' Linuxconf (Webmin is the same): the tool framework was good, but each configuration module had to be developed *on top* of the tool/program to be managed. Being Linuxconf basically a Red Hat only tool, the programs developers didn't have or feel the need to produce the Linuxconf modules for themselves (after all, their apps already had their own documented config files) so Jaques himself ended up being the one having to develop Linuxconf modules for Sendmail, Bind, networking etc. As such, modules tended not to cover new versions/obscure options of the programs and, in the end, that made Linuxconf to fade away. Except for the fact that Webmin has managed to stay longer, all the same can be told of it.
On the other hand, Microsoft is the single party for all the core of the OS so it can offer up-to-date configuration GUI tools (even if they were not so up to date, you probably wouldn't know it, since you wouldn't use options you ignore that even exist) and, on top to it, the Registry is offered from bottom up to third party developers so all of them end up using the same common infrastructure (imagine that all unix apps were somehow forced to use, say, the Apache config file syntax. It would make a common configuration GUI framework much more easy to acomplish, wouldn't it?).
"Only OS X has had a consistent file location schema over the past 10 years."
Wrong.
Debian has had a consistent file location schema over the past 10 years. Red Hat has had a consistent file location schema over the past 10 years. Suse has had a consistent file location schema over the past 10 years.
"Realistically, if you're a company with less than a 100 employees [...] it just won't matter to the admin if they can script, say, creating a mailbox for 100 new users instead of just one."
Well... it won't matter till the day your single server dies and you learn that, being a little drop in the sea, you don't have a "gold support contract" and it takes you one week to get a new spec'ed server (if only I weren't such a cheap ass and I'd buy two...). And when you turn on the new server you learn that you don't have the slightest idea about how it was exactly configured with all the tweaks you added through the years.
"The trouble with Linux, and I'm speaking as someone who's used YaST in precisely this context, is that you have to make a choice - do you let the GUI manage it or do you CLI it?"
Your problem is YaST, not your approach.
"The only solution I really see is for manual config file support with optional XML"
I'll tell you a better one (XML for configurations is almost never the answer).
1) Proper engineering practices. Most of them are quite simple, once you get them. Just an example that it would be quite apt to this case: Debian favours as much as possible having configurations for complex services in its own directory, '/etc/complexservice.d/' where you drop "config snippets" instead of a big/etc/complexservice.conf file. If Suse did the same, YaST could be able to tweak the config snippets you allow it and you could manage by hand the ones you wanted/needed. But ask yourself why are you still using Suse and you probably will have to answer yourself "because YaST". Suse has no interest on making YaST a proper configuration tool because YaST is a lock-in tool instead. For the "easy" things you go with YaST, so you don't learn how to do it "by hand" on the cases where it makes more sense, the easy ones; by the time YaST gets short you don't know how to fully do it "by hand" and you can't manage it partly "by hand" because YaST will overwrite it. Net result: you end up locked in Suse.
2) Today, almost any "workgroup-graded" server has enough horsepower to handle virtualization. Fire up a virtual guest, test your new configs in the test environment, making use of the GUI tools if needed, and then go analyze the resultant configuration and replicate it by hand in your production environment. This will bring you the best of both worlds: fast entry path for new things by means of the GUI while retaining full customization abilities on production (and the analysis part will make you learn a lot at a very fast pace).
"There are more and more small businesses (5, 10 or so employees) realizing that they can get things done easier if they had a server. Because the business can't really afford to hire a sysadmin or a full-time tech person, its generally the employee who "knows computers""
Which is, again, a Microsoft sin: it was Microsoft the one that told once an again the bussiness owner that "Windows is easy" and that showed him that their server products just looked like their desktop/home/whatever you want to call them, so it must be true that a savvy user can be overloaded with admin tasks.
That and the case that, specially for minor environments and certainly even for big ones most part of its history, administering Windows was a case of going to the computer's console and locally do the thing.
For the last 10~15 years with common high speed Internet connectivity the answer to that scenario was not having "the employee who knows computers" doubling as local system administrator, but outsourcing it to someone knowledgeable that remotely works on the server through ssh and shows by the office once a month basically for the warm fuzzy feeling of human interaction. If the bussiness owner would have known any better, that is.
"chattr +i/etc/resolv.conf I had to do that on Ubuntu a couple of years back because it kept overwriting resolv.conf and the GUI wouldn't accept the configuration I wanted to use."
No. You had to do it that way because you didn't know any better (it probably was the case that your DHCP client was dinamically editing your/etc/resolv.conf file and using values given by the DHCP server, behaviour that is, of course, configurable once you know how to do it).
That was the parent post's point: you can't know everything about everything and there GUIs can come to your help.
My point (and that from the article's) is that while that's true, the long term inconveniencies of a GUI-focused environment doesn't compensate for the short term advantages, not at least on a professional environment.
"I find it rather disturbing the UNIX ideal that sysadmins should be programmers."
That should be the case, but it isn't firstly because becoming a good sysadmin is a full time activity as it is being a good programmer and secondly because of subtle character differences between the people that choose one role or the other.
"I know more than a few programmers that are abysmal at system administration, and I know sysadmins that can't program. There is nothing wrong with this."
Yes, there is, and very wrong. Maturity of current IT systems is still far away to what's needed to be able to work in aisles. A programmer doesn't need to be a top notch sysadmin nor the other way around, but they both need to have very clear ideas about the other's trade because is needed both to understand where your program is going to be run and how and what would make proper practices to acomodate the programs within a wider and partially peculiar local environment (and in order to recognize properly engineered programs from lame intents).
"Not everyone should have to learn that skill, and you could well be excluding people you want by requiring it."
And, in fact, not everyone needs to learn that skill, it's only sysadmins that need it. And take for granted you are not excluding interesting people to fill a sysadmin role if they don't have at least clear foundations on programming.
"Also there's the simple matter that GUIs work better for unfamiliar situations."
Quite true (but proper man pages with examples and tutorials work almost as well).
"Part of systems administration is being able to solve novel problems. Ok well GUIs help in that regard, at least when well designed. "
But don't forget a *very* critical point: a new thing is only novelty the first time you do it. Do not let a bit of easiness for your first time getting in your way for the subsequent 10.000 times you will do it again from then on.
And that's exactly why GUIs sell so good. When you are "buying" something new (it might mean literarilly exchanging money, but it means commiting yourself to the effort that will require work with new thingie) it usually will be to do new things, which is the kind of situation when GUIs (and "wizards", for that matter) will help, so the GUI by itself will be a very valuable agent to sell the app/services. By the time you understand that the shiny GUI gets in the middle you have invested too much in the app (money, time and effort) to get away from it. Microsoft, for instance, has learnt that leson very, very well.
"They also can help prevent errors. For example I can't count the number of times our DNS has been temporarily broken by a student messing up the file."
That's not an argument, it only seems to. While "manual handling" is prone to syntax failures, GUIs are prone to knowledge failures which are, by the way, much, much more dificult to debug. For each time you had a student making a severe syntax error on a DNS zone file, I can show you a self-called sysadmin making horrible design choices that led to situations dificult to repair and problems dificult to debug because the GUI allowed for an action on Windows environments (which was not a failure of the GUI itself, because the action was correct under the proper circumnstances, but because the GUI allowed for someone without enough knowledge on the consecuences of their acts to do "something" resulting in an "OK" message: a case of "garbage in, garbage out").
So it's a stalemate on this.
"In Windows? Not a problem"
Now that you mention the text config files vs. GUIs on a multiple admins (some of them students) environment, here comes a hugh problem with the vast majority of GUIs:
You get at work early in the morning and something is not working properly. You summon your minions and tell them "something is broken; what have you messed up since yesterday?"
On a text files-based environment the answer is easy and you already advanced it: "we have it in a versioning system so
"I think the author might not fully understand who most admins are."
I think you -and most people, is forgetting what an system admin is. If all you do is push buttons and follow menu entries, then you are not an admin, you are an operator.
Yes, the vast majority of people with administrative privileges on Windows environments are operators, not admins.
"Has anyone done the calculations for the lowest altitude you could actually make an object - let's say an aerodynamically-shaped chunk of uranium or something else ultra-dense - orbit the earth at least once if you just got it moving fast enough in the right direction."
If you are not meaning about the real engineering problem but a theoretical one, no need to do the calculations: sea level.
Well, that's theoretical, since you still would need to find a clear path in order not to hit a land mass, a vessel, etc.
For an absolute without-problems altitude, just about 2,5m meters over Everest peak (to account for the fact that there could be a mountaineer at the top raising his arms in satisfaction just when your thingie passes over there).
But if you want to do the math, you can take a shortcut on your way from the "typical" orbital speed calculations: you just need to take into account that your object has to be speedy enough to make about 40.000 Km (the Earth's perimeter) in the time it takes for the object to reach ground falling free from the height it starts the motion from.
So, if you start from 1 m of height, since it takes about half a second to reach the floor (well, it's 0,45s), you need an object starting at about 80.000 Km/s, or about 65 mach (being sound speed at see level something like 1.225 Km/h).
All that said, well... there *is* a limit even in theory since a massive object can't go beyond light speed as per special relativity theory, so the theoretical lowest altitude would be the one that it takes falling from it about 0.13s (which the time an hypotetical photon would take to orbit once the Earth at sea level), or about 8 cm.
"It may not fit our anal definition of 'space', but it's an awesome effort by a couple of regular people"
Reaching 100.000 feet with a $150 weather balloon is *trivial*.
"do something most people would never try."
I'd never put my tonge on a live electric cord either.
Sorry to break your dreams but the feat is not awesome. It's just lovely that a father will entertain/instruct his son with something like this, but that's all.
"'Think about it,' writes Madrigal. 'You've got a wire and you've got a magnet. Switch on the current - which you can't see and have no intuitive way to know exists - and suddenly the wire begins to rotate around the magnet."
You have no intuitive way to know current exists? My ass!
Turn on the current and then apply your fingers to the naked wire and then tell me there's no intuitive way to know if current is passing through!
"Don't forget this exact issue comes to security as well."
I don't.
"Seen the SLAs of most cloud providers when it comes to security?"
They work on my previous assumption too: offer as little as you can go with for as much money as you can go with. If the customer doesn't explicitly ask for security, the provider won't offer security.
Even if the customer asks for security, as long as the provider can go with customers that don't ask for it (and then, for a better profit margin), the provider will just ignore that customer and go for the lower hanging fruit (or even worse, they'll promise but never deliver).
And this doesn't even implies the provider being a devilesque bad guy or something like this. It is just an obvious "emerging property" on a system steamed by money that money will be the selective pressure.
"otherwise he would know that with volume licensing from Microsoft, the support is included"
Unless you pay extra, the only support that comes with volume licensing from Microsoft is:
1) Support on the volume license procedure itself
2) Telephone support -on office hours, about install issues
3) Everything else is subjected to further charges Maybe I'm mistaken and there's adittional support for free under basic volume licensing agreements. Can you, please, point me where can I read about it from an official source? Or else I might think you are just trolling.
"Dependencies in Linux are murder if you go off the beaten path."
You can't go off the beaten path with Windows, to start with.
Pretty packaged Linux programs vs pretty packaged Windows programs? Stalemate.
Linux programs not packaged to fit your distribution? problems ahead but doable. Windows programs not packaged to be distributed? virtually impossible.
Linux programs distributed as source tarballs? problems ahead but doable. Windows programs distributed as source tarballs? virtually impossible.
"Linux dependencies suck balls, I'll take Windows executables and dll hell over that any day."
Slashdot Mirror
"Despite the efforts of ISPs and some institutions (heck even Comcast has an IPv6 pilot program) no significant number of end-users are going to turn on IPv6."
Of course not, because that's not what end users do.
End users will go IPv6 en masse as soon as the DSL "thingie" that their ISP installs on their homes and works magically to connect them to the intertubes goes IPv6.
"By sending autonomous robots ahead of us to assemble fuel depots: we can slingshot to the destination."
Out of what? Deep space is, well, quite empty.
"Parsec is a measure of time, not currency. Duh."
Maybe his friend was talking about a mortage. Duh.
"I have a hard time thinking that a secies more advanced than us would give/sell their technology. Maybe if we stopped trying to kill each other and live in peace that could happen but I aint holding my breath."
Klaatu barada nikto...
And then, for all the experience you have at hand, that surely would happen: "white people" had no problem selling guns to "red skins", so go figure.
"A man on foot maybe 20 [miles a day] if he's in top shape."
Quite a bit more. Unless Wikipedia is wrong Yiannis Kouros, from Greece, owns since 1997 the world record for a 24-hour run a bit over 20 miles: 188,590 miles to be precise.
20 miles a day, every day, can be acomplished by "normal" people since that's a typical daily stage for Way of St. James pilgrims (about 200.000 of them this year).
"I disagree that all sysadmins require programming knowledge [...] Some companies use almost entirely pre-canned, purchased software applications to run in their environment without an inhouse dev team and support is a phone call away."
That's not a system administrator, that a system operator. And, well, yeah, a system operator doesn't need programming knowledge.
"[your single server has died]
How does that change with scripting?"
Scripting leads naturally to testing and automation. You will either promote temporarily your test box to production and/or you automate your installation so you just reapply the scripts in order to get your configuration in place again (think, i.e. Puppet or CFengine). Even without automation, CLI+text config files tends naturally to source management: you have your modified by hand config files within, say, Subversion, so you reapply your last config or, even if you lose the repo with the server you still have your current sandbox in your local PC.
As a general matter, CLI+config files makes config management so much easier it opens up a complete new world of possibilities that goes absolutly ignored by the GUI advocates. It's not only the obvious advantages but a lot of things they even don't hint (but due to this, you don't grasp all the CLI advantages from day one, you need to get accustomed to it and learn from experience).
"then having the GUI reset the file to a "consistent" state"
There's a "mental state" shared both by the GUI developer and the end user that "GUIs are so easy" nobody would want or need anything else so the developer, when facing the problem of supporting direct user edits naturally tends to *not* support them in an obvious manner: rewriting the file from scratch each time.
And it is not that the config file is dificult to parse, think that the app using the config is *already* parsing it properly (or it wouldn't work), it is that is more complex than just rewriting the file and, after all, using the GUI is so easy and desirable that nobody would want to hand edit it, wouldn't it?
"Net result: you end up locked in Suse.
Not if YaST doesn't do the job."
The problem here is the 80/20 law. YaST does the job... for the beginner, most of the time. It shares kind of a Windows user mentality: if it's not obviously doable from the GUI, is not doable; we will just need to buy that other app that will do it for us from its own shiny added GUI.
"great as they might be, can get just as inconsistent whenever dpkg-configure is thrown in the job. Why? Because unstructured text files is very human-friendly and very machine-unfriendly."
dpkg-configure and relatives, is *not* a config management tool no matter this issue rising from time to time. It is just a helper for first time configuration. And it works sanely most if not all of the time (if the config file has not been edited by hand, displace it with a new version; if it's been edited, tell the user).
And with the human/machine friendliness... well, if the text-based config file is so machine-unfriendly, how is it that the app itself manages to use it? And for the most part it is not unestructured: they are mostly idempotent variable->value or the same within a config block (after all, that's why quite a lot of programs have managed to use them as a configuration backend). No: the problem for the config GUI developer is usually not that it can't handle the config file but that the GUI developer is more insterested about the framework (say, YaST) than about the configured app, so he really doesn't want to deal with the miriad of the different config styles: it's easier to just stick with a limited subset of the config options, without having to write a more or less complex parser; I'll just rewrite it (and, by the way, wreaking havoc to any file system check tool you might happen to use: dare mind using something like Samhain on Suse and cry when most of the time you just fire YaST it will rise a ton of false positives because it will touch most of your config files).
"A happy middle ground that lets you edit configurations by hand if the system goes down but requires consistent grammar would solve a ton of those problems."
XML has the advantage that you can incorporate a grammar along the file (by means of the DTD definition). Such an advantage is *only* needed when two partners, unknowin
"If your GUI dosn't offer the same advantages than a console/terminal text interface, then your GUI is lacking some features and is a GUI for some but not all your needs, very common in the nix world btw"
Now, please, tell me how well a GUI-oriented environment copes with:
* Repeatability (I want exactly the same you did yesterday on server A, now on server B)
* Auditory (what did change in this server from yesterday, who did it?)
* Automation (remember what you did yesterday on server A? I want you to do it again on server B; but do it tonight at 2AM -no, no extra hours payment allowed)
* Conformance (now that we know how exactly it has to be done from our working on the test environment, let's do it -without mistakes, in our 100 production servers)
* Orchestration (let's do changes a, b and c on servers A, B and C as fast as possible, without mistakes, in proper order and each step only after being sure the previous one is properly working -oh, and let's do it at 2AM -why do you ask it again? No, no extra hours payment allowed)
For I know all of them are virtually trivial on text-based CLI-oriented systems.
"I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL.
Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script."
Yes. Then you upgrade the firmware because of a security-related bug and all your scripts fail at once.
URL managing is just slightly not as bad as screen scrapping.
Oh, and you probably don't POST the requests, you GET them.
"I've mentioned them above, but you can do damn-near anything that Windows can do via either LinuxConf (for older distros) or Webmin/Usermin."
No. Linuxconf, Webmin and any other GUI-based high level configuration abstraction tools in Linux have a big drawback that you won't find in Windows: The former are created on top of the tools to be managed while Microsoft controls theirs bottom up.
Take Jaques Gelinas' Linuxconf (Webmin is the same): the tool framework was good, but each configuration module had to be developed *on top* of the tool/program to be managed. Being Linuxconf basically a Red Hat only tool, the programs developers didn't have or feel the need to produce the Linuxconf modules for themselves (after all, their apps already had their own documented config files) so Jaques himself ended up being the one having to develop Linuxconf modules for Sendmail, Bind, networking etc. As such, modules tended not to cover new versions/obscure options of the programs and, in the end, that made Linuxconf to fade away. Except for the fact that Webmin has managed to stay longer, all the same can be told of it.
On the other hand, Microsoft is the single party for all the core of the OS so it can offer up-to-date configuration GUI tools (even if they were not so up to date, you probably wouldn't know it, since you wouldn't use options you ignore that even exist) and, on top to it, the Registry is offered from bottom up to third party developers so all of them end up using the same common infrastructure (imagine that all unix apps were somehow forced to use, say, the Apache config file syntax. It would make a common configuration GUI framework much more easy to acomplish, wouldn't it?).
"Only OS X has had a consistent file location schema over the past 10 years."
Wrong.
Debian has had a consistent file location schema over the past 10 years.
Red Hat has had a consistent file location schema over the past 10 years.
Suse has had a consistent file location schema over the past 10 years.
Should I continue?
"Realistically, if you're a company with less than a 100 employees [...] it just won't matter to the admin if they can script, say, creating a mailbox for 100 new users instead of just one."
Well... it won't matter till the day your single server dies and you learn that, being a little drop in the sea, you don't have a "gold support contract" and it takes you one week to get a new spec'ed server (if only I weren't such a cheap ass and I'd buy two...). And when you turn on the new server you learn that you don't have the slightest idea about how it was exactly configured with all the tweaks you added through the years.
"The trouble with Linux, and I'm speaking as someone who's used YaST in precisely this context, is that you have to make a choice - do you let the GUI manage it or do you CLI it?"
Your problem is YaST, not your approach.
"The only solution I really see is for manual config file support with optional XML"
I'll tell you a better one (XML for configurations is almost never the answer).
1) Proper engineering practices. Most of them are quite simple, once you get them. Just an example that it would be quite apt to this case: Debian favours as much as possible having configurations for complex services in its own directory, '/etc/complexservice.d/' where you drop "config snippets" instead of a big /etc/complexservice.conf file. If Suse did the same, YaST could be able to tweak the config snippets you allow it and you could manage by hand the ones you wanted/needed. But ask yourself why are you still using Suse and you probably will have to answer yourself "because YaST". Suse has no interest on making YaST a proper configuration tool because YaST is a lock-in tool instead. For the "easy" things you go with YaST, so you don't learn how to do it "by hand" on the cases where it makes more sense, the easy ones; by the time YaST gets short you don't know how to fully do it "by hand" and you can't manage it partly "by hand" because YaST will overwrite it. Net result: you end up locked in Suse.
2) Today, almost any "workgroup-graded" server has enough horsepower to handle virtualization. Fire up a virtual guest, test your new configs in the test environment, making use of the GUI tools if needed, and then go analyze the resultant configuration and replicate it by hand in your production environment. This will bring you the best of both worlds: fast entry path for new things by means of the GUI while retaining full customization abilities on production (and the analysis part will make you learn a lot at a very fast pace).
"There are more and more small businesses (5, 10 or so employees) realizing that they can get things done easier if they had a server. Because the business can't really afford to hire a sysadmin or a full-time tech person, its generally the employee who "knows computers""
Which is, again, a Microsoft sin: it was Microsoft the one that told once an again the bussiness owner that "Windows is easy" and that showed him that their server products just looked like their desktop/home/whatever you want to call them, so it must be true that a savvy user can be overloaded with admin tasks.
That and the case that, specially for minor environments and certainly even for big ones most part of its history, administering Windows was a case of going to the computer's console and locally do the thing.
For the last 10~15 years with common high speed Internet connectivity the answer to that scenario was not having "the employee who knows computers" doubling as local system administrator, but outsourcing it to someone knowledgeable that remotely works on the server through ssh and shows by the office once a month basically for the warm fuzzy feeling of human interaction. If the bussiness owner would have known any better, that is.
"chattr +i /etc/resolv.conf
I had to do that on Ubuntu a couple of years back because it kept overwriting resolv.conf and the GUI wouldn't accept the configuration I wanted to use."
No. You had to do it that way because you didn't know any better (it probably was the case that your DHCP client was dinamically editing your /etc/resolv.conf file and using values given by the DHCP server, behaviour that is, of course, configurable once you know how to do it).
That was the parent post's point: you can't know everything about everything and there GUIs can come to your help.
My point (and that from the article's) is that while that's true, the long term inconveniencies of a GUI-focused environment doesn't compensate for the short term advantages, not at least on a professional environment.
"I find it rather disturbing the UNIX ideal that sysadmins should be programmers."
That should be the case, but it isn't firstly because becoming a good sysadmin is a full time activity as it is being a good programmer and secondly because of subtle character differences between the people that choose one role or the other.
"I know more than a few programmers that are abysmal at system administration, and I know sysadmins that can't program. There is nothing wrong with this."
Yes, there is, and very wrong. Maturity of current IT systems is still far away to what's needed to be able to work in aisles. A programmer doesn't need to be a top notch sysadmin nor the other way around, but they both need to have very clear ideas about the other's trade because is needed both to understand where your program is going to be run and how and what would make proper practices to acomodate the programs within a wider and partially peculiar local environment (and in order to recognize properly engineered programs from lame intents).
"Not everyone should have to learn that skill, and you could well be excluding people you want by requiring it."
And, in fact, not everyone needs to learn that skill, it's only sysadmins that need it. And take for granted you are not excluding interesting people to fill a sysadmin role if they don't have at least clear foundations on programming.
"Also there's the simple matter that GUIs work better for unfamiliar situations."
Quite true (but proper man pages with examples and tutorials work almost as well).
"Part of systems administration is being able to solve novel problems. Ok well GUIs help in that regard, at least when well designed. "
But don't forget a *very* critical point: a new thing is only novelty the first time you do it. Do not let a bit of easiness for your first time getting in your way for the subsequent 10.000 times you will do it again from then on.
And that's exactly why GUIs sell so good. When you are "buying" something new (it might mean literarilly exchanging money, but it means commiting yourself to the effort that will require work with new thingie) it usually will be to do new things, which is the kind of situation when GUIs (and "wizards", for that matter) will help, so the GUI by itself will be a very valuable agent to sell the app/services. By the time you understand that the shiny GUI gets in the middle you have invested too much in the app (money, time and effort) to get away from it. Microsoft, for instance, has learnt that leson very, very well.
"They also can help prevent errors. For example I can't count the number of times our DNS has been temporarily broken by a student messing up the file."
That's not an argument, it only seems to. While "manual handling" is prone to syntax failures, GUIs are prone to knowledge failures which are, by the way, much, much more dificult to debug. For each time you had a student making a severe syntax error on a DNS zone file, I can show you a self-called sysadmin making horrible design choices that led to situations dificult to repair and problems dificult to debug because the GUI allowed for an action on Windows environments (which was not a failure of the GUI itself, because the action was correct under the proper circumnstances, but because the GUI allowed for someone without enough knowledge on the consecuences of their acts to do "something" resulting in an "OK" message: a case of "garbage in, garbage out").
So it's a stalemate on this.
"In Windows? Not a problem"
Now that you mention the text config files vs. GUIs on a multiple admins (some of them students) environment, here comes a hugh problem with the vast majority of GUIs:
You get at work early in the morning and something is not working properly. You summon your minions and tell them "something is broken; what have you messed up since yesterday?"
On a text files-based environment the answer is easy and you already advanced it: "we have it in a versioning system so
"I think the author might not fully understand who most admins are."
I think you -and most people, is forgetting what an system admin is. If all you do is push buttons and follow menu entries, then you are not an admin, you are an operator.
Yes, the vast majority of people with administrative privileges on Windows environments are operators, not admins.
"What would be nice is if the GUI could automatically create a shell script doing the change"
AIX's SMIT, and it's... how old? merely 20 years now?
"Has anyone done the calculations for the lowest altitude you could actually make an object - let's say an aerodynamically-shaped chunk of uranium or something else ultra-dense - orbit the earth at least once if you just got it moving fast enough in the right direction."
If you are not meaning about the real engineering problem but a theoretical one, no need to do the calculations: sea level.
Well, that's theoretical, since you still would need to find a clear path in order not to hit a land mass, a vessel, etc.
For an absolute without-problems altitude, just about 2,5m meters over Everest peak (to account for the fact that there could be a mountaineer at the top raising his arms in satisfaction just when your thingie passes over there).
But if you want to do the math, you can take a shortcut on your way from the "typical" orbital speed calculations: you just need to take into account that your object has to be speedy enough to make about 40.000 Km (the Earth's perimeter) in the time it takes for the object to reach ground falling free from the height it starts the motion from.
So, if you start from 1 m of height, since it takes about half a second to reach the floor (well, it's 0,45s), you need an object starting at about 80.000 Km/s, or about 65 mach (being sound speed at see level something like 1.225 Km/h).
All that said, well... there *is* a limit even in theory since a massive object can't go beyond light speed as per special relativity theory, so the theoretical lowest altitude would be the one that it takes falling from it about 0.13s (which the time an hypotetical photon would take to orbit once the Earth at sea level), or about 8 cm.
"It may not fit our anal definition of 'space', but it's an awesome effort by a couple of regular people"
Reaching 100.000 feet with a $150 weather balloon is *trivial*.
"do something most people would never try."
I'd never put my tonge on a live electric cord either.
Sorry to break your dreams but the feat is not awesome. It's just lovely that a father will entertain/instruct his son with something like this, but that's all.
"But helium regularly escapes the Earth's gravity field..."
Brownian motion.
"so maybe it isn't so crazy to think you could take a balloon into space."
Archimedes' principle.
So, yes, it's quite crazy.
"'Think about it,' writes Madrigal. 'You've got a wire and you've got a magnet. Switch on the current - which you can't see and have no intuitive way to know exists - and suddenly the wire begins to rotate around the magnet."
You have no intuitive way to know current exists? My ass!
Turn on the current and then apply your fingers to the naked wire and then tell me there's no intuitive way to know if current is passing through!
"Don't forget this exact issue comes to security as well."
I don't.
"Seen the SLAs of most cloud providers when it comes to security?"
They work on my previous assumption too: offer as little as you can go with for as much money as you can go with. If the customer doesn't explicitly ask for security, the provider won't offer security.
Even if the customer asks for security, as long as the provider can go with customers that don't ask for it (and then, for a better profit margin), the provider will just ignore that customer and go for the lower hanging fruit (or even worse, they'll promise but never deliver).
And this doesn't even implies the provider being a devilesque bad guy or something like this. It is just an obvious "emerging property" on a system steamed by money that money will be the selective pressure.
"otherwise he would know that with volume licensing from Microsoft, the support is included"
Unless you pay extra, the only support that comes with volume licensing from Microsoft is:
1) Support on the volume license procedure itself
2) Telephone support -on office hours, about install issues
3) Everything else is subjected to further charges
Maybe I'm mistaken and there's adittional support for free under basic volume licensing agreements. Can you, please, point me where can I read about it from an official source? Or else I might think you are just trolling.
"who can give advanced support on Windows but Microsoft?", there is only about 10,000 certified support agencies in which you can get support"
Which one of them can trace back a Windows bug, find it, produce a correction and deliver to me a new version of the product with the bug corrected?
I can do that (and I've done that) for Red Hat.
"Dependencies in Linux are murder if you go off the beaten path."
You can't go off the beaten path with Windows, to start with.
Pretty packaged Linux programs vs pretty packaged Windows programs? Stalemate.
Linux programs not packaged to fit your distribution? problems ahead but doable.
Windows programs not packaged to be distributed? virtually impossible.
Linux programs distributed as source tarballs? problems ahead but doable.
Windows programs distributed as source tarballs? virtually impossible.
"Linux dependencies suck balls, I'll take Windows executables and dll hell over that any day."
Knock-knock! reality is calling.