Slashdot Mirror
The Case Against GUIs, Revisited
snydeq writes "Deep End's Paul Venezia advocates the importance of the command line, in light of the increasing use of GUIs in today's technologies, as well as the increasing perception among admins that proponents of the CLI are dragging computing back to the 'dark ages of the C:\ prompt."
I use Linux specifically for the powerful Bash-fu.
You should just be able to talk to your computer and get whatever results you want.
... speaks more of the admins who assume that "CLI" == "C:\ prompt".
Or the idiots who think "CLI" == "the GUI in front of me is therefore made unusable". The people at "GUI Industries" can't make a link or shortcut to the appropriate script?
Why would you trust an admin who can't, as TFA indicates, edit a text file?
As I see it, the difference between a GUI and a CLI is the difference between ordering from a menu and telling the waiter exactly what you want. Both are useful, but there are times when being able to say exactly what it is you want is really nice.
This is dead on. Human beings invented symbolic language because it's simply more expressive than pointing and grunting. CLIs are superior to GUIs for the same reason.
Give me Classic Slashdot or give me death!
I'm afraid I can't let you do that, Dave.
There's no -1 for "I don't get it."
I haven't used windows since '99.
looking around my desktop right now, while posting to slashdot, I have chromium running, and 7 xterms. Two of'em are running irssi, the others are just nice little windows to do various bits of work in.
I live and breathe in a CLI environment. I can't really remember doing much useful in GUI's except lookup information (for which it's suited perfectly well).
But why on earth would you do configuration in a GUI? Why would you ever program in a GUI, instead of vim or emacs?
I just don't get it.
"Rune Kristian Viken" - http://www.nwo.no - arca
CLI is not essential. It's a holdover from a time when we thought words were a good way to express function. And then left the 'e' off "creat" for kicks.
Everything can be done in a GUI. I don't see why not. We just haven't made that happen yet.
I can back up the claim that the CLI is making a huge come back. I run a feed on twitter and identi.ca called @climagic that is becoming very popular. I think that people are trying to find ways to do the things that they need to do in GUIs and when it can't be done, they find that it is easier to access and manipulate your data using Unix command line tools in very efficient ways. Does that mean that its great for everything? No of course not, I'll admit that I use the GUI for many things too, in fact, I do graphical work in Blender and Inkscape and listen to music in Pandora and do my browsing in Firefox because it works well for me, but in many places, I can get my work done using the CLI and still wow people with iPhones and Androids in 2011.
Well of course nobody wants to continue to use a Windows CLI, it IS from the dark ages.
I read the first couple of paragraphs, got bored, and skimmed the rest.
So, he prefers command lines for admin stuff. I can understand that if that's what you do day in and day out. There's nothing more efficient - especially if you're running scripts which you really can't do with a GUI.
For the rest of us who may do a particular admin task once a year, a gui is a wonderful help and makes thing MUCH easier.
Administering Linux became so much easier when the GUI admin tools came out years ago - oh, and it made SAMBA actually usable for us average people!
GUIs are great for repetitive, predictable functions and data visualization.
CLIs are great for ad-hoc processing.
People who need a GUI to do complex processing of a one-off chunk of data are just as incompetent as people who set up a text-based way of monitoring a 4000 node network. They're tools, people, the screwdriver will NEVER replace a hammer.
A command line is more flexible than a GUI could ever be. It just has a steeper learning curve. Since computers are more mainstream these days GUIs are more prevalent. That doesn't decrease the value of command lines though.
except that software should be accessible by design, and GUIs have issues for blind people.
Ever see an NFS server not work because the config file had a space instead of a tab? How about something not working because you picked two options that conflict with each other? A gui would not allow that. Thankfully apache split httpd.conf into multiple files because it was getting several thousand lines long. A gui could have all those options in a few tabs and a hovering help box if you really wanted.
Yeah yeah scripting blah blah, multiple setups, how about taking a screenshot of the gui?
Only the State obtains its revenue by coercion. - Murray Rothbard
I'm not sure if this is the case, yet it seems GUI layers of garbage introduce a layer of viris vulnerabilities. CLI, I'm game with it.
cmd.exe is a terrible shell. The new Powershell Microsoft has is pretty nice. I like it more than Unix shells. I find passing objects between commands to be easier. Now Microsoft just needs to dump their console.
how this is news?
Slashdot: News for CEO's, stuff that's obvious!
--stoops
Anyone who thinks that a command line prompt starts with a 'C:\' has no idea what they're talking about.
Systemd will do more to rub out the use of the command line than any thing since the gui. The author has decided for every one that applications should be able to figure every thing out for themselves and passing switches and arguments to them is archaic. This will remove the incentive for application writers to bother adding interfaces to applications that will alter their functionality. That will give us fewer reasons to use the command line. It is a vicious circle.
I'm in the middle. I like GUIs for a lot of advanced program usages that I haven't learned on my own yet, but, for example, I've never found a visual DNS utility I liked. They're all just too slow. Classic (read: non-AJAXy) Web Interfaces are worse. Maintaining a router via it's built-in web server is antagonizingly slow.
Having said that, most everything else I do is all command line work.
The idea that people have to be on either side of the fence is almost as ridiculous as there being a metaphorical fence to begin with. I use a desktop OS (Windows 7) and I love cygwin, which I run in Console2. The two can be used together, you know. There's no need for it to be a black and white discussion -- only useful for making one seem 1337 or 'in the know' and bicker like tools. We have both -- why not love both?
Truth, Just Us, And Hatred For All Mankind!
I still contend that primarily menu-driven terminal(doesn't actually need to be a terminal but it should operate like one) interface, with more complex textual input as appropriate, is the most efficient method of operating many line of business apps. Simple, focused, repeatable and able to be understood by anyone that can read.
Sounds like a mixture of GUI and CLI.
Is this really a case against GUIs or really a case for more powerful GUIs? GUI doesn't always mean pulling up a form that matches a record and saving it.
For example: What if they had a GUI that displayed the network info in a grid of text boxes with configurable rows and columns? What if they could set up the form to match the spreadsheet's rows/columns and paste the spreadsheet data into the grid and update the network tables that way?
Hence why they came up with Powershell, which I have to say is rather good, and many Server 2008 tasks demand a basic knowledge of it.
Hell it even has grep (findstr), though sadly it hasn't go a worthy sed substitute.
For all intensive porpoises your a bunch of rediculous loosers
While the C:\ prompt would really be the Dark Ages all over again, command lines done right can be significantly faster to use for experienced admins. Not to mention they can also be used in diverse interface environments like serial connections in almost exactly the same way that they are used anywhere else. It's significantly easier to script from the command line as well.
Just about every shell available on a UNIX-like OS is at least ten times better than DOS ever was. Lumping in bash with DOS is like taking a BMW and saying it is equivalent to a Yugo because they both have four wheels and an internal combustion engine.
There's certainly a place for a GUI, and well designed GUI apps are lifesavers in big environments where seeing a graphical representation of 1000 servers as icons and being able to click and drag to select and execute group commands is a much easier way to work with that many servers. Having 1000 lines of text zoom by is going to be hard to take in at a glance. I love the GUIs that I use for certain tasks like visualization and management of complex environments.
Still, anyone who considers the command line to be the Dark Ages either doesn't know how to type, doesn't understand how to use a CLI, or is simply trying to sell you a pretty GUI app.
that the new ubuntu start menu has a part when you can run programs... by typing the names of them!
because scripts don't work
thank God the internet isn't a human right.
There is some places where their use may overlap, and some places where it doesn't.
Interestingly, I had to put little watermarks on about 400 images a year ago. It took about 5 minutes of scripting with ImageMagick to do it.
If I'd done that with Photoshop or GIMP, I'd still be at it!
A picture (GUI) is worth a thousand words. Why use a thousand words when one or two CLI words will do?
GUIs are, in fact, essential - without them, slashdot would not exist.
GUIs are useless at performing repetitive tasks. The emergence of PowerShell on the MS platform in the last few years means I can do stuff that was previously impossible to do - maybe throw user objects around between AD, SQL Server and SharePoint. Heck, even the GUI tools are based on top of the PowerShell commands.
In fact, PowerShell is one of Microsoft's best moves, and something that has sorely been lacking from the Windows platform for too long.
CLIs are also really good for:
1) Configuration differences
2) Compliance logging
My company (www.uplogix.com) makes a device that does these two things for a wide range of advices. It's pretty damned useful. And it doesn't rely on the GUI maker adding useful logging of each step done in the GUI. You have the text session. You know exactly what the user did.
As an avid CLI user on *NIX and Windows I would vehemently object if I was dragged back into the "dark ages" (aka 1980s). It seems that as soon as you mention CLI this is what people bring up for an argument. I suspect these are the same people who have not taken the time to objectively evaluate a modern CLI be it bash or powershell or something similar.
I humbly suggest these are the same people who have never had to log into and click away on a GUI to configure an option because the package does not have any CLI support on 30+ machines. Don't get me wrong, GUIs are great for a great many things but there are many tasks where a good script and a command line beats the GUI hands down. A simple example is turning 70+ machines over in a computer lab to put them in a special "exam state". With scripts and command line this takes literally less than 1 minute to hit all machines. Now I suppose if you had some nice admin tool GUI that allows you to point and click to select a set of actions to perform on each machine or group of machines you could achieve the same thing but I have yet to see it.
Goddamn, you can tell this is a site for geeks. People who use command line are about 1% of people who use computers. The reason we all have jobs is because so many people use web sites and software these days. The only reason so many people DO use websites is because they DON'T have to use command line!
America, Home of the Brave.
The difference between a GUI and a CLI is that a CLI rewards understanding with capability.
GUIs are appropriate to non-expert systems where functionality must be patently clear. Think of your smartphone / PDA, or a consumption-oriented computing device (iPhone, iPad, PowerBook).
If you're administering or creating content, you'll eventually want the power of a real scripting tool.
for scripting things there is nothing like the CLI. only thing i have seen even close is automator on macs
I have with most GUI'd applications is that they lack the ability to do batch processing, something that is almost completely lost on most devs especially of smaller tools, I ended injecting my own code into the running processes of some (non OSS) applications to get bloody batch processing into them the way I needed it (this may not be a problem in casual use of course, but when you have to perform the same operation on 5000+ files it is, and when the only tool available is one that lacks the functionality, frankly doing this would've taken a couple of days at least, while poking around the application with a debugger and reversing it only took a few hours...)
What do you mean "C:\ Prompt"? Did you mean the "bash-4.1$" prompt?
How about AutoIt?
http://www.autoitscript.com/site/autoit/
Or any number of other GUI automation tools. Did you know that Windows 3.x used to come with one?
Mind you, it's not very flexible. But neither is 'the CLI' without any number of utilities. E.g. grep. Where would the CLI be without grep?
But for automating some complex tasks, it's almost just what the doctor ordered - especially when the thing you want to automate doesn't have any CLI option.
Having read the article, the author's issue seems to be with importing tables. The Linux dude does it via CLI and hey presto, and the Windows dude does it via GUI and hand-enters each individual record and fat-fingers something and screws everything up by the time it goes live.
Ignoring the cheap Linux vs Windows association... this seems like a gripe with a device that -only- has a GUI front-end which, in addition, despite apparently being marketed at enterprise solutions does -not- have a file field with browse button to browse for a table to import.
No offense - but that's not a CLI vs GUI issue. That's a CLI vs BAD GUI issue.
Imagine if the device didn't accept the rule files over the CLI via a file and instead required manual entry, while the GUI version had the file field and browse button. Would he then be praising the GUI?
"Why Paul Venezia sucks, soon to be revisited" as he's bound to make other such comparisons given his obvious bias.
Command lines discriminate against those with poor memories. GUIs make it possible for people who can't remember detailed shit to be productive without having to constantly refer to some other resource(s).
I learned English well enough that I rarely require a dictionary, but I was never so lucky with programming languages and other syntaxes. I love my GUI... when it's implemented correctly. Paul Simon wanted his Kodachrome, and I want my GUI.
Why does this always have to degenerate into a Campbell's Chunky Soup "Fork or Spoon" debate? Why not just use the most appropriate interface for the task at hand?
A GUI can be shit for some things, and (unless you live and breathe CLI) a CLI can be too complex and unwieldy for other things.
Does it make you happy you're so strange?
> And when's the last time you edited photos [] with a CLI?
I do that all the time. I want a set of photos that are standardised for size and compression and with a copyright mark. I throw the ones required into a dir (using text mode midnight commander) and run a script.
The advantage of CLI tools is that if I need a GUI I can easily knock one up to take the parameters and run the CLI tool to do the actual work. In many cases these GUI front ends already exist.
All tabs, one after the other? Every single config page called out from a tree selector in a sidebar? The pages that scroll - carefully scroll each one in turn and make repeated screenshots? You're practically guaranteed to leave something out. Then to recreate the same config on another system what do you do? Repeat the entire exhausting process in reverse? When you're done, you're practically guaranteed to have errors because the entire process relies on a human doing tedious work that a script should be doing perfectly every time.
A config file that differentiates between tabs and spaces is an inexcusably badly designed config file. It says nothing about a weakness of the CLI.
Master Foo Discourses on the Graphical User Interface
One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful.
"The command-line tools of Unix are crude and backward, he scoffed. a Modern, properly designed operating systems do everything through a graphical user interface."
Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand.
I don't understand you!, said the programmer.
Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window.
"What are you trying to tell me?" asked the programmer.
Master Foo pointed at the programmer's head. Then he pointed at a rock.
"Why can't you make yourself clear?" demanded the programmer.
Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan.
As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him.
At that moment, the programmer achieved enlightenment.
(http://www.catb.org/~esr/writings/unix-koans/gui-programmer.html)
There is no debate here. The CLi is good at some things and the GUI for others. They both serve valid purposes. I love and hate both at times. --the religious capitalist "send me $50 to be saved"
A GUI is really awesome if you want see different information from different sources, and make specific actions that cannot be automated.
The two of them need to coexist - use the best tool for the job, which could be either a CLI or a GUI.
Guns don't kill people, "with glowing hearts" kills people.
Why not just have both? Lets take apache httpd.conf for example. Someone who's good at CLI can whack that open in vi/emacs, jump down to the line they want and change an option, or write a script that appends their configuration (eg. adding a vhost) automatically then roll it out across multiple servers. And then, for people who aren't doing a specific change and need to be able to see what's going on (eg. first time setup, where you're going through a lot of the options as you go anyway) can have the GUI open, where the GUI is just a pretty front end for the text based config underneath. Cisco routers work this way, they've got the web based gui that you can set things up in, or you can work in the CLI and config everything that way. Why not just offer both and give the users the choice to use whatever they please? Both CLI and GUI have advantages.
In other news, some random computer journal writer said the existence of the right hand should not mean we cut off the left.
Could you please re-architect your post in a GUI expressing the same point?
Apple has some work on this area that is instructice to consider. Have a look at Applescript, which is an (admittedly crappy) simple language for scripting GUI applications in a standard manner. I do hate Applescript very much, and consider it one of the worst languages ever, but still, the basic mode is the important thing here: GUI applications expose their functionality in a standard fashion through a textual interface that supports programming.
Are you adequate?
What do you mean "we," white man? You don't think embedded software development provides jobs? Very little of it has anything to do with GUIs.
This article is really about why you should use a provisioning system for backend process management. Using a CLI or GUI to complete the configuration are both lame choices.
Why pay engineers to continually make redundant configuration changes to backend systems at all?
Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
--Kenneth Thompson
... with some regularity.
Especially if your systems administration involves a photo / graphics oriented site. Usually just trivial bulk resizing or cropping, but other edits can also be necessary, whether of photos or art, GUI elements, monitoring plots, and/or A/V / multimedia content, etc. I've heard that there might even be a few of these with significant numbers of users.
And yes, ImageMagick has powered a few mainstream major (think 40m members+) websites.
But any person not able to use a CLI effectively is not a "computer professional" let alone admin material. Especially System administration, but basically anything that can be automatized is the domain of the CLI. Those that cannot use the CLI lack essential skills in what is still the most powerful human-computer interface method. GUIs are specialised tools and have a limited scope. Within that scope they may do fine, but that is it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." --Kenneth Thompson
"creet"? That's even worse!
Are you adequate?
I mean, if the GUI is really straightforward they could just have the receptionist do it.
Why do we have so much text in GUIs?
Yesterday I had to install some applications. I had a pile of debs. Some were the dependencies and what have you. Installing all those using gui would have taken forever. Or I just did "dpkg -i *.deb" and I was done. Use sed or awk just once and gui is blown away.
A dividing line in human history is the invention of writing. That's what differentiates pre-history from history. After the invention of writing we have records of what happens, before that it's up to archaeologists to dig ancient garbage dumps to infer things.
Incredibly, there are people who want to run the inverse way in computing.
What next, will we have to climb trees to use computers?
If you are unable to think of examples in which a GUI is better suited to configuration than a CLI, then I think you have TTV syndrome.
The rest of us see pros/cons on both sides of the issue.
Get (or write) software for the GUI that does the same thing the CLI does. Choose group of workstations. Put checkmark in box to select all and then deselect the ones you don't want. Click "OK". Done
Now you don't have to worry about having the wrong (or missing) character in your cryptic string of text commands.
In other news, using round wheels takes you back to the dark ages.
Some things will stay for a long time... You can improve on them but their essence will remain.
This is an example of someone being right and wrong at the same time. He is right for the year 2011. I work in a massive IT infrastructure and clearly the goal is to cheapen the workforce. This is done through GUI's. The trend is to get unskilled labor to perform the complex tasks SA's et al perform now. Software is starting to get so advanced that you can see the light at the end of the tunnel. One example is Solaris fma which is supposed to manage hardware (normally done by humans now) They have been developing it for a long time and frankly I dont think it works yet, but I think they will succeed some day. I have noticed that the newer talent coming onboard doesn't despise GUI's like us old farts either, they kind of like them. I think that author just committed suicide - he clearly doesn't know what he is talking about, at least from an empire standpoint which is the only thing that really matters.
My dotcom boss used to say "DOS is dead" when I was using command line in Windows NT3.5. Hmmph.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
..because after all, 640k should be enough for everyone.
Now, if you'll excuse me, I have backups to corrupt.
In the beginning was the command line - a great short story by Neal Stephenson.
- read it, it helps put things in a more proper perspective.
http://www.cryptonomicon.com/beginning.html
After reading yesterday's post on Creating the Software Art In Tron Legacy I started thinking about the limited way I was using the shell in my day to day work. I was thinking that there has to be a better way, some sort of middle ground between the shell and GUI. I don't want to give up the power that the shell provides, I don't even want to take my hands off the keyboard - I just want a richer more contextual display. My computer is capable of rendering very slick graphics but my shell makes no use of it. Does anyone know of any projects that are working towards a graphically enhanced shell?
Unexpect the expected!
So many comments for a non-story. Yes, most people use both depending on their task, to make the task the most bearable. Both have their plusses and minuses which have been discussed time and time over. If you are one of those people who think that you are leet if you use CLI, or the other kind of person who thinks CLI is for basement dwellers only, I sympathize with you.
Because if you have a decent shell and you know how to program, half of what you do involves writing little programs for tasks that the GUI designer either did not anticipate, or could not support without incorporating a programming language. Most people who know how to use CLIs use GUIs for the jobs the latter do well, but users who cannot program have no idea of what they are missing from not being able to use the CLI effectively.
The MS-DOS command line is excluded here, by the above caveat of a 'decent shell'. Trying to do anything useful in a DOS box makes one realize just how clever the creators of Unix were. Fortunately, there is Cygwin...
There will always be a place for the command line:
GUI's make easy tasks easier, but hard tasks impossible.
(I have half a dozen command shell windows open at any given time in Windows -- unixtools for windows (sed, awk, grep, etc.) are absolutely invaluable to stay sane.)
... I think the fine article was completely misguided. For example, WSH script could have read the spreadsheet that eas mentioned, parsed the data into URLs that call the web interface for the "GUI" only router, and completed the task in much the same way as the article suggested that the CLI be used to solve the problem.
In other words, it's not the actual GUI holding the GUI Corp back, but a failure of admins to adequately understand the tools at their disposal. Given that the author is familiar with UNIX, he knows how to do things the Unix way. It should be no surprise that he doesn't know how to do an enterprise level roll out using Windows style tools.
Experts argue that humans should cut off their arms, as they are much worse than legs when used for tasks such as walking and running.
Just ask anyone old enough to remember Hypercard.
Or, for that matter, NetBeans.
New kids on the block may find the SSIS snap-in for MS Visual Studio to be a good example.
The problem isn't GUI vs, CLI per se. The problem is click and drool interfaces that sacrifice flexibility for simplicity and end up ony approriate for simple tasks.
I'm an artist and have spent a good part of my life working with Max, Maya, Pshop, AutoCAD and many more tools.
I have long loved the command line of ACAD - it's been well over a decade since I used it in a production environment but I still think that it struck a fine balance between GUI and CLI. I'm not sure if ACAD captures the above Author's intentions but it does illustrate that simple, human-readable text commands are fairly easy to learn with some diligence and can grow to be extremely powerful.
I used ACAD (back in the version 4-7 days) for many years on my own and in isolation. I used the UI exclusively. I was slow. I later (around when version 13 came out) started working with teams of people. The first day I saw them working, I freaked out. I remember going home and spending days-on-end learning the commands. Within a few months, I was a speed demon like the rest.
"I hate these filthy neutrals Kif! With enemies you know where they stand but with neutrals? Who knows! It sickens me."
dragging computing back to the 'dark ages of the C:\ prompt.'
Well there's your problem right there. Comparing all command lines to a command line system where choice.com was king, loops were crafted from GOTO statements, and return values meant nothing consistent. Even the C:\ prompt in Win7 these days is much better. cmd.exe is passable with For, and powershell is quite nice. But [ba/[t]c/k/z]sh is better than anything native on a windows system, not to mention the standard gnu utils.
What is Google but a command line interface? Your browser url bar? Your start menu search box with integrated desktop search? Then there's something called the Web.
It seems CLI and GUI has been hybridized after a brief fad of flashy GUI (now isolated to gimmicky tablets). If you actually IT at the momment, rather than post on a website blog about the IT industry you'll find yourself working more and more with web interfaces. No CLI, no native GUI. It's just how it's all going to be done. (please take away some of the CLI and crappy native interfaces I have to deal with PLEASE!).
Ultimately 80x50 inline text sucks for representing any information. Since re-flowable HTML and the hyperlink it's as obsolete as dinosaur DNA. Ultimately you can sit down to a very powerful web app or the occasional well designed GUI and start getting shit done. You don't have to read the man page or all but read the source code to use it, which I might add, man pages still don't have examples. GUI you don't learn, you just use it. Ironically, most CLI work is done from a GUI.
Have worked with CLI for years, I cut my teeth on it way back, it still helps me out but I don't delude myself that CLI is somehow magical or is in some way a superior interface it's not. It's often epic usablility and discoverabiltiy fail and completely ignores advancements in human interface over decades). I don't need that doublethink in order to cope. Admit it, it sucks. But we use it at times and we get awesome shit done.
Thats what matters.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Simply use the right tool for the job at hand; both GUIs and CLI have their place.
This article reeked of 'get off my lawn'.
My gripes are less about GUI vs Command Line but more on the designs for these tools. I have used excellent CLIs and terribly horrible CLIs and the same goes for GUIs. If they are done well for their particular purpose then no argument from me, I'll use them. My concern is the # of GUI and CLI interfaces that make me pull my hair out when I go to use them. So often designers and testers are seem to not be testing real world scenarios nor real world scales and some designers seem to not have a clue when a GUI or a CLI is more appropriate. CLIs that are interactive only, don't use return codes effectively, and don't provide easy to understand outputs (where it takes a natural language parser to understand the output for example.) GUIs can offer a whole different set of frustrations.
When you can get the best of both worlds? gnome-do. I just type meta+space "te" return and I'm in the terminal. meta+space "ch" return gets me into Chrome. For more obscure programs, the visual feedback is nice, but the intuitiveness of typing is also very nice.
. . .counting my punch cards and listening to Elvis on paper tape. Oh, the good old days.
If proponents of the CLI feel threatened by the GUI, they must be horrified by the FUI.
On another tack, I did a quick search and nobody seems to be calling the new interface the FUI - Finger User Interface. It seems so obvious that I can't believe I'm the first to do so.
Both scenarios in at "CLI Inc." were cases of editing config files, not using a CLI. The same sed command that was used to modify the config for the BIND server and the Cisco box could have been done better with a good GUI text editor that supports regular expression based find and replace. The Windows admin could have done exactly the same text editing (at least for DNS), or could have scripted the whole thing. I've scripted a web based GUI more than once in my career.
.Net classes. Both are vastly superior to a CLI. Most Windows administrative tasks already have a CLI these days. If they don't, or if you want to make a better one, simply whip up a PowerShell script to use as a CLI.
The sad fact is that most Windows admins are bad at automation. However, it isn't the platform's fault. Windows is so easy to administer that any half-witted moron with enough persistence can manage to hold a job. There are a lot that are good at it and Microsoft has a plethora of tools for those who see the value in them. What is important isn't a CLI, but a usable API on which to build. CLIs are the "lowest common denominator" of APIs. UNIX and Linux have had a hard time establishing a common API, so that's what they are left with. Microsoft has been through several generations of APIs, each better than the one before. In the mid 1990s, any Windows admin worth his paycheck was doing VB Script with COM. Today, they are using PowerShell with
OK we get it. Shell scripts and pipelines are still great for system administration and general file system maintenance. GUIs are better for a lot of other things, like surfing the web and (yes) editing documents.
While command lines are powerful, and ill admit that the little i know of Linux has taught me it versatile, far more then windows. some people just have a hard time remembering command lines; I am a visual person and remember pictures better then words, therefore, GUI's work best for me. There is nothing wrong with either, Linux has its advantage and M$ also has its advantages (i know, i disgust myself)
Simple GUI's for simple jobs, and CLI's for more detailed jobs.
That's what Apple does with its servers, and it does it fairly well (still a way to go, but it's going in the right direction).
Nevermind the limited menu systems and the unidentifiable icons, GUIs lack any means for users to use multiple programs beyond the clipboard (mouse cut'n'paste) also available on CLIs.
For example, I type
$ du -m | sort -n | tail -69
to get the 69 largest directoriess under the current working directory (often but not always /). And something only slightly more complex to search logs for the IPs who have attacked me most. I have lots of neat one-liners like this stored in my command history ~/.bash_history and will often use one as a template for a new task.
${SUBJECT}. GUIs that do things in the background using the CLI are really the best that I have used. You get the benefits/eye candy of the GUI, but can script anything you need. Examples are Veritas volume manager and their cluster manager (hagui). They even get bonus points for logging the GUI's command line calls in a log file so you can see what was done. You do it once in the gui and then script the other dozen/hundred actions. (Or, help maintain a change log of the system for recover/rebuild purposes.) EMC's Legato used to do it as well. (Up to early 7.x, not sure how the newer 7.5/7.6 is doing things.)
Who the fuck is Paul Venezia, and why should we care?
Perhaps I'm trolling, perhaps I'm not.
This is pointless troll-baiting. GUIs have their place for complex tasks that may be done infrequently. I don't want to have to dig out my reference manual or google search every time I want to perform a task. CLIs are perfect for batch, repetitive tasks that may be done a dozen or more times a day.
The secret is, most good interfaces offer both a CLI and a GUI.
Slashdot is such garbage these days it's barely worth visiting.
Despite the heading, the article is "Things that can be scripted make batched actions easier and faster than things that cannot be scripted". The rest of the article is just strawmanning. (That's totally a word now...)
His router-changes example doesn't even use the CLI interface on the router, it has the router upload the script to a TFTP server, the admin edits it (not using a CLI, I hope, but some kind of text editing software), and causes the router to fetch it back and execute the script. Hell, a router with a web GUI doesn't even need a TFTP server, you can upload and download the file using HTTP. Or edit the script live with a handy javascript syntax checker, if your router developer's so willing...
I'm going to take this opportunity to scoff at his "lesson in IT", imperilled as I might be.
*scoff*
Paul "TBBle" Hampson
Paul.Hampson@Pobox.Com
An anecdote is not even data, let alone proof. And a hypothetical anecdote is even less.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
There's an article about MS bashing being kicking puppies, and here you are kicking cats... what has the (hello,) world (\n) come to?
... that are really quite simple?
A GUI is for when you don't know what you are doing.
A CLI is for when you do.
Retrocomputing is my hobby. My current project is a Origin 300 machine, which I can communicate with in one way: with an old DEC VT525. If I'm feeling feisty, I even have a TTY 43 I've hooked up on occasion, which completely eliminates the possibility of doing anything that requires the cursor to be addressable. That means no vi, emacs, nano, lynx, etc. Just me, ed, awk, sed, and a bottle of scotch. This is a machine that has /dev/tty, and it really means it. 38400 baud, N/8/1. NO keyboard port, and NO framebuffer of any kind.
Really, what I'm saying is that this is a machine with nothing but the CLI. But this is not what most people are speaking of when they get all GUI-hateful. I can't open a Xterm window, because X is not even installable on this machine. I have to do it the old-fashioned way.
How I wish I had a GUI, if only so I could pop open a bunch of terminals and arrange them all pretty. And then complain on Slashdot about how the GUI is *ruining* my day. With Firefox, which doesn't count, because even though I pray to the gods of vi, I'm not going to try to use lynx to get that tarball I need. I mean what are we, primitives?
Be thankful that someone invented GUIs. Hell, be thankful that someone invented the pixel-addressable display for you. I have 80x24, with 4 pages of scrollback, and that's about it.
Of course, that's what makes it fun, and as a hobby I wouldn't have it any other way, but I'd have to have my head examined if I seriously proposed doing actual work with a strict CLI interface.
using a command-line interface. I'm a huge CLI guy, but GUIs have their place.
That's the other thing about the CLI vs GUI debate. It doesn't only ignore the fact that you can use both together, but that some applications are neither CLI nor GUI. Yes, they have GUI versions, but emacs and vim are fundamentally not GUI applications. They are, let's speak it, full screen text mode.
Full screen text mode is not a CLI. There are editors that run in a pure command line. The most famous is ed. When vi was invented, it was a big step up from ed, but it wasn't a full replacement because it required full screen text mode.
Full screen text mode is certainly not a class of GUI. It doesn't require graphics. It may borrow concepts from a GUI, like pointers, menus, even windows, but it isn't graphical because it doesn't require the operating system to have graphics capabilities.
Full screen text mode is what we were using before GUIs took off. For certain tasks, it can be as usable as a GUI. It does, however become redundant when you have a GUI, hence vim and emacs get upgraded to GUI applications. The CLI, then, is the survivor, and full screen text mode gets written out of history.
When are the teological discusions going to end. This is old news, and still people fight it as if their life depended on it. Chill out.
As humans we can make sense out of the lack of order in the linux commands. While the windows GUI with it's limitations is much easier to use. The sad part of the story is that we don't really have a better alternative to either of them yet. The windows powershell, althought I have not user it myself may be a wakeup call to Linux, or maybe not. While people are willing to learn arcane nomenclature and adhoc syntax, there is not really much any CLI alternative can do.
The bigger question is while we invest time in petty MS vs LINUX discussions, we miss the third alternative. What will be the better way to do what we do. the repetitive tasks. As well as ease of use and learning? Does a Steve jobs need to come and spell it out with a product (like he did with the iphone) before we can begin to understand that there ARE other posibilities!!!
That should be where our energies should be invested towards.
I think it was Rob Pike who quoted this first: What You See Is All You Get. (WYSIAYG). Now read that carefully. I didn't type What You See Is What You Get, thats the old WYSIWYG. The idea behind WYSIWYG is that what you see on the screen is what will be printed on your printer. Its doesn't mess with the fonts, or colors, or formatting of the text. Its what most people wanted in the old DOS days when dot matrix printers would give them something very different from the display. When Rob Pike stated "What You See Is All You Get", what he meant is on a graphical user interface, in the name of clarity and forms creation, some information will be left out to make the form less cluttered. In a CLI, they print everything the system can generate, and there are tools the user can use to suss out the various pieces that are immediately relevant. With a CLI, you start off with more than you want, and filter it to get all you want. With a GUI, you get what they give you, some of which might be useful, and some of which might not be useful. They filtered some stuff out when they made the form, and there aren't enough ways to make a form changeable without turning it into a CLI. For printing, WYSIWYG is good. For system administration, WYSIAYG is bad.
Executive Overload?
Perhaps you ought to turn off the approach radar...
This is not equivalent. find does a deep search, while globbing */*.jpg will yield all files ending in *.jpg in the first level subdirectories (and only those files and directories whose names don't begin with a dot, except when an obscure shell option is enabled).
My exception safety is -fno-exceptions.
A maintained Yugo will run FOREVER, but DOS, specifically, command.com and cmd.exe, are handicapped pita, like a car without wheels or an engine -- its why Microsoft finally built a car, they call it PowerShell
Thank you so much!
I was already missing my daily fix of incoherent gibberish and mentally disturbed practices.
Again, thank you so much. You don't know how much fun you bring into people's lives.
This is silly, CLI and GUI interfaces aren't mutually exclusive. They're both good for different things. They're two different tools with the same end goal; an apples vs oranges comparison is relevant here. You can argue about taste, but you can't argue that they both satiate hunger and get the work done.
That said; as a programmer it makes most sense to create a CLI program and then slap a GUI on top of it. Codewise you can test more easily, you can more easily create logs from the program, and the program becomes easier to script - while still remaining useful and easy to handle for those people who don't intend to use it very often.
I would like to argue that the elitism caused by pro-cli users will only in the end harm the Linux cause if we want to get normal desktop users to start using it.
... it doesn't need an "API" proper. HTML allows for forms to be prefilled via URL calls. Since the fine article stipulated that the router had a web frontend as its GUI interace, a WSH script can prefill and submit any form thatt is displayed merely by calling a URL.
And, even were that were not the case, so long as the GUI widgets are named, WSH scripts can manipulate them programatically. And, even if they aren't named, there is the possibility that automation is possible via other mechanisms such as manipulation of hot keys, tabs, etc. I wrote some scripts in WSH to do performance testing circa 2005 that did just this. It called a series of proprietary programs, to time how long it would take to log into a database, complete specific tasks tasks, and log out.
CLI is best for admin work, a few scripts and you've semi-automated most of the admin work. Compare that to the click here-and-here-and-here method. That's why it takes less staff to admin a Linux service than a Win er .. GUI one. Even on the desktop, BASH and a few scripts achieves more in a few seconds than minutes of clicking ...
"Armed with printouts of the spreadsheet, the .. admins sit down .. and painstakingly go through each record .. one by one, typing in each address manually for each record .. It takes several hours at least -- and unbeknownst to them, they've managed to fat-finger a few addresses and swap a digit here or there in the blear of a late Friday night"
"Meanwhile, an admin over at CLI Inc takes the two address columns from the spreadsheet, copies them to a clipboard, and pastes them into a file on a Linux box. It's the work of 10 seconds to parse that into a usable sed script" link
and next time, Marmite, is it tasty, does it make you code better, and ' red of blue ' - which is better ..
Yeah, thats it.
...then you are not a professional.
What sucks is not the GUI, but the failure of the computer industry to provide the three natural user interfaces to the full user base population as a standard in all applications and OS's. And we know the constraints are done strictly for profit, but it is also the lie of imposed false constraints.
From Abstraction Physics
"Primary computer user interfaces:
Nature likes three (3) in primaries, as color in light (additive - red, blue, green) and paint (subtractive - blue, yellow, red) from which we can create all other colors in the rainbow. This applies to abstraction physics as well, as applied through the tool of computer, for there are three primary user interfaces. The command line, the Graphical User interface (GUI) and the side door port to application and functionality access (known by many different names and application levels such as API, IPC, DCOM, dcop, D-BUS, Plumber, computer sockets, etc., but each having its limitation and typically not so end user friendly as the concept should be.) And like the primary colors, if you take one away or limit its use, you constrain the ability of the user in putting new automatons together or modifying existing ones. Causing false limitations in user ability........."
Uh, using a GUI doesn't preclude you from editing text.
Isn't that like saying "A CLI is a graphical UI, because the monitor needs to be on to use it" or "A CLI can be made into a GUI by using an on-screen keyboard"?
In my mind there's a real distinction between inventing and typing textual commands, versus choosing stuff from a menu or list of choices. Links (say) is in the latter category. Yes, it's displayed on a text terminal, but it's more like a GUI in that the user chooses from a pre-specified list of commands or actions, rather than composes one of their own.
Some things are not best done by choosing from a list of pre-specified functions.
The CLI is like talking. Intent is expressed as a series of written phrases which could have been orally communicated to the computer provided that speech recognition worked effectively.
The GUI is like painting: Intent is expressed via a series of pictures and gestures.
Both ways have their pros and cons. They are complementary to each other.
A good GUI can do things the CLI does not offer, and the CLI can do things that are difficult to express via a GUI.
Here is an idea: a GUI application that allows the user to select one or more CLI commands via the mouse, then select the appropriate parameters from a list presented via the GUI, and then optionally linking commands together by drag-n-drop. The GUI could present previews of commands where possible, and allow the user to do an interactive modification of commands.
Is there such a beast?
I'd put it more strongly: Every application should have a CLI and a GUI for everything.
* CLI for logging, interoperability and scriptability,
* GUI for state visualization, function discovery and safe input (with validation and sanity checks that catch errors before saving them, which doesn't work well over a CLI).
Additionally, every application should expose all its configuration in one place, in human-readable text files. The article makes a case for these text files to also be human-writable. That means humans and human-written scripts have to be trusted to always get the syntax right, which doesn't seem a good idea (see bad regex in the article). OTOH config files have to be writable to implement versioning. The best approach for solving this dilemma is GUI feedback.
In the example given in the article, both the CLI and the GUI interface are apparently flawed. The GUI lacks version control (or at least import/export of application state) and bulk data import, the CLI lacks data validation. These are implementation flaws, they can be fixed. They're not fundamental shortcomings of the CLI or the GUI approach per se.
Once again it degenerates into a my {IDE} is superior to {vi,emacs}. For how many years will people need to point out that it's not one or the other? Both my IDE of choice (IntelliJ IDEA) and my Emacs are set up to auto-synchronize their buffer on any open file change. When I need refactoring, real-time code inspection (even on partial ASTs), etc. I'm under IntelliJ IDEA. When I need to do stuff that only Emacs can do, I switch to Emacs.
And this is *just* the beginning: one day you'll have {vi,emacs} right in the center of your IDE, as the "text editor" and you'll understand how poor and lame you were to enter the "IDE vs {vi,emacs}" flamewar.
If anyone here suggests that the text-editor part of their IDE is more powerful than {vi,emacs}, then a visit to the nearest psychiatric hospital is needed. If anyone here suggests that {vi,emacs} offers all the bells & whistles that good IDE offer, the same advice apply.
It's not "one or the other". I'm using both. It takes *one* shortcut to swith from my IDE to emacs.
And that is *today*. Tomorrow it's going to be {vi,emacs} at the center of your IDE.
Live with it.
Currently I work in a healthcare related field doing mostly database work. While personally I'd normally prefer a nice SQL statement, their entire auditing system is set up with automation and error reporting and everything else in Access. Why? Because it's necessary to be able to show the relationships and what's happening to healthcare professionals so they can make clinical based decisions about the validity/results of the tests and forcing them all to learn SQL is
1)probably a waste of time
2)can be much more complicated to pick apart than just looking at a graphical representation of database relations.
Everything has it's place. If it didn't, it would still be around.
The best interface would probably be a GUI on top of a CLI interface. There are programs that implement this. EagleCad for example has a command line box in the GUI where you can type in any command. The GUI itself only injects commands into the CLI when you click on the various widgets. The user can drive the program from either input, and sometimes the CLI box gets the job done where the GUI grabs the wrong object.
You can't track an IP address in Visual Basic with a CLI. Ha!
http://www.youtube.com/watch?v=hkDD03yeLnU
Now do the same thing with [some] regular expressions. What?!?! Windows search doesn't take [some] regular expressions? My command-line has since the 1990s. I win. Too bad I didn't think of that as my initial example :D
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
This got +5 insightful?? I see nothing but opinions based on two fundamental misconceptions:
1) Editing C# in a GUI editor means you are "programming in a GUI"
2) CLI == vt100
Why do some people insist to discuss the question if a screwdriver or a hammer is the better tool? I browse this site in a GUI and I perform complex file operations using pipes with a CLI. There is no way how either can replace the other fully without the overall usefulness of the system going down.
This is just silly: there are thousands of tools and dialogs for doing stuff in a GUI and there are thousands of commands and features and options for doing stuff on the command line.
In addition, a system that allows to do most important things thought the CLI in addition to the GUI has several advantages: typical tasks can be written down, copy-pasted and automated easily while you still can achieve it in the more intuitive and easy to remember graphical way too.
From a Security device perspective I find that the CLI is more flexible and less "you can't get there from here" problems than the GUI.
The GUI is wonderful if the Ethernet jack is setup correctly. If not, then you are screwed.
The CLI can always be accessed via a Console port and it is usually more flexible than the GUI for the "aw crap I totally messed up the IP addresses and hosed the device configuration and now the bloody firewall will not connect to anything" situations.
When the device is working I still find the CLI easier to deal with remotely since I have an SSH client on my IPad and Android phone. I found the CLI via SSH a simpler and more reliable process than with the GUI. Also the GUI drain the batteries faster for some reason. I could tether my laptop to the Android phone but the GUI still eats up batteries on both the laptop and phone plus I burn through my phone's data limit faster, assuming the device's GUI is even working correctly.
I have seen device's GUI interface lock up solid due to a rampant process or DDOS attack while the CLI still works, albeit at a snail's pace.
Now I do like the GUI to guide me through setup procedures I rarely use. Multiple choice is always better than having to totally recall arcane CLI commands for rare situations but to eliminate the CLI option makes as little sense as eliminating the GUI option.
"The Matrix[gui] is everywhere. It is all around us. Even now, in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work... when you go to church... when you pay your taxes. It is the world that has been pulled over your eyes to blind you from the truth[console]. That you are a slave, Neo. Like everyone else you were born into bondage. Into a prison that you cannot taste or see or touch. A prison for your mind."
gui was/is a marketing trick played on dummies; it was invented for those intellectually lazy people who are always scared of [new] things they don't understand. and if you don't understand something you shouldn't confuse/scare yourself by pretending to be an expert in it. when a "sysadmin" claims that gui is better than cli (ROFL), you can almost see his carrier path in becoming a "sysadmin"; an old staff member with, in best case scenario, help-desk level of knowledge, which happened to be around when the decision was made to use computerz in a way that needed a server around. they couldn't (didn't bother to) hire a real sysadmin to do the job so they promoted him to $some-mouthful-it-title. to be fair, these people _are_ experts in one thing and that's office politics...
"most of these people are not ready to be unplugged. And many of them are so inured, so hopelessly dependent on the system, that they will fight to protect it."
more to the subject, that command line used as an interface is different that scripting a task.
"I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it."
"You take the red pill, you stay in Wonderland":
switch to runlevel $console-mode
chsh to zsh
put this in your .zshrc (among other goodies you find out there):
function zle-line-init zle-keymap-select {
RPS1="${${KEYMAP/vicmd/-- CMD --}/(main|viins)/-- INSERT --}"
RPS2=$RPS1
zle reset-prompt
}
autoload -Uz compinit promptinit
compinit
zle -N zle-keymap-select
zle-line-init(){
zle history-incremental-search-backward
}
setopt APPEND_HISTORY
setopt SHARE_HISTORY
setopt INC_APPEND_HISTORY
zstyle ':completion:*' verbose yes
zstyle ':completion::complete:*' use-cache on
zstyle ':completion:*:match:*' original only
zstyle ':completion:*:*:kill:*' menu yes select
zstyle ':completion:*:kill:*' force-list always
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
zstyle ':completion::complete:*' cache-path ~/.zsh/cache
zstyle ':completion:*:approximate:*' max-errors 1 numeric
zstyle ':completion:*' menu select=1 _complete _ignored _match _approximate
zle_highlight=(region:standout special:standout suffix:bold isearch:bold)
bindkey -M isearch "^I" vi-repeat-search
bindkey -M vicmd '^[[Z' reverse-menu-complete
bindkey -M vicmd "^I" history-incremental-search-backward
"and i show you how deep the rabbit-hole goes".
TomHudson, gmhowell, or clone (who I ran off this forums by catching him posting as AC for trolling me before -> http://slashdot.org/comments.pl?sid=1927208&cid=34689576 , AND, upon TomHudson's request he & gmhowell + others do so, shown here -> http://slashdot.org/comments.pl?sid=1646272&cid=32150544 )
---
PERTINENT QUOTE/VERBATIM EXCERPT:
"Wait until he starts on another kick, then reply to him as an AC. It's the new meme." - by tomhudson (43916) on Sunday May 09 2010, @08:29PM (#32150544) Homepage Journal
---
AND, "lo & behold" in that very URL where that excerpt quote was taken from?
Well, we have
Gmhowell
TomHudson
Clone
gmhowell's TomHudson's "sock-puppet" I suspect, since he always shows up whereever TomHudson posts usually, as shown there above no less!
Also, "Will Wonders NEVER cease?"
Well - So is clone (under one of his alternate registered user guises of clone52431 or clone53421)
Clone, in fact, was caught doing AC trolling posts directed @ me here -> http://slashdot.org/comments.pl?sid=1927208&cid=34689576
He has been driven from this website though, afaik. Neither of his CLONE accounts are in use & have not been since that all happened where he was caught doing that & worse (something w/ the law & MichaelKristopeit accusing him of VERY bad things like theft of IP, death threats, guns, & more where POLICE came into the picture!). I left that be @ that point... can anyone blame me?
So, in the end, now that THAT's all "said & aside":
Dearest troll - Is your FAVORITE COLOR, "transparent", or what? I say that, because your PUNY effete tactics are very, Very, VERY EASY to "see thru"... just "too, Too, TOO EASILY" in fact.
APK
P.S.=> The funniest part of all though, is that you were FORCED to "downward moderate" my init. post you responded to here:
http://it.slashdot.org/comments.pl?sid=2070518&cid=35729898
Simply because my response to your trolling here:
http://it.slashdot.org/comments.pl?sid=2070518&cid=35731242
Shows that you KNOW, as do I, that you're an off-topic trolling TRULY "anonymous coward" & nothing more...
Again - Except that I KNOW that others here who troll me as AC or otherwise, & yes, specifically who in fact, does it to me (see above quote for proof of that much).
Poor job IF I can find out WHO you are easily, since you seem to "get off" on trolling me as AC (ineffective & PUNY 'tactic' troll... right up there with your off topic trolling, spelling/grammar checks (where there is no such forum here or topics usually either), & technically unjustified mod downs of my posts, not that I care... I have 100's of upward modded ones too!)
(Whereas @ least by way of comparison, I identify myself in my AC posts (all I ever do is AC ones here))... & if a technically unjustifed effete "mod-down" is "the best you've got"? You're hurting troll... apk
>If you would be really proficient in bash, you would know, for instance, that your for would choke on filenames containing spaces - while his cat | read construction handles it well.
Does it?
This works for files with spaces:
for X in *; do ls "$X"; done
But if you don't use quotes, it doesn't:
for X in *; do ls $X; done
The OP's example should work.
I'm not a lawyer, but I play one on the Internet. Blog
CLI vs GUI is a silly argument. They both clearly have their place. When it comes to dealing with multitudes of devices or computers, the point is it's a lot easier to write a script to do massive numbers of configuration updates instead of having a room full of Phoenician oarsmen clicking away via web-based GUIs. A home router? GUI is fine. An enterprise WiFi access point that a company will have 200 of? CLI is essential.
There is a place for the command line, and there is no doubt, a place for the GUI. The key is using them in the *right place*.
-- $G
Hotwire, an innovative shell
http://code.google.com/p/hotwire-shell/
Click here to install on Debian/friends
PowerShell clone on Linux (warning: uses Mono)
http://pash.sourceforge.net/
Ruby-based shell:
http://rush.heroku.com/
I'm not a lawyer, but I play one on the Internet. Blog
U mad or smth?
http://it.slashdot.org/comments.pl?sid=2070518&cid=35735382
I said all I had to there, with backing proofs, so - take a read, & a piece of advice too:
TomHudson? You can stop your ac stalking & trolling of my posts already! I already KNOW you're about doing this to me, & it's amusing @ the very least.
APK
P.S.=> Especially when all you had was a mod-down of my post, rather than disputing anything technical about it... apk
how else are we going to use up all that excess computer power we have now? It hardly takes a quad processor and 4 gig of memory to send a 140 char text message, now does it?
Are you done yet?
See subject-line, + "drink it in & digest it": Because if the "best you've got" is your off-topic trollery & stalking me with AC posts? LMAO!
APK
See subject-line, & answer the question.
APK
P.S.=> When you can get "on-topic" also it would be nice... but then, perhaps that is expected a "wee bit much" from "the likes of you" (an AC troll)... apk
Tell me more about "Do YOU troll ALL posts, off-topic, as AC always?"
Tell me more about "Do YOU troll ALL posts, off-topic, as AC always?"
""?syawla CA sa ,cipot-ffo ,stsop LLA llort UOY oD" tuoba erom em lleT" - by Anonymous Coward on Tuesday April 12, @02:40AM (#35790182)
?
TL:DR
(LMAO!)
APK
P.S.=> So - If you're trying to "get my goat" or "waste my time" (like some loser, or a woman, might think bothers me (NOT) because they're MY minute to waste making you look stupid after all & that's fun)?
Ahem: They're YOUR MINUTES YOU'RE WASTING TOO, in trolling me... again, like the above - just PUREST "reverse psychology", lol, @ its finest!
---
Besides, I'm happy to have solved a lot of folks problems WORLDWIDE, & in PYTHON (only my 2nd week using it here no less) with the multithreaded timer class today, vs. the "NoneType error is not callable" issue in it today, here:
http://g-off.net/software/a-python-repeatable-threadingtimer-class
Simply by using a "Proxy Dummy Launcher function" that takes no parameters, which is what their problem was: passing parameters to functions inside the RepeatTimer class, which was actually a SUBCLASS of Thread that inherits from it, but NOT BUILT TO TAKE PARAMETERIZED FUNCTIONS!
So, To beat it, you have to setup a "dummy proxy function" as I call it!
One that CALLS YOUR FUNCTION THAT TAKES PARAMETERS, but, the dummy proxy function, doesn't!
It works... & allows multithreaded timer usage in Python WITH PARAMETERIZED FUNCTIONS in the RepeatTimer class...
E.G.-> "Dummy Proxy Function" method:
So - That's how I spend my free time - helping others, in technical issues in networking, & programming too + even FIXING OTHER PROGRAMMERS MISTAKES FOR THEM, as shown above...!
So... how about you? Oh, that's right:
URA TROLL, nothing more... go waste your life some more man... your loss! apk
Time wasted writing one line time wasted writing wall of gibberish. Dummy.
*smaller than
See subject-line, & your off topic trolling proves you're nothing but a WASTE OF LIFE, because all you do is troll others here (off topic like usual as well, showing you're nothing but an undereducated dolt typically).
What I wrote is FAR from "gibberish", & it works.
I.E.-> 2 lines of code (from "yours truly") that fixed @ LEAST 1/2 a dozen other coders' difficulties in fact, for making a threaded timer class useable by they, with PyThon...
You can stop posting as AC in your trollish attacks on myself TomHudson. I am "onto you", from your own words giving away the fact you do this to myself on this website:
So, does TomHudson do that? Well, take a read, & you tell me:
http://slashdot.org/comments.pl?sid=1646272&cid=32150544 [slashdot.org]
(Oh, & it's kind of tough to hide yourself as AC tomhudson, when your own words give you & your pals away as doing that to myself, as shown in that URL above)... apk
APK
P.S.=> Yes, "not too shabby", on MY part... heh, fact is? YOU WISH YOU WERE ME, lol... apk