Has anybody ever done a usability study on the Linux CLI interface?



  • And for those failings that Linux can't do (probably relating to GUI).. OS X can save the day and let Unix have a great GUI as well.



  • @blakeyrat said:

    @nonpartisan said:
    What do you mean "the CLI is the API"??

    I mean that in a sensible design, APT would consist of at least two parts: 1) the library that does the actual work and provides an API, 2) one (or more) UIs that define how the user interacts with the library.

    Here you go: the library; one UI (the one you used); another UI.

    @blakeyrat said:

    The beauty of that is if I don't like the CLI, or if I like the CLI but I don't like the default APT CLI interface, I can build a new one which talks to the underlying library and handles errors in an intelligent way. There'd be nothing to stop me from writing my cleaner "install" command and putting it on the Ubuntu server.


    Let us know when it's finished.



  • @Monomelodies said:

    If you're administering a Linux server from the command line, you should know your command line tools. Sorry, but that's just the way it is. Servers aren't meant to be administered by click-monkeys.

    "click-monkey". Very diplomatic.

    Sometimes I talk about how things should be and not how they are. Software developers who are dead inside don't understand that the way things are now is not necessarily the way they should be. I frequently have this problem when posting on forums like this one.

    @Monomelodies said:

    The error messages, IMHO, make perfect sense: the package was not found, and the file couldn't be locked. A friendly hint was even provided (are you root?). No idea why this pisses you off so much.

    That's not a hint, that's a question. It pisses me off because the error is useless. It doesn't give you any information you need to solve the problem. Or, even better, it could have just automatically asked me to elevate instead of giving me an error at all. It pisses me off because it's fucking stupid, and I like my computers to be (or at least act) smart.

    @Monomelodies said:

    Blakey seems to think Windows and OSX applications are something magical that live inside the graphical shell.

    I do?

    @Monomelodies said:

    They are not; they're just binary applications like any other,

    As opposed to what? Hypercard stacks?

    @Monomelodies said:

    and if they can't "connect" to a GUI they will in fact error out.

    Gibberish. "connect" to a GUI? Utter gibberish.

    @Monomelodies said:

    A number of Windows applications I know of have very useful command line switches.

    Ok?

    @Monomelodies said:

    In that sense, there is actually no difference between Windows, OSX and *nix systems.

    In the sense that applications have useful command line switches? I guess not. Relevance?

    BTW, you should try Mac Classic. There's no command line switches because there's no command line. Your head would explode.

    @Monomelodies said:

    Windows keeps a dir.exe somewhere in the $PATH, just like *nix has /bin/ls.

    It does? First I've heard of it. Googling "dir.exe" brings up an anti-virus site as the first hit. I honestly think you have absolutely no idea what you're talking about.

    @Monomelodies said:

    There is one important difference though, and that's in philosophy. Under Windows and (to a slightly lesser extent) OSX, applications are expected to do "everything" in and of itself. Under *nix, the philosophy is firmly "do one thing, and do it well".

    The problem is the "one thing" in this case was "install mongodb", and APT did not "do it well". (The other problem is the Linux philosophy is crap, what "one thing" is for example a spreadsheet application supposed to be doing well? The only answer is "be a spreadsheet application". But that's another thread.)

    @Monomelodies said:

    If that scares you, so be it. I personally enjoy the sense of non-duplication it gives me.

    "The sense of non-duplication?"

    Look, I'm not even 100% against the Linux philosophy. The problem is, it doesn't make any sense to string together applications with UIs if you're making these compound tasks. What makes 1000,00000,00000000 times more sense is to string together libraries that have no UI and let to do things like, pass around data that isn't text! Or handle errors in an intelligent way! Or let the people who are building the UIs change them to their heart's content without breaking other programs! Wouldn't that be utopia?

    For an example of this philosophy done right, take a look at PowerShell.

    @Monomelodies said:

    Let's firmly agree to disagree on THAT one. While obviously Linux has its own areas of improvement, name me one thing that Windows CAN and Linux CAN'T do.

    Hell, if you actually went through every bulletpoint that a software product like "Active Directory" implies, you could come up with some pretty long lists. The problem is Linux users literally do not know what features Windows has, and they literally think Linux does all of the same things. (Alternatively: they point to pre-Alpha crap code that's been abandoned and unsupported and isn't shipped in any distribution and say that's equivalent to the Windows feature.) And of course my Linux knowledge is pretty out-of-date so I'd be pretty bad at it. For example, I mentioned I was surprised that Ubuntu Server finally has Windows-like Services, but I still don't know if it has all the event logging features that Windows has (the ones I mentioned in a previous post) because I haven't had a need to look into it.



  • !@@Q$Q!$@$@%@!%@%^#

    @pjt33 said:

    Here you go: the library; one UI (the one you used); another UI.

    So if a library exists, WHY THE HOLY SHIT IN HELL IS THE GUI TOOL CALLING THE CLI APP!??!??!!?>!?@><

    Your post explains nothing, it just raises more questions!


  • ♿ (Parody)

    @blakeyrat said:

    I knew what I was doing: installing mongodb. I didn't need to learn that, I already knew it.

    The problem is that accomplishing the task "install mongodb" requires a lot of knowledge that has nothing to do with knowing what the hell I'm doing. It shouldn't.

    This is fucking retarded, even for blakeyrat. So, when you installed it on Windows, and it was so easy, you didn't have to know anything at all? You clicked on the magic "Install MongoDB" button, right?


  • ♿ (Parody)

    @blakeyrat said:

    the CLI is thean API.

    Actually, FTFY


  • ♿ (Parody)

    @blakeyrat said:

    WHO CARES WHAT DISTRO IT WAS RUNNING. IT IS NOT RELEVANT.

    Here's the thing, which you refuse to admit or understand. The "official" instructions for installing some package start with your distro's repositories. That should be the first place you look. It's true that sometimes, it will use a version that you can't use, or was built with some obscure option that makes it unfit or whatever. But that's pretty rare.

    By not trying your distro's repo first, or even apparently being aware of it, you have demonstrated a high level of ignorance about the operating system/distro that you are using. Frankly, enough that you should not be in charge of this system until you actually know something about it. Whatever you think you learned in you past experience was apparently not enough to function in a modern Linux environment.



  • @blakeyrat said:

    See? See? We get into this stupid "no true scotsman" shit.
    The point is scope.  You said you were a "system administrator".  If all you ever did was to restart a service when it had problems, you were not a server administrator.  You were a server technician.  You were the equivalent of someone working in the operations center.  If I am a system administrator, I expect to know my administration tools and the operation of the operating system's tools.

    If you run the engine of a car for five minutes once a month while it's in storage, that doesn't make you a driver.  That makes you someone who starts the car once a month.  I wouldn't expect you to know the full operations of the vehicle.  If you are a driver of the vehicle . . . one that you've driven "for several years" . . . then I would expect you to know the vehicle, how to operate the lights, the radio, the AC, etc.  I wouldn't expect that level of knowledge from someone who runs the engine periodically for a few minutes.  So if you were the system administrator for this server for "several years" I would expect you to know its operations inside and out.  And that is not an unreasonable expectation.

    @blakeyrat said:

    And the "logging" point means "centralized, organized logging".
    Syslog.@blakeyrat said:
    Meaning, the OS keeps track of when the Service starts, stops, or has an error and the Service itself keeps its logs in the same place.
    Syslog.

    @blakeyrat said:

    My impression is that pre-Service daemons put their logs "eh whatever" and there was no OS-level logging of when they started, stopped or had an error.
    Your "impression" is incorrect.  Any daemon worth its salt has a syslog logging functionality.

    @blakeyrat said:

    Since the OS handles the logging, you can do a whole bunch of neat stuff (like centralizing the logging for an entire network on a single computer) at the OS-level without having to rewrite or reconfigure your Service.
    Syslog.  RFC 3164.

    @blakeyrat said:

    Additionally, Services can be auto-rebooted by the OS where (again in my experience) with daemons you had to write a little monitor program that would keep an eye out to restart it as necessary.
    Okay . . . well, we just had one of our mail services crap out on a Windows machine and Windows didn't restart it automatically.  Took an administrator to go in and restart it.  But Windows is supposed to restart these services.  Now you're going to tell me how my administrator is shit and doesn't know what he's doing and blah blah blah, yet you're the one telling me that the OS is supposed to be able to restart this services automatically.

    @blakeyrat said:

    It works for you. It does not work for the person who learns sudo as "the magic word that makes commands not fail" and uses it before every single command.

    If I learn the word "fast" to mean "characterized by a lack of speed", that means I learned the wrong definition.  sudo is not "the magic word that makes commands not fail".  It provides for access to administrative functions when you need them and provide for a way to log who executed them.

    @blakeyrat said:

    As for requiring the password the first time, Ubuntu Server's default configuration doesn't do that.
    In my "Scotsman experience" it doesn't do that.  I ask with all sincerity:  did you install this server from scratch or did someone else do it?  If you did it, then I can't explain the difference -- I've never known a default Ubuntu installation to not ask for my password on first invocation of sudo.  If someone else did it, then I would think he/she/it made a change on sudo's behavior.

    @blakeyrat said:

    Oh you just SELECTIVELY read the thread. Fuck.
    Again, you ignore the context.  I was explaining to you how it operates within the GUI not because it applied to this situation, but because I wanted to give insight on how the GUI reacts in the same situation.

    @blakeyrat said:

    (Why isn't "proports" in Chrome's dictionary)

    @nonpartisan said:

    As a side note, I believe the word you're looking for is "purports"

    @blakeyrat said:

    . . . Google results made it look like "porports" was the correct spelling.
    @blakeyrat said:
    ILLITERATE

    Let the irony sink in.  I'll wait . . .



  • @Monomelodies said:

    Windows keeps a dir.exe somewhere in the $PATH, just like *nix has /bin/ls.
    Yeah, actually . . . that's not quite true.  cmd.exe has a number of built-in commands -- commands that, indeed, have equivalent executables on a UNIX-type system.  dir, copy, rename, erase, del, cd, md, rd, . . . all of those are built into cmd.exe.  That was the design back in the MS-DOS days with command.com (which was the basis for cmd.exe).  If they were executables you'd need to have some kind of a system disk in a floppy all the time in order to use the command prompt, which just wasn't practical.

    I had a lot of fun hacking on command.com back in the day.



  • @boomzilla said:

    This is fucking retarded, even for blakeyrat. So, when you installed it on Windows, and it was so easy, you didn't have to know anything at all? You clicked on the magic "Install MongoDB" button, right?

    Did I ever make that claim? Quote me. I dare you. Because it's not here.

    You MADE IT UP. IN YOUR TINY LITTLE SKULL. Then claim I said it. Like you always do. Because you're Boomzilla: Worst Human Being Alive. DIAF.



  • @nonpartisan said:

    The point is scope.  You said you were a "system administrator".  If all you ever did was to restart a service when it had problems, you were not a server administrator.  You were a server technician.  You were the equivalent of someone working in the operations center.  If I am a system administrator, I expect to know my administration tools and the operation of the operating system's tools.

    Stop it. Just fucking stop.

    If you are incapable of engaging in a debate without pulling this completely irrelevant "no true scotsman" bullshit then don't even fucking bother typing the posts, because from this point on I'm not fucking reading them. I've told you TWICE that it's irrelevant. IT IS IRRELEVANT. GO AWAY.



  • @blakeyrat said:

    @nonpartisan said:
    The point is scope.  You said you were a "system administrator".  If all you ever did was to restart a service when it had problems, you were not a server administrator.  You were a server technician.  You were the equivalent of someone working in the operations center.  If I am a system administrator, I expect to know my administration tools and the operation of the operating system's tools.

    Stop it. Just fucking stop.

    If you are incapable of engaging in a debate without pulling this completely irrelevant "no true scotsman" bullshit then don't even fucking bother typing the posts, because from this point on I'm not fucking reading them. I've told you TWICE that it's irrelevant. IT IS IRRELEVANT. GO AWAY.

    I'm so glad I'm not as angry as this.

    I'm also glad that I understand how my systems actually function.



  • @nonpartisan said:

    @blakeyrat said:

    See? See? We get into this stupid "no true scotsman" shit.
    The point is scope.  You said you were a "system administrator".  If all you ever did was to restart a service when it had problems, you were not a server administrator.  You were a server technician.  You were the equivalent of someone working in the operations center.  If I am a system administrator, I expect to know my administration tools and the operation of the operating system's tools.

    If you run the engine of a car for five minutes once a month while it's in storage, that doesn't make you a driver.  That makes you someone who starts the car once a month.  I wouldn't expect you to know the full operations of the vehicle.  If you are a driver of the vehicle . . . one that you've driven "for several years" . . . then I would expect you to know the vehicle, how to operate the lights, the radio, the AC, etc.  I wouldn't expect that level of knowledge from someone who runs the engine periodically for a few minutes.  So if you were the system administrator for this server for "several years" I would expect you to know its operations inside and out.  And that is not an unreasonable expectation.

    @blakeyrat said:

    And the "logging" point means "centralized, organized logging".
    Syslog.@blakeyrat said:
    Meaning, the OS keeps track of when the Service starts, stops, or has an error and the Service itself keeps its logs in the same place.
    Syslog.

    @blakeyrat said:

    My impression is that pre-Service daemons put their logs "eh whatever" and there was no OS-level logging of when they started, stopped or had an error.
    Your "impression" is incorrect.  Any daemon worth its salt has a syslog logging functionality.

    @blakeyrat said:

    Since the OS handles the logging, you can do a whole bunch of neat stuff (like centralizing the logging for an entire network on a single computer) at the OS-level without having to rewrite or reconfigure your Service.
    Syslog.  RFC 3164.

    @blakeyrat said:

    Additionally, Services can be auto-rebooted by the OS where (again in my experience) with daemons you had to write a little monitor program that would keep an eye out to restart it as necessary.
    Okay . . . well, we just had one of our mail services crap out on a Windows machine and Windows didn't restart it automatically.  Took an administrator to go in and restart it.  But Windows is supposed to restart these services.  Now you're going to tell me how my administrator is shit and doesn't know what he's doing and blah blah blah, yet you're the one telling me that the OS is supposed to be able to restart this services automatically.

    @blakeyrat said:

    It works for you. It does not work for the person who learns sudo as "the magic word that makes commands not fail" and uses it before every single command.

    If I learn the word "fast" to mean "characterized by a lack of speed", that means I learned the wrong definition.  sudo is not "the magic word that makes commands not fail".  It provides for access to administrative functions when you need them and provide for a way to log who executed them.

    @blakeyrat said:

    As for requiring the password the first time, Ubuntu Server's default configuration doesn't do that.
    In my "Scotsman experience" it doesn't do that.  I ask with all sincerity:  did you install this server from scratch or did someone else do it?  If you did it, then I can't explain the difference -- I've never known a default Ubuntu installation to not ask for my password on first invocation of sudo.  If someone else did it, then I would think he/she/it made a change on sudo's behavior.

    @blakeyrat said:

    Oh you just SELECTIVELY read the thread. Fuck.
    Again, you ignore the context.  I was explaining to you how it operates within the GUI not because it applied to this situation, but because I wanted to give insight on how the GUI reacts in the same situation.

    @blakeyrat said:

    (Why isn't "proports" in Chrome's dictionary)

    @nonpartisan said:

    As a side note, I believe the word you're looking for is "purports"

    @blakeyrat said:

    . . . Google results made it look like "porports" was the correct spelling.
    @blakeyrat said:
    ILLITERATE

    Let the irony sink in.  I'll wait . . .

    Maybe you make excellent points but I'll never know because your post is unreadable and tedious. Anyways when I saw "server technician" I wrote you off as a bore. "Computer operator" would have a bigger impact.



  • @Speakerphone Dude said:

    Maybe you make excellent points but I'll never know because your post is unreadable and tedious. Anyways when I saw "server technician" I wrote you off as a bore. "Computer operator" would have a bigger impact.
    I'll include a pony next time.  Maybe I should apply for the main page writing job.



  • Is there an operating system around where the errors don't suck? "The parameter is incorrect" "The system cannot find the path specified" – which parameter? In what way was it incorrect? Who specified a path, how, why, where, and what is this path anyway? Windows is horrendously awful for vomiting up errors that have absolutely no bearing on the command given by the user, errors that don't even begin to suggest what might be wrong. At least "are you root?" is helpful.

    I have also had rm fail silently on Debian. The file remained present after every attempt to remove it. According to lsof, the file was not open in any process. (I did forget to check the exit code of ls, but according to the man page, there don't seem to be any.)

    What was the cause? A daemon hadn't shut down after I'd instructed to, and an uninstall script had also told it to, and neither case reported any error there either. A plain kill (SIGTERM) closed it instantaneously: I forget whether the file vanished or whether I was then able to remove it. A file that, as I said, Linux pretended wasn't open.

    And yes, I see red when I receive error messages where the software is too frigging lazy to check the problem for itself; this is the best one I've seen to date:

    The path C:\dfrg.msc was me copying over a "working" copy of the MMC snap-in from my PC to conclusively rule out every one of the suggestions from MMC. I never did figure out what was wrong – I rebuilt the snap-in file from scratch and it worked perfectly.

    Linux is no worse than Windows – they both suck horribly, just in different but overlapping ways, and neither one of them reports errors properly. Mac OS Classic was immensely good at understanding the user's intent and offering helpful solutions, but at the same time it was just as likely to report gibberish like "error of type 25" or (my favourite) "error of type -110" (essentially random underling failure). I kept various error code list applets to hand to decode this crap. Just give me the error as a string!!!



  • @blakeyrat said:

    So if a library exists, WHY THE HOLY SHIT IN HELL IS THE GUI TOOL CALLING THE CLI APP!??!??!!?>!?@>

    Your post explains nothing, it just raises more questions!

    I'm surprised nobody brought up this point previously: the CLI defines a protocol. Anything built against that protocol can be insulated from irrelevant internal changes to the underlying library, so by default, it's preferable to write other software against an app's CLI rather than its library API. It's a basic *nixy philosophy.

    So that explains 1) why it's done, and 2) why there is such strong resistance to changing the way it's done.



  • @Daniel Beardsmore said:

    Mac OS Classic was immensely good at understanding the user's intent and offering helpful solutions, but at the same time it was just as likely to report gibberish like "error of type 25" or (my favourite) "error of type -110" (essentially random underling failure). I kept various error code list applets to hand to decode this crap. Just give me the error as a string!!!

    Mac Classic didn't have memory protection. Every single error could just read, "something stomped over memory and now it's crashing, and we don't really know what or when did it". I'm sure the vague names were due to there not being any really good way for the OS to tell what actually caused the problem.



  • I went through (as part of my schooling) a semester long drill instructor style education on CLI linux. Not Ubuntu or BSD, straight CentOS with no GUI available, or even allowed. We did text everything; text installation, text configuration, text usage. We even wrote our reports and papers in vi and printed them with cups. IMHO the Linux CLI makes both Windows and OSX's look like useless junk. Does it have a learning curve? Hell yes, it has a bitch of a learning curve and I had to put every ounce of energy into the class to come out with an 85%. But that kind of curve is reserved for tools that are extremely powerful and useful.

    Parenthetically, blakey, I agree with you on a lot of things, but just because you don't pick up on it within 5 minutes, or it's so bluntly obvious that anyone could, doesn't mean it's badly designed. It just means you don't know everything, and that's ok, no one else does either.



  • Expanding on the previous post...


    I should make it more clear that I'm talking about Enterprise linux, not Desktop linux. Desktop linux is largely shit, and that's largely because of arrogance (if you don't know how to use it, you shouldn't be using it) and as I've pointed out before, if that's the game they want to play that's fine, but then they should drop the "year of linux" crap, because it's not going to happen.


    That said, CentOS, which for the uninformed is a free version of RedHat with no official support, is quite nice. It's rock solid, I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.



  • @blakeyrat said:

    Mac Classic didn't have memory protection. Every single error could just read, "something stomped over memory and now it's crashing, and we don't really know what or when did it". I'm sure the vague names were due to there not being any really good way for the OS to tell what actually caused the problem.

    Error 25 was well-defined and meant out-of-memory, which one would imagine was a relatively important message to convey on a system that required manual adjustments to process memory allocation.

    I maintain that it was the same stuck-in-a-rut laziness that we see in every OS to this day. Of course, ASP.NET is the opposite and likes throwing entire stack traces at end users. That's mostly due to click-monkeys though: I do agree with the general sentiment of the comments that anyone administering a server should know what they're doing and understand the system in depth. Windows is to a server OS what VB is to programming languages, in allowing any idiot to have a crack at it. Same old story across the industry.

    It's a half-way meet: Linux needs a lot of polishing and tidying (no more lying about having deleted files it didn't, and make apt-get not be a fragile piece of junk) but companies need to hire and train compentent sysadmins. Below the candy coating of Windows, there is so much that goes wrong, and Windows is ill-equipped to deal with it. The scant information in the event log (and never anything relating to any real problems you have, just garbage due to known bugs), and menial progress dialogs are not conducive to understanding and maintaining such a complex system.



  • @Master Chief said:

    That said, CentOS, which for the uninformed is a free version of RedHat with no official support, is quite nice. It's rock solid, I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.

    It has awful repos and its latest supported version of glibc is 3 major versions behind.



  • @Master Chief said:

    I went through (as part of my schooling) a semester long drill instructor style education on CLI linux.
    @Master Chief said:
    IMHO the Linux CLI makes both Windows and OSX's look like useless junk.

    THAT IS BECAUSE YOU SPENT MONTHS BEING BRAINWASHED TO THINK THAT

    Holy shit people show some self-awareness when you post here christ.



  • @Master Chief said:

    I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.

    How many printers does one man need?



  • @Speakerphone Dude said:

    @Master Chief said:
    I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.

    How many printers does one man need?

    Nine and a half.



  • @Master Chief said:

    IMHO the Linux CLI makes both Windows and OSX's look like useless junk.

    How is one unix system that drastically different than another unix system? OSX has a BSD userspace, runs bash by default in terminal. Has a lot of useful system commands to handle various mac specific tasks (applescript, text-to-speech, network services, reading data from the systems ROM).

    As much as I agree with you for most other things.. Linux and OSX are both *nix command lines. You can install any posix compatible application on either of them.



  • @Daniel Beardsmore said:

    Am I the only person who sees "MMC" and automatically expands it as "Mickey Mouse Club"?

     



  • Yes. You are a freak and should be hunted down and killed.



  • @blakeyrat said:

    For example, I mentioned I was surprised that Ubuntu Server finally has Windows-like Services, but I still don't know if it has all the event logging features that Windows has (the ones I mentioned in a previous post) because I haven't had a need to look into it.
    Technically it does; there's a program called "syslogd" that most programs that don't have their own logs spam messages to, and it handles filtering them and storing them in one or more centralized locations, which can include spraying them over the network on UDP port 514 to the host of your choice. And yes, Upstart uses that facility to log when things start and stop. Unfortunately, there's no pretty GUI like Windows' Event Viewer that I've been able to find; the plumbing is all there, but someone forgot to attach the faucet.



  • @blakeyrat said:

    "click-monkey". Very diplomatic.

    I apologize, that was indeed uncalled for. "Fucking retard fuck you fuck fuck fuck." Better?

    @blakeyrat said:

    Sometimes I talk about how things should be and not how they are.

    Actually, you sometimes rant on how things are not how YOU expect them to be. Which is not necessarily the same. What's happening here is that you're essentially saying "Linux should be more like Windows. I like it better that way." and a bunch of are replying "No thanks".

    @blakeyrat said:

    That's not a hint, that's a question. It pisses me off because the error is useless. It doesn't give you any information you need to solve the problem.

    Ehm, yes it does: you'll need to become root (or check if another process is keeping your repositories locked). In what world is that not helpful?

    @blakeyrat said:

    Or, even better, it could have just automatically asked me to elevate instead of giving me an error at all.

    That is a debatable point, but I'll grant you it would be nice to have as an option for the sake of user-friendliness. Having said that, not all Linux systems have sudo (my servers sure don't, way too risky) so it would add needless complexity. I actually think it would be impossible due to the way Linux keeps user accounts separated (i.e., the root account does not know what command some user was previously trying to run and vice versa) but I'm not a kernel hacker so I can't really be sure if this is possible at all.

    Hm... thinking this over: it probably would be possible. But on second thought, it's ridiculous; Linux 101 is "become root if you need to do anything system-wide". If you don't know that you should stay away from the system.

    @blakeyrat said:

    Gibberish. "connect" to a GUI? Utter gibberish.

    I'd honestly be interested to learn how in fact Windows and OSX pull this off, then. It is my understanding that both run the GUI as a service (iexplore.exe and X respectively, IIRC) and that applications are bound to that (and will refuse to start if it's turned off).

    @blakeyrat said:

    In the sense that applications have useful command line switches? I guess not. Relevance?

    ...in that we are debating CLI's and their use?

    @blakeyrat said:

    BTW, you should try Mac Classic. There's no command line switches because there's no command line.

    Now THAT seems like a retarted idea to me. Good luck fixing stuff if the GUI goes down for whatever reason.

    @blakeyrat said:

    Your head would explode.

    I highly doubt it. I'd probably shake it in amazement at such a silly design choice, though.

    @blakeyrat said:

    It does? First I've heard of it. Googling "dir.exe" brings up an anti-virus site as the first hit. I honestly think you have absolutely no idea what you're talking about.

    I stand corrected on this one, apparently WinME was the last version that did this (either that or my memory is faulty). I know DOS did that and that up to ME Windows ran on top of DOS. I only have a VM with Vista here and that indeed does not have it anymore (so it's probably built into cmd.exe, though I'm willing to bet it's essentially still the same code...).

    @blakeyrat said:

    The problem is the "one thing" in this case was "install mongodb", and APT did not "do it well".

    It did it fine once you invoked it correctly.

    @blakeyrat said:

    (The other problem is the Linux philosophy is crap, what "one thing" is for example a spreadsheet application supposed to be doing well? The only answer is "be a spreadsheet application". But that's another thread.)

    Point being? Yes, that's absolutely the one thing it should be doing well. One of my pet peeves with OpenOffice.org is that they provide their own graphical UI instead of plugging into the system's; a clear violation of the principle.

    @blakeyrat said:

    Look, I'm not even 100% against the Linux philosophy. The problem is, it doesn't make any sense to string together applications with UIs if you're making these compound tasks. What makes 1000,00000,00000000 times more sense is to string together libraries that have no UI and let to do things like, pass around data that isn't text! Or handle errors in an intelligent way! Or let the people who are building the UIs change them to their heart's content without breaking other programs! Wouldn't that be utopia?

    Unless we're actually speaking a different language, that sort of exactly describes a *nix system. A shell command with options != a UI. A shell command that handles only text is fine doing just that. Added bonus: I can still use it from a command line in case of an emergency. But I can see how that would be scary if you're used to reinstalling or restoring an image in those instances.

    Obviously, a spreadsheet application does NOT consist of 1000 CLI tools strung together. Because, like, that would make no sense at all. I'm also entirely unclear what you think is unintelligent in Linux's error handling, especially when compared to Windows'.

    @blakeyrat said:

    Hell, if you actually went through every bulletpoint that a software product like "Active Directory" implies, you could come up with some pretty long lists. The problem is Linux users literally do not know what features Windows has, and they literally think Linux does all of the same things.

    Well, I could just as easily turn THAT one around. But then, I've never understood what's so incredibly useful about AD as opposed to something like Kerberos and mounting /home from a central NFS server. Mind you, I'm a programmer and part-time server admin, not a business network administrator, so it could very well be AD serves a purpose I'm not seeing.

    @blakeyrat said:

    And of course my Linux knowledge is pretty out-of-date so I'd be pretty bad at it. For example, I mentioned I was surprised that Ubuntu Server finally has Windows-like Services, but I still don't know if it has all the event logging features that Windows has (the ones I mentioned in a previous post) because I haven't had a need to look into it.

    Linux has had daemons and associated runlevels since, well, forever. And I can't think of one that doesn't offer to log to syslog. I personally don't use Ubuntu Server, so out of interest: what changed that makes you think they're somehow "more like Windows" these days?

     



  • @TwelveBaud said:

    Unfortunately, there's no pretty GUI like Windows' Event Viewer that I've been able to find; the plumbing is all there, but someone forgot to attach the faucet.

    Out of interest, what does Event Viewer have to offer that 'less /var/log/syslog' doesn't? Or 'tail -f /var/log/syslog | grep 'my-broken-command''?



  • @blakeyrat said:

    Which is HORRIBLE. Like, "crime against humanity horrible". Why is ANY UI (meaning USER interface) being used by things that aren't USERS? Why isn't there an API for that?

    Exactly. This is something a lot of CLI enthusiasts fail to understand. Automation through the CLI is equivalent to using tools that move your mouse and click buttons in a GUI. Trust me, I know. I've had to automate certain graphics software in a studio environment and sometimes it was the only way. Another thing I learned is that solutions like these, be they in the CLI or GUI, are incredibly fragile. One misplaced character on the CLI or one pixel off on the GUI and the automation fails.

    Scripting a CLI and automating a GUI are just really unfortunate workarounds for a lack of an API provided by the developer. When it comes to *nix this is usually due to laziness on the part of the developer because, let's face it, open source is typically about glory coding, getting to code the fun stuff you don't get to code at work, and building APIs for your software usually isn't much fun. I mean, Twitter had a human-usable site to tweet with before it had the twitter API, right?

    Finally, on the subject of usability, the CLI is the least discoverable interface possible. Even automated phone menus are easier to use since they actually let the user know where they are and what options they have.



  • @Monomelodies said:

    @TwelveBaud said:

    Unfortunately, there's no pretty GUI like Windows' Event Viewer that I've been able to find; the plumbing is all there, but someone forgot to attach the faucet.

    Out of interest, what does Event Viewer have to offer that 'less /var/log/syslog' doesn't? Or 'tail -f /var/log/syslog | grep 'my-broken-command''?

    The ability to be found, run, and used without knowing an arcane set of CLI commands off by heart. Not to mention a nicer UI, analytics, documentation, subscriptions (allowing alerts and emails without yet more CLI-fu).



  • Dear me …

    @Monomelodies said:

    I stand corrected on this one, apparently WinME was the last version that did this (either that or my memory is faulty). I know DOS did that and that up to ME Windows ran on top of DOS. I only have a VM with Vista here and that indeed does not have it anymore (so it's probably built into cmd.exe, though I'm willing to bet it's essentially still the same code...).

    No and no. DOS did not use DIR.EXE – it was built into COMMAND.COM. Windows 9x did not run on top of DOS. dir may still be the same code, after it got rewritten to run off the Win32 API with long name support, rewritten to handle Unicode etc.

    @Monomelodies said:

    I'd honestly be interested to learn how in fact Windows and OSX pull this off, then. It is my understanding that both run the GUI as a service (iexplore.exe and X respectively, IIRC) and that applications are bound to that (and will refuse to start if it's turned off).

    Seriously? You think Internet Explorer (iexplore.exe) is a service that runs the Windows GUI? (iexplore used to be a thin wrapper around the Internet access libraries and the Shell Document Viewer (shdocvw.dll) library, which is why explorer.exe and iexplore.exe were interchangeable. I don't think this is true any more!)

    As far as I've ever been able to observe, the Windows GUI is monolithic and integrated: no process or service is directly responsible for it, though you have services that assist it (themes, multiple sessions etc). The Mac OS X GUI is definitely not X (the X Window System): it's a PDF-based renderer.

    Linux on the other hand does have a truly discrete GUI and it's not tied to any particular one: when Linux was ported to Psion palmtops, for the Psion Revo they went with PicoGUI instead of X11 because the Revo only has 16 MB of storage and X11 needed something like 40 MB just to itself. I forget the specifics now, only that Linux is independent of the choice of GUI and runs without it. Even Windows Server now can be built without the GUI, but I have never studied how this works, given that the GUI is so tightly integrated into Windows.



  • @Soviut said:

    Not to mention a nicer UI, analytics, documentation, subscriptions (allowing alerts and emails without yet more CLI-fu).

    Seriously? The new Event Viewer is horrible. I couldn't imagine a more sluggish behemoth – Linux lets you search or follow logs without needing to sit there while the bloated new UI loads every log entry going back to the extinction of the dinosaurs into RAM first.

    Also, it lacks obvious features such as right-click → Filter → By this event / By this source / By this date ... – if you've used Sysinternals tools you have to wonder why Microsoft buying them up still hasn't resulted in any decent UI making it into Windows tools. There's also no calendar selector to jump to the day or hour when you know a problem occurred: every part of the UI is sluggish and with poor keyboard accessibility.



  • Re: Blakeyrant's opinion about Debian's god-awful package CLI tools

    @Monomelodies said:

    @blakeyrat said:
    In the sense that applications have useful command line switches? I guess not. Relevance?

    ...in that we are debating CLI's and their use?

    No, we're not, apparently.  Don't be distracted by the misleading subject.  Here, I'll fix it for you.



  • @blakeyrat said:

    @Cassidy said:
    Yeah, I'd explained that in an earlier post. I just made an assumption that Blakey had read it.

    Yeah it just doesn't make sense. Why does APT download from where its cache says to instead of where the live server says to? And if it tries to download from the cached path, and hits a 404 error, why doesn't it check the live server to resolve the error?


    Sorry - my response was more aimed at bannedfromcoding, although he expanded upon the explanation better than I had.

    AIUI, the idea is that there's a scheduled job refreshing the cache so that apt checks this, rather than hitting the update servers all the time. Of course, if you manually tweak your download sources, the caches will be out of date, so there's a manual command that instructs apt to refresh the caches. It's a similar principle to a DNS caching.

    Whether or not

    @blakeyrat said:

    "Your cache is out-of-date, let's just fail in a retarded way instead of checking the live server."
     

    I'm not sure what retarded way it failed for you. I used to get a message saying something like "perhaps you need to run 'apt-get update'" and I found that manually running that then re-running the "apt-get install" command seemed to work. I read up about why it does that and... it didn't really interest me. All I gained from the explanation is:

    1. use the GUI tool and it'll do a refresh for you
    2. use the command line and it should instal
    3. if the command doesn't work, manually refresh your caches and try again - it'll probably work

    @blakeyrat said:

    WHO CARES WHAT DISTRO IT WAS RUNNING. IT IS NOT RELEVANT

    Because different distros do things in different ways. There is some commonality between them, but don't assume that just because one distro does it in a specific manner that ALL Linux distros follow that pattern. It's rather like shouting WHO CARES WHAT VERSION OF WINDOWS IM USING ITS NOT RELEVANT ITS ALL MICROSOFT IT SHOULD WORK THE SAME WAY. Linux should be considered the group or the vendor, rather than the product itself.

    And yeah, the differences and simularities between them are ample fodder for WTFs, but let's not get derailed with further Linux-bashing. Those fish can stay in that barrel a while longer.

    @blakeyrat said:

    1) Why should I have to research things to install a DBMS?

    @Cassidy said:

    WAT? Is this a "why should I be expected to learn what the hell I'm doing?" question?

    @blakeyrat said:

    I knew what I was doing: installing mongodb. I didn't need to learn that, I already knew it.

    The problem is that accomplishing the task "install mongodb" requires a lot of knowledge that has nothing to do with knowing what the hell I'm doing. It shouldn't.

    Okay, I was going to go pedantic dickweed on that - but you kinda answered it for me. You knew what you wanted to do, just not how to do it, and I'll contend that you should be expected to learn/research that stuff in order to perform the required steps correctly to acheive your goals. If you don't put the effort in, you won't get the rewards you deserve.

    I think you're identifying two things:

    1. that these actual steps are much easier - or made much simpler - under Windows than under Linux
    2. the install instructions on the vendor's webshite sucks hairy sweaty donkey balls.
    Now 2 I won't disagree with. Many instructions in the Linux are poorly-written: gramatically incorrect, inaccurate, out of date, inappropriate level of detail, badly-translated, etc. Stupidly, there are some well-written HowTos which shows that it can be done, but I've never expected a particularly high quality of documentation out in the open-source world - they're the expection, rather than the norm, but it's an accepted cost of volunteer-driven projects.

    It's 1 that some people are taking issue with, and most arguments really boil down to "if you're familiar with the process, then following it for the umpteenth time is fairly routine. If you're new, then the process itself isn't easily discoverable and unfamilar people will struggle." As you're using Ubuntu Server I'm guessing you may not have a GUI to play with - otherwise you may find those tools an utter relief from command-line frustration you've encountered.



  • @Soviut said:

    @Monomelodies said:
    @TwelveBaud said:
    Unfortunately, there's no pretty GUI like Windows' Event Viewer that I've been able to find; the plumbing is all there, but someone forgot to attach the faucet.

    Out of interest, what does Event Viewer have to offer that 'less /var/log/syslog' doesn't? Or 'tail -f /var/log/syslog | grep 'my-broken-command''?


    The ability to be found, run, and used without knowing an arcane set of CLI commands off by heart. Not to mention a nicer UI, analytics, documentation, subscriptions (allowing alerts and emails without yet more CLI-fu).

    You know, Linux *does* have a GUI tool like that.  Except, of course, that whole 'ability to be found' bit.  It's not installed by default, and, if I recall correctly, it doesn't have an intuitive name.  I happened on it while looking for something else, installed it, played around with it, and then removed it as not very useful for me, since I excel at the CLI-fu.  But it is (or at least was, years ago - Hardy timeframe?) in the Ubuntu repository somewhere.



  • Lemme break it down: tail prints the last N lines of a file to standard output. Adding -f (--follow) makes it continue to read until stopped. grep does searching. Those are basic Linux command line tools. You should know them, along with less, man, and :(){:|:&};:



  • @blakeyrat said:

    @Master Chief said:
    I went through (as part of my schooling) a semester long drill instructor style education on CLI linux.
    @Master Chief said:
    IMHO the Linux CLI makes both Windows and OSX's look like useless junk.

    THAT IS BECAUSE YOU SPENT MONTHS BEING BRAINWASHED TO THINK THAT

    Holy shit people show some self-awareness when you post here christ.

    If by brainwashed, you mean educated and trained, then yes.


  • @Master Chief said:

    @blakeyrat said:
    @Master Chief said:
    I went through (as part of my schooling) a semester long drill instructor style education on CLI linux.
    @Master Chief said:
    IMHO the Linux CLI makes both Windows and OSX's look like useless junk.

    THAT IS BECAUSE YOU SPENT MONTHS BEING BRAINWASHED TO THINK THAT

    Holy shit people show some self-awareness when you post here christ.

    If by brainwashed, you mean educated and trained, then yes.
    RTFman


  • @Ben L. said:

    @Master Chief said:
    That said, CentOS, which for the uninformed is a free version of RedHat with no official support, is quite nice. It's rock solid, I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.

    It has awful repos and its latest supported version of glibc is 3 major versions behind.


    Quite true, but I also don't get the cryptic incompatibility errors when I install packages. What is there may be old, but it works, and if I have to choose between new and shiny and stable and useful, I'll choose stable and useful.



  • @Speakerphone Dude said:

    @Master Chief said:
    I have two machines running it on my home network, neither has been rebooted since we moved in (3+ years). I've used Apache, SQL, several FTP daemons, and host all of my printers on them, and any time there is a problem with something, it's never the CentOS machines.

    How many printers does one man need?


    A laser for black and what reports n such, a color laser for graphs, graphics and whatnot for school/work, and a photo printer for photos. I'm kinda big on the "use the right tool for the right job" thing. I should add that the CentOS server in charge of them hasn't had a minute of downtime since it was configured, and all the machines in the house including a couple Macs, Windows 7/Vista/XP machines, and even a Desktop Linux machine, all connect to it just fine.



  • @gu3st said:

    @Master Chief said:
    IMHO the Linux CLI makes both Windows and OSX's look like useless junk.

    How is one unix system that drastically different than another unix system? OSX has a BSD userspace, runs bash by default in terminal. Has a lot of useful system commands to handle various mac specific tasks (applescript, text-to-speech, network services, reading data from the systems ROM).

    As much as I agree with you for most other things.. Linux and OSX are both *nix command lines. You can install any posix compatible application on either of them.


    Yes, but a lot of the Mac stuff is just...weird. There's no other word for it. My vi has never worked quite right, the hotkeys seem to be sitting on each other. Not to mention, Apple took all the usual commands and skinned over them with new names, which is just dumb. After some clever aliasing I had it working like a proper CLI, but before that, it was like trying to thread a needle by tying it to a brick first.


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    This is fucking retarded, even for blakeyrat. So, when you installed it on Windows, and it was so easy, you didn't have to know anything at all? You clicked on the magic "Install MongoDB" button, right?

    Did I ever make that claim? Quote me. I dare you. Because it's not here.

    You MADE IT UP. IN YOUR TINY LITTLE SKULL. Then claim I said it. Like you always do. Because you're Boomzilla: Worst Human Being Alive. DIAF.

    This is hilarious. Yes, of course I made up the magic button. I thought that would be clear to any semi-literate (or semi-familiar with Windows) forum goer. You didn't give details of how you installed on Windows, so of course I was speculating based on what you said. But since everyone else is also more familiar with what you write than you are, here's what you said previously:

    @blakeyrat said:
    BTW, I thought Mongo was going to be a pain to install in Windows, but it was actually quite painless. They even built in a mode so it can run as a Service, which admittedly did have a bug, but the bug was well-documented and easily fixed.

    Now, you didn't say exactly how you installed it, but that it was quite painless (though there was some service-related bug that you had to fix somehow). And you've cut the post to which I was replying, which was you whining about how you shouldn't have to know anything about anything other than "I want to install MongoDB." And my obvious point was that you were on a system (Windows) that likely requires you to know about more non-install related things than you would on Ubuntu. That little quote of your right there definitely assumes a fair amount of knowledge on the part of yourself with respect to the system you were working with. I would have described my installation of MongoDB on Ubuntu as even more painless (and no pesky bugs to work around...and it automatically started running as a service). But then I'm familiar with installing software there in a way that you clearly are not.

    As has been pointed out, there are several applications provided by Ubuntu whose main purpose is installation. So (to belabor this since you're too stupid to figure it out), you probably had to know something about your web browser, and how to find and download the right installer. Then you had to know how to run the installer. Then you had to know how to set it up as a service. Again, all of that stuff would have been handled for you if you just understood how to install software on Ubuntu.

    I'd like to thank you, once again, for making this so easy. You're like a WTF straight man. I'm looking forward to the post where your Ubuntu C: drive has gone missing.



  • @Cassidy said:

    @blakeyrat said:

    @Cassidy said:
    Yeah, I'd explained that in an earlier post. I just made an assumption that Blakey had read it.

    Yeah it just doesn't make sense. Why does APT download from where its cache says to instead of where the live server says to? And if it tries to download from the cached path, and hits a 404 error, why doesn't it check the live server to resolve the error?


    Sorry - my response was more aimed at bannedfromcoding, although he expanded upon the explanation better than I had.

    AIUI, the idea is that there's a scheduled job refreshing the cache so that apt checks this, rather than hitting the update servers all the time. Of course, if you manually tweak your download sources, the caches will be out of date, so there's a manual command that instructs apt to refresh the caches. It's a similar principle to a DNS caching.

    I don't know about y'all, but I tend to install new packages on a box very rarely, and I probably only check for new updates about once a month, unless I hear about a security vulnerability in one of my packages.  So, basically, this is optimizing things by updating a cache every day that is, for the most part, unused.  And, when it is needed, it may be broken because I've made a change that should trigger a cache update, but it doesn't.

    <sarcasm>Good job, Debian!</sarcasm>

    DNS caching works by specifying a time to live on entries when you do a lookup, and keeping the cache until that time expires.  So, if by 'a similar principle to a DNS caching', you mean 'not at all like, apart from the fact it's a cache', then spot on.  Incidentally, the Yellow Dog package manager that RedHat has adopted uses a cache more like the way DNS uses it.  I'm not sure if it's a repository-defined TTL (like DNS) or a static TTL (like the DNS standards non-compliant nscd), however.

    That having been said, I'm not with Blakey on this one, only because I believe in using a distro that works.  If he'd change his focus from 'Linux CLI sucks because Debian has retarded package management tools' to 'Ubuntu sucks because it uses Debian's retarded package management tools', I'd agree with much more of his viewpoint on this thread.


  • ♿ (Parody)

    @Monomelodies said:

    Out of interest, what does Event Viewer have to offer that 'less /var/log/syslog' doesn't? Or 'tail -f /var/log/syslog | grep 'my-broken-command''?

    With event viewer, you have time to get a cup of coffee, read the paper, etc. With those other things, you've generally found what you're looking for way too fast, and then you have to go back to work.



  • @Master Chief said:

    My vi has never worked quite right

    % cat ~/.vimrc
    set fileformats=unix,dos,mac
    % 

    HTH.  HAND.

    No, I have no idea why that isn't the vim default *everywhere*, but not having it on MacOS X is especially gratuitously bad.  Now, if you were expecting MacOS X's vi to work exactly like vi, rather than vim in vi compatibility mode due to your not having a .vimrc, then, well, you need more help than I can offer.  But I''d suggest some reading up on vim, and how it's many times better than vi.  My personal favorite vim addition, I think, is recording and replaying macros.



  • Blakey, do me a favour and answer these two questions, please:

    • IF you'd know up-front that Linux software should be installed from the distribuition's package repository (appstore-like concept) and not from the maker's website, do you think you'd avoid making some of the mistakes?
    • IF you'd try to install this software on Windows while being totally unfamiliar with Windows, and the crappy instructions on maker's website would tell you to edit the registry, delete a system file (but only if you don't have service pack 13), and do similarly idiotic things, would you blame Windows or the instructions?

      I'm genuinely curious.


  • @Monomelodies said:

    Actually, you sometimes rant on how things are not how YOU expect them to be. Which is not necessarily the same. What's happening here is that you're essentially saying "Linux should be more like Windows. I like it better that way." and a bunch of are replying "No thanks".

    No; I'm saying Linux should be easier to use. I never said it should be more like Windows. I did point out, for comparison's sake, that many of the problems Linux suffers from have been solved by OS X and Windows.

    @Monomelodies said:

    Ehm, yes it does: you'll need to become root (or check if another process is keeping your repositories locked). In what world is that not helpful?

    The error message doesn't say you need to become root; it asks if you are root. That is a different thing. Cue exasperated "I can't believe I had to explain that." Erm.

    @Monomelodies said:

    I'd honestly be interested to learn how in fact Windows and OSX pull this off, then. It is my understanding that both run the GUI as a service (iexplore.exe and X respectively, IIRC) and that applications are bound to that (and will refuse to start if it's turned off).

    Haha wow. And you work in IT? You don't know anything.

    iexplore.exe is an application dipshit. I would say you meant "MSHTML.DLL", but that's just a web browser and has nothing to do with the GUI. (Except that, if you point it at a window handle, it can draw a webpage into it.)

    The GUI in OS X and Windows is a first-class citizen. It's not something applications "connect" to. (Again: that statement is total gibberish.) The application says to the OS, "hey open me up a window" and they're a GUI application. There's no "connecting". There's no service involved. The GUI is a first-class citizen because it's the part of the computer users interact with, and therefore by far the most important component.

    You don't know anything.

    @Monomelodies said:

    @blakeyrat said:
    BTW, you should try Mac Classic. There's no command line switches because there's no command line.

    Now THAT seems like a retarted idea to me. Good luck fixing stuff if the GUI goes down for whatever reason.

    The GUI is the OS. That's all the user ever sees, so that's all Apple wrote. If the GUI "goes down" (and seriously, even in Mac Classic, that never happened-- your mind is so warped by unstable Linux software you must think everybody else crashes all the time too) then you just reboot and there it is again. Did it crash? Yeah. Sorry. No memory protection, an application could take the system down. In practice it didn't matter.

    @Monomelodies said:

    @blakeyrat said:
    Your head would explode.
    I highly doubt it. I'd probably shake it in amazement at such a silly design choice, though.

    I would like to again point out that Mac Classic was a fuckload more successful on the desktop than Linux has ever been.

    @Monomelodies said:

    @blakeyrat said:

    The problem is the "one thing" in this case was "install mongodb", and APT did not "do it well".

    It did it fine once you invoked it correctly.

    And to its credit the last error (the 404) actually says in the error message that running apt-get update might fix it. (It was too fucking stupid to just update automatically on its own, but eh.)

    But I had to go outside the system to invoke it correctly. I had to leave the screen where I was trying to run the command and hit up Google and Twitter for help. That is a problem that needs to be solved.

    @Monomelodies said:

    @blakeyrat said:
    (The other problem is the Linux philosophy is crap, what "one thing" is for example a spreadsheet application supposed to be doing well? The only answer is "be a spreadsheet application". But that's another thread.)
    Point being?

    Wow. Point being, if that's honestly how I'm supposed to read it, it's useless.

    Look, what I was getting at is that people use spreadsheet programs to do extremely diverse tasks, everything from preparing a .csv file for uploading into another system, to data analysis with pivot charts, to project planning with gantt charts, to making a list for mail merge, to ... actually using them as a virtual accounting spreadsheet (but that's rare.) You said a program is supposed to do "one task" and do it well. Well, I just named 5 tasks. Which of those is the "one task" for a spreadsheet?

    That is the problem I was trying to point out. To do so, I made the "hilarious" suggestion that the only "on task" that fits a spreadsheet program is "be a spreadsheet program". Which is obviously useless and makes the statement "do one task and do it well" useless.

    Obviously that was far too clever for you, I'll try harder next time.

    @Monomelodies said:

    Unless we're actually speaking a different language, that sort of exactly describes a *nix system. A shell command with options != a UI. A shell command that handles only text is fine doing just that. Added bonus: I can still use it from a command line in case of an emergency. But I can see how that would be scary if you're used to reinstalling or restoring an image in those instances.

    The problem is that if you're using the CLI application as a sort of ad-hoc API for other applications (shell-scripts, GUI applications that inexplicably wrap it instead of using the proper API directly, etc) then you've gotten yourself in a shitty situation where you can never upgrade the CLI application without breaking other applications. So if someone comes up with a radically better version of apt-get you can't actually put it on the system because if you did, oh that guy's shell-script would break and oh those 4 GUI apps would break and nobody wants to rewrite them. Which means the entire system stagnates, no problems can be fixed, no deficiencies can be corrected, due to that one shell-script written in fucking 1973.

    That's insane. You can't tell it's insane because you're inside the asylum looking out, but trust me: that's insane.

    @Monomelodies said:

    Well, I could just as easily turn THAT one around. But then, I've never understood what's so incredibly useful about AD as opposed to something like Kerberos and mounting /home from a central NFS server. Mind you, I'm a programmer and part-time server admin, not a business network administrator, so it could very well be AD serves a purpose I'm not seeing.

    You think Internet Explorer is a service every GUI app in Windows has to somehow "connect to". You don't know shit. I'm not going to engage a person who doesn't know shit on AD.

    @Monomelodies said:

    Linux has had daemons and associated runlevels since, well, forever. And I can't think of one that doesn't offer to log to syslog. I personally don't use Ubuntu Server, so out of interest: what changed that makes you think they're somehow "more like Windows" these days?

    Maybe the only change is that they used the word "service." I already said I didn't know, why are you still asking? Believe me, I didn't spend my fucking Saturday researching Linux.



  • @Daniel Beardsmore said:

    Seriously? The new Event Viewer is horrible. I couldn't imagine a more sluggish behemoth – Linux lets you search or follow logs without needing to sit there while the bloated new UI loads every log entry going back to the extinction of the dinosaurs into RAM first.

    Oh yeah no doubt. Microsoft really fucked up on that rewrite. But it still has a lot of features in a handy GUI package.

    @Daniel Beardsmore said:

    Also, it lacks obvious features such as right-click → Filter → By this event / By this source / By this date ...

    You can do that, it's just not in the contextual menu. It's under the "Filter" button in the "Action" pane (which you may have turned off to help with the bloat.) And its UI is awful, like the rest of the new Event Viewer. But it is there.


Log in to reply