10 Dos and Don'ts To Make Sysadmins' Lives Easier

Fuck you, you fucking command line Nazis! by Anonymous Coward · 2010-12-23 07:57 · Score: 0, Troll

Command line was used by Nazis to kill Jews, and is unconstitutional.

I, for one, welcome our new command line overlords.

In Soviet Russia, line commands you!

Obligatory xkcd

.

Re:Fuck you, you fucking command line Nazis! by The+Clockwork+Troll · 2010-12-23 08:16 · Score: 1, Troll

I think you misunderstood the term "Jew bashing".

--

There are no karma whores, only moderation johns
Re:Fuck you, you fucking command line Nazis! by Anonymous Coward · 2010-12-23 08:44 · Score: 0

Mel, is that you?
Re:Fuck you, you fucking command line Nazis! by r1_97 · 2010-12-23 09:56 · Score: 0

Looks like we've failed to take our meds today.

CHIMIT by Anonymous Coward · 2010-12-23 07:59 · Score: 0

Computer-Human Interaction for Management of Information Technology's

I hate every term in that series.

Re:CHIMIT by Nogami_Saeko · 2010-12-23 08:09 · Score: 1

I was sort of hoping it was going to spell CHIMP. Unfortunately it didn't. Pity.

--
"Nothing strengthens authority so much as silence." - Charles de Gaulle
Re:CHIMIT by Yvan256 · 2010-12-23 08:46 · Score: 1

Computer-Human Interaction for Management of Personnel?
Re:CHIMIT by mrawhimskell · 2010-12-23 09:38 · Score: 1

CHIMP - Computer Human Interaction for Management Professionals . There you have it!

1 Do for being a user by TheL0ser · 2010-12-23 08:00 · Score: 2

1. DO switch every don't to a do and do to a don't on that list. You are now a user.

Re:1 Do for being a user by Anonymous Coward · 2010-12-23 08:06 · Score: 0

You are the problem, not the solution. It *is not* your system. It exists solely for the use of "users".

And, dude, put down the Cheeto's and Dew, don't you think 210 is a bit heavy considering you're only 5'6"?
Re:1 Do for being a user by Monkeedude1212 · 2010-12-23 08:20 · Score: 1

This one made my chuckle:

7. DO tell us about security issues. Announce them publicly. Put them in an RSS feed. Tell us even if you don't have a fix yet; we need to manage risk. Your PR department doesn't understand this, and that's OK. It is your job to tell them to go away.
My CEO asks me to whip up a web page that users can use to submit who their phone provider is (we were all given options and not tied to 1 vendor. That has its pluses and minuses) and how long they have left on their contract so that he can get an assessment of where the phone situation is at for upgrading people's company phones. He wants this about 5 minutes ago.
I spent the trivial 1 minute it took to make sure my text boxes were SQL injection proof - but I haven't bothered doing any real data validation on each of them.
I've got a Try Catch around the data insert - if a user doesn't enter things in right it'll tell them to contact me... We'll see how well that goes.
I think I've made the trade-off of time/security plenty of times at this job. It's never really my decision though. I go for the Security through obscurity method here... If I'm the only one who knows how insecure this website is, no one in the company would try and break it, or so I hope.
Re:1 Do for being a user by epyT-R · 2010-12-23 08:54 · Score: 2

No.. the users are the ones who can't figure out how to use the system, that's why there's an admin.. if users knew what the fuck they were doing, we wouldn't NEED sysadmins in the first place.
Re:1 Do for being a user by houstonbofh · 2010-12-23 09:31 · Score: 0

Really? Can you rebuild an engine? Than give me your car.

User should not have to be mechanics. But mechanics should not need an extra elbow in the forearm just to change a spark plug.
Re:1 Do for being a user by jedidiah · 2010-12-23 09:49 · Score: 1

...except this isn't about "rebuilding an engine".
It's about DRIVING. You are operating on the false assumption that this is about how users can't be admins. No. They haven't even gotten that far. They can't even use the GUI that comes with the system. Nevermind anything any more advanced than that.
The average n00b computer user CAN'T EVEN DRIVE. Nevermind fixing the engine.

--
A Pirate and a Puritan look the same on a balance sheet.
Re:1 Do for being a user by apparently · 2010-12-23 09:52 · Score: 1

So in your world, this makes sense?
"DON'T include a clearly defined method to restore all user data, a single user's data, and individual items"
"DON'T instrument the system so that we can monitor more than just, "Is it up or down?""
"DON'T tell us about security issues." "DON'T use the built-in system logging mechanism"
Yeah, it sounds like you could do well with just one: "DON'T give advice: you clearly have no idea what in the hell you're talking about."
Re:1 Do for being a user by DragonWriter · 2010-12-23 09:54 · Score: 3, Insightful

No.. the users are the ones who can't figure out how to use the system, that's why there's an admin.. if users knew what the fuck they were doing, we wouldn't NEED sysadmins in the first place.
If the system was designed properly for the userbase, so that users could use the system, you'd still need sysadmins to administer the system, which is notionally what sysadmins are for (hence the name.)
You wouldn't need sysadmins to take breaks from administering the system to handhold users through basic usage tasks, but then, that's not really the point of a system adminstrator in the first place.
Re:1 Do for being a user by skarphace · 2010-12-23 11:19 · Score: 4, Interesting

I wonder if there are forums on the Web where plumbers shit all over eachother.

--
Bullish Machine Tzar
Re:1 Do for being a user by darealpat · 2010-12-23 11:59 · Score: 1

Some users are also sysadmins or tech support...like me. IMHO all "power users" would highly appreciate that list, and the insight provided by the comments following in the original article.
L0ser, you are seriously trolling....

--
For every present, there is a past
Re:1 Do for being a user by Fulcrum+of+Evil · 2010-12-23 12:11 · Score: 1

If the system was designed properly for the userbase, so that users could use the system
You don't get it - these aren't retarded people - if they made an effort, most of them could use the system successfully, but they either view the system as hostile or else are proud of their ignorance, so they don't even try.

--
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Re:1 Do for being a user by jombeewoof · 2010-12-23 13:24 · Score: 4, Insightful

I disagree,
take any person of reasonable intelligence and place them in an unfamiliar settting. They become retarded.
The fact that they have been in front of that unfamiliar device for 20 years means they just don't care.
Give me a user who cares to familiarize them-self with the system and 6 months, I'll give you a half decent sysadmin. At least better than half of the paper certified MCSE's I've had the pleasure to work with.

--
Linux Zealots: Smarter than Mac Zealots, but still zealots.
Re:1 Do for being a user by asticia · 2010-12-23 14:21 · Score: 1

There is a myth about computer being magic device that amplifies stupidity and causes normal intelligent people loosing common sense when they sit in front of it. True fact!

--
There is no light without darkness.
Re:1 Do for being a user by twidarkling · 2010-12-23 17:17 · Score: 1

I think plumbers get enough literal shit that they probably don't bother in forums.

--
Canada: The US's more awesome sibling.
Re:1 Do for being a user by vegiVamp · 2010-12-23 22:11 · Score: 1

I dunno. Do plumbers have a dozen different, mutually-incompatible types of pipe; are all of them convinced that the one they are using is the one holy system and that all the others are idiots for not understanding why ?

--
What a depressingly stupid machine.
Re:1 Do for being a user by wesleyjconnor · 2010-12-23 22:53 · Score: 1

comedy gold :)

--
http://www.awfullybigmoustache.com
Re:1 Do for being a user by telekon · 2010-12-24 02:23 · Score: 1

You are the problem, not the solution. It *is not* your system. It exists solely for the use of "users".

Except that, it Is *my* system, or at least, my employer's. IT decides who gets to use it, what their privileges will be, when to grant and revoke access... That's the problem, users who think the systems they access belong to them. In any sort of enterprise environment (i.e., one where there exists such a thing as a sysadmin), the system exists solely for business reasons, some of which include/require access by end-users. But that's an unfortunate coincidence, which we do our best day-in and day-out to minimize.
You're welcome.

--
To understand recursion, you must first understand recursion.
Re:1 Do for being a user by calskin · 2010-12-24 04:46 · Score: 1

There is a myth about computer being magic device
Could anyone really use a computer without the power of Thor?
Re:1 Do for being a user by damaged_sectors · 2010-12-24 18:51 · Score: 1

I disagree,
take any person of reasonable intelligence
Clearly you have reversed the meaning of intelligence
See wikipedia for a list of definitions - all of which can be summarized as a "measure of understanding and ability to adapt. Stupid and/or lazy are *not* forms of intelligence.
Feel free to make hay with "reasonable"...
Re:1 Do for being a user by Derling+Whirvish · 2010-12-25 07:29 · Score: 1

I wonder if there are forums on the Web where plumbers shit all over eachother.
Gosh, how would one go about finding that ... http://tinyurl.com/32xmf94

i am impressed by digitalsushi · 2010-12-23 08:01 · Score: 5, Funny

10 is an even number. There's no duplicates. None of them are filler.

I don't understand how this happened.

Did someone plan this before they wrote it? What gives?

--
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue

Re:i am impressed by mcgrew · 2010-12-23 08:06 · Score: 3, Insightful

Not only that, but I'd say almost all of them don't just apply to making admins of large networks' jobs easier, but to ALL software development for any computer use.
#11: NO DRM, dammit!

--
Free Martian Whores!
Re:i am impressed by Anonymous Coward · 2010-12-23 08:18 · Score: 1

10 is an even number. There's no duplicates. None of them are filler.
I don't understand how this happened.
Did someone plan this before they wrote it? What gives?
This is your one Christmas present from Slashdot. It's the one story this year where the editors did their job.
Which, of course, means it will be duplicated three or four times in the next week.
Re:i am impressed by Anonymous Coward · 2010-12-23 08:26 · Score: 0

Ah, the gift that keeps on giving.
Re:i am impressed by kimvette · 2010-12-23 08:31 · Score: 3, Funny

No slashdot editors were involved in the production of the list. ;)

--
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Re:i am impressed by fuzzyfuzzyfungus · 2010-12-23 09:00 · Score: 5, Funny

There is a special place in hell for vendors who sell bulk licenses(50+ seats) for software whose DRM prevents automated installation, and requires that the IT office's picker of the short straw go around and type in a gigantic license key on all machines.

If a hole has to be punched in the firewall for the online activation/authentication step; because they were just too damn special to use SSL on a standard port like everybody else, that special place in hell is filled with screwworms.

If there is a hardware dongle component(that looks exactly like a USB flash drive, and thus wanders accidentally if not carefully hidden) and requires a new purchase order and a nasty pile of cash to replace, that special place in hell automatically inserts bullet ants into the scrotum of anybody placed there.
Re:i am impressed by JerseyTom · 2010-12-23 10:02 · Score: 2

I had 15 items and picked the 10 best.
Re:i am impressed by nine-times · 2010-12-23 10:18 · Score: 1

#11: NO DRM, dammit!
God, I really don't know how developers get away with "activation". I have had so many fricken problems with activation over the years that I basically won't buy or install software that requires it. So first, right there, it's costing sales. Of course I can't say for sure that it costs more sales than it creates, but I can tell you anecdotally that multiple companies have lost sales to me because of their activation policies.
Second, in a strange way it's actually encouraged piracy to some degree. At my last company, I had a bunch of programs that required activation and were really finicky about deactivation and activation on a new computer. Uninstalling from one computer and reinstalling on another usually required a 45 minute phonecall to the developer. Worse, with one of the applications, the developer refused to support that version of the software anymore. If we wanted to move the licenses, we'd have to spend hundreds of dollars to upgrade to the most recent version, which also required updating other expensive software (it was a plugin).
Luckily, most of the software that required activation didn't do a good job of detecting when you moved the hard drive into a new machine. Since I couldn't uninstall or reinstall that software when I needed to, my solution was to create a single image with the remaining activations that I had, and then use that image as a standard desktop image. So yeah, I had a bunch more installs than I had licenses. I wouldn't have done it if not for the activation scheme, and I don't think it mattered (morally) since we always had fewer people using the software than we owned licenses for it.
So yeah, I totally agree with your #11, but I would probably put it at #1. No software activation.
Re:i am impressed by man_of_mr_e · 2010-12-23 11:48 · Score: 1

I don't get it. I read stories like yours all the time. People complaining about activation and DRM.
I've never had a single issue with DRM or activation of any product. Ever. And i've dealt with hundreds of users needing products activated across dozens of hardware platforms. I've *heard* lots of stories, but never actually seen any of them personally.
Makes you wonder...

--
If you need web hosting, you could do worse than here
Re:i am impressed by Anonymous+Brave+Guy · 2010-12-23 12:17 · Score: 1

Most expensive commercial software gets activation right most of the time these days. If it didn't, it wouldn't sell. The trouble is, if you are the guy in the unlucky X% who are doing something perfectly legitimate that the DRM/activation code happens not to like, you can still have a really bad day even though most people don't even notice.
As for less expensive consumer software like games, if you've never had a problem with activation or DRM then either you've been amazingly lucky or you just don't play a lot of recent high-end titles. I've got so bored of the bugs and invasive software and games that want me to turn off various security programs I run as standard (because that's going to happen) that I hardly buy AAA titles at all myself these days, and looking at the Assassin's Creed II fiasco I can't say I'm sad about it.

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:i am impressed by tepples · 2010-12-23 12:21 · Score: 1

I have had so many fricken problems with activation over the years that I basically won't buy or install software that requires it.
Including Windows? What operating system do you choose on your PCs?
Re:i am impressed by dbIII · 2010-12-23 12:40 · Score: 2

Extra points if the USB dongle needs 16bit software that needs both command line switches and a GUI to update licences, but at least it's still possible to run while there are 32bit versions of XP still around. Then there was Macrovision's Y2K bug in flexnet in 2008 which thought permanent licences expired in 2000.
Dongles and the crapware surrounding them are only there to punish the innocent.
Re:i am impressed by dakohli · 2010-12-23 12:49 · Score: 1

I used to administer a system that was segregated. There was no connection to the internet. A couple of times we had to really jump through hoops to get software that was paid for up and running. Hour long phone calls, cut and pasting activation codes into emails on an online computer. It was often messy. In fact, we started to carefully consider the software we were buying in order to make life easier. We only had 2 sys admins, a couple of times it took as a week to get software running. Recently, I bought a game that needed a connection every time it was played. It was so cumbersome, I don't play it any more. I understand why companies invest in DRM/licensing schemes. For some systems, it's not worth the hassle. (My 2 cents)
Re:i am impressed by dbIII · 2010-12-23 13:23 · Score: 1

I get about three or four such issues per year. The classic that should never, ever have happened was a Y2K bug in 2008 with flexnet from Macrovision that decided all of our permanent licences for a product on MS Windows had expired in 2000! Their abandonware, flexlm, is still used on *nix for a few things and it seems that even with a working version of the licence manager every second new licence we get just does not work and must be redone by the software vendor. Then there are the USB "security" dongles that mysteriously die despite never being moved and we need to wait a week for a new one to be shipped.
It's not just Macrovision and their frequently crashing licence software designed to punish the innocent, there are many other vendors of dodgy USB "security" dongles that create problems or prevent us deploying a Windows7 compatible application on Windows7 because there is no "security" dongle driver yet. You probably have just been lucky enough to use software from vendors that have not been ripped off by the likes of Macrovision so have not encountered such problems.
Re:i am impressed by mlts · 2010-12-23 14:05 · Score: 3

To elaborate on #11:
#11: No DRM. The BSA would turn any company inside out and have their entrails for Christmas lights if they are caught pirating even a single copy of WinRAR. Businesses who value being open are not going to be pirating anyway. So why add DRM which removes value from the product?
#12: Ability to rebuild the product if it gets corrupted. Have it as an option to have the .cab/.bz2/RPM/.deb/etc. file stored in a directory, including patches. This way, if there is concern about registry/NetInfo/ODM/whatever corruption, it shouldn't be hard to have the product reinstall itself.
#13: An uninstaller. Shit happens and crap gets in a half installed state. It would be great to be able to have a utility that completely removes any and all traces of a program, move aside/archive config files, and rename the config directories. This way, if a config document is causing problems, it is out of the path.
#14: Ability to send reports to a third location, via E-mail or whatnot. This way, either by system logs or E-mail, there is proof that a package was installed or maintained, and not just the install mechanism; but from the application itself.
#15: Ability to install as a non-administrative user if the functionality is relevant (this wouldn't be doable for system utilities, but a Web browser, yes.)
#16: Ability to have a way to completely block installs of the product.
#17: All executables are signed. Not just with the OS signing mechanism, but either with a manifest, or PGP/gpg detached signatures.
#18: A "master console" program that can check for updates, store them, check installed clients if the update is needed, push out updates (either by a program or through the OS's install mechanism), perhaps even allow for removal en masse.
I just wish more operating systems had not just an install mechanism (msiexec, rpm), but an update mechanism from repos (yum, macports). This would make life a lot easier, especially if it can be configured from custom repositories so enterprises can have their own mirrors.
Re:i am impressed by man_of_mr_e · 2010-12-23 14:32 · Score: 1

I simply call that crappy software. You have the same problem with abandonware software that doesn't work on new versions of OS's.
Macrovision is perhaps a bit of an exception, they pioneered the rootkit and other methods of copy protection. Not sure i'd call them either Activation or DRM, just crappy old copy protection techniques.

--
If you need web hosting, you could do worse than here
Re:i am impressed by man_of_mr_e · 2010-12-23 14:38 · Score: 1

You have an exception environment. It's hard to get software updates, install software, and even use it in such environments in many situations.
If you choose to have such an environment, you should also realize that you're fighting upstream against the way all software is designed these days, and simply realize you have to deal with problems because of that.
If you choose to use a laptop computer on an archelogical dig in the middle of the sahara, you have to be prepared to deal with the issues that will bring. Not complain that every laptop isn't made to support using it in such an environment.

--
If you need web hosting, you could do worse than here
Re:i am impressed by Anonymous Coward · 2010-12-23 14:47 · Score: 0

There is a special place also for sysadmins/netadmins who block outbound connections to high ports, insisting on completely inappropriate use of HTTPS for what should be stateful connections. Re-implementing TCP over HTTPS is no fun and very slow.
Re:i am impressed by dakohli · 2010-12-23 14:50 · Score: 1

I agree it was an exceptional situation. However, it was not by choice. The security requirements were imposed on us by a higher level.
Today, I would set up a server to conduct the patching automatically once the patches were tested.
Back then, we even had to download virus defs and burn them on to a cd to bring them in.
Now, I do have issues with any software that is required to connect to the net in order to run. I think that is unreasonable. Once registered, software should be able to run in isolation.
Re:i am impressed by dbIII · 2010-12-23 14:55 · Score: 1

The entire concept of DRM is a layer of often crappy software that sometimes gets abandoned once it is written between you and the software you have paid for. You are not the client when such software stuffs up so support is very slow and two steps removed if it exists at all. What you consider urgent and what the vendor considers a potential loss of a lot of future sales just sits in a queue until a week later (real example) it hits a guy that sends an email back that says (genuine quote) "what is a Y2K bug?".
It puts software furthur and furthur out of your control to the point where not even your vendor can be sure that you can get it going again with something as simple as a change of hardware. It means you cannot always get what you paid for when the vendor agrees because you have to wait for a fairly disinterested third party. With anything remotely time critical (notice my example had a week before the first reply) it is a barrier that could potentially result in the loss of a lot of revenue and a reputation of delivering on time - thus it makes people angry. It is typically only there to punish the honest.
Re:i am impressed by RaymondKurzweil · 2010-12-23 15:39 · Score: 1

Be happy you've never encountered an actual problem with DRM and copy protection systems and enjoy feeling smugly superior to all of us incompetents telling stories. And you can also go fuck yourself while you're at it, douche bag.
Re:i am impressed by IchBinEinPenguin · 2010-12-23 18:27 · Score: 1

... that special place in hell automatically inserts bullet ants into the scrotum of anybody placed there.

What happens in the special place in hell reserved for people who perpetuate the stereotype that all IT workers have scrotums?
Re:i am impressed by sjames · 2010-12-23 20:36 · Score: 1

Alternate on 15, do NOT refuse to run until last night's minor patches are installed, the person running the software is not an administrator and cannot do the update. I'm looking at YOU Quickbooks!
#19: allow more than one version of the software to coexist on the system.Sometimes the latest isn't the greatest. For mission critical software, the admin will want to keep the devil he knows working until the new version proves itself at least.
Re:i am impressed by Ash+Vince · 2010-12-24 00:35 · Score: 1

#11: NO DRM, dammit!
Actually, a working DRM solution that only prevented unauthorised installs from functioning but was otherwise completely invisible would be no problem at all. It is only when they screw up that they become insufferable.
As an example the old hardware dongle solution was not too bad. If windows died and needed a complete re-install, no problem. If the PC itself died then you just move it to another PC.
With USB keys now becoming so cheap maybe this is a pretty good solution, just include a Kensington security slot so we can lock the device to the PC in question. Vendor gets piece of mind, we get to not pay extra for freeloaders using the software while we pay full price.
Some people might say what happens if the PC gets thrown away inadvertently, but if this happens without it going via the system admin then you have a problem with the harddisks not being destroyed correctly anyway. All PC's should be deployed by the system admins and then retired by them as well going through a well defined process at both ends depending on data and software stored on the PC.
I seem to remember your UserID though so we have probably had this debate on slashdot before regarding DRM :)

--
I dont read /. to RTFA, I read /. to offend people in ignorance.
Re:i am impressed by nine-times · 2010-12-24 02:23 · Score: 1

My network at work is mostly Windows machines (a couple Macs and a couple Linux machines). I use Windows XP volume licensing. I won't be upgrading because of activation. Like I said, anecdotally, it's costing some sales.
Re:i am impressed by nine-times · 2010-12-24 02:46 · Score: 1

It depends on the software you're using. I've had problems with major software packages Windows or Adobe Creative Suite, but they're usually more rare and they're usually resolved more easily. Where I've seen more problems is in more specialty professional software. You know, the sort of stuff that you'd never use if you weren't a professional engineer doing something a consumer wouldn't do. That stuff is the worst.
But yeah, I've had problems with major software packages. Part of the problem is that I've always treated systems like they were interchangeable. If someone's computer is having problems, I'll yank the hard drive and put it into another system; if the hardware is different, I'll install the drivers. Obviously this is going to run afoul of activation sometimes. I also make heavy use of imaging.
Yeah, you can say, "Well don't do that! Or if you're going to do that, you can make a bunch of adjustments that will make it less likely to set off the DRM..." Really, though, it shouldn't be a problem. More specifically, I don't think it should be *my* problem, since it's not a problem without "activation".
As a result, I've stuck with Windows XP and Adobe CS2, and I'm going to continue staying with those versions. I would upgrade to the latest versions of each of these programs if I didn't fear activation complications.
Re:i am impressed by man_of_mr_e · 2010-12-24 06:17 · Score: 1

I'd feel special that you took the time to get so pissed off over what I wrote, but perusing your posting history shows you are pretty much a douche bag to everyone...
Which just makes your anger so everyday and commonplace. Good luck with that.

--
If you need web hosting, you could do worse than here
Re:i am impressed by eriqk · 2010-12-24 06:39 · Score: 1

When you're in that special place in hell, you have a scrotum, whether you're a man, woman or eunuch.
Re:i am impressed by damaged_sectors · 2010-12-24 18:59 · Score: 1

I just wish more operating systems had not just an install mechanism (msiexec, rpm), but an update mechanism from repos (yum, macports). This would make life a lot easier, especially if it can be configured from custom repositories so enterprises can have their own mirrors.
You missed one... .deb
And, I agree with all except #15 - that's what privilege escalation is for.
Re:i am impressed by damaged_sectors · 2010-12-24 19:09 · Score: 1

I don't get it. I read stories like yours all the time. People complaining about activation and DRM.
I've never had a single issue with DRM or activation of any product. Ever. And i've dealt with hundreds of users needing products activated across dozens of hardware platforms. I've *heard* lots of stories, but never actually seen any of them personally.
Makes you wonder...
Makes me wonder too.... if you only deal with single users, on single machines, in take your time environments. Try that with Adobe multi-license, SAP, Oracle, Quickbooks, MYOB, etc, etc, et-fucking-cetera (sigh).in mission-critical government environments.
But then you did say "hundreds" - which is something I (and many other admins) deal with before my morning coffee. In mitigation - perhaps you've had the luxury of having only one version of a particular piece of DRMed software installed at a time
Just don't get me started on dongles for six figure must-have hardware that isn't supported (and won't be) on the version of OS forced on me by non-IT "decision" makers.
Re:i am impressed by mcgrew · 2010-12-27 03:43 · Score: 1

you should also realize that you're fighting upstream against the way all software is designed these days
Not in the FOSS world. IMO FOSS's biggest strength is no DRM and no activation.

--
Free Martian Whores!
Re:i am impressed by mcgrew · 2010-12-27 04:21 · Score: 1

I remember a rant someone had on the internet a dozen or so years ago about dongles. This poor sap had one paralell port with seven dongle hanging off of it.
And yes, I do believe we've had this discussion before.

--
Free Martian Whores!
Re:i am impressed by Geminii · 2010-12-28 08:27 · Score: 1

"Do not require that a system need more resources to install the product than to run it." Particularly obnoxious for utilities which can run entirely in the background but require a minimum video resolution to install - or a screen at all.
"Do not require that a system have external access in order to install software." A DVD or downloadable installer should contain all the files needed to install and configure the software. Don't use a 50K installer which then pulls down 20G of "updates" before the software even runs for the first time.

fucking apostrophes, how do they work? by jollyreaper · 2010-12-23 08:04 · Score: 1

nt

--
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne

Re:fucking apostrophes, how do they work? by Anonymous Coward · 2010-12-23 08:09 · Score: 3, Funny

"sysadmins' lives" is correct. It is referring to the lives of sysadmins.
Unless, of course, you are referring to the sexual practices of punctuation marks. Then, I don't know.
Re:fucking apostrophes, how do they work? by Anonymous Coward · 2010-12-23 08:09 · Score: 0

fucking apostrophe's, how do they work?
Re:fucking apostrophes, how do they work? by pantheonwhaley · 2010-12-23 08:11 · Score: 1

I don't know, how do fucking apostrophes work? I'm a descriptivist. I don't judge either way. I like your way better but that doesn't make you right any more than me liking communism makes Marx right.
Re:fucking apostrophes, how do they work? by Monkeedude1212 · 2010-12-23 08:29 · Score: 1

When you're already in double quotes you use single quotes for any quotes they used.
"Then Jim said, 'Hi', and that made Sally smile".
The more you know!
*didlidlido duuum!*
Re:fucking apostrophes, how do they work? by blind+monkey+3 · 2010-12-23 08:35 · Score: 5, Funny

I thought they just followed Jesus around.......

--
BM3
Re:fucking apostrophes, how do they work? by Millennium · 2010-12-23 08:46 · Score: 1

Quite well, actually. And at least in the title of this article, they're even used correctly.
Re:fucking apostrophes, how do they work? by enjerth · 2010-12-23 09:01 · Score: 1

Well, there's 4 cups in a quote, and 4 quotes in a gallon. If that's too complicated, we can just get rid of the quote and count 16 (10 hexadecimal) cups in a gallon.
Re:fucking apostrophes, how do they work? by daremonai · 2010-12-23 09:22 · Score: 5, Funny

"sysadmins' lives" is correct. It is referring to the lives of sysadmins.
No, I'm sorry, it is not correct. Sysadmins don't have lives.
Re:fucking apostrophes, how do they work? by Anonymous Coward · 2010-12-23 09:52 · Score: 0

So you are saying 16 cups, 1 gal.
Re:fucking apostrophes, how do they work? by Anonymous Coward · 2010-12-23 13:28 · Score: 0

So there's only ever 12?

The mere existence of an API? by a+Flatbed+Darkly · 2010-12-23 08:07 · Score: 1

I agree with most of these; however, I'd revise #3 to refer to "a substantial API" and not the minimal, in terms of usefulness execrable, deposits of code provided by some software.

Re:The mere existence of an API? by Anonymous Coward · 2010-12-23 08:36 · Score: 0

I'll take simple and well documented, substantial is just a nice bonus, but good documentation is a must.

DO NOT by Anonymous Coward · 2010-12-23 08:08 · Score: 1

DO NOT be a sysadmin

Re:DO NOT by noc007 · 2010-12-23 10:07 · Score: 1

I wish I got this memo when I was deciding my career path at a young age. So many small-medium sized companies out there want a Sys Admin to administrate everything from systems to facilities, including the occasional furniture move, and only pay $40k-$50. A lot of hats to wear with the expectation of being able to handle anything new, keeping everything running, and keep one's cool during crisis management. Trying to make a career out of one of those roles, like e-mail administration, only makes sense if it's going to be for a large company and still won't get much more compensation.
I should have gotten into programing and DB administration; much more profitable and in demand. Yes I could learn to do that type of work now, but it would have been much easier when I was a teenager. Making the time now to do more than just brief reading and dabbling is difficult. I know I haven't marketed my self as well as I could. Perhaps I should find something that pays better and focus in on that or maybe just get into management.

Summarizing by billcopc · 2010-12-23 08:08 · Score: 1

In essence, all 10 items on the list say "Use Linux!"

Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P

--
-Billco, Fnarg.com

Re:Summarizing by Anonymous Coward · 2010-12-23 08:19 · Score: 2, Insightful

In essence, all 10 items on the list say "Use Linux!"
Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P
Not really. The same problems exist in Linux -- authentication, logging, putting files in random folders (/var, /etc).
Re:Summarizing by causality · 2010-12-23 09:55 · Score: 1

In essence, all 10 items on the list say "Use Linux!"
Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P
Not really. The same problems exist in Linux -- authentication, logging, putting files in random folders (/var, /etc).
The difference with Linux is that if you don't like it, you stand a decent chance of actually being able to do something about it.

Obviously that's sub-optimal. It would be better for vendors to soundly design their software in the first place. Still, open (in the sense of "transparent") systems make it much easier to actually mitigate such nuisances.

--
It is a miracle that curiosity survives formal education. - Einstein
Re:Summarizing by JWSmythe · 2010-12-23 14:26 · Score: 1

You know, that's one of the points I evaluate when looking for a new distribution. Do they follow some sort of standards that will play nicely with others. My biggest beef is when you compare the distro's documentation with the author's documentation, and find a huge discrepancy. If the authors documentation clearly states /etc/[package] for configuration, /var/[package] for the data, and /var/log/[package].log for the log, it should be that way. I'm just stunned with some of the systems I've worked on. Lets use Apache as an example. httpd.conf. Pretty easy idea. It resides where?
1)Path: "/usr/local/apache2/conf/httpd.conf"
Apache (2.0 and 2.2) (official)
FreeBSD 6.1 (sometimes)
2)Path: "/etc/apache2/apache2.conf"
Debian and Ubuntu
OSX Leopard
OpenSUSE
SLES
3)Path: "/etc/httpd/conf/httpd.conf" with pieces in "/etc/httpd/conf.d"
Fedora, RHEL, and CentOS
Redhat (up to version 9), and Menervia
4)Path: "/usr/pkg/etc/httpd/httpd.conf"
NetBSD
5)Path "/usr/local/etc/apache22/httpd.conf"
FreeBSD 6.1 (sometimes)
6)Path: "C:/Program Files/Apache Software Foundation/Apache2.2/conf/httpd.conf"
Windows
7)Path: "/etc/apache2/httpd.conf"
Solaris 10
Gentoo
8)"/etc/httpd/httpd.conf"
Slackware 12 and newer
8 different places, with at least 2 different names. As I recall, Redhat actually used quite a few different paths over the years. That was a blast working for a place with virtually every version of Redhat released in the last 10 years. Their idea of standardization was "do exactly what the distro said, don't make any changes" Of course, that meant I'd find 3 or 4 different httpd.conf files with strange timestamps, because people before me had gone in, tried to make a change, found it didn't work in that file, and kept moving on until they found the right file. It may have been easier to look at the startup file, except nothing was to start automatically, you were only to reference the manual procedure document in the event of a system reboot. The manual was never right.
On various machines people have asked me to work on, when they ask "Can you fix this in the web server", I hop on, and run "locate httpd.conf && locate apache.conf", just to see how many targets I'll have. A lot of them aren't just distributions, but variances of distributions for specific tasks. Sometimes it's obvious. Sometimes I'll spend 15 minutes trying to find the right one. And no, a lot of time common tools like lsof don't help because they aren't installed, and there's no easy way to get it there.
My own system, on networks I'm in control of, has been a lot easier. Like you said, if we don't like it, we can change it. I do the same, regardless of the platform (with a subtle variation for Windows machines). /[something]/ holds all important server files. /[something]/httpd/conf/httpd.conf is where Apache's config lives. /[something]/httpd/bin/httpd is where the binary lives. /[something]/dns/conf/ is where named's configurations live. Symbolic links for "known" locations all point back to this tree. It's a lot easier to back up /[something]/ than to back up all the crap that is lying around in the various other trees. Migration between servers or platforms becomes almost trivial. Automation scripting becomes simplistic.
That's not to say Windows is any better. /etc/hosts is actually c:\windows\system32\drivers\etc\hosts . Very intuitive. The IIS equivalent of httpd.conf? ha. How about /etc/rc.d/rc.local? A dozen or so registry locations, the system servi

--
Serious? Seriousness is well above my pay grade.
Re:Summarizing by Anonymous Coward · 2010-12-24 04:56 · Score: 0

You really think /etc is a random folder?

Holy crap, a slashdot first by subreality · 2010-12-23 08:09 · Score: 4, Interesting

It's a top-10 list that actually has insightful information on how to do software right, instead of being a random collection of ten things to make a fluff article. Bonus points for being things that I actually agree with.

Re:Holy crap, a slashdot first by _Shad0w_ · 2010-12-23 19:53 · Score: 1

Well it was published by the ACM...

--
Yeah, I had a sig once; I got bored of it.

The Practice of System and Network Administration by XanC · 2010-12-23 08:10 · Score: 5, Informative

The article author is also behind The Practice of System and Network Administration, truly an excellent text into the practicalities of work in IT.

Ten??? I read that as Two! by Anonymous Coward · 2010-12-23 08:13 · Score: 0

(blush)

#11: Meaningful error messages by eln · 2010-12-23 08:14 · Score: 5, Funny

If you want to make a sysadmin's life easier (as if any programmer ever wants to do that), you can start by making your error and status messages 1.) plentiful and 2.) easy to understand. Also, provide several logging levels so we can drill down as needed, and make sure the logging levels are meaningful. Too many programmers put just two log levels: one which shows nothing useful, and another that spews out indecipherable hex dumps of every call it makes.

Face up to the fact that no matter how awesome your software is, it's going to fail. Not only that, but it's going to fail in ways you never thought possible at the worst possible times. Make sure we have enough information to figure out what happened. Otherwise, stuff like this happens:

Program: *crash for no apparent reason*
Sysadmin: Why did you crash?
Program: Because something went wrong.
Sysadmin: What went wrong?
Program: Something.
Sysadmin: I need more detail. Increasing log level.
Program: Something bad went wrong.
Sysadmin: I need more than that. Increasing log level again.
Program: Fuck you. Here's a 16GB hex dump of system memory. Figure it out yourself jackass.
Sysadmin: *picks up a crowbar and goes off to find the programmer*

Re:#11: Meaningful error messages by Anonymous Coward · 2010-12-23 08:22 · Score: 0

I'm imagining the sound of a Half-Life crowbar beating on headcrab zombies right now.
Re:#11: Meaningful error messages by Psyko · 2010-12-23 08:33 · Score: 1

too true.
Years back I remember a symantec app on windows that would pop up a dialogue box when it was trying to shut down that just said:
Should not see this.
with a big red X on the left and a cancel button on it. I had a screenshot of it somewhere, it was my favorite error message to date. I was always thinking ok... you took the time to have it pop a box with that message in it, but couldn't actually put any useful info in it?

--
01:36AM up 426 days, 2:46, 1 user, load average: 0.14, 0.11, 0.05
Re:#11: Meaningful error messages by Monkeedude1212 · 2010-12-23 08:36 · Score: 5, Insightful

That reminds me of a Web Developer I once knew.
He said he didn't bother putting try/catches around certain standard things (Like Database connection opening, closing, transactions, etc) - because if anything ever went wrong it was easier for the user to take a screenshot of the Stack Trace if and when it went wrong from the Webapp. Said it took too much time to build in proper exception handling and error messages.
He said that the user experience basically means nothing if your application doesn't work, so when something doesn't work, don't bother making it pretty.
He no longer works here, though I can't imagine why.
Re:#11: Meaningful error messages by mehrotra.akash · 2010-12-23 08:38 · Score: 1

i had ubuntu give me a
"This should not have happened"
message recently
Re:#11: Meaningful error messages by jimicus · 2010-12-23 08:38 · Score: 1

Seems to be far worse for Windows applications than Unix ones, and worse for commercial rather than F/OSS applications.
I've no idea why this is, but I swear to God that Windows developers have no concept of logging. It really makes me wonder how the hell they debug the application - debuggers only ever go so far.
Re:#11: Meaningful error messages by Monkeedude1212 · 2010-12-23 08:42 · Score: 1

Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?
Re:#11: Meaningful error messages by frank_adrian314159 · 2010-12-23 08:44 · Score: 2

as if any programmer ever wants to do that
Got that right!
Face up to the fact that no matter how awesome your software is, it's going to fail.
As any good programmer knows, failure is not an option. If software fails it is because of misuse, foreign (read "anyone who isn't me") programming staff, or failure to RTFM. Please do not bother us with your petty problems and See Figure 1. Understand this and your life as an admin will be forever simpler.
XOX,
Your most awesome programming staff

--
That is all.
Re:#11: Meaningful error messages by Anonymous Coward · 2010-12-23 08:46 · Score: 0

Meaningful error messages mean you might figure out how to solve the problem yourself, and then you wouldn't need an expensive, annually-renewed, convoluted, "platinum" support contract.
Re:#11: Meaningful error messages by martin-boundary · 2010-12-23 08:47 · Score: 1

You thought wrong. This was most likely scaffolding (for himself) that he put up while looking for a bug, and that a he forgot to take out afterwards. Since he didn't take it out, that probably means he never found or fixed the bug he was looking for. BTW, the effort involved in putting up one of these messages is very low, it's much much lower than building a proper logging facility from scratch.
Re:#11: Meaningful error messages by blind+monkey+3 · 2010-12-23 08:55 · Score: 1

*picks up a crowbar and goes off to find the programmer*
KY gel in the other hand? Easier access to logs.

--
BM3
Re:#11: Meaningful error messages by mewsenews · 2010-12-23 09:03 · Score: 1

God I love slashdot sometimes
Re:#11: Meaningful error messages by GMFTatsujin · 2010-12-23 09:22 · Score: 1

At last, we know why Gordon Freeman was so handy with the crowbar... AND the most solid clue yet as to why Black Mesa went blooey!
Thank you, sir! You've done us a great service!
Re:#11: Meaningful error messages by jimicus · 2010-12-23 09:24 · Score: 1

IME you're doing well if you get that.
There's at least a few apps I would like nothing better to get to speak to the dev team leader and ask them why, on FSM's sweet earth, they decided to do that. Was some deranged PHB involved or is there some sort of requirement that nobody can be hired to develop for Windows unless they point-blank refuse to log a single damn thing?
Re:#11: Meaningful error messages by UncleTogie · 2010-12-23 09:36 · Score: 2

Meaningful error messages mean you might figure out how to solve the problem yourself, and then you wouldn't need an expensive, annually-renewed, convoluted, "platinum" support contract.
Managed to get a client away from just this sort of jackassery. It was a DOS-based medical practice app that was buggy as hell. Their solution: Package bug-fixes as "upgrades" and charge for 'em. I was disgusted.

--
Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
Re:#11: Meaningful error messages by Jaime2 · 2010-12-23 09:36 · Score: 3, Interesting

Of course, good error handling is best. But, no error handling is usually better than cargo-cult error handling that displays a pretty message, but doesn't record the error detail anywhere. Very few things bother me more in a code review than somebody who put in the extra effort to ensure that an error message can never be found, I would have rather they simply skipped it.
Re:#11: Meaningful error messages by noidentity · 2010-12-23 09:41 · Score: 1
You joke, but most programmers I encounter think that acceptable error handling is one of the following, in order of preference:
1. Pretend errors can't happen. Even when code isn't working right, do not put any error checking in.
2. Check for errors, but simply exit program when one occurs, without telling user of that fact.
3. Check for errors, and when one occurs, exit program and print "error occurred". Throughout program, return boolean success/failure from routines.
4. Check for errors, and actually tell user the cause, for example: out of memory, disk full, disk error, network error, corrupt file, wrong version, unsupported file format. This way the user can actually have some idea of how to solve the problem before he tries again.
Re:#11: Meaningful error messages by YrWrstNtmr · 2010-12-23 09:41 · Score: 1

"Windows has found unknown hardware and is installing the software for it."

wait...what? If you don't know what it is, what SW are you installing?
Re:#11: Meaningful error messages by pclminion · 2010-12-23 09:54 · Score: 1

I actually ascribe to your colleague's view. You really need to do your best to anticipate and handle all REALISTICALLY POSSIBLE error scenarios. But if something unimaginable happens, you probably do NOT want to:
A) Sweep it under the rug so that the user, and you, never even know it happened
B) Try to recover, i.e. perform complex tasks, while state is corrupted in unknown ways
Really, the important idea is to make sure the user knows something REALLY bad happened, and give the user enough information to report back to you, so that you have a chance in hell of figuring it out. This DOESN'T mean you need to display a raw call stack to the user. But a dialog which pops and allows the user to send a crash report via email isn't a bad idea. If you just log it and continue, the user will probably never know anything went wrong, and your application might end up doing more damage in its attempts to recover than by simply aborting. If an insane person came into your house and re-arranged and broke all your stuff, would you trust the same person to fix it?
Having said that, your friend seems to have misunderstood this idea and applied it to situations where it shouldn't apply -- you can realistically expect that sometimes a database won't get opened correctly, or a file open operation fails, etc. But if you're hitting problems like using a null reference in a place where the reference can't possibly be null, that's really a serious logical flaw in your code and you really do need as much detail as possible to find it and fix it.
Re:#11: Meaningful error messages by causality · 2010-12-23 09:58 · Score: 1

You thought wrong. This was most likely scaffolding (for himself) that he put up while looking for a bug, and that a he forgot to take out afterwards. Since he didn't take it out, that probably means he never found or fixed the bug he was looking for. BTW, the effort involved in putting up one of these messages is very low, it's much much lower than building a proper logging facility from scratch.
But why would you ever have to build a proper logging facility from scratch when there are several good, open, mature implementations ready for you to use? Oh, right, it was a Symantec app on Windows he was talking about. Nevermind.

--
It is a miracle that curiosity survives formal education. - Einstein
Re:#11: Meaningful error messages by causality · 2010-12-23 10:04 · Score: 1

Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?
Windows does have a system logging facility, as in it's provided by the operating system. I have no idea whether it's as functional, but otherwise it's comparable to the syslog facility provided by Unix and Unix-like systems. Maybe I'm being fanciful but this is what I imagined when I read Jimicus' post.

--
It is a miracle that curiosity survives formal education. - Einstein
Re:#11: Meaningful error messages by jamesh · 2010-12-23 10:04 · Score: 1

Or even worse:
Program: *crash for no apparent reason*
Sysadmin: Why did you crash?
Program: I didn't crash.
Sysadmin: What went wrong?
Program: Nothing went wrong.
Sysadmin: But there's an error message right there!
Program: No there isn't.
Sysadmin: Yes there is. Look. Right there in the logs where it says Error.
Program: And what does it say after the word Error?
Sysadmin: ... "the operation completed successfuly"...
"Error: The operation completed succesfully" is my all time favourite error message!
Re:#11: Meaningful error messages by jamesh · 2010-12-23 10:08 · Score: 1

That works both ways though. I kind of agree that crashes shouldn't be pretty - you don't want to make a serious error something you can just click through. If the nightly backup job failed I don't want a benign little error message presented to the user, I want something that will get their attention. And if that means blowing the application up so that Windows lets them know then so be it.
Crashing with a stack trace because you can't open the database, instead of MessageBox.Show("Could not connect to database\n%s", useful_error_message) seems kind of dumb though.
Re:#11: Meaningful error messages by causality · 2010-12-23 10:11 · Score: 1

Meaningful error messages mean you might figure out how to solve the problem yourself, and then you wouldn't need an expensive, annually-renewed, convoluted, "platinum" support contract.
Managed to get a client away from just this sort of jackassery. It was a DOS-based medical practice app that was buggy as hell. Their solution: Package bug-fixes as "upgrades" and charge for 'em. I was disgusted.
For commercial software that sounds like a standard industry practice.

--
It is a miracle that curiosity survives formal education. - Einstein
Re:#11: Meaningful error messages by swordgeek · 2010-12-23 11:01 · Score: 1

I'd agree with you, but SOMEONE has to keep the crowbar manufacturers in business!

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Re:#11: Meaningful error messages by onionman · 2010-12-23 11:07 · Score: 2

Please do not bother us with your petty problems and See Figure 1...
I couldn't help but notice that the last line of the linked article was, "Love VMS or leave it, but don't complain."
I guess we all got tired of being told to see Figure 1 and just left VMS... I haven't logged into a VMS machine in over 15 years.
Re:#11: Meaningful error messages by Anonymous Coward · 2010-12-23 11:08 · Score: 0

Or my favorite from recently: "A fatal error has occurred. Reason=Success."
Um, did it fail, or is it successful? Its a "successful failure"?
Re:#11: Meaningful error messages by man_of_mr_e · 2010-12-23 11:53 · Score: 1

Actually, if you understand a little about how people write software, you would know this makes a certain amount of sense.
The window in question was most likely a hidden window used to accept messages passed to it. You shouldn't ever see it because it's supposed to be hidden. If it's not hidden, something goofy is going on. What was happening was that during shutdown, the window was becoming visible somehow and it wasn't supposed to do that.

--
If you need web hosting, you could do worse than here
Re:#11: Meaningful error messages by man_of_mr_e · 2010-12-23 11:54 · Score: 1

What it should say is "WIndows has found unknown hardare and is attempting to identify it and install it's software". It just got shortened.

--
If you need web hosting, you could do worse than here
Re:#11: Meaningful error messages by Anonymous Coward · 2010-12-23 12:45 · Score: 0

KY gel in the other hand? Easier access to logs.
Those aren't the logs he is looking for.
Re:#11: Meaningful error messages by JWSmythe · 2010-12-23 14:53 · Score: 2

Sometimes you don't want to be quite so obvious about the error. They're good to log though. :)
On one of my sites, it's very dependent on the database working. Sometimes the database isn't available, say someone rebooted it during the middle of the day. Shit happens. Instead of throwing a nasty "Couldn't connect to database - timeout connecting to 192.168.229.11", it just says "Sorry, we are temporarily down. Please check back in a few minutes.". Of course, the nasty error is logged. Of course *I* know where the database is, but sometimes I am unavailable also, like sleeping, or flying somewhere. Sometimes someone with no personal knowledge of the code needs to fix things. Looking at the log is a lot friendlier than saying "Hey, go find that error in the code, and then go find where the variables come from to populate it." I'm a fairly clean programmer. Sometimes it takes what seems like forever to dig through their chaos of code, just to find out that site/lib/funks/special/cdb12232010.cgi has two functions in it, one of which connects to the database, and site/lib/cf/import/cf12012010.txt has the less than intuitively named variables for the DB server and credentials. Ok, I just made up those paths, but I've seen stuff like those and worse.

--
Serious? Seriousness is well above my pay grade.
Re:#11: Meaningful error messages by Anonymous Coward · 2010-12-23 14:55 · Score: 0

It is possible to make unknown hardware that is flagged in such a way that Windows knows what drivers to use (e.g. generic HID).
Re:#11: Meaningful error messages by mlts · 2010-12-23 15:09 · Score: 1

My favorite ones are programs that just exit instead of bringing up the UI, and don't even set an error code, or if they do, its just 0. No error messages, no nothing. Just exit. Even worse is when they do some major changes before pulling up a UI, and you don't know if they either completed the changes, partially, or nothing.
Re:#11: Meaningful error messages by _Shad0w_ · 2010-12-23 20:03 · Score: 1

Proper error handling is, of course, best. Half-arsed error handling can actually create more problems than no error handling at all. At least with no error handling at all you know there's a problem.
We have code at work where I wish the, uh, "developer" hadn't bothered with error handling at all. Primarily because their idea of error handling is a try-catch block which does nothing in the catch; it just swallows the error so it's never reported. Programs can cease operating correctly and it will be months before anyone actually notices.

--
Yeah, I had a sig once; I got bored of it.
Re:#11: Meaningful error messages by sorak · 2010-12-24 05:15 · Score: 1

He no longer works here, though I can't imagine why.
You seem to be alluding to his termination, but I imagine that it is just as likely that he got a higher-paying job somewhere else.
Re:#11: Meaningful error messages by Geminii · 2010-12-28 08:34 · Score: 1

I'd add - if you're making corporate and/or in-house software, allow the display-to-user error messages to be easily modifiable and overnight-pushable by the helpdesk or whoever is handling FPOC for when the application breaks. A small unchanging alphanumeric string followed by IT-department-defined text enables much better customisation of common errors, including incorporating a quick description of what has gone wrong, troubleshooting steps to try, and/or who to contact.

click-wall. by nblender · 2010-12-23 08:21 · Score: 5, Insightful

Don't make me use a real browser to click all the way through your site, make me agree to a stupid set of conditions for using the software, and then provide my browser with a cookie that it can subsequently use to download your software; when my browser is on one continent and the machine that wants the software is on another continent; you ass-fucks...

Re:click-wall. by crunchygranola · 2010-12-23 09:11 · Score: 1

Don't make me use a real browser to click all the way through your site, make me agree to a stupid set of conditions for using the software, and then provide my browser with a cookie that it can subsequently use to download your software; when my browser is on one continent and the machine that wants the software is on another continent...
Reminds me of the time I was going to spend a month vacation at a beach cottage. No broadband, no cable TV, no WiFi AP, but it did have a telephone. So I decided to sign up for a month with an ISP who had a POP that was a local call from the cottage. There was only one that I could find - EarthLink. Now obviously I couldn't sign up on-line for their service FROM THE COTTAGE since I would need an Internet connection for this. Additionally I did not suppose there was any reason that I would need to use the very computer I was going to have at the beach simply for the sign-up.
EarthLink thought differently. When I signed up it automatically downloaded software to the machine I was using (belonging to a relative I was staying with) that erased all of its Internet settings, making EarthLink the ISP on that machine, and replacing all of my relative's info (username, etc.) with the data I had entered on sign-up, all without warning me or giving me any options. I couldn't restore the settings myself since I didn't know them. Though not a disaster it was a real nuisance to undo all the "help" it deemed fit to give me.

--
Second class citizen of the New Gilded Age
Re:click-wall. by jombeewoof · 2010-12-23 13:52 · Score: 1

earthlink dial up was always as simple as opting out of their crappy software and creating the dun entry manually.
Took me about 30 seconds to have it running on all 4 computers in my house back when win98 didn't have a SE.
First few times though, that software screwed me all up.

--
Linux Zealots: Smarter than Mac Zealots, but still zealots.

How to make a good top 10 by tepples · 2010-12-23 08:22 · Score: 2

10 is an even number. There's no duplicates. None of them are filler.

I don't understand how this happened.

I know how they came up with a high-quality top ten: They had 13 or so, and they cut the weakest ones.

Re:How to make a good top 10 by samjam · 2010-12-23 10:06 · Score: 0

We need "+impressive" mod points

--
blog.sam.liddicott.com

On #10 by Anonymous Coward · 2010-12-23 08:22 · Score: 0

Some of work in the field and we should be able to read the documentation via telnet or lynx. It's not always convienient to grab a laptop, sometimes there's no wireless availiable and either all the switch ports are used or getting internet access is a kafkaesque nightmare. Yes I have a smartphone -- it's not an efficient way to browse documentation!

That's plain ASCII to you... by sl149q · 2010-12-23 08:23 · Score: 5, Insightful

> DO have a configuration file that is an ASCII file, not a binary blob.

And by ASCII we mean something that can be edited by any editor.

XML is the equivalent of a binary blob when you are up to your ass in alligators trying to get things working again with minimal tools available.

Re:That's plain ASCII to you... by HomelessInLaJolla · 2010-12-23 08:41 · Score: 1

Absolutely. The art of the ASCII file, the plain text editor, and the comma separated data file is more important than all of the internet.
1. Silent install? Well, great idea, but ideally you have one program file and maybe a few config files. This whole concept of installation is a product of lazy programmers and/or poorly written operating systems. There isn't anything to be done about it in modern computing... just sayin'.
2. No GUI. Totally. Similar to the concept of dependencies--you should know what you are doing before you consider yourself an admin. Same applies for computer security. If you cannot secure your local priveleges then no amount or combination of network firewalls or safety nets is going to save you from incompetence.
3. Somewhat disagree. API for remote admin? If it were written properly it would just run and remote admin would consist of editing the text config files.
5. Ideally all of the data is stored in the text files. That's easy enough. If you're worried about information security then pass the text files through your own custom made algorithm which you've hand-craftedly carefully buried within the asm of the executable.
6. Ha. I consider that like ftp. Log in and poke around. Is it up or down? That's all there is. If portions of your program become inaccessible when other portions are still running then you wrote it wrong or the underlying operating system sucks.
7, 8, 9... totally.
10. Documentation should be in ASCII text readable by any text editor/pager. _IF_ you create fancier docs from the original that is fine... ASCII plain text human readable should be first and foremost.

--
the NPG electrode was replaced with carbon blac
Re:That's plain ASCII to you... by c++0xFF · 2010-12-23 08:43 · Score: 2

Wait ... why are the alligators trying to get things working?
Re:That's plain ASCII to you... by Nadaka · 2010-12-23 09:12 · Score: 1

Because the alligators made the mistake of eating the bottom half of the on call sysadmin before he fixed their server.
Re:That's plain ASCII to you... by jimicus · 2010-12-23 09:30 · Score: 2

Any self-respecting sysadmin gets attacked by the alligator, it's alligator steak for dinner.
Re:That's plain ASCII to you... by Anonymous Coward · 2010-12-23 10:08 · Score: 0

UTF-8, please.
Re:That's plain ASCII to you... by Anonymous Coward · 2010-12-23 11:44 · Score: 0

Because the Raptors are out of their cages. The electric fence won't work unless the alligators can get the network back up.
Re:That's plain ASCII to you... by sjames · 2010-12-23 11:52 · Score: 1

It turns out they're better at it than "certified" whatevers most of the time.
Re:That's plain ASCII to you... by bigstrat2003 · 2010-12-23 11:54 · Score: 0

The "No GUI" rule is idiotic. Some people prefer to work with a GUI, after all. What would be a reasonable rule is "have the option to not use the GUI if you don't want to, and make it have at least as much power as the GUI".

--
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Re:That's plain ASCII to you... by Anonymous Coward · 2010-12-23 12:04 · Score: 0

Here, here! Well said! And say it again, louder! This is a key point that some programmers never, ever understand.
Re:That's plain ASCII to you... by Anonymous Coward · 2010-12-23 12:12 · Score: 0

Wow. You just don't have a clue. The CLI should set the foundation for the GUI, and not the other way around. You get those concepts right, and you can expand it. You get them wrong, and the best the GUI can do is patch up the flaws.
If you want an example of programmers gone mad, take a look at Xen Cloud Platform. They botched the CLI, and decided to cover it up by re-writing all of *nix in python so they could have a web-based interface. Stay away from that POS if you have a chance.
Hopefully some real programmers with get things right with KVM. And no, Redhat's Cloud offering just isn't it either.
Re:That's plain ASCII to you... by GWBasic · 2010-12-23 16:07 · Score: 1

XML is the equivalent of a binary blob when you are up to your ass in alligators trying to get things working again with minimal tools available.
Depends on if the programmer understands XML or not. Microsoft's XML configuration system is an obfuscated behemoth that I avoid whenever possible.
In contrast, I've combined a low-level XML reader with a dependency-injection library to create a very easy-to-use configuration file.

--
No, I will not work for your startup
Re:That's plain ASCII to you... by m50d · 2010-12-23 22:32 · Score: 1

Yes and no. A standard format, even XML, is far better than your own custom one. I don't want to have to write my own parser to be able to script changes to your conf files.

--
I am trolling
Re:That's plain ASCII to you... by TheRaven64 · 2010-12-24 03:34 · Score: 1

And something with structure, like XML, is often easier to edit from a script. You can use XPath and friends to insert or remove sections from an XML config file. Doing the same with something like the ini file format is much harder.

--
I am TheRaven on Soylent News
Re:That's plain ASCII to you... by bigstrat2003 · 2010-12-26 16:53 · Score: 1

Apparently you don't have reading comprehension, because I never said anything about which order things had to be done in... merely that both should be available, and the CLI shouldn't be gimped because the designers are lazy.

--
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard

DON'T make the administrative interface a GUI by Chucky_M · 2010-12-23 08:23 · Score: 2

2. DON'T make the administrative interface a GUI.

Amen, the number of times I have dumped on products because of the lack of a CLI is almost rude and funnily enough it saves a lot in licensing costs so "almost" everyone is happy. Pretty pictures and buttons will get you past the management and sales but if you come near my systems with your "button pushing monkey" toys expect your time in the building to be very short indeed.

Re:DON'T make the administrative interface a GUI by ArchieBunker · 2010-12-23 08:34 · Score: 2

Ok this I don't understand. A GUI can clean things up a lot. Instead of wading through a 1000 line config file all the options are in front of you. They are better organized and can prevent things like conflicting options or flags. I've seen NFS stop working because there was a space used instead of a tab in the config. At least apache was nice enough to finally split up httpd.conf into different parts.

--
Only the State obtains its revenue by coercion. - Murray Rothbard
Re:DON'T make the administrative interface a GUI by Anonymous Coward · 2010-12-23 08:41 · Score: 0

Double Amen. I'm the local Linux admin. I feel so so sorry for my colleague the Windows admin every time he has to setup something in IIS. Our conversation usually ends with "Hmm, I don't know dude, in Apache I'd just use sed to update XXX across all our sites..." And his mouse goes click click click.
Re:DON'T make the administrative interface a GUI by Chris+Mattern · 2010-12-23 08:50 · Score: 3, Insightful

GUIs are (sometimes) better when you want to do something *once*.
They really suck when you have to do that same thing hundreds of times. Which sysadmins do. On a regular basis.
Re:DON'T make the administrative interface a GUI by causality · 2010-12-23 10:25 · Score: 1

Ok this I don't understand. A GUI can clean things up a lot. Instead of wading through a 1000 line config file all the options are in front of you. They are better organized and can prevent things like conflicting options or flags. I've seen NFS stop working because there was a space used instead of a tab in the config. At least apache was nice enough to finally split up httpd.conf into different parts.
The config file needs to be plain ASCII that can be edited with any standard text editor or read with any pager. It's acceptable to have a GUI to help you edit that plain ASCII human-readable config file, but use of the GUI should never be mandatory.

FYI, it sounds like NFS is unusually anal about its config files. I can't say much more since I don't personally use NFS. I will mention that most of the time, all whitespace is treated equally. To name one important system file as an example, the /etc/fstab file doesn't care whether you use tabs or spaces, nor does it care how many you use. The problem you mention with NFS is not caused by the absence of a GUI. Using a GUI to overcome that problem is a workaround; it is not a solution.

--
It is a miracle that curiosity survives formal education. - Einstein
Re:DON'T make the administrative interface a GUI by icebraining · 2010-12-23 10:40 · Score: 1

Instead of wading through a 1000 line config file all the options are in front of you.

Search and possibility of including other config files - or reading all files in a configuration directory - are better solutions.

They are better organized and can prevent things like conflicting options or flags.
Any program should verify that before loading the file anyway. And you can have flags just launch a verification process - Awesome WM has the -k parameter which just loads the configuration file and tells you if it's OK.
Plenty of apps also have a "dummy" parameter to load the configuration and print out what it would have done without actually doing it.

I've seen NFS stop working because there was a space used instead of a tab in the config.
Stupid configuration parsers exist, yes, just like stupid GUI panels exists. That's not an argument.

--
Dilbert RSS feed
Re:DON'T make the administrative interface a GUI by BotnetZombie · 2010-12-23 10:57 · Score: 1

A good, intuitive GUI can help a lot the first time. But after all the radiobutton-clicking, field entering, next, next and finsh, you want the configuration saved to a text file that can from then on be used for automatic installation for the next who knows how many times are needed.
Re:DON'T make the administrative interface a GUI by mmontour · 2010-12-23 17:53 · Score: 1

FYI, it sounds like NFS is unusually anal about its config files.

I remember trying to troubleshoot an IPSEC problem on OpenBSD several years ago. The problem turned out to be *trailing* whitespace after an IP address in the config file.
Re:DON'T make the administrative interface a GUI by Anonymous Coward · 2010-12-24 04:10 · Score: 0

That's because fstab is a real file and knows it can't be picky, it just has to do a damn job, and do it well.
Re:DON'T make the administrative interface a GUI by abulafia · 2010-12-26 16:52 · Score: 1

It might make more sense to you if you find yourself troubleshooting a failure from a cell phone. Using vi via issh on an iPhone sucks, but is possible. Launching some crappy Java applet isn't. The rule of thumb that makes the most sense to me is that the GUI should be a tool for issuing command line statements. If you can't do it on the command line, you can't do it.

--
I forget what 8 was for.

Top 10 by sakdoctor · 2010-12-23 08:31 · Score: 1

I demand a meta top 10. The top ten list of top 10 lists.

Re:Top 10 by Anonymous Coward · 2010-12-23 09:50 · Score: 0

I demand a meta top 10. The top ten list of top 10 lists.
Thanks for explaining that confusing two-syllable word for us.

I disagree on the GUI by Zarhan · 2010-12-23 08:33 · Score: 5, Interesting

...if the GUI is well done and complements command line.. Some tasks actually ARE much better performed with Point&Click.

One example of a "good" GUI that I use a lot is the ASDM for Cisco ASA firewalls. Most of the simpler admin tasks are in fact *faster* via ASDM. If you have your network objects all properly set up and you need to add a firewall rule, it's far simpler to select it from a list (actually, in this case it's a combobox - just type first few letters to filter your choices and then click) than typing that stuff in manually. Packet tracer to check the rules is much nicer to use via the GUI. Setting up VPN profiles is simpler via ASDM. Handling network object groupings is simpler via ASDM.

Editing access-lists, doing routing configuration and most of the more "rudimentary" tasks are still something I do via command line, though.

Re:I disagree on the GUI by Anonymous Coward · 2010-12-23 08:41 · Score: 0, Funny

What version control tool do you use to track changes to your firewall configuration?
Didn't think so.
Re:I disagree on the GUI by Whatsisname · 2010-12-23 08:43 · Score: 1

The gold standard in my opinion is when the GUI utilities are essentially glorified config-file editors. Having a service that is configured with a respectable text-file (xml config files are awful), and ships with a good GUI application to guide configuration, is absolutely fantastic.
Re:I disagree on the GUI by Zarhan · 2010-12-23 08:47 · Score: 2

What version control tool do you use to track changes to your firewall configuration?
Ciscoworks RME?
Re:I disagree on the GUI by Zarhan · 2010-12-23 08:49 · Score: 1

That's what ASDM essentially is. When you make a change, it basically just generates some commands and then sends them the box. If you tick an option, it even allows you to review those commands in advance (and manually copy-paste them in, if you prefer that instead.).
Re:I disagree on the GUI by PrimalChrome · 2010-12-23 08:52 · Score: 1

I have to agree. CLI scripting is wonderful and incredibly useful, but it does not render an admin GUI obsolete. It is not feasible to learn the CLI syntax for each of the hundreds of apps I deal with for clients. In most of them, creating a new user is a matter of a handful of clicks and entering the appropriate user information....not poring over poorly written txt files for an hour looking for which switch grants the user rights to edit the time entries of a different practice group.
GUI and CLI should both be well designed and complimentary in nature. They are excellent tools and suit their own set of admin needs.
Re:I disagree on the GUI by Qhartb · 2010-12-23 08:53 · Score: 5, Insightful

I think it's more a matter of not making a GUI instead of a command line interface. Making both is, of course, perfectly fine, so long as the CLI is fully-featured and reasonably usable.
Re:I disagree on the GUI by Simulant · 2010-12-23 08:53 · Score: 2

How about RANCID? http://www.shrubbery.net/rancid/ It doesn't give a shit how you edit your firewall config. Version control does not preclude using a GUI. While a CLI should always be there, I have no problem adding a GUI to just about anything.
Re:I disagree on the GUI by lbates_35476 · 2010-12-23 08:59 · Score: 1

Only if you are setting up one firewall or editing one rule. Try that on 50 firewalls for 50 remote offices and you will notice that this doesn't work well any longer. You will want a script that you can apply to all 50 quickly and with confidence that all of them are EXACTLY alike.
Re:I disagree on the GUI by greed · 2010-12-23 09:04 · Score: 1

You can easily build a GUI on a good script-able CLI. You can even build Web interfaces to them... though the "good"ness of that idea depends on the security around your web server.
You can rarely build a CLI on a GUI, no matter how good. You would have had to build all the CLI hooks into the GUI code anyway, at which point you might as well have done it the other way up in the first place.
It makes much more sense to start with a strong CLI and build the GUI on top; most UNIX admin GUIs are exactly that. Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).
The other thing, of course, is admins deal with broken stuff. The more stuff you need, the harder it will be to deal with when things are broken.
Re:I disagree on the GUI by Anonymous Coward · 2010-12-23 09:18 · Score: 1

Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).
Everyone who uses the Very Wrong Editor (emacs) is using a TUI built on top of a line editor (TECO).
Re:I disagree on the GUI by jimicus · 2010-12-23 09:18 · Score: 1

I'm in two minds. A CLI is a fantastically powerful tool, but at the same time some quick & easy way to change small settings that doesn't require you to go back to the manual (because the last time you looked at this item was eight months ago, and you can't remember a single damn thing) is damn handy.
Re:I disagree on the GUI by Anonymous Coward · 2010-12-23 09:21 · Score: 0

Guess you have no experience outside small doze admin tasks? Command lines are best for the simplest of reasons: automation.
Anyone can click an option for "admin", try and do that for hundreds or even thousands of machines, though.
Re:I disagree on the GUI by MichaelKristopeit328 · 2010-12-23 09:24 · Score: 1

it's quite obvious that an optimal solution is the combination of an optimal command line solution and an optimal smart thin client GUI solution.
Re:I disagree on the GUI by nine-times · 2010-12-23 10:32 · Score: 1

Honestly, even as an administrator, I often like GUIs. If you have a list of check-boxes, drop-boxes, and radio-buttons, it's very easy to quickly assess what options are available and what their current states are, and then change their states from the same view. There may be some tools and services where I'm already very familiar with all the possible options, but I don't know everything.
That said, of course CLIs are still vital. I can live with a good CLI and no GUI. The other way around causes problems as soon as I want to script anything.
Re:I disagree on the GUI by Voyager529 · 2010-12-23 12:12 · Score: 1

It is not feasible to learn the CLI syntax for each of the hundreds of apps I deal with for clients.

This.
There's a tipping point with each operation. Making a new user and giving them a mailbox takes less than 30 seconds in Exchange 2007 when using the GUI, whereas typing in all the syntax for the same command can take closer to 90, and that's assuming that I don't have to dust off the fine manual to figure out which argument I forgot to add. If I had to add a hundred new users, however, it would certainly behoove me to write the script and just add names, rather than doing the GUI wizard for each user.
Command lines don't scale down well.
GUI interfaces don't scale up well.
Knowing how to use both is just as important as knowing WHEN to use both.
Joey
Re:I disagree on the GUI by ErikTheRed · 2010-12-23 12:19 · Score: 1

Ugh. That's only because the ASA CLI is so hopelessly, thoroughly screwed (actually, that describes ASA software in general). I love running "sh run object-group | b " and then scrolling back through 600 object-groups to see the one I was interested in. Or searching through access lists that are in no particular order. Or remembering that clearing a site-to-site VPN connection is in the "clear crypto" command tree, and remote client VPN connections are "vpn-sessiondb logoff" (I could go on for ages).
The whole thing should have been refactored ages ago...

--

Help save the critically endangered Blue Iguana
Re:I disagree on the GUI by Anonymous Coward · 2010-12-23 13:45 · Score: 0

...if the GUI is well done and complements command line.. Some tasks actually ARE much better performed with Point&Click.
One example of a "good" GUI that I use a lot is the ASDM for Cisco ASA firewalls. Most of the simpler admin tasks are in fact *faster* via ASDM. If you have your network objects all properly set up and you need to add a firewall rule, it's far simpler to select it from a list (actually, in this case it's a combobox - just type first few letters to filter your choices and then click) than typing that stuff in manually. Packet tracer to check the rules is much nicer to use via the GUI. Setting up VPN profiles is simpler via ASDM. Handling network object groupings is simpler via ASDM.
Editing access-lists, doing routing configuration and most of the more "rudimentary" tasks are still something I do via command line, though.
With the greatest respect - a gui is good for configuring how many firewalls simultaneously? Does it allow you to make conditional variations? Do all the firewalls have to be actually running at the time you push out changes?
It the answer to any of those questions is no.... can I have your job? Where I work there is only one admin. Me. From the sound of it I'd be out of work and pursued by thousands of users brandishing pitchforks if I tried that method :-(
Re:I disagree on the GUI by RichM · 2010-12-23 15:21 · Score: 1

ESXi interface vs ESXi CLI - not even in the same league.
Bizarrely, there is STILL no way to set an MTU of 9000 using the GUI.
One vendor that gets GUIs right though is Dell - the Equallogic interface is superb.
Re:I disagree on the GUI by Martin+Blank · 2010-12-23 15:54 · Score: 1

In addition, for some things, starting on a GUI for general work and then getting used to the command line for certain larger-scale operations is also good. The firewalls we have at work are very good, and the GUI is simply a front-end for the CLI, but the learning curve for both is fairly steep, much more so for the CLI. I have found it much easier to get new admins up on the GUI and then introduce them to the CLI one job at a time until they get the syntax (which is fairly uniform).
There is something else which GUIs can excel at over CLIs, though it depends on the design of each. When zipping through huge volumes of logs, I prefer to have the GUI scroll it past at volume-appropriate speeds because the columns are much more neatly laid out and I can spot general patterns more easily. Less-common items do require me to either use finer filters or to move to the CLI where I can make use of grep, sort, and awk, but the flexibility of those options is highly preferable over a simple CLI output that does not provide contextual coloring or other useful aids.

--
You can never go home again... but I guess you can shop there.
Re:I disagree on the GUI by Martin+Blank · 2010-12-23 15:55 · Score: 1

Or a central firewall manager. I'll take that over a bunch of individual firewalls.

--
You can never go home again... but I guess you can shop there.

All very good suggestions by trollertron3000 · 2010-12-23 08:35 · Score: 0

All very good suggestions. But as a programmer it's my job to ignore these. Thank you come again. I joke, I try my best to make my tools admin friendly. Because that admin might be me.

--
Tiger Blooded Bi-Winning Machine

Re:I'm sorry, why should we care? by Coren22 · 2010-12-23 08:36 · Score: 1

You sir have no idea what it is sysadmins do. Try doing the job some time and you will see that these items make that 1 sysadmin managing 10k computers possible and saves the company millions.

--
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?

Channeling Philosoraptor by Xaositecte · 2010-12-23 08:36 · Score: 2

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

Re:Channeling Philosoraptor by Monkeedude1212 · 2010-12-23 08:39 · Score: 1

You describe what it isn't, based on the other exceptions you were designed to handle.
Narrows down the search/troubleshooting.
Re:Channeling Philosoraptor by bwindle2 · 2010-12-23 08:48 · Score: 1

by catching return codes to functions, and displaying their results back to the user. If a function tries to open a file, and it fails, the OS will tell the program the reason and describe the failure; all you have to do it pass it along to the user. such as: open FILE, "filename.txt" or die $!;
Re:Channeling Philosoraptor by greed · 2010-12-23 08:58 · Score: 3, Informative

Which is a perfect example of a terrible error message. And there's plenty of bad examples like that to crib from, too. (In your particular example, sure, you'll have the "at line XXX" so someone can start digging around in the code... but that's something only suitable for quick-and-dirty hack scripts.)
What you need to know is WHAT, WHERE and HOW. You know WHO (the program), and are trying to figure out WHY. I've often had to resort to strace -etrace=file to find out "What file couldn't be opened? Why couldn't it be opened?"
So, sticking with perl:
open FILE,"filename.txt" or die "Cannot open \"filename.txt\" for reading--$!\n";
Your example will give only the errno, which is what I'm calling HOW [it went wrong]. WHAT went wrong is the "open for reading". WHERE it went wrong is "filename.txt".
I generally wrap such calls with a library; that way, I don't have the error handling littering up every call-site. But if you're using an exception-oriented language, we need the SAME INFORMATION once it turns into an error message!
Oh yeah: For error recovery code, files can't be opened for more reasons than just, "It's not there." You can try all you want, but if (say) the filesystem has gone read-only due to a disk controller failure resulting in journal abort, you might want to do something different. That one's strictly hypothetical, haven't had it happen in over a week--ever since I replaced that faulty cable....
Re:Channeling Philosoraptor by janeuner · 2010-12-23 09:06 · Score: 1

C --- if (err 0) printf("Unexpected Error: some_method() returned %i\n", err);
C# --- catch (Exception ex) { EventLog.WriteEntry("AppNameHere", String.Format("Unexpected Error:\n{1}", ex.ToString()) }
There are better ways, but this at least gives *something*.
Re:Channeling Philosoraptor by fishexe · 2010-12-23 09:33 · Score: 1

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
By putting error messages in a ton of places you don't expect an error to arise, just in case (i.e. places where you expect the input to have been sanitized, add error messages for unsanitized input; places where you expect parameters to be in a certain range, check for them to be out of range and indicate which was out of range).

--
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
Re:Channeling Philosoraptor by DragonWriter · 2010-12-23 09:46 · Score: 1

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
Well, if you (or, rather, the application code) know that it fails (IOW, if it hasn't failed at a level so far down that it just dumped core/GPFed/etc. without even signalling your code) then you probably know something about the context where the error occurred (what was in progress), what code module of yours received the error, and what the exception or other indication of failure you received from outside of your code to let you know that something was wrong.
Re:Channeling Philosoraptor by Anonymous Coward · 2010-12-23 11:33 · Score: 0

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

Program bug: Impossible situation detected in function Function(). Aborting operation.
Yes, I have actually implemented this on more than one occasion, usually as the "default" branch of a switch statement where I've (theoretically) matched all possible values already.
-JS
Re:Channeling Philosoraptor by sjames · 2010-12-23 11:49 · Score: 1

It's terrible for an anticipated error (things like wrong file name given or other bad input), but as a catch-all for entirely unanticipated errors, it beats such "informative" messages as "abnormal termination" or just going away.
Re:Channeling Philosoraptor by mmontour · 2010-12-23 17:41 · Score: 1

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
You say what it wasn't.
Start by #include <assert.h> and adding assertions that should never fail (such as being passed a NULL pointer). When one of them does fail, you will get a message saying what condition wasn't satisfied and the line number where it happened.
For system calls like open(), check for a result code of 0 (success) or one of the error cases that your program explicitly handles. For anything else, first print the value of 'errno' and then trigger an assertion failure. This is particularly useful when your open() fails randomly on something like EMFILE due to a file-descriptor leak in a completely different section of the program.

At a minimum ... by LoudMusic · 2010-12-23 08:36 · Score: 1

This list is a good start. Don't consider purchasing software that doesn't meet these criteria.

--
No sig for you. YOU GET NO SIG!

Windows CAL cost by tepples · 2010-12-23 08:36 · Score: 5, Informative

From the article:

8. [...] Similarly, use the operating system's built-in authentication system and standard I/O systems.

This can be a bad thing if your application runs on a platform whose built-in authentication is a nickel-and-dime revenue stream for the platform's publisher. Microsoft Windows Server is like this: each user account on the built-in authentication system requires a Client Access License.

Re:Windows CAL cost by GMFTatsujin · 2010-12-23 09:25 · Score: 2

Point taken. Consolidating directories of authenticated accounts in general is a good idea, especially if open standards are involved. If Active Directory (or whatever) isn't your cup of tea, setting up an OpenLDAP server or something similar should be an option.
I think the basic idea is to avoid over-replicating information and minimizing the potential for human error in the duplications.
Re:Windows CAL cost by Jaime2 · 2010-12-23 09:32 · Score: 2

Incorrect. Client Access Licenses are for those who use File and Print services. Authentication services only require a license for the server itself.
Re:Windows CAL cost by jimicus · 2010-12-23 09:37 · Score: 2

WTF are you talking about?
With Windows, you need the CALs for the user to access any application running on the OS in the first place.
Re:Windows CAL cost by Anonymous Coward · 2010-12-23 09:38 · Score: 0

But NTLM is a specific authentication implementation developers shouldn't have to bother with. A good application uses an abstraction layer like SASL, so I can choose the scheme myself. And one update to e.g. the LDAP module should be sufficient to fix all SASL-enabled applications using LDAP.
Re:Windows CAL cost by Anonymous Coward · 2010-12-23 11:08 · Score: 1

From the article:

8. [...] Similarly, use the operating system's built-in authentication system and standard I/O systems.
This can be a bad thing if your application runs on a platform whose built-in authentication is a nickel-and-dime revenue stream for the platform's publisher. Microsoft Windows Server is like this: each user account on the built-in authentication system requires a Client Access License.
A common misconception. A CAL is not required for each user account created. The OS and most of the application servers (i.e. SQL, SharePoint, etc) have licensing models that support an unlimited number of non-employee type users. You can use whatever authentication method you wish for these users, including AD accounts, as long as you have the appropriate platform license.
Re:Windows CAL cost by tepples · 2010-12-23 12:29 · Score: 1

Incorrect. Client Access Licenses are for those who use File and Print services. Authentication services only require a license for the server itself.
But still, for web sites run on Windows Server, do you see them creating a Windows user account for every member of the public who signs up?
Re:Windows CAL cost by quacking+duck · 2010-12-23 12:42 · Score: 3, Insightful

This is why I hate having to deal with Windows on the side. In this aside about user CALs, there's three different takes (so far) on when you need a Windows CAL and when you don't.
I got sick of researching Windows Small Business server when I read their FAQ, and the section on licensing was longer than all the other sections combined!

Amendment to #2 by c++0xFF · 2010-12-23 08:42 · Score: 4, Insightful

Feel free to make a GUI for the administrative interface, but not at the expense of an underlying CLI.

There are two ways to do this: have your GUI call the CLI when necessary, or use a common API behind both. Other methods will lead to bitrot in one of the interfaces, most likely the CLI.

GUIs are fine and even enjoyable to a certain extent, but the author is right that the CLI takes priority.

GUIs by Waccoon · 2010-12-23 08:56 · Score: 1

My Amiga was a computer that was equally comfortable with CLI and GUI interfaces, and may programs with GUIs had plenty of shell commands with the same executable. I'm not sure why the rest of the computer industry turned it into a religious war that continues to this day.

Some planning and thought are all that's required to make a balanced interface that handles both methods well.

Re:GUIs by F.Ultra · 2010-12-23 11:59 · Score: 1

Yes that one was a real beauty, on the Amiga you could figure out whether you where started from the shell or from the Desktop so you knew whether to pop up a GUI or not. Contrast this with something like Windows where you don't even know if you have been started as a service, which is why so many add --service to their command lines when installing as a service.

I love bash. by miffo.swe · 2010-12-23 08:58 · Score: 2

I manage almost exclusively Linux servers and i must say the command line saves me ooodles of time. Some quirks can be alleviated by just restarting some services before they run out of memory, some needs a bit more magic but nothing takes time like having to login to many computers every day and click on the same friggin GUI stuff on multiple servers.

Bash saves me time by totally taking repetitive tasks away. Ive tried the same with some Windows machines but while powershell has potential, it does not work in reality unless you are a 100% Microsoft shop, and you happen to run the limited set of applications that has full support for powershell.

Maybe in time Windows will climb up to the level of Linux when it comes to manageability but right now i spend most of my time doing repetitive stuff on my Windows boxes while i write scripts that handles anything on the Linux boxes.

--
HTTP/1.1 400

Re:I love bash. by jimicus · 2010-12-23 09:40 · Score: 1

Maybe in time Windows will climb up to the level of Linux when it comes to manageability but right now i spend most of my time doing repetitive stuff on my Windows boxes while i write scripts that handles anything on the Linux boxes.
I doubt it. Even relatively recently, I've had serious conversations with tech support at companies where they don't put someone with the IQ of a pot plant on the phone explaining that I need to automate something and you would not believe the number of times I've been told something along the lines of "Why would you want to do that? It's not that complicated - just a couple of clicks."
Getting the message across that it's a couple of clicks to you, it's a couple of clicks possibly several hundred times to me is too often an exercise in pain and futility.

No admin clients that only work on Windows by Air-conditioned+cowh · 2010-12-23 09:23 · Score: 1

Unless you want me to drop the product and choose something else less irritating. Hello VMWare? Xen?

Re:No admin clients that only work on Windows by Bucky24 · 2010-12-23 12:30 · Score: 1

Are you implying that Xen won't work on a non-windows system? I know for a fact that this is incorrect...

--
All the world's a CPU, and all the men and women merely AI agents

More options by SnarfQuest · 2010-12-23 09:30 · Score: 1

- If you don't provide documentation, requiring the sysadmin to dig through the source code for configuration information, please add some useful comments and meaningful function names.
- Make the option parsing code clear enough so we can at lease see what words are used for the options. Cute parsing code may save a millionth of a second each time the program is run, but is useless if we can't figure out how to configure it.
- If you have a configuration file, tell us where it is and what it is named, at a very minimum. Scanning a binary file for strings to locate the configuration file is a major pain.
- Don't develop yet another build system. Especially if it only works on one specific version of a specific operating system on specific hardware.
- Don't make every error message exactly the same. Trying to figure out which one of the fifty "oops" messages was triggered is painful.

--
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.

Re:I'm sorry, why should we care? by Anonymous Coward · 2010-12-23 09:45 · Score: 0

We have a hard job because we have morons like you writing our software. If we have competent people, it goes fine and we don't need to whine and bitch and moan because there's nothing to whine and bitch and moan about.

Now go write some more trivial business apps for me, please.

And we'll call it ... by rudy_wayne · 2010-12-23 09:49 · Score: 1

Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line

Copy Pasta Security®

Its an acm.org article ... by perpenso · 2010-12-23 09:56 · Score: 3, Informative

10 is an even number. There's no duplicates. None of them are filler. I don't understand how this happened. Did someone plan this before they wrote it? What gives?

Its an acm.org article. Not only did the author probably plan, re-read and revise the article before submitting it but a technically knowledgable editor probably read it and may have offered useful and insightful suggestions. Now there may not have been a formal peer review process but the editor may have also had one or more experts in the field read it and offer comments and suggestions.

Yes the above seems an archaic process but consider that the acm is full of old people who had experience publishing back when things were done with dead trees. ;-)

Re:I'm sorry, why should we care? by JerseyTom · 2010-12-23 10:01 · Score: 1

You sound like one of those people that piss all over the public bathroom floor and say, "ha! it's someone's job to clean it up! why should I care!" (since you made the janitorial analogy, I thought I'd complete it)

The biggest change in business in the last 10 years is the realization that IT is not a "cost to be reduced" but the driver of innovation that should be invested in, respected, and optimized.

unix? by AntEater · 2010-12-23 10:08 · Score: 2

This reads like a specification for building a unix system.

Those who don't understand Unix are doomed to reinvent it... or something like that.

--
Alex, I'll take keybindings not used by Emacs for $400....

Re:unix? by mjwx · 2010-12-24 20:27 · Score: 1

This reads like a specification for building a unix system.

Those who don't understand Unix are doomed to reinvent it... or something like that.

The article understands a Unix system and does not want to re-invent it.

The article wants developers to write to that specification.

--
Calling someone a "hater" only means you can not rationally rebut their argument.

truncate the swapfile by Anonymous Coward · 2010-12-23 10:12 · Score: 0

Once on a live solaris box, "swapoff" was executing too slowly for me and I wanted to delete the swapfile (yes it was) to free up some discspace.

Because I could:

> /swapfile

and a squicro-second later the box just slammed to a halt

had to drive to the data centre to reboot it.

Posted anon cost I want to re-tell this at a christmas party without someone spoiling the ending

Eventlogs by Spad · 2010-12-23 10:37 · Score: 4, Insightful

In reference to point 8, this is something I wrote I while ago after dealing with several Windows apps that either horribly abused the Eventlog or refused to use it entirely:

DO create your own event message DLL(s) where appropriate to avoid your events looking like this
DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.
DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0×8003387 means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.
DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.
DO make your logging level easily configurable by the user and DO set a sensible default.
DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.

#1 big dont by MrLint · 2010-12-23 10:40 · Score: 5, Insightful

Do not assume that your software is running with elevated access... (root/administrator)

Re:#1 big dont by furrymitn · 2010-12-23 15:32 · Score: 2

Do not assume that your software is running with elevated access... (root/administrator)
Correction: don't assume your software NEEDS to run with elevated privileges.
Re:#1 big dont by MrLint · 2010-12-24 05:37 · Score: 2

Do not assume that your software is running with elevated access... (root/administrator)
Correction: don't assume your software NEEDS to run with elevated privileges.
Ya know that's actually an interesting semantic difference. I think both are true. Much software is written making the blind assumption that it will be in an environment with elevated access (my comment). But with yours (which is also true) some developers just assume that their SW needs it, and they act on that assumption, and then you end up back at situation #1.

First rule by PPH · 2010-12-23 10:56 · Score: 2

Make sure its clear whether you meant '10' in base 2, 8, or 16.

--
Have gnu, will travel.

"none" is singular by newdsfornerds · 2010-12-23 11:03 · Score: 1

"None of them is filler." But you get full credit for the question marks. So many people seem to think they are optional.

--
Damping absorbs vibrations. Dampening is caused by moisture.

Re:"none" is singular by Anonymous Coward · 2010-12-23 14:20 · Score: 0

"Damping absorbs vibrations. Dampening is caused by water."
My hero!! One of my oldest pet peeves as a suspension engineer (automotive & bicycle suspension).
Re:"none" is singular by Anonymous Coward · 2010-12-23 14:50 · Score: 0

"How many people are in the tent?"
"There is none."
His usage was fine.
Re:"none" is singular by digitalsushi · 2010-12-29 07:40 · Score: 1

The object of the preposition was plural. My choice was correct.

--
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
Re:"none" is singular by newdsfornerds · 2010-12-29 07:53 · Score: 1

Hey I need heavy duty springs for my 1997(?) Rockshox Judy SL fork. I could send it to hippietech in CO and they'd cut springs to fit but that would cost bug bucks. Any idea what springs my work? All I can find on ebay is soft and extra soft springs.

--
Damping absorbs vibrations. Dampening is caused by moisture.

Re:It's noce to know by swordgeek · 2010-12-23 11:05 · Score: 4, Interesting

A GUI is NOT fine for administering a broken system over a slow link to the other side of the world.

I used to remotely administer a set of servers in the middle east. The bandwidth was tiny, and the latency was insane. I would type a command out, then take a sip of coffee while waiting to see it displayed before hitting "enter." I had to use a GUI for one application, and it took over 40 minutes to fire up and display on my machine.

Mandatory (and well-designed) GUIs should be for using an application, not administering or installing it.

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban

Old Versions by Plekto · 2010-12-23 11:10 · Score: 2

#10 should probably be #1. Support and documentation is everything. Because when it hits the fan, finding the original install CDs or manual is almost always a requirement. It's also why I stopped buying Nvidia cards. They got rid of almost all of their patches and drivers as well as installation CDs on their site and now force you to use their "all in one" tool. And lo and behold, you're screwed 90% of the time with an older machine if you don't have the original install CD because it simply doesn't work without the CD.

Case in point - I tried to recover an old machine's crashed system(video drivers and dirext X had eaten themselves when "upgrading" as is typical) - but the online driver was useless. The original CD was the only option, but it wasn't to be found. (as is typical, few customers keep driver CDs where they can find them). The manufacturer didn't have the original CD to download, either.(honestly, a 50mb ISO file isn't going to kill their server space) I had to buy a new card to solve what should have been a ten minute problem. Nobody was happy about it, either, as you would imagine, since the card wasn't even two years old at the time.

(note - a "roll back" option also needs to be available when "upgrading") I'd wager that 95% of the time it is simply not there.

Re:Old Versions by Anonymous Coward · 2010-12-23 12:15 · Score: 0

I measure documentation on a scale of "Excellent", judged against Monit which I once saw claimed as "excellent documentation". The scale goes from "Quite Excellent" where the documentation is simply utter shit to "Highly Excellent" where it is non-existent or wildly misleading E.g. GlusterFS 3.

so tempted to name some names by Anonymous Coward · 2010-12-23 11:20 · Score: 0

Dealing with some really awful "enterprise" logging and file transport replacement software packages right now (replaced good old Solaris boxes). Every blinkin' update they "enhance" the web gui's to make them flashier and more useless.

And don't make me copy the entire 10G dist... by Arrogant-Bastard · 2010-12-23 11:46 · Score: 2

...off the install media into a scratch area, just so I can run your obfuscated, opaque Java application, just so it can copy everything into the real installation directory.

Instead, why not try using, oh, I dunno, "tar" and "make" and friends -- you know, the standard 'nix tools that every system administrator has been working with quite happily for decades and which suffice nicely to install tens of thousands of software packages ranging from the dirt-simple to the incredibly complex.

I'm looking at you, SAS.

I _WISH_ we had system administrators where I work by Anonymous Coward · 2010-12-23 12:17 · Score: 1

The list is constructed for quality, intelligent system administrators who strives to understand and maintain the underlying system. Instead we have an idiot man-child who thinks system administration is clicking on the right button and rebooting. He's completely befuddled if he has to type in a command, or edit a file as if either of these tasks is like constructing your own working nuclear reactor. I actually believe most applications are targeted at this level of stupidity.

But hey, I'm not bitter about it at all.

Re:I'm sorry, why should we care? by Bucky24 · 2010-12-23 12:28 · Score: 1

The IT equivalent of a Janitor? I know at the ISP I work for our server admin isn't considered that way at all. I would love to know half as much as he does about how our servers run and how everything is put together.

Then again being at an ISP we tend to put a little more value on keeping the network alive, and I think this is not the case at standard corporations.

Regardless, the tips given in TFA are not just for sysadmins. I don't consider myself sysadmin-I'm a standard software engineer, and I would also like to see programs with the characteristics given. It's not just helpful to one group, it's solid programming advice.

--
All the world's a CPU, and all the men and women merely AI agents

GUIs vs. command line: false dichotomy by wealthychef · 2010-12-23 12:51 · Score: 1

How about layering a nice GUI on top of command line tools? This allows repeatability, scriptability, etc., but also can provide access to things a GUI does more easily, such as browse for files, perhaps, or pick your favorite feature. It's not like all GUIs suck at all things.

--
Currently hooked on AMP

Re:Amendment to #2 by Kjella · 2010-12-23 12:55 · Score: 0

As long as we're talking sysadmin duties, which imply that you have ONE admin to many boxes. If it's any kind of setting that a user should have to touch, please make it part of the GUI. A good GUI is infinitely more structured and helpful than a long, long flat man page of cli switches. The reason you want a CLI is scripting, not user friendliness.

--
Live today, because you never know what tomorrow brings

10 years of personal experience... by CAIMLAS · 2010-12-23 12:58 · Score: 3, Insightful

1. DO have a "silent install" option.

Silent install is nice, but so is an intelligent install, or a well thought-out, correctable upgrade process.

These systems do it well:

Debian and RedHat derived; Windows, post-2003. OS install is still a bit of a bitch with Windows. The upgrade process for MediaWiki is also stupid easy and effective (basically: untar new tree and run db alter scripts).

Poorly:

FreeBSD, and, really, most BSDs, are horrible for upgrading. I suspect OS X is similarly stupid when it comes to "promptless installs". Cacti, likewise, is awful.

2. DON'T make the administrative interface a GUI.

A useful amendment to this is: don't make the administrative interface shitty. GUI is fine, as long as I can leverage it progmatically. CLI tool is great, as long as it's fucking documented and not obtuse.

Case in point (in opposition): MegaCLI, for MegaRAID cards. Absolute. Shit.

3. DO create an API so that the system can be remotely administered.

An API is great, and allows for programmers to dig in and extend the product. I'm thinking of VMWare, XenServer, and Virtualbox right now. The latest Windows versions with PowerShell and the management consoles are not a bad combination of usability/power/utility.

Most sysadmins don't have the time to dig into the API, though, so a good initial tool that isn't terribly dense or limited in functionality is a must (XenServer, please improve your shitty-useless UI on xsconsole and XenCenter; I'd like a little more access to my VM disks without digging into lv/pv commands, too).

4. DO have a configuration file that is an ASCII file, not a binary blob.

No argument here. Likewise, configuration should be human-readable and not have vague incantations.

Good: samba, and all tools which use similar configuration syntax.

Bad: sendmail is the worst offender I can think of at the moment. I'm sure all the djb* stuff, too.

5. DO include a clearly defined method to restore all user data, a single user's data, and individual items (for example, one e-mail message). The method to make backups is a prerequisite, obviously, but we care primarily about the restore procedures.

Good: any UNIX system and it's $HOME; modern Unix MTAs like Courier.

Bad: Cyrus IMAP. Pretty much any tape archive system comes close to frustrating as hell. Windows still has a long way to improve until it's capable of Unix-style $HOME utility.

6. DO instrument the system so that we can monitor more than just, "Is it up or down?"

WMI is great. SNMP on Unix/Linux hosts, not so much, due to the configuration and divergence involved. Most OEM Linux/Unix based machines or systems (XenServer) are relatively shitty in this regard, too.

7. DO tell us about security issues.

Telling us about them is great, but upgrading these things are the most important, time-sensitive upgrades we need to make, so they should also be the easiest. We should not have to break two-three different things just to get the upgrade done.

BSDs are bad about this; horrible, even. The time consumed by a simple upgrade is enormous.

Linux is mediocre, but better than most.

Windows, in this case, "just works". Except when it doesn't (though I'd argue the degree is no greater than, say, the Linux upgrade process). Your biggest cost will be when it installs something you've explicitly told it not to (*cough* new IE versions) or in bandwidth and/or uptime requirements.

8. DO use the built-in system logging mechanism (Unix syslog or Windows Event Logs).

Something which doesn't do this isn't even worth looking at. It's yet one more thing to manage and uses exponential

Addition: make your logging sensible, please. I don't want to see a full trace of everything in the logs and not be able to configura

--
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers

Re:10 years of personal experience... by Anonymous Coward · 2010-12-23 15:08 · Score: 1

We sell software for money. We sell support for money. Upgrade to the latest version is commonly an answer to support requests. If you have paid for the support (which is the only way to get an engineer to look at it) upgrades are included so ...

Fuck no by dbIII · 2010-12-23 13:02 · Score: 1

With a pure GUI interface you completely rule out any sort of automated configuration tool (puppet etc) and can turn a single person job into one where you have large numbers of temps running around kicking people off their PCs just so they can click their mouse on a few things on the screen. While the programmer may think their program deserves the individual attention of somebody sitting down at the console and pointing at pretty pictures there is always the possibility that the people configuring it have other things to do and may want to run it on more than one machine. Even if you think it is a one per company thing some large place may get a hundred of them and put one person in charge of deploying them. That one person shall curse you and you GUI and wish they were given an interface where things could be scripted instead of having to behave like a three year old pointing at pretty pictures.
There are many that cannot grasp this idea, being stuck with the non-networked single user idea we saw with the Apple ][ and got stuck with when Microsoft hit us with a cut down version of CP/M without the concept of multiple users. Time to grow out of the concept of a three year old pointing at pretty pictures and understand that we can use words to tell the machines what to do. Present it as both if you like but NEVER make us sit through a dozen mouse clicks on one hundred different machines if we need to do one hundred installs.

Re:It's noce to know by Anonymous Coward · 2010-12-23 13:19 · Score: 0

A GUI is NOT fine for administering a broken system over a slow link to the other side of the world.

Agreed, or when the broadband connection is down (or DDOSed)

And especially when the *tards demand *cough* Adobe *cough* be deployed across 12K machines running different OS versions, in different States, in different time zones.... a packaging nightmare at the best of times. Add in a few hundred headless boxes and cli becomes the only feasible way to implement the changes.

Maybe, just maybe, when the economic fuckup we're in becomes obvious to Accounting - the same cost/benefit tests that are applied to the purchase of a chair will be applied to IT decisions

In the meantime IT decisions are not being made by IT managers. And the people who choose the chairs are not getting free trips to the Gold Coast, and winning Golf Buggies (sigh)

I am suprised! by Anonymous Coward · 2010-12-23 15:04 · Score: 0

I on the other hand am suprised that nobody has equated the poster's name to Lemoncello and it's mascot.

http://www.youtube.com/watch?v=46wakJ8oggM

in other words... by Anonymous Coward · 2010-12-23 16:42 · Score: 0

don't do anything microsoft does.

Microsoft is Greatest Jobs Engine by Tablizer · 2010-12-23 17:32 · Score: 1

The grunt-work of installing and re-installing software has turned into a great job creation machine. True, it's boring and mundane most of the time, but jobs is jobs. And it can't (yet) be off-shored to Asia.

Also, vendors generally don't want to simplify and standardize the installation process because it also simplifies pirating. A mess is harder to clone and copy than a logical and consistent arrangement.

--
Table-ized A.I.

What about sane version numbers? by thsths · 2010-12-23 20:57 · Score: 1

That would be close to the top of my list. You need at least two levels: minor fixes, and major upgrades. Fixes should be minimal, make the system strictly better, and not get in the way of things.

Java is the example of how not to do it: 1.6.0u23 - and upping the last digit has often introduced new features and broken other things (plus the installer is extremely unpredictable). Adobe gets at least the version numbers right, but their upgrade path is often a miracle. Firefox gets it right, most of the time.

GUIs are hard to document by FoolishOwl · 2010-12-23 22:20 · Score: 2

2. DON'T make the administrative interface a GUI. System administrators need a command-line tool for constructing repeatable processes. Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line. We cannot achieve the same repeatability when the instructions are: "Checkmark the 3rd and 5th options, but not the 2nd option, then click OK." Sysadmins do not want a GUI that requires 25 clicks for each new user. We want to craft the commands to be executed in a text editor or generate them via Perl, Python, or PowerShell.

Since I've had to work with Windows servers in my new job, I thought I'd better read up on them, so I've been reading Windows Server 2008: The Definitive Guide. The sections on the underlying principles and theory of the OS are fine. But that's one third of the text, at most. Most of the text is useless blow-by-blow accounts of sequences of clicks in GUI applets. It's completely unreadable -- the descriptions are meaningless unless you're working through the instructions with an instance of Windows Server 2008 in front of you. And who's going to set up several instances, just to make sense of the description of the applet for configuring load balancing?

I can't blame the book, particularly, as it's a problem of GUIs.My workplace has lots of documents with step-by-step instructions for configuring services, which have one sentence of text, followed by a screenshot, followed by another sentence of text, and another screenshot, and so on.

On the flip side, one of the great things about text configuration files is that while they're full of obscure configuration options, they're also full of the documentation explaining the obscure configuration options. Config files are rich with documentation. GUI configuration applets frequently aren't. I'll take a documented option in a config file over an undocumented option in a GUI config applet any day.

Re:It's noce to know by m50d · 2010-12-23 22:36 · Score: 1

Mandatory (and well-designed) GUIs should be for using an application

Not even that. All applications should have their functionality usable from the command line.

--
I am trolling

Re:It's noce to know by Anonymous Coward · 2010-12-24 02:24 · Score: 0

mod parent up. I had to administer a windows server that was in Malaysia. The client had the fastest ADSL line that could be installed at their location, and I had a massive 15kb/s bandwidth up from them. Remote desktop was a pain in the rear at these speeds. Not only that - but this line was serving several hundred remote users through special client software.

If there was ever a problem we couldn't solve it during work hours, because remote desktop used all of that bandwidth, even at 1024x768 B&W

shudder

Re:Amendment to #2 by TheRaven64 · 2010-12-24 03:39 · Score: 1

The CLI is not important, the things that you can do with a CLI are important. You can easily use it with a crappy network connection (SSH is usable over GPRS or an analogue modem). You can script it. You can document exactly what the process is, easily.

If you can provide all of this functionality without a CLI, then by all means do so. A web interface might be better than a CLI for remote access. A proper set of scripting APIs might be a lot better than a CLI for scripting. A record and replay facility for all configuration changes at the layer below both the scripting API and the GUI might be better for reproducibility.

--
I am TheRaven on Soylent News

Re:I'm sorry, why should we care? by damaged_sectors · 2010-12-24 19:49 · Score: 1

Actually I know exactly what you all do. You whine and pule and cry like you have a hard job, and you bitch and moan and get basic concepts incorrect and regurgitate things we programmers invented that you ill understand.

Go unclog the toilet.

On behalf of all admins - please accept my apologies.

Your .net programming skills are awesome - you what? wrote a program that performs mathematical equations? only how many megabytes? you are awesome!

Not only do I love the idea of a digital calculator - I also admire your cubicle art. Have you ever considered painting in a colour other than brown?

Slashdot Mirror

10 Dos and Don'ts To Make Sysadmins' Lives Easier

246 comments