Slashdot Mirror
Are Unix GUIs All Wrong?
BrightIce writes "Advogato has an interesting article about GUIs on Unix. The basic message is that it is wrong that the command line is "a completely seperate world" and proposes some interesting ways CLI and GUI could cooperate." The feature actually isn't all that long - but I'm sure the discussion can get going from there.
Hrm, I really ought to think before I post. This sort of stuff could be done now. But it'd require rewriting a lot of stuff, or at the very least cleaning it up.
:( still, I would definitely love something like this. We'll have to see what the two competing desktops bring.
The nice thing about this is that not only does it make everybody's life easier, it makes it easier from every angle - whether they're coding command line or GUI.
The technology is there (I meant the rewriting bit, dammit), but since you would need to rewrite almost everything to make it useful that might resitrct it's usefulness somewhat
You couldn't be closer to the truth.
However your last paragraph bring up the idea that is still must be possible, and easy for 'power users'. Nobody seems to be able to solve the problem of a gui that is intuitive and simple for the average user, but that will scale up to the needs of a 'power user'.
An added bonus would be a gui that made it easy for people to develop their abillity easily with little effort.
Say UNIX didn't have a command line.
Ala MacOS or Ala NT.
I have too often had too re-install a killed system, because it could no longer, for one reason or another, reach the complicated state of the GUI.
Having the fallback of console mode is a UNIX strength and let's not forget it!
The article in question doesn't address any of the strength's of UNIX GUIs, it just ponders the unaddressed feature possibilities of the standard tools (tar and rm are examples). These arn't core UNIX issues, and also, with a bit of Tcl could quite easily be implemented.
The strength's of the UNIX GUI (I'm talking about X here) are:
Client/Server philosophy, allowing X clients to run on one architecture and X servers to display those clients on a completely different architecture. (e.g. You can run X applications on a Cray and display them on x86 or even embedded Architecture. You can even display Cray applications on an iPaq (bloody hell!!!)
and
Placing the "look and feel" into user space. Be it desktop environment any user can change the L&F by simply choosing a different Window Manager at start-up. kdm has a lovely way of doing this.
I agree, but imagine if tar provided its status info to the OS through a more generalized interface, so it was stored in the process table. Some people would run a GUI that exploits this - you wouldn't. But if you're curious about how far that backgrounded tar got, you might type 'status --complete $PID' and get back '32%' or something. This would be a much cleaner solution than having tar attempt to drive a GUI directly.
For me a GUI at the very least lets me run multiple CLIs and see the progress in all of them at once.
For more info, see the The Softpanorama University Orthodox File Managers Site.
Possible solution:
As far as I know -dontdothatguishit is unused in any current unix tools.Bit long, but you'd have no trouble remembering it.
Afraid of OS X, huh?
--Never trust a guy who has his IP tattoed to his arm, especially if its DHCP.
What about Ctrl-Alt-Backspace?
Or Ctrl-Alt-F1, then log in as root, then killall X? Crude, but works even in the most dire of circumstances.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
Let's see, problems I've had with windoze over the past week. Okay the computer in my comitee at school would go from normal use to the "you can now safely turn off your computer" screen at random. You could be typing a text in word and BOOM, you need to reboot. I fixed the problem by turning off the "plug and play os" option the bios. I think there was a problem with the sound card drivers. Then my roommates computer went AWAL, I had to run a scandisk, then a scanreg /restore, then another scandisk in windows(which wouldn't even boot in failsafe mode) to fix a truckload of long filename problems. Then I uninstalled a couple of programs that I thought were the cause. Windows froze when uninstalling an anti-virus, but thankfully a scandisk later my rommmate could use his computer again. My computer generated about 15 blue screens yesterday, outlook express crashes like clockwork citing problems with mshtml.dll, IE is even worse, and explorer will crash by itself for no reason. Sometimes I am just litterally looking at the screen and the computer is doing nothing and then a screen pops up saying explorer crashed. I have no problem when I'm booted in linux. And that's just the computers that I have/had to fix in the past week(oh yeah, almost forgot I have to go fix one of my friend's computer, windoze screwed up and she needs to have it reinstalled). I work tech support for an ISP, having hundreds of people call you because their windows is screwed up is a real eye opener on the quality of the product. YOU need to open your eyes, nobody is making up rumors of blue screens popping up.
(Assuming Linux can't do this) I would assume that the Linux windowing archetecture is not integrated well enough to allow this. In my experience, this is the biggest barrier to getting linux into wider use.
I was consulting with one of my clients about installing a network for them. I mentioned that they should consider using a linux server for DHCP and IPChains. The contact looked at me funny and said about "Lunix? That's one of them command line things without windows right? Naw, ain't nobody here that would know how to work that thar thing. You best just give us that click and point stuff that we can run." (this is a group of civil engineers, by the way, not your average burger flipper).
Blah, after all the rambling, my point is pretty much that more work needs to be done on Linux GUI before it can be seriously competetive.
funny munging
The Unix shell CLI is predicated upon the notion that every piece of code has essentially two input streams: a set of bits that flows in and a set of bits that flows out. That's a fairly powerful metaphor, and, if you have the cycles to throw at it, even universal. Look at XMLTerm if you want: although it's incredibly clumsy and unbelievably slow, it really does allow the user to go back and forth between CLI and GUI.
But there's a problem with the control structure of that model. The computer is in control; it reads from stdin when it wants to do so, and it writes to stdout when it wants to do so, and the user is the slave of the processor. For CLI-like tasks, and particularly those where the computer can itself generate a data stream, process it serially, and then spit out the result, it's exceptionally efficient.
The GUI has an essentially user-centric control model. There is not just one stream of data: the mouse and the keybooard are independent of one another. Components can be embedded in one another in non-linear fashions: the user can enter data into any of several slots, and, when a certain conjunct of data presence is available, a new set of slots or actions can become available to him. In order to build an abstract data model for such a machine, you need to step from the clean and comprehensible linear machine-based Unix CLI into a Petri-machine based system.
Can it be done? Of course. But expressing a Petri machine in text is very hard, and so it's quite unnatural to use a CLI to describe GUI-like processing. Imagine trying to express the idea that "When data are available at each of these two streams simultaneously, do x and send the result to component seven" for a system with twenty or thirty components. Then understand that my screen has approximately one hundred different active elements on it right now. How do you describe that as a pipe-stream?
The standard phrase is:
"Make the most expected thing happen automaticly, and make all things possible"
So what is desired 99% of the time should be the default and happen with no user input, but there should be hidden dialogs and options where the power user can tweak to their hearts content.
That's GUI-101 from the original Apple perspective. They've strayed, but most Mac GUI developers still operate under that principle. The key is to have every option under the sun available, but hidden where you don't have to see them if you don't want to do so.
You know there was a time when shells were optional components on computers. Of course the people who really understood computers wrote their own program loaders and didn't have to rely on a command line. The shell is just a usablitity tool, and has nothing to do with how the computer "really works".
Just like the shell, the GUI is just another form of abstraction which makes certain tasks easier. Sure cp *.foo ~/foo is easier with a commandline, but for people who create filenames that aren't easily regexed, it's probably easier with a mouse (and there's no amount of teaching that can solve that problem) Both are an abstraction of how the computer moves inodes around on the disk.
I think the Unix perception is "Because the init, login, and the startx process is a massive hairball of shellscripts, that must be How It Really Works(tm)." Well, no, that's just Unix's kludgy way of making it work by exchanging flexibility for fragility.
We've now got a whole bunch of interesting component technologies free and widely available which offer lots of possibilities in terms of providing a user interface (cli, gui, or hybrid). Don't lock yourself into thinking that stdin and pipes is be-all-and-end-all because it's nothing more than a 60s hack -- and once you've broken that conception, the idea that everything boils down to a CLI command doesn't hold much weight.
When I hear the word 'innovation', I reach for my pistol.
- Yes there is a problem with CLIs being a bit untransparent for newbies and therefore alienate them from the power of the operating system.
- Yes it would be nice to be able to get graphical feedback from the tools that we all use (and love once we get used to) on the CLI.
- No it would be a really bad idea to try and drop all this 'added functionality' into the tools because you run the risk of breaking/bloating something that really doesn't need it.
So if we want to start to provide some added functionality to our existing CLI then it has to be some kind of wrapper around the existing tools. ie no recompilation of the tools, no dependance on external graphical libraries (whichever one is your own chosen 'true path'), and no compromise of the tools for the power users who have used them for years and would be up in arms if anybody changed them.What can we find out about a process that might be useful in a graphical pop-up thang? We know what processes are running by seeing what spawned what, we have all the usual system resources about how much memory/cpu etc that a process is using, but this still doesn't really tell us anything about the process.
What would be really nice would be to know what is going into the process and what is coming out the other end of it. ie if I type:- and I don't see anything, is that because syslogd has crashed or just that the kernel is quite happy? What would be nice would be some way to tap into the points between the processes and look at the communications between them. Suppose we rewrote the previous CL as:- where monitorPipe is a small process that is transparent as far as input --> output is concerned, but it then registers itself with your favourite graphics environment and then lets people query what is actually passing through the pipe. This query could be in terms of Display the output in a scrollable window, or Plot the average speed in CPS in a scrolling graph or whatever. It is no longer the responsibility of the process that is outputting or inputting this information to guess in advance what people might like to ask it, it only has to do what it was designed to do and do it well.
The next thing to do is to try and sort out some way of getting your pipes to be aliased into 'enhanced pipes' depending on whether you are running your shell under a dial-up, or if you have provided an enhanced pipe that communicates with your environment of choice. Off the top of my head this would probably require some kind of patch to the shell or some kind of wrapper around the shell (enhanced xterm kind of thing?).
Let's stick with the enhanced xterm that filters your input and 'enhances' it to give 'better' functionality. We would now be in a position where you could have a drop-down list beside your xterm listing the processes that are currently running, lets you look at the input/output of each process, maybe even some kind of folded in multi-stage diff across the various pipe plugins so that you can see what is actually changing.
Other posts had talked about the need for pop-up lists for autocompletion. Again, just trap the "tab" key in situations where you think it might be going to auto-complete, pass the request onto the shell, get back the list of alternatives and pop up a widget. What is the problem?
Basically what I am trying to say is that I feel it is a very bad mistake to assume that just because a certain tool (eg tail) doesn't give you the functionality that you want/need, that patching this tool is the place to insert the functionality. This way only leads to a massive fork of all the low level tools that people rely on to get their work done. Instead try and find a single higher level point to patch in your functionality and you should be able to make a much more extensible system.
The only Good System is a Sound System
That idea is completely wrong. As a Mechanical Enginering student I know that this couldn't be any less true. Its time you figure out that IT, software, ect... people are NOT the only people who use computers for serious work. All the serious CAD stuff runs on unix originally (if not exclusivelly) and even the software that has been ported to Windows takes $5000+ workstations to run. Note these programs are not xterm, mozilla, an image viewer, a mp3 playwer, or fvwm2.
X is for xterm, that's good enough for me,
So xterm...? I couldn't do any of the work I need to do in an xterm...so no its not good enough for me.
Cmon, dude... yer just using your Linux box to view Goatsex..
You're not fooling us.
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
The author seems to be arguing for adding GUI functionality to the CLI; I would say it should be the other way around; why can't we add CLI functionality to the GUI? Why can't I select from a listbox by typing a regex, instead of selecting each element one at a time?
I belive MS has had this functionality since Windows 95, but I can only vouch for Windows 2000. In any file open dialog, you have standard right mouse menu. On this menu, you can delete, rename, or send the file wherever you like.
Too big to fail? Does that make me to small to succeed?
Unix is the only OS remaining whose GUI (a vast suite of code called the X Windows System) is separate from the OS in the old sense of the phrase. This is to say that you can run Unix in pure command-line mode if you want to, with no windows, icons, mouses, etc. whatsoever, and it will still be Unix and capable of doing everything Unix is supposed to do. But the other OSes: MacOS, the Windows family, and BeOS, have their GUIs tangled up with the old-fashioned OS functions to the extent that they have to run in GUI mode, or else they are not really running. So it's no longer really possible to think of GUIs as being distinct from the OS; they're now an inextricable part of the OSes that they belong to--and they are by far the largest part, and by far the most expensive and difficult part to create.
...
THE INTERFACE CULTURE
A few years ago I walked into a grocery store somewhere and was presented with the following tableau vivant: near the entrance a young couple were standing in front of a large cosmetics display. The man was stolidly holding a shopping basket between his hands while his mate raked blister-packs of makeup off the display and piled them in. Since then I've always thought of that man as the personification of an interesting human tendency: not only are we not offended to be dazzled by manufactured images, but we like it. We practically insist on it. We are eager to be complicit in our own dazzlement: to pay money for a theme park ride, vote for a guy who's obviously lying to us, or stand there holding the basket as it's filled up with cosmetics. ...
Excerpts of "In the Beginning was the Command Line" by Neal Stephenson.
Worth a read.
--ricardo
sgis ddo ekil t'nod i
You haven't seen anything yet.
Either from Linux, computers or the internet.
The next 5 years are going to be a tremendously exciting time.
I have the kernel source. The GUI is NOT in the kernel. It's just the GUI is all there is, not all that's possible. You could write a command line for the kernel and not use the GUI.
The truth about Michael
I believe Commando is still available for MPW (although I haven't used it in a couple of years). I imagine whatever the MPW equivalent on OS X is will have it too.
I agree -- it's a great way of having the best of both worlds.
My idea for the name of such a GUI: ATOG (A Taste of Gates).
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
IMO a very interessting idea but it would not work nevertheless. Sure; you can give a GUI the exact feel of a plain commandline but even then it would not be exactly the same.. I think the author is missing a very important point here. In theory he makes some very good points IMHO and indeed, in theory it could very well work out. But in the real world people tend to associate GUI's with completely configurable environments. iow; I can decide how the windows get placed, how big the fonts are, and the likes. Thats not really new. But going back to the article:
What if the shell popped up a window, showing you the last N commands you typed, or showed you what you would get if you hit tab at that point. Or let you mix a file selection dialog with the command line. You could type rm , select the files you want to remove
In this example the GUI would allmost feel like a commandline yet would not work. The "idiots" would demand a more flexible and more easy way to administrate their boxes while the more advanced users would still complain about the time it takes to transfer all the used data over the Net in order to remote administrate these servers.
Like I said, the author is missing a point here. At least IMHO.. If you really know what you are doing you don't need a GUI period. not even when you're administrating a Windows based (web)server.
My comany maintains some IIS (NT based) webservers mainly because we need the options NT offers (ASP). Sure; there may be much other options which can provide non-asp based solutions but that isn't an option and not the point here. Some time ago we had a major problem on the IIS part and I asked a colleague to help me out. I know my way around in IIS but I'm still, and prob. allways will be, *nix minded and therefor not interessted in IIS enough to specialize. He took control over the box using a remote admin tool and to my surprise immediatly did a "run program -> cmd". From there he typed like hell and did the rest to sort out the problems (yes; the solution worked as well).
Noticing my surprise he basicly told me that Windows never did let go of the commandline *if* you knew how to use it.
Experiences like this made me wonder about this whole GUI stuff as well and IMO it all boils down to the fact of acceptation.. People accept that you can or cannot do certain things in a console and get excited if something is possible. In a gui people are more demanding which tends to lead to more excessive environments. Personally I've never seen anyone on a console get freaked out on where a certain error message was placed yet in a GUI environment I tend to see people even move error messages to another spot...
This is exactly what I liked about EFM (before the beta was removed). It combined command line and GUI filemanager perfectly (IMHO).
/etc) and it would open a window with that directory. It could be a command, simple or complex such as "rm foo" or "for i in *.foo ; do foobar $i; done" and the command would execute.
For those of you who never got a chance to use it, it worked like this: It had your standard desktop with icons and folders that you could open, but at anytime you could just start typeing and hit enter. What you typed could be a directory name (ie:
It probably had a lot more than that (beautiful graphics, alpha blending, a background you configured via layers (a la gimp/photoshop), etc), but those were the things that made people go "oooohhhhh" when I showed them to them.
I know there are some systems that have something like this (konqueror has a command line option in it I think), but it still is a separate entity. EFM had a (mostly) seemless integration of command line into a GUI filemanager.
The name is unfortunate XML is supposed to mean X Window + HTML but, of course, its confused with, well, XML.
Humans are linguistic animals. We have very finely tuned linguistic skills and we have the linguistic centres in the brain with at least 100,000 years of evolution behind them. As a result I'd have thought that language was one of the best ways of communicating with a machine. I certainly find it easier to learn a lexicon and grammar (ie. command line commands and how to use them) than a list of operations like "the third menu, select the second item, click on the third checkbox that comes up" and so on. In addition I find a mouse to be a hopelessly analogue tool for linguistic tasks such as programming. GUIs bear little relation to the way humans have communicated for aeons. Unfortunately eye candy sells and so we are doomed to using tools that are not adapted to human brains - GUIs
--
-- SIGFPE
Most every inexperienced programmer comes up with tools for programming that are supposed to be the silver bullet, increase programmer productivity, etc...
They usually cost more time to code and maintain then they ever save. Very few are worth using, and none have been "silver bullets". (I include myself as one of the guilty).
I remember the case of "Apware" (which was Novell's name for it after they bought it; it was originally on the Mac, but I forget it's name there).
Very much like a GUI version of the unix tools. Rather than command line args and stdin/out, you'd graphically plug the tools together to form an application.
Seemingly easy, targeted at the casual user.
Easy as long as it was simple, but couldn't do anything usefull until it became complex.
No savings here. Just another kid with a new programming tool, no easier to code and maintain than the equivalent "C" or shell scripts.
Anyway, in coming to terms with this idea -- it is very different. It's aimed at the user, not the programmer.
We often code GUI front-ends to shell scripts, using Tcl/Tk/Wish, Python, Xforms, or Glade. Having the commands in the shell scripts work together to service a window of widgets isn't a bad idea.
You'd surely want to be able to turn it off (or not enable the feature) for any given command, as well as add persistance (so a given command re-operates the same widget every time it's envoked in a script). Some environmental variables for pulling it all together (command widgets for formatted windows) would be nice too.
It might be easier to make a special shell that monitors the commands in a script and displays a GUI. It would be easier than getting those who support the open source tools to come to an agreement as to how this would work.
Scratch That Itch!
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
In Windows, use +r for the RUN command, similar to +F2 under KDE. Why is this so hard? The hotkeys are already there, just use them.
I'm really offended.
I don't post trolls.
It just shows how broken the moderation system is when someone disagrees with someone else who expresses a strong opinion.
I'll see your senator, and I'll raise you two judges.
Here's a nifty little *trick* that I use on my setup. I'm running gnome, and Sawmill... although, this will work with other environments such as KDE or enlightenment...
In X/gnome... open a terminal window and size it to your liking. Set it's background to transparent. Set the window depth to the lowest layer possible, and then make it frameless.
What you're left with, is basically a Command line that is your GUI desktop environment. I can work completely in CLI (programming), while having a few little windows open that I need.
I think it's a fine blending of the two worlds. In effect it's the opposite of Windows. Meaning, the GUI is now sitting on top of the CLI, not the CLI sitting in a window in the GUI. Makes a great environment for more technically oriented people.
As for the article, it sucked. The whole idea of giving immediate focus to a windows as they pop up sucks. Windows does that and I'm always being forced away from my work because of other apps. In my current Gnome setup, I don't have that problem because no window gets focus until I give it focus.
Skiers and Riders -- http://www.snowjournal.com
It may be one of the Mac's strengths... But it has also been one of the reasons why the Mac has been a failure.
Those of us who are adept with computers do not appreciate the way the Mac treats everybody as an idiot. I've found the Mac incredibly frustrating to use over the years, but that's not to say I wouldn't recommend it to a friend I didn't want calling me for help. Thus the problem is the adept people who might actually support and write software for the Mac universally despise it, which can't help it's marketing.
Granted, Windows started down the path of everybody is an idiot. But then most people are. But Windows also provides you with the other tools one needs to actually dig down in deep and do your work. So it's simple enough for idiots, powerful enough for programmers.
Now Unix on the other hand has the unique distinction of being the OS for everybody but idiots. It's elitist, but it works for some people.
So we have a different OS for everybody, and obviously the one which has taken the middle ground is the most popular.
The problem I see is that if Unix starts going down the path of Windows, it will simply become Windows.
And at that point, why not just save a lot of effort and use and improve Windows to begin with?
I've never been a big fan of the Linux everywhere argument, I think it's silly.
If there are no
If there's one
If there are multiple
Go read it again. If you want to delete all files beginning with "foo", but not "foobar" or "foobaz", you have a hard time using file completion.
-russ
Don't piss off The Angry Economist
No, you misundstand. AtheOS has the kernel & appserver seperate. However, AtheOS does not have any way of running the system at a pure command line (Other than Telnet or SSH). When you boot AtheOS, the appserver is loaded and started for you, and you use the GUI. You can open a terminal though, and use bash, so you do have a command line.
;)
The kernel & GUI components are not integrated into a big ball of mud as you seem to think, but are fully seperate. My best advice is to try AtheOS (Now on VMWare, so you have little excuse
Syllable : It's an Operating System
I have many computers. I have run one with Windows 95 for about 3 years with no major problems (and no regular blue screens except when messing with shady software), I had a P133 with 32MB of memory, and that was enough to run what I did, which included photo editing, Internet Explorer 4, Netscape 4.5, etc. Really, it wasn't that bad. I recently got another computer that is running Windows ME, which I have had no significant problems as well. I have gotten more blue screens than I did on Windows 95, but even then I'd say I've had a total of 4 in the past month. That also is from dealing with shady software (god damn you zsnes!)
I have many other computers that have had nearly no problems as well. Maybe you are having so many problems because you fucked up your windows installation. Just because you don't know what you are doing with Windows doesn't mean that it is completely unreliable. It just means you need to learn how to use it. I really hate to see people that claim to support open source by lowering themselves to lying about the reliability of Windows. It doesn't help make linux any better if you pretend that Windows is completely useless. If you really wanted to help make linux a better desktop, figure out how to get it to be compatible with more hardware, write drivers. Write some plug and play detection that works. Do something so linux as a desktop will actually have the ease of use people expect from Windows. Bitching about a product you obviously know nothing about doesn't solve anything.
Oh, and that bit about you taking the calls for a helpdesk shows nothing about the quality of Windows. It is not an indication of the quality, only of how widespread Windows is as an OS. Also, it's probably the only OS your ISP supports so the linux and MacOS people don't bother calling because they know they won't get support. Try to use your brain a little instead of bashing Windows all the time.
Mas vale cholo, que mal acompañado.
You lack imagination, I can see that. The command line is decidedly not a different world from the GUI. Fundamentally, you talk to the X GUI over a socket. Well, when you telnet to a remote host, you use a socket. How is that so different?
-russ
Don't piss off The Angry Economist
The biggest advantage of a Mac-style GUI is consistency: every program has a File menu with similar commands, and so on. Interfacing it somehow to a CLI would just make it more complicated and less consistent.
I like the fact that the GUI and the CLI are completely separate in MacOS X, for example. It keeps everything conceptually simple. And you'd better believe that the average Mac user is completely uninterested in the CLI -- that's why Apple has made it so clear that they don't want software developers ever to assume users will use the CLI.
The Assayer - free-information book reviews
Find free books.
or, WIN + R for run command in windows, ALT + F2 in KDE.
--
All men are great
before declaring war
A government is a body of people notably ungoverned - AC
Okay, again, sorry, my fault :)
:)
Truth be told, I am sucking back NyQuil quite quickly, and I'm having trouble focusing
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I hate to jump to any conclusions, but this looks like the answer to the question. This looks like an excellent project to build on.
This is definitely the way it needs to be done.
:)
Also, it would be a Good Thing to make it completely optional in the makefile (or with a configure flag) and stick a few IFDEF's in there to avoid too much controversy
I can say exactly what we would have: Windows NT.
(This is where the smart people stop reading and go write a terribly clever Microsoft dig. Us dumb people can continue.)
Yes, NT does have a command line, two actually. CMD.exe is a 32bit extended DOS shell. command.com is it's 16bit little brother. Are they as robust as most *nix shells? No, of course not, mainly because the design philosophy of the two OS's are VERY different. NT is (in design philosophy) a 32bit VMS offshoot that uses a GUI as the main interface.
Because NT shells are typically weak programming environments most serious programming is done via the GUI. This lends itself well to the object oriented design philosophy behind Windows NT. For simple tools and tool combinations the shell is still needed. When I need to manipulate multiple systems across a network for administrative purposes I find it very easy to write a script for most simple operations.
Getting back on topic, how does this affect the types of programs produced that interact between the two? Well, typically there are two effects:
1. The command line arguments are not as robust.
Normally programs run from the command line will concentrate on interface related functions. (i.e.: Run minimized, non-interactive mode, run with the following configuration, location of data files to be loaded before GUI starts). This is a generalization but it is the exceptional NT program that takes more than 1 page in a help file to explain.
2. Tools with GUI's evolve to meet the majority of needs.
This is not to say that the OS manufacturer provides the tools. For example, Microsoft provides many tools for systems administration including Event Log Administrator, Server Administrator, User Manager, etc. A third party tool called Hyena combines these all into a single interface which can output data to a script generation tool. Is it as flexible as a series of command line tools which can interoperate well? No, it isn't. However it fulfills 95% of my systems administration needs.
There is also a secondary affect that very little work is done toward new shell creation. *nix has a rich blend of shell environments developed for it (i.e.: bash, csh, tcsh, etc.). NT has had a very few (and rather weak) NT specific shells created (i.e.: 4NT, KiX). Many shells have been ported to NT from *nix but they typically don't thrive. Why? The file-centric command line shell environments aren't as effective in NT as the object-centric GUI programming environments.
The end effect? The GUI tools created tend to be very powerful but lacking the flexibility of command line tools. (IMHO)
Dan
Alt-F4 also works in Motif, if you run mwm.
I used to run it on Linux (SWiM Motif, which Cheapbytes used to sell). It must be something from that IBM UI definition that Win 3 and Motif are based on...
No, you're adding a command into into a GUI. That's not what I want. I want my command-line applications to know that they've got the resources of a GUI.
-russ
Don't piss off The Angry Economist
You know what? I had mozilla crashing a while ago and hangs X with it. Of course ipchains is still running so apparently only my mouse and my keyboard stopped responding.
Even don't work. I actually had to SSH from another machine and reboot from there - killing X didn't help either.
Oh well. I guess it is still better than pressing the power button. At least I got a clean reboot.
I use a batch file to reboot Windows regularly; it exits the current shell (win.com) but keeps other processes and the kernel running. Try this: @echo off @exit Save it as c:\windows\reboot.bat and make a link on the desktop. Open properties on the link and under program, check-mark "close on exit". Hit the advanced tab and checkmark MS-DOS mode. This may be greyed-out, but you can clear the box by removing the default checkmark(s) above it. Make sure "Warn me" is unchecked. Fill the "current MS-DOS" configuration button. Click OK. Click OK again to exit the applet. Now, when you click on reboot, you will get a warm refresh of the GUI, restoring its lost RAM. The underlying DOS will still be running, so this will not solve problems in the "lower 640," but as those are the resources the "80 per cent" refers to, this should clear your prob. I have made it a habit to hit this icon after I close every project, no matter how small. It works (tested personally by me) on W95 and W98. Dunno about the later ones, won't use 'em. Yer Welcome.
Something got screwed up, try http://xmlterm.com/
Meldroc, Waster of Electrons
When tar runs quickly, that's fine. When I'm doing an untar over the network, you can bet I want a progress bar.
The command line rules because it does what you tell it? Obviously YOU have never typed "rm -rf foo *".
-russ
Don't piss off The Angry Economist
I meant, Event [CTRL-ALT-whatever] don't work.
If I want to play games on my Linux -you gonna stop me? If I want to have a look a Microsoft.com - you gonna stop me? It's my computer, my internet connection, I can do what the hell I want with it! It's my operating system, license lets me do what I want to it - you gonna stop me? /rant
Not a flame, just get pissed off when people say I can't do it.
I can use Linux for whatever I want. Same as I can use my car for whatever I want.
BWS
Emacs does this already. It first checks to see if the $DISPLAY environment variable is set. If so, it behaves like an X app on that display. If not, it behaves like a console app. It's a simple trick that causes Emacs to usually do the right thing.
You can also change the behaviour by using the -nw (no window) or -d (display) switches. If we had a couple of standard switches like these to turn off and on the X-isness of applications, this plan would be entirely workable.
Greg
I want this thing to act just like one dismissable DOS box/*nix terminal with a looong history. Just like the Quake console is, but with more functionality.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
But how about adding 'STDGUI*' handles to the program (or the shell, whatever), like 'STDGUIIN', 'STDGUIOUT' and 'STDGUIERR'? That would communicate with the windows manager with some kind of xml maybe; the normal terminal would ignore it.
--
--
Stay tuned for some shock and awe coming right up after this messages!
I'm currently working on getting my command history to trail the mouse pointer with a nice elastic swooshy effect.
Phillip.
Property for sale in Nice, France
...but what we are basicly talking about is an impossible task that will end up in a totally messed up Operating System. See, ive been watching Linux develope into some sort of Windows lookalike for some time now.
The point is: We can never win with this strategy and frankly most Linux Users dont even want to. Face it, Linux has no need to be easy to use, it already is: Its an OS for people who want to create their own solutions for their specific problems, and if you want to create something it will always be a bit harder than just using an off-the-shelf solution. But it will probably suit your needs better too.
If we keep moving into the Windowslike-GUI direction Linux will be obsolete because Windows is already a great OS for the click&go people. But on the other hand we will loose some of the flexibility as we know it for it turned into the clumsy, halfhearted, GUI-thing that NT already is.
I dont think GUIs are a bad thing but if the community pushes too much effort into GUI-only applications we could loose some of the Linux flavour that we love so much...
Lispy
It let you use the mouse to navigate the BBS and such. I never really liked it, but quite a few boards had it.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
And then you can run an abritrary command in that directory?
.o files.
Not from where I sit. I right click on a file, or in the empty window, or a directory and I get no way to execute a command.
You seemed to have missed his point - sure you can use most file managers NOW to delete and rename. What he wanted was the next step, being able to run commands from the file manager and have it work in concert with the file manager - you traverse directories or select files graphically, then operate on them will the command line.
My example - imagine selecting four files and then just typing tar -cf fred.tar in the command line below the window. You get a tar file in that directory named fred.tar containing the four files you just selected. Or, typing ls *.o in the command line would automatically change the filter in the window to show only
"There is more worth loving than we have strength to love." - Brian Jay Stanley
On my system, when the UI crashes about the only thing left going is the mouse. It takes my keyboard with it. Strange. My sound crashes a lot too. Takes everything with it. I must just have bad luck though.
I'm sure many of you are familiar with Visual Basic - and might loath or hate it, but, imagine for example, that, as people imagine you could query how far a tar was progressing simply by using any interfaces it was using.
.toString().
:)
ie, for example
andy@whore:$
PID TTY TIME CMD
9130 pts/0 00:00:00 tar
andy@whore:$ 9130.status()
23% complete
Would be (seemingly) a fantastic interface.
if commands were implemented as objects rather than an actual executable it would be quite easy to have this sort of approach. Imagine that each executable simply had to implement an interface (think Java stylee)
status() on tar could return a TarStatus object, and thus something like that simply uses
This unfortunately would require more technology than is currently available, but with move to a very component orientated approach which I think would be a good thing (mm, I like components
Wow, imagine another way to do it. Just type: 'man ls' and it would tell you all of the options and their meanings. Or even a GUI version -- let's call it 'xman'. Someone should start coding today!
Ever heard of mc?
I think that a "graphical pipe" would be one of the greatest things that could happen to GUIs. I imagine arrows that I can draw between various widgets. E.g. xterm might provide, say, 8 slots. I connect slot 2 to my xmms playlist widget. Now I can type something like this:
ls *.mp3 | gpipe2
to add some files to my playlist. Then again, xmms might provide a slot that I can connect to synaesthesia, sox, etc.
...force people into a GUI environment
But we're already IN a GUI environment. Is there *anyone* who still uses Alt-F1, Alt-F2, etc as their "windowing" environment? I used to, but netscape is an essential tool. In fact, I'm soaking in it now.
-russ
Don't piss off The Angry Economist
I saw a suggestion on here I liked, but it wasn't modded up. So I'll try it for him with my own little spin on it...
We already have stdin, stdout and stderr. Why not three more for GUI manipulation. gstdin, gstdout and gstderr or whatever you want to call them. Than you could just write to them if you would like to for GUI output, maybe in some manner of XMLish language, and a special program or daemon would interpret and display the widgets and windows and status bars by reading the stream.
Then all you have to do is just not use them if you don't want a GUI. Or redirect them to a log file if you want and use the software to play back a graphical log of the actions of a program later on. Sounds reasonable.
It wouldn't break any existing programs cause they just wouldn't use the new streams but they could easliy be extended to take advantage of it.
Justin Dubs
Actually, I really believe if Linux were the default desktop in corporations, there would be far fewer help desk calls. Really funky things happen with Windows that don't happen on Linux. And when something is hosed on Linux, you can usually fix it without the acrobatics one needs to do when one installs the wrong version of IE for the service pack he is running. Try out KDE2 and you will see how rapidly the Linux desktop is advancing. It's really all coming together now.
No. Use an environment variable. Environment variable names arn't nearly as constrained as switches, and it would be easy to find one that isn't used already.
Not to mention that you only need to set env variables once, whereas you'd need to specify the switch every time.
At this moment in time. I actually regret removing my windows partition. I can honestly say that Linux crashes more than even Win 98. I am seriously considering Win 2000.
"switch"?? Who needs a switch. If you don't want a CLI program to use your GUI, unset your DISPLAY environment variable. With no display to display on, it doesn't display.
-russ
Don't piss off The Angry Economist
Networks, programs, files, widgets, and so on, can be Internet-distributed components represented in a GUI as the nodes of a flow chart. The user can join nodes via lines that depict links for data flow, procedural steps, relationships, and so forth.
--
This sort of thing has cropped up before. And it has always been due to human error.
--
This sort of thing has cropped up before. And it has always been due to human error.
HAL9000
D00000D! U forgot da Sk1nZ!!!!!!! If 1T duZnt half sk1nz, 1t sUx0rz!!!!
(But apart from that, you just described the design philosophy behind Mozilla to a "T" ;-)
sounds like Mac OSX...
Everything he is asking for can be done already (a few lines of perl, python or tcl can produce the progress bar he's looking for) and most window managers allow for assigning keys commands (get sawfish, learn lisp, hack away). There are lots of ways to perform the processing he is looking for. Unix (and linux) is great at this stuff because the gui crap isn't built in. (BTW, which toolkit would you use? Are we going to have tar for gnome, tar for kde, tar for athena, tar for ... )
If he really wants all that flashy crap, go to town, write some code, LEARN SOMETHING. Don't make the rest of us re-alias all the commands to turn off USELESS FLUFF! Pick your tools, learn how to use them, and shape your system to your liking. That's one of the benefits of open source.
Don't trade substance for style. Adding flash is easy, removing it nearly impossible.
g
because it sucks
Speaking from a user's point of view, my computer is a tool. I want to send and receive email, browse sites for information and/or entertainment, write some code, create a graphic. I need a tool that works and, once I have one, don't want to spend weeks learning how to use a new one to perform the same tasks.
I have a tool. It works. Sadly, it's an MS tool...but I don't have time to learn a new one (see above). I suspect I'm not alone in saying, "that's why insert your favorite non-MS OS here isn't on my desktop.
Let's face it. Microsoft got one thing very right, and that's the GUI. As soon as Linux gets it right, I'll gladly change.
cat photo.png page.html
and render the image and/or HTML on the page would be a wonderful addition to the command-line toolset. However, the ability to work in text-only mode is a critical part of the appeal of Unix.
That's the way I would like to see it. Basically the opposite of the articles idea. Instead of having CLI programs also support a graphical interface, make graphical programs support interations with CLI programs....
It can't be too difficult, plan9 did it a long time ago after all... Then again I'm a lowly perl/C++ program and not a kernel hacker/graphics hacker/windowing system hacker/whatever so what do I know...
I want to be able to say:
wc -w /somepath/window/1
And have get the number of words currently in the window with ID 1 (which might be a text editor with my thesis open or something - of course there are issues as to does it just the text currently visible or the whole files text)...
cat somefile > /somepath/window/new
Should open a window with the text of somefile in it...
rm /somepath/window/1
Could close the window with ID of 1.
cp /somepath/window/1 foo
Could save a copy of the web page I'm viewing in the web browser with window ID of 1...
Take the 'everything if a file' concept a bit further and turn the windowing system into a file system (as an alternative way of interacting with it)...
echo "20dd" > /somepath/window/1/cmd
Could send 20dd to the aplication running in window 1, and vi would delete some stuff...
But I'm not going to code it so I'll shut up about it now...
And it would use file descriptor 3, right? You can't do that --- it's already used by other programs.
The XPFE also is so good, that it allows people to build applications on top of it! (Just like people build apps on top of UNIX tools). Check out MozDev.org for a good listing of these apps. They all can be run on any platform Moz runs on.
Mozilla is the next UNIX. If you don't believe me, see this article.
http://theopenlab.org/piper
--
This sort of thing has cropped up before. And it has always been due to human error.
--
This sort of thing has cropped up before. And it has always been due to human error.
HAL9000
Let me know if I'm wrong, but my impression was that an operating system was simply designed to allow a user to interact with hardware. If it runs on a CLI or a GUI (love those acronyms) so what.
X + KDE, GNOME et al = way of using CLI without seeing it
Look at win9x or even NT/W2K, deep down it is still an old, old OS with a lot of makeup.
A GUI simply represents CLI operations. As far as I can see *NIX/Windows/Mac/whatever seem to work fine for what you need it to do (I won't list the uses) regards BWS
You do have visual feedback actually. What you type appears in the middle of your desktop. Stop typing, and it fades, continue, and what you had typed appears again.
:)
Tab-completion works as well
It is like the embedded terminal view, except there is no terminal, and no line between what is GUI, and what is command line.
Anyway, Advogato is a stronghold of the "It didn't exist anywhere until Gnome added it." mentality so there's no point raising these points there.
:)
In this case, it's neither gnome, nor KDE that got this (in what I consider) right, but raster and mandrake and the E guys. I just wish they'd re-release it, or re-write it or something.
also to note, most of the operating systems of this millennium do not yet have all features that we took for granted 20 years ago.
2) However much of a "failure" the Mac itself has been, a copy of it runs 90-something percent of the world's personal computers. And those rebel Linux desktops are busy copying that copy.
3) You can't have encountered too many Windows users if you think they're all people who found the Mac interface insufficient for their advanced computing needs.
Funny, I thought I left Windows to escape that horrible GUI they forced me to work with, among other things.
Like I once saw in an article, "GUI" to me means for xterms and netscape open. This is how I work best, fast and furious. It is easier to type commands and read textual output than it is to spend time controlling windows with a mouse, and it is far easier to control windows with a mouse than with a keyboard.
Not to mention the fact that my two-floppy firewall is now impossible, since I need to have X on there in order to run ipchains or ipfw.
The world does not always need to be about fancy pictures shining at us; we aren't little babies who are attracted to anything that moves and shimmers. Some information, like the output of tar, is best left to characters.
Furthermore, we'd need a standard graphics system for displaying this stuff, and a standard widget set, and all that good stuff.
If you want to select files to delete from pictures, get a graphical filemanager. If you want to see how many lines scroll by in a given time period while running tail (not very useful, if you ask me), write a program to count this and display it in the upper line of characters. It's all open source, you can modify tail itself, if you like.
Binding us to GUIs is a foolish idea. They are often cumbersome and resource-heavy. Let's not go the way of Windows; we can all see the shit it's become.
A new year calls for a new signature.
I use my PC as a 'TV' all the time. I slip in a VCD of 'The Simpsons,' switch it to play fullscreen, and pretend it's a Tee Vee.
You have a good point, a very good point. If Unix is so good at pasting tools together, then there's no need for tar to be modified. Okay, how about this, then:
xprogress gzcat files.tar.gz | tar xf -
xprogress would stat stdin, fork the rest of its command line with stdout going through a pipe, and show a progress bar over the length of the file.
But that's just tar. There's a bunch of other things I'm wanting.
-russ
Don't piss off The Angry Economist
Better yet: put this stuff in its own library and make these library routines and functions Do the Right Thing. For example, if your tar program (built with the "--with-popuplib" switch) is run from cron, or with '&!' appended (read: not attached to a terminal), or if the user is not using X, then the "popuplib_progress_bar()" call becomes a clean and silent NOP that returns an errno or status value that a coder can test or ignore. The calling program doesn't absolutely *have* to know whether a pop up progress bar is appropriate (or even possible) in order to run! That is popuplib_progress_bar()'s job. It and it alone, should determine if a progress bar is relevant to it's environmental context (ie, encapsulation), and if so, present the right one for that context (ie, polymophism).
How about zsh? If you load it's completion functions it can do miracles (like you type
rpm -e and it lists installed packages)
---
The command line *is* a different world from the GUI, it can be used as a toolset for constructing GUI tools. If you want to design a tool you sit down and design that tool, you don't graft on little doo-dads to a perfectly good command line tool.
Anyway, most of the stuff I see on Advogato is crap, and they won't let me post there either. Bleah.
I tend to work almost inclusively inside of emacs, using dired and sub-shells. You want a file-manager that let's you work without a mouse? Think about dired (it can also be run outside of emacs, though I can't comment on how well). Sometimes I might be typing a command in a shell window and decide to look up a file name: so I split the shell window in half (C-x 2), run dired in one of them (M-d), cursor through the directory listing, select a file name (C-x SPC, C-e), copy it to the clipboard aka 'kill-ring' using the command 'copy-region-as-kill' which I personally have bound to C-z), skip to the shell window (C-x o) and paste the name in place (C-y).
After awhile you get pretty fast at these kind of manipulations, and I much prefer it to dorking around with a mouse...
(On the other hand: I have yet to find any useful method of doing things recursively inside of dired, e.g. cutting a tree. But then, if I cared enough I could write a modification to dired to do this, much in the same way that I've written commands that do things like copy selected files to the directory displayed in another dired window. It'd be nice to get some more people involved with polishing up the emacs way of life... Another thing I'd like: a way of doing an "su" inside of emacs/dired...)
Anyway, in conclusion I want to point out that you really shouldn't get caught up in the CLI vs. GUI dichotomy. It's entirely possible to have a windowing system which is *not* graphical, e.g. emacs.
>Actually, I really believe if Linux were the
>default desktop in corporations, there would be
>far fewer help desk calls
I disagree - there would be more calls, just different kinds of calls.
Instead of "This is broken", you'd be seeing an awful lot of "I can't figure out how to..."
-LjM
Ummm..
All of the "features" this article mentions boil down to command line completion. He wonders why a GUI selection window can't pop up for the rm command. Simple: rm fo !tab! to execute rm foobar.file
Linux -- or rather, your window manager of choice -- can do that quite well.
I would assume that the Linux windowing archetecture is not integrated well enough to allow this.
Even if you couldn't just pop open an xterm whenever you want, it would be because the windowing system was incomplete, not because it was poorly integrated.
Blah, after all the rambling, my point is pretty much that more work needs to be done on Linux GUI before it can be seriously competetive.
The problem is that a server, and especially a server running ipchains (presumably as a firewall), shouldn't be running a GUI. Serious competition shouldn't mean sacrificing performance, stability, and security so that civil engineers can get by without knowing what the hell they're doing. Why couldn't they hire some 14 year-old to tell them how to set up DCHP?
And you ssh into these machines from a real VT-100?? Or a simulated one running under X.
-russ
Don't piss off The Angry Economist
What if a process happily running sans gui from the command line, also had an interface in something like XSLT or somesuch, that allowed an interacting gui entity to access data retrieval sources (say query a percentage value for a progress-bar display, in its simplest mode) and data input channels (if the interface defined one or more file name or list 'properties', these could be populated from drop-downs or file browser features etc from the gui).
:)
Im taking a far more simplistic approach to this than I would dare to take with any working specification I would have to program from, but the OO aspect is what is important in making sure X gui's dont all slowly turn into Windows.
The process objects public interface could be extremely simple, with hooks for adding your own complexity, as programmers must, but keeping to the basic rules of any good command line centric process or application.
The gui engine just needs to serve out objects, either simple default types for basic stuff or customised & specialised objects for the tougher stains, which could either read the interface definition and build a gui interface on the fly, or alternatively pull up a specialised interface from the 'library' as such when it is called for.
Well it could work, anyway
It doesn't need to be graphical, but doing it that way is a convenient way of getting all sort of contextual clues accross with a minimal amount of screen realestate and a minimal amount of recognition by the user.
Radio buttons or popup menus for exclusive selections, checkboxes for non-exclusive ones, text boxes for optional arguments and file dialogs for files. It gets the point accross retty easily and quickly.
Another point about commando that hasn't been mentioned so far is that it had a text area on the bottom that built the command for you as you edited the UI elements. This kept it as being a learning tool instead of a crutch.
I don't quite see the advantages of your smartshell alternative. The tab completion requires a smart terminal, so it already throws the unix stream paradigm out the window. It wouldn't be a mouse vs. keyboard thing, since MPW made extensive use of keyboard shortcuts.
I guess, I'd suggest taking a look at they way commando is set up before you start suggesting "better" alternatives.
I've said this before and I'll say it again.
For 95% of valid Linux uses, a GUI is just useless eye candy.
Linux was not meant to be a desktop environment, because real computer users don't use desktop environments. That's not how serious computing is done.
It's for serving files and relaying mail. It's for doing complex scientific calculations. It's for contributing to SETI@home and other valid research.
It is not for writing letters to grandma. It is not for balancing your checkbook. It is not for playing games!
Stop using a tool like a toy, dammit!
Not on any of the Star Trek shows? Well, this is a movie, but consider ST IV, when they go back to the 20th century... Yeah, you saw a mouse there, in Dr. Nichols' office, on that silly Macintosh. The best part is where he tries to talk into the mouse... maybe that's saying something; how about integrating speech and keyboard input with graphical output?
the real at&t mix
It is one thing I don't like to admit, but here dos actually have a better command-line than unix. But for every task other than renaming files, I still think I prefer Unix. I just hate that renaming files is so darn difficult :-)
Ok, so you can control KDE2 stuff via DCOP. What does that do for all the command line stuff that existed long before KDE was even conceived?
What about a system that provides a GUI for those command line tools, such as Kaptain (http://www.hszk.bme.hu/~tz124/kaptain/)? It's a Qt app that allows the user to set up scripts or grammars that define the CLI options. Kaptain builts the GUI and then fires off the CLI tool with the parameters that were set via the GUI. It seems to work ok. It currently just sends the stderr/stdout of the program to the shell where you ran the kaptain script. However, to fully take advantage of a GUI environment, it should pop up a window and display the output there (it may do that already, I've just started playing with it).
the good ground has been paved over by suicidal maniacs
I'm surprised that there isn't a OS GUI that does this yet; perhaps I should make the Windows version of it myself. It could be Quake's donation to the GUI world.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
If I posted a comment to slashdot about linux not having a decent GUI or not being able to operate on a wide variety of hardware, I'd be flamed out of existance. However, I can easily post about windows being unstable and frequently BSODing, even though I haven't had a problem with BSODs on a properly configured machine, and win2k doesn't seem to need to reboot. Things that were true 5 years ago aren't true today. Linux does have some very nice desktops, runs on most hardware (although cutting edge still might be a problem), and windows has gained a lot of stability since the win95 days.
Windows does have its faults, but if you want to start ranting about stability you sound like a bunch of linux zealots without a clue. Anecdotal evidence does not prove a point. If it did, I could "prove" that linux "sucks", since I've seen my gnome desktop crash more then a few times, and I've managed to crash and trash the hard disk of a redhat 6.2 install as an unprivilaged user repeatedly. (A recent release of ADOM would always do this when I tried to save and exit).
Don't be afraid to admit that windows does have some good points. We don't have to promote linux by tearing down the competition, its much better to promote linux by its own merits.
As for your problems, there is a registry hack to unload *.dlls after you close a program, it helps to free up resources (especially mem usage). Also, if you have been getting a lot of BSOD, check your setup, something is wrong with the box somewhere. Its my humble opinion that a stable windows box should have few, if any, bsods.
When Unix was written, the GUI did not exist. Unix was written to be a command-line OS only. I'm not saying that's a bad thing, in fact, some people prefer the simplicity of command line scripting over an OS with an integrated GUI like Windows or MacOS. Due to hardware limitations when Unix was originally written, there was no other option. Even the most powerful computer in the 1970's could not provide the processing power required to support a GUI. Unix was a great operating system in it's day, but sadly, there are limits to what you can do with 30 year-old technology. It's time to let go and move on to technology that was created in the days of punch cards and processors that were measured in kilohertz. I think we should respect Unix for it's past greatness, and put it out to the pasture in favor of software that was written in this millennium.
"Technically, a cat locked in a box may be alive or dead." -Kurt Cobain
Is that the sort of advanced functionality you're talking about (that has only existed for a few decades or so...)?
I see command line applications failing to take advantage of all the resources available to them. I'm not saying that we should abandon the CLI. I'm saying that CLI applications could give us more information than they do now. They could interact better with us than they do now. For example, try doing something on the command line to all files but one. For example, try tracking the progress of a long-lived pipe command. There's a LOT of value to knowing whether you should sit and wait for a command to finish, or if you should go read slashdot for ten minutes while it's working.
-russ
Don't piss off The Angry Economist
Well, much of the power and generality you're praising comes from the fact that every process has three file descriptors, STDIN, STDOUT and STDERR with standardized meanings. Now imagine if we add a fourth file descriptor to the Unix paradigm: STDINFO. A program could optionally print messages to STDINFO in a standardized format (we'd need an RFC) which could be parsed by numerous tools. For example tar might print to STDINFO "percent_complete=34". A GUI might use this to power a progress bar.
However those of us who aren't into GUI's would find lots of cool uses for this info. How cool would it be to type ps -<something> and have most of the processes show certain metrics, like how many lines of input they've processed and how many errors they've encountered? Or imagine typing "tar -xvf huge.tar 3|grep'percent_complete=5[0-9]'>&1". In other words, let me know when it's half done.
I think this would rock. And adding a few printf's to tar wouldn't be much bloat.
> KDE 2.0 already claims you can do anything
> from the keyboard and the object model supports
> scripting.
JOOI, does this mean that they've hacked X so you can start it without a CorePointer device? Just that I was trying to start XFree86 4.0.2 the other day with no mouse -- I wanted to see if it was that that was causing a prog to go bananas -- and it seemed damn near impossible. Which I thought was odd, becuase the number pad following a SHIFT+NUMLOCK works just as well....
What I would like to see is a combination of both of these. For example when I am browsing around in a file manager, sometimes I want to just rightclick and delete a file or something simple. Other times I want to type in a script name to run on the file. I think the best way to do this would be to have a command line space on the bottom of the file manager. The command line space's working directory would be whatever the current working directory in the file manager is. Then I can do my gui stuff in the file manager, and then type in stuff on the bottom if I needed to. Basically a bash shell whos working directory stayed in synch with the file managers directory. It's the best of both worlds.
Outdoor digital photography, mostly in New Engl
If Slashdot stole it how come its still there, smarty pants...
Sounds like you want some sort of component architecture for algorithms... Kinda like JavaBeans, but without the emphasis on graphical representation.
I guess OO languages already do this in essence, by putting all common functions in some class with some interface to the world...
-- Mike
- prevents the copying of text files that carry copyright notices
- automatically translates natural-language text files to and from English, French, German, Finnish, Serbian, Mayan hieroglyphs, and Klingon
- interfaces to e-mail, FTP, palmtop computers, hearing aids, and coffeepots
- For users who don't understand the philosophy of the Unix CLI, Cat now incorporates the functionality of over 120 other Unix commands, such as Grep 2006 and More 2005.
- For users who are used to inaccurate Windows progress bars, Cat 2007 features a special nonlinear mapping that makes the bar go almost completely across, and then crawl the last 5% of the way very slowly while little animated pictures of pieces of paper fly across the screen.
Smith also noted that Cat 2007 is not interoperable with files written by Cat 2006. "We don't think it will be a big issue," said Smith. "We think all our users are going to want to pay for the upgrade because of all the new features."Red Hat's stock rose 37 cents on the news of the new product.
The Assayer - free-information book reviews
Find free books.
I say this, because to me, this seems like making the iceing before you make the cake. I don't know about everyone else, but XFree86 leaks like crazy. the 3.3.x strain eventually became relatively non-leaky, but was quite slow.
Now, though, we've got the 4.0.x stuff, which is fast(er), but leaks horribly. I'm not the only one I know who has to restart the beast at least once every couple days. This is beyond inconvinient - if I'm running half a dozen instances of a GUI program that have data I can't easily save and haven't gotten to yet (netscape/mozilla, for instance), I do not want to shut down X to clear up cache/swap. Yet, I know it needs to be done, because the system is getting bogged down. It makes UN*X desktops look really bad from any perspective - linux, unix and the like are supposed to be stable and bug-free. X is a huge component, and I'd wager one of the more widely used pieces of software in the OSS world.
This should be a focus point, and a matter of concern, not integrating CLI and GUI usability. That will follow once all the CLI nazis (sorry guys) start using the (future) more dependable, stable, less memory intensive X.
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
With all the talk about sound software recently, this reminds me of signal flow, which is put through a patch bay in an analog setup.
So, imagine a *nix GUI that involved a CLI, but allowed you to visualize the "signal flow" as you typed. Look at this example from Symbolic Sound. This would allow very complex CLI commands, and you could modify them by moving around the blocks in the visualization (see above example). Something similar to "round trip" HTML editing in Macromedia Dreamweaver, but hopefully better implemented.
I'm a bit of a newbie; so forigive my ignorance. Could the Unix/Linux/*BSD community not come up with some sort of graphical shell output with standardized API's? The console has stdout, stdin, stderr, etc. If you create a utility gsout (for output to the graphical shell), which could be accessed with >>>, then a command in an *term would know to display the results in whatever graphical shell you might be using (Nautilus, Konquerer, EFM, etc -- I suppose this would be an environmental variable). >>> would essentially be a pipe to the graphical shell. Gsout would analyze what is coming from the *term and relay the info to the graphical shell, which would have its own specialized way of representing that info. Just a thought...
~~~~~~~~~
dissertus scribendo latine videri volo.
Firstly it's already been done. There are X versions of many programs which are nicely bloated to include all of the GUI gumpf and you have a choice to install them, or not. So why don't so many people install or use them? Why isn't there a massive effort under way (some may argue there is) to create such a thing? Perhaps it's because it isn't nescessary to accomplish the tasks that users are presented with today. There are generally two types of tasks that people use computers for. The first is to set a computer up to automate a tasks such as serving documents, switching transactions etc. You set it in motion and you leave it alone. The second is to get the computer to aid you in creating information. It requires constant user interaction. *nix does a good job with the first, WinX does a good job with the second. They both cross boundaries but they both start getting more complex as they do. There is room for both, there is a need for both.
KDE 2.0 already claims you can do anything from
the keyboard and the object model supports
scripting. Also, most KDE 2 applications even
allow you to use regular expressions every place
they might be useful--as an option (not a
necessity).
I absolutely agree that the philosophy of small
tools should be expanded to GUIs, but I think
KDE is doing this. The QT toolkit's signal and
slot philosophy is a near parallel and KDE
componant objects nearly complete the
requirement.
The old OS-9 operating system (used on CoCo's and
some M68000-based computers like Atari ST) also
had an interesting philosophy for GUIs.
You could pipe data in and out of every Window
and all kinds of GUI activity could be managed by
character streams all centered upon ASCII.
It was an excellent philosophy. Last I checked,
OS-9 was still marketed for embedded systems.
This is the OS-9 of Microware systems
corporation--not the MacOS 9
--Matthew
COMMAND -option1... -optionn file/object/ output location
It seems obvious to me that this concept can be easily implemented in a GUI, and hence be easier to understand. A pull down menu for the available commands would cover the first part. Usinag a similar method, one would select the options with simple clicks of the mouse. Then one would browse the file hierarchy and choose a file to operate on, and a location for the output to be piped to, STDOUT as default.
This would give newbies an easy way of using the power of the command line from an easy environment.
One could also include lots of online help, something that bash is not very good at. Man pages are notoriously dificult to understand.
I think that this schema would be an obvious first step in creating a GUI'ed shell, and could well exceed the power of the shell in terms of easy understandibility and visualisation. I am sure that Network Admins and Windows users would find it a very useful tool on Unix.
You know exactly what to do-
Your kiss, your fingers on my thigh-
You know exactly what to do-
Your kiss, your fingers on my thigh-
I think of little else but you.
Even if the user never fires up a terminal session, the command line interface is important. This is because a GUI is objects that one sends commands to.
The simplest is a program launcher, where one creates a command "$1" in. In a drag and drop, one drags $2 onto $1, and runs the command "$1 $2". One can also have the context drag, where one drags $2 onto $1, and gets a popup menu that $1 and $2 interact in defined ways.
Of course, one can use context menus for the drag and click. The Windows start and send to menus are nothing more than desktop objects used differently. You can actually put shaddows of these (c:\windows\start menu, and c:\windows\sendto) on your desktop and manage the icons directly from the desktop.
Selecting from the start menu is simply doubleclicking an icon from the desktop, and the send to is the target of a drag, but one does not need to see the desktop to make this happen.
You can use a right-drag to allow multiple options to be selected from the same drag and drop. You drag $2 to $1, and from the pop-up menu, select "$1 -m $2" or "$2 $1" or "gfc $1 $2" whatever. The icons can be configured to do this. It is the user perception that needs to be made aware of it.
It goes the other way as well. The Windows start command will open documents, directories etc from a command line, and I have changed Windows and OS/2 icons and titles from a command line script. This gives a visual indication that the script is done, and there needs to be attention from the user. The easier the interface is understood, the better it runs.
This is a strength of OS/2, in that the icons have global names, and is not dependant on their positions in the desktop. You can change the name of an icon, or start it from the command line from a rexx script. The c:\nowhere folder is used for icons not intended for the desktop or vible directory.
You can join the GUI and CLI in innovative ways, but unless you communicate what is possible, the user is simply going to ignore it. Ignore it, becaise the User is forgotten. :)
OS/2 - because choice is a terrible thing to waste.
Isn't it easily done in Unix too?
Runlevel 3?
It does not start the CLI shell for user input at all if I understand it.
The command-line rules for one very good reason. It does what you tell it -- no accidental slip of the mouse to execute the wrong file (whoops! I didn't mean to click "rm", where is "undo"?)
And there is no need for a gui on many boxen - routers don't necessarily need a gui, or even a monitor. Just let the thing crank away and ssh to it when necessary.
Your solution would require the installation of X libraries on all machines using your binaries.
Or: drag a url onto your gui-aware terminal and it runs your fave textmode browser and goes to the url...
Are there any xterm replacements doing this sort of thing?
--
.sigs: Just Say No!
If we don't do that soon, Unix on the desktop is doomed
Je t'aime Stéphanie
Hmm...
JESUS CHRIST and his black bastard brother Harry! That tastes like SHIT!
Bad idea. Nuff said.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
"even though I haven't had a problem with BSODs on a properly configured machine, and win2k doesn't seem to need to reboot."
Ah, you're using Win2k. Most Linux users who have had stability problems with Windows have had problems with the DOS-bases versions of Windows, namely Win9x, and possibly WinME, which *are* crufty.
The only problem with that is feedback. It's very convenient for quick app launches, but if something segfaults you can't tell(except for the obvious fact that it doesn't open).
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
a/s/l?
Automatic Slashdot Looser?
build a desktop unix and build a server unix... Build from the common tree. People can elect to run the windows or server version. If you're away 200 miles, you should be running a desktop Unix and dialing to your server version via a 300bps line. Let's not ignore the GUI part of Unix. Too often times, the server backend is decided by the desktop/frontend. For a dumb A___ example, if desktop users run Windoze, guess what sort of filesystems/file server they want on the back end?
> Providing programmability for the fancy graphics software remains an open problem.
Get KDE 2 -- or even better KDE 2.1 which will be released in the next few days.
Accessing the GUI from the CLI is already possible in KDE 2 for a long time via DCOP. Fire up kwrite (make sure you don't have two kwrites there at the same time -- otherwise you have to add the pid to those commands) and type into your favourite xterm:
--snip--
dcop kwrite KWriteIface insertText 'Windows rocks!' true
dcop kwrite KWriteIface setCursorPosition 0 8 true
dcop kwrite KWriteIface insertText 'sux! KDE ' true
dcop kwrite KWriteIface shiftHome
dcop kwrite KWriteIface writeFile 'conquer_your_desktop.txt'
--snip--
or check your Mail using KMail by entering:
dcop kmail KMailIface checkMail
or bind the command "dcop kdesktop KScreensaverIface lock" to your "Pause"-key using kmenuedit. That way you can start kscreensaver by pressing the "Pause"-key.
To explore the possibilities you might want to use kdcop.
Greetings,
Tackat
There have been a number of excellent ideas proposed here, and the common theme of them seems to be: just expand the present UNIX CLI paradigm a bit further to encompass the possibility of a GUI:
/proc style filesystem to keep track of windows and window information
- Adding a STDINFO handle to the usual STDIN, STDOUT, STDERR
- Adding a
- etc.
Let's face it, what we really want here is for windows, and other gui objects to just fit in as extra objects that can be handled, piped, grepped, etc., but in exactly the same way that processes, devices, can be.
That's true integration of the GUI with UNIX - don't layer it on top in a mishmash manner, embrace it in a UNIX way (as opposed to trying to cram the whole thing down your throat ala windows), so that it doesn't matter if it's not there.
Jedidiah
--
Craft Beer Programming T-shirts
Did anyone ever run the default Window Manager for Domain OS (Was Apollo Computer, then HP bought them). The system had a cli at the bottom of the screen (with history, history substitutions, etc.) but the coolest feature was that you could select input from an open window, apply substitutions or even whole scripts from another window, and dump the results into yet another open window. All from a graphical UI that was similar to X, although it wasn't. I imagine something like this fits the requirements of most peoples CLI bashing (cat file | grep 'findme' > file.found) or something of the sort at least. It might be a model for further integration of more integrated GUI/CLI type functionality. Robert
First off, one of the most useful (powerful) parts of the CLI is the ability to pipe/redirect output. It's not that unusual to have five commands stung along to some end-result; I would not want 5 dialog boxes popping up that I then have to close.
Secondly, linking in GUI routines to CLI tools would make these programs many times larger (in disk space and memory consumption) then they already are. Something like 'cat' which is ~10 lines of C would turn into several hundred.
Third, which GUI toolkit do you standardize your CLI tools on? GK? Qt? athena? openwindows? Then you have to make assumptions on which GUI libraries are installed on a given operating system, not to mention differences between one platform and the next. The simple bintools that used to be compilable on any platform will then increase in incompatability and build complexity exponentially.
The final reason not to do this is that you then force people into a GUI environment regardless of if they want it or not. Whats the point of GUI-linked tools on system with only a serial console for instance? You end up requiring a GUI toolkit be on a system regardless of if the system needs or even supports such a thing. You force the tools to become unstable if only becsause a windowing system is inherently more complicated and therefore more likely to have problems.
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
Take a look at AtheOS (www.atheos.cx) where the GUI is incooperated into the kernel. Its pretty slick! =)
Before you email me, remember: "There is no god!"
In Windows, use win+r for the RUN command
This opens a single command line. History? Tab completion? cd? Hardly. It does not open a shell window. To open a shell window, you have to type command or bash into the dialog box that the Run... command creates. (To get bash and friends, download and install DJGPP (DOS/Win9x) or Cygwin (9x/NT).)
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Not like in Windows and linux where I need an CTRL+Q to quit
Damn, and all this time I've been using ALT+F4 (to quit) without any extra bending.
Key bindings, like touch-typing, are a learned skill. Different people will find certain keys akward to press, while others think it's "efficient" or "quick".
signal, noise, to me it's all the same.
Subshell support has never worked properly (if at all) in any graphical edition of MC (xview, tk, gnome).
Having said that, I must say that I'm impressed with OSX. The GUI is different from pre OSX but it's still very easy to use. In addition to this, you get a terminal. Oh yes, just about anything that can be done on Linux can be done on OSX. The March 24th release of OSX will finally turn the Mac into something that people who read /. can respect. (That being a Unix based OS...)
Willy
Oh, so now i'm a liar? All the problems in my post were 100% real. Ok, so you didn't have any problems, so I must be lying then. What kind of screwed up logic is that? And how the hell did you get modded up as interesting, because you used "lying", "linux" and "zealot" in the same post?
I've been running on microsoft products since DOS 3.0, thank you. And I know my windows god damn fine, I've been fixing everybody's computer I know since I was 12. And I've been doing tech support for 3 years now. Oh, and btw dumbass, we support MACOS as long as it's newer than 7.5.3, and I do give linux support(as long as the person i'm talking to knows what he's doing), altough it isn't officially supported.
YOU my friend, should start using your brain instead of running to the defense of M$. And how the hell was that bashing, all the problems REALLY DID happen in the last week, who the hell are you telling everybody i'm lying. I mean, do I have to tape myself everytime I fix a god damn computer so you can believe me?
The only problems I ever had with linux was my own fault(i.e running out of disk space so X wouldn't start, etc). Actually I appreciate you calling me a linux zealot but the truth of the matter is I'm probably more skilled with windows than you'll ever be.
No. The GUI things that most CLI programs would do would be quite similar, which would suggest a higher-level library that the CLI programs can link to. The library would abstract the windowing system and GUI toolkit away from the CLI programs (which would then not care about the actual windowing system used) So, to address your concern: if you want no graphical stuff of any kind, just add the version of the said higher-level library that has all its functions empty. There ya go, no graphical bells and whistles, and no X libraries (or other GUI libraries).
--
SecretAsianMan (54.5% Slashdot pure)
Washington, DC: It's like Hollywood for ugly people.
> This opens a single command line. History? Tab completion?
Yes, If you select the keyboard-scheme "Unix" you get tab-completion in KDE 2.1. A history exists as well.
Translating that into a UNIX environment is a bit harder, but it might be worth having another go at at it, perhaps based on XML and web infrastructure.
I would like to see programs that are coded in such a way that all the core algorithms are compiled into one file, and you simply have to code an appropriate access module for each interface, plus whatever graphical goodies you might throw in. You'd probably be fine just coding everything so that it can theoretically run from CLI and then pipe that into your graphical front-end. That way everything is nice and portable, so people can use it in their graphics system of choice. Many windows programs do this with DLLs, and often with great success. Obviously you get problems with managing the DLLs and everything gets unstable after a little while, but that's the kind of thing maybe we could get right. I know there are some downsides to this method, such as requiring programmers to write portable code. On the other hand, if we lost half of the bad programmers to laziness and trained the other half to do things right, I think we'd all be better off.
WARNING: there is a trojan on your
Before everyone starts getting excited or annoyed, it should first be remembered that UNIX doesn't have a standard GUI, and for the UNIX tools to have GUI parts or GUI reactions we would have to settle on which GUI would make the best fit. Or perhaps a default toolkit that all GUIs interface with? Either way, I think CLI and GUI should remain seperate.
I think someone out there is trying to make UNIX easier for *them* to understand.
"It's here, but no one wants it." - The Sugar Speaker
There are many problems with including the x libraries into these tools.
First is bloat. tar is nice and small, so are the rest of the command line tools I don't want tar to be several megs. leave the bloatware to microsoft.
Second, not everyone installs X. I have a firewall box that I didn't install X on, guess what, the default emacs wont load (can't load the x libs to determine that x isn't there, stupid). I'm not too peeved about having to rebuild emacs, but don't ask me to rebuild all the shell tools as well.
Your example of the alias would work better the other way, write a wrapper for tar (Xtar?) and alias that.
The strength of unix is the "do one thing and one thing only" ideal. Each of these tools works great and can be combined in ways that amazes GUI users.
Please, PLEASE, do not make the mistake that microsoft made and integrate the GUI into everything.
g
Beyond the disconnected punch cards and paper tapes the first electronicly connected User Interface was logically the keyboard. Where versatility came as a result of and matter of character sequencing on the command line.
In time the GUI became the next and still logical in the evolution of User Interfaces. It provided less versatility but greater ease of use by those being introduced to computer for the first time.
But what both of these User Interfaces have in common is the fact that they are both based on the use of icons or symbols. The GUI having less versatility then the keyboard but greater ease of use. And thru various methods the sequencing versatility of the keyboard, character sequences could be automated or prewritten and attached to a GUI icon.
But then there is the incredably slow evolution of the logical third User Interface. The interface that completes the natural triplet of core user interface set. Not so unlike the value of having all three primary colors to mix paint or light color from. Removing any one of these primary colors greatly reduces possibilities.
There are various speices, if you will, of this third user interface. Often it's spoke of in term of the programmers APIs but command line piping and Interprocess communication or messaging are other labels. But overall, this third user interface is that of having the ability to send a running program or function library or other functionality such as DOS, commands from an external to its operation, common location.
As an example, the Commodore Amiga evolved with an AREXX port usually included in programs and libraries, etc.. NOTE: it's not AREXX here but the fact of this side door for external control exist as a standard, even in some programs that didn't require AREXX to be running.
So the three User Interfaces Are:
1) keyboard (ASII)command line interface
2) Graphical User Interface, typical mouse access
3) The side door to functionality control and
integration.
The keyboard or manual character sequencer can address both the commandline environment and the side door. And it can also be used to define a character sequence automation attached to a GUI icon that triggers a control communication to a specified side door.
Of course there are other possibilities, as is obvious in the analogy of primary color triplets.
But then there is even more that can be accomplished once these three user interfaces are established on a system.
Dynamic integrated automation can evolve. From allowing the user to easily access thru a consistant interface, the details or descriptions of functionality... to making their own definition to extend their systems dynamic automation ability. Providing the user with the ability to automate anything they do over and over again, regardless of how many programs or other functionality is used in the automation.
Now isn't this really what computers are all about? The ability to define and activate the automation of complex functionality sequencing?
Programmers do it all the time, that's what the point of programming is, to automate complexity to the point of being much simpler to activate then doing manually.
In fact with such a general purpose automation tool being used thru the three user interfaces it would be possible to automate the do's, don'ts and standards of any program language as well as any functionality inclusion that can be repeated, even dynamically.
And as the automation continues it compiles and executes the generated code, etc...
But what I have found is that the psuedo programming industry doesn't want to really remove the foundation on whch companies like Microsoft stand. For MS was built on the premise that programming is a difficult and complicatd thing to do. Identified and labeled in the 60s, as the "software crisis" from which it probably evolved in the 50's out of IBM causing a distraction in genuine computer science along with the governments war decription/encryption efforts.
Sad to realize the computer industry got a major start due to the practice of hiding and trying to see hidden communications.
An apparent practice that seems inbreed to the point of...... well where does inbreeding usually lead?
That's going to end. Just call me Neo!
Yep! the informant is real!
Each one of the character represent an action. Something we all do. Actions that can be programmed and used to automate dynamically.
How bad do you really want the next advancement in User Interfaces? Bad enough to become unplugged from the psuedo programming system, and that which supports it?
3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!
Another way to do this is for xterm to catch the file completion key (ESC-ESC or TAB), verify that you are in a shell (not running an editor), and then pop-up a file completion dialog box. IMHO, the only hard things about this is determing if you are in a shell or not, and what the shell's PWD is. CS Miller.
It has become appallingly obvious that our technology has exceeded our humanity. --- Albert Einstein
We absolutely MUST make a desktop version of UNIX before Microsoft moves much farther into Server-land. So long as the GUI is optional, why should it bother you if you don't want to use one? Keeping diversity alive for any and all software depends on significantly diminishing Microsoft's dominance of the Desktop. That's means it has to be better (not mere as-good-as) Windows. Let Diversity of Innovation Thrive! --Matthew
So maybe you need two cars. One, a tool, to get you to work and the other, a toy, to go to the beach. That'd satisfy the author of the original post, surely.
What a long, strange trip it's been.
Really we've seen that Linux does best as a server in a back room with only a web interface or an appliance with a button interface or a remote control. You wouldn't want users to have to interface it through a GUI or a command line.
Linux methology, in general, is making an operating system that assumes you do know what you're doing - and otherwise you've got an ever decreasing circle (are you really sure you want to delete the file?). You can push your monitor beyond the specification limits and many times you don't fry it (and achieve better performance - consider it like overclocking and entirely at your risk).
Windows limits you (well, you could edit the registry) to what the manufacturer is sure the equipment can do. I think that's a bad thing.
Anyway, XFree4 can read the monitors syncs frequencies. There's no reason to burn something on purpose if you do your research. I've fried a few monitors (on purpose - they were going to the dump and it sounded like fun), chalk it up to experience.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
Hmmm... looks like the project's been pretty quiet for a while. Anyway, it's still a good idea.
use mmv. it rules.
:)
mmv "*.txt" "#1.html"
you can do all sorts of cool things - great for renaming mp3s from napster.
At the beginning was at.
I am increasingly troubled by how many new applications are designed to work solely under a GUI. While this may make some amount of sense for people coming from the PC or Mac worlds, one of the strengths of Unix has always been the ability to use it from anywhere. These people don't seem to understand this. Of how much ultimate utility is that nifty new spreadsheet, editor, or debugger if I can't dialup from the field and run it on my vt100? Too often a tool that "does windows" is little more than a marketing gimmick to dazzle impressionable users into not noticing that they don't have the real functionality they need. GUI-minded programs seldom lend themselves to being used as components in larger tools. As such, they do not fit well into the UNIX tool-and-filter philosophy. Instead of each being a single program that modestly attempts to do one thing well, they are a throwback to the Bad Old Days when each program was a standalone, monolithic monster that didn't interface with anything else. It's all well and good to place a GUI wrapper around an existing tool, but to design a new application with only a GUI interface in mind is to forever limit that tool's flexibility. After all, how to you write a shell script that drives an automated xrn session? Providing programmability for the fancy graphics software remains an open problem. The most effective use of GUIs in UNIX environments is to design the nitty-gritty computational function as a "back end" that can be driven either manually or automatically. The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology, such as SunView, NeWS, or even X11 or its children, like Open Look or Motif. Sending standard commands down a pipe the way the STDWIN or wafe packages behave is also a reasonable approach. This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems. It has been noted that GUIs make simple things simple, and complex ones impossible. Certainly it is worthwhile to make simple things simple. But too often software is geared to only one level of expertise. That which is novice-friendly is too frequently expert-hostile, and vice versa. Being needlessly forced to click the mouse over a menu will slow down the expert user who is more comfortable with a keyboard interface. Gratuitous distractions from the keyboard only slow down the experienced user. A precision pointing device that didn't require taking your hands off the keyboard would help. There are cases where only a GUI makes sense, like a CAD system. Being able to delineate a region or draw a figure with a mouse is probably a reasonable use for it, but selection of a range of possibilities isn't, at least not after you've become familiar with the tool. -snellac
I don't think this fits with the UNIX philosophy. Let's face it, all of the important aspects of UNIX have been hammered out many years ago and we're just adding sprinkles right now. There are still pipes, signals, and processes, and we're probably going to have to deal with them for the rest of its lifetime.
... What our next OS needs to have is processes that can tell the outside world what they're doing. For instance, grep would say "I'm working on this stream of data, with these options, and I'm this percent complete..." and the GUI could display this info, perhaps in a flow graph format.
But let's not assume that we're going to be using UNIX-like OS's for the next 100 years (please dear God no)
I would like a system where the user could graphically drill down into a script and see the execution flow, monitor the data being slung around, and have some control over what is happening. My big beef with UNIX GUI commands (and Windows programs) is that they spawn off processes that spew output into some remote terminal somewhere, or terminate for no reason and you can't find out why. (Witness the RedHat installer -- at least the old versions)
UNIX UIs aren't "all wrong". They're simply a reflection of the environment in which they must exist. We'll have something different when we build a different OS world for a UI to live in.
For example, on the command line, doing the copy operation you mentioned is easy. But what if I want to choose a few desparate files (for example, somepic.jpg athing.gif and foo.c from ten or so files. I think this is much easier to do in a GUI.
Likewise, I think it is simpler to drag a picture into a WYSIWYG HTML program, positioning it (although, having the code on hand is nice as well).
Further, when we start getting into larger icons that *all* contain thumbnails of pictures, miniature documents in thumbnails, miniature code in C++ programs, etc., it will be a lot easier to pick out "all the pictures with a red boat in them", and "all the documents that look like web pages with no extensions" and make file changes. The command line will lack here. (Look to Mac OS X and even Windows 2000 for examples of this "miniature view" of files beginning to take hold).
To each his own. I agree that *NIX makes a hell of a file server. People are idiots if they think a server needs a GUI. That's a waste of resources. Still, for workstation tasks a highly-customizable, highly object-oriented (not simply in the C++ sense, but designating files as actual "things" with properties relative to their picture/document/code classification) is best.
--------
Carmack is an elitist, pseudonerd bastard.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
I've said it before, and I'll say it again:
:)
.txt to have thousands of files that no longer have .txt, but .html at the end. Hoo-YAH! :) Quick 'n easy, if hard to learn. Try doing the same without an quick 'n dirty shell script, or script of some other sort.
:)
People migrating from Windows to *nix, and Linux in particular, are wasting their time if they never leave GNOME/KDE/whatever.
Aside from stability and philisophical issues, Linux doesn't have all that much to offer if you stay in the various desktop environments.
The power of *nix, and therefore Linux, comes at the command line. Lots of little utilities, which are fairly easy to learn(if one decides to learn them, and takes the time to read the documentation) lend themselves to a great environment.
I've found that in Linux, the more complex a task becomes, you need to put proportionally more work into it. I think it's about 1:1.
In Windows, the more complex a task is, you end up spending an exponential amount of time at it. As soon as you try to do something that doesn't have a button somewhere, you've got to bend over backwards.
Even when there is a button for it, you'll often have to find it, which isn't always easy.
There, I've said it
Anyways, I'm all for integrating the CLI into the GUI. I'd love to be able to type 'for i in *.txt; do mv ${i%%.txt} $i.html; done' in a URL bar.
Look at that, I just re-named thousands of files that ended in
If GUIs start incorporating more shell-like features into them, we bring that up another layer, and make things easier.
Okay, I'm babbling. You'll have to forgive me, I'm really terribly sick with the flu
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Heh, it's funny to see people discussing integrating CLI and GUI. Something that was available already in 1985, if you used Amiga's
I totally agree, I would love to see some of Raskin's ideas implemented. (although I don't think all of them would be as intuitive as he makes them out to be) I'm currently research human computer interaction for a report in my human factors class and I am thoroughly intriguied with the ideas in Jef's book. Unfortunately, it seems like mainstream user interface designers have gotten it all wrong.
on a clean install, 98SE is not bad.... not good, tho. this is why (besides the file security issues and such) it is not used in a corporate environment more. NT, on the other hand, has not been mentioned once here. Of my 3 servers here at the office, all 3 run NT with relatively mainstream hardware. Total downtime of all 3 combined over 1 year of operations? About a day. Total. This includes the memory upgrades i did a few months back.
Check out 2000 before you discount all of windows systems. It's pretty nice; even my Linux-runnin'-windows-bashin'-billgates-despising friends agree with me. One even acknowledged (GET THIS) that microsoft got it right for a change.
wierd to hear, but true. Don't confuse the 9X kernel systems with NT kernels... the 9X are acceptable only for newbie home use. NT and 2K are what you should be comparing your linux monster distros to.
have a nice day, kids.
--endcycle--
When I do data management tasks with MS COM, I'm painfully aware of how crippled the Windows environment is. For example, I would like to run an AS/400 5250 terminal automatically to grab data instead of clicking the mouse and hand typing in stuff. Sure, the terminal (I'm using WRQ) is a COM server that lets me do all sorts of neat stuff from COM clients. But I still am forced to deal with an app that was primarily built to be GUI, not remotely leveraged by other code or apps. Work that would be a short, little process running behind the scenes in Unixland turns into a dance of windows popping up and disappearing (I actually have to tell the stupid thing to go away when it's finished). That's why I like the author's idea of dual CLI/GUI utils. However, the Uxinae still can't touch COM for slickness, modularity, and flexibility. GNOME is beginning to address this gap with Bonobo(sp?). I think some cross-fertilization would be good for both camps....
--- WWSD? What Would Strider Do?
For example, try tracking the progress of a long-lived pipe command. There's a LOT of value to knowing whether you should sit and wait for a command to finish, or if you should go read slashdot for ten minutes while it's working.
So write an 'xpipe' application which executes a command pipe, and notifies you when each application exits, optionally with a popup message. Modify an existing shell to do this.
Pull your finger out man!
I just stick xclock at the end of a long pipeline, so I can piss off and do something else.
...using Slackware boxen with WindowMaker, CLI from aterm, wterm or other term -- all else is irrelevant in a GUI.
Those dependent upon desktop manglers (Gnome, KDE, etc.) just MS Windows Wienies pretending to be leet: May RPM wreck your box even sooner than it would otherwise! Then you learn value of knowing vs. pretending to know, glasshoppa.
Everything in the Universe sucks: It's the law!
Touch screens looked good in Star Trek, but in real life, you end up with users suffering from Gorilla Arm.
Similarly another Trek-ism, voice control suffers from the same problem. Just as touch screens cause Gorilla Arm, voice recognition generates laryngitis and has the additional effect of annoying bystanders.
I think I'll stick with the keyboard & mouse for the time being. Though I wouldn't mind seing the keyboard redesigned. Get rid of useless keys like Scroll lock, and simplify things a bit.
Meldroc, Waster of Electrons
>default desktop in corporations, there would be
>far fewer help desk calls
I disagree - there would be more calls, just different kinds of calls. Instead of "This is broken", you'd be seeing an awful lot of "I can't figure out how to..."
Not with proper training. Newbies (like we were all at some point) sometimes have problems trying to figure out how to do something because we are used to the 'other' way to do things, but thats easily solved with a well designed training course.
Where I work, (Fortune 100 company), if your job requires you to have a Windows computer, you have to complete training on how to use the OS and all the aplications used here.
Lesson 1 includes such gems as:
*Parts of the Computer
*How to use the mouse
*Description of the directory tree system
*What is the Internet
*How to read and write email using MsOutlook
etc, etc, etc...
The helpdesk here mainly works trying to solve diverse design problems with the Win2000/Exchange based networks (good thing that the mission critical systems are on UNIX) and explaining people that its 'perfectly normal' for the computer to freeze randomly when opening up a new email message.
------
C'mon, flame me!
No sig for the moment.
I think by convention it would be --dont-do-that-gui-shit.
treke
I'm sleep deprived and a little buzzed, so...
Imagine little snippets of unix cli like 'rm', 'mv', 'awk', and so on to be akin to genes. Atomic components that can be combined in endless variety to form all manner of little scriptlets to perform an endless variety of tasks. Combined completely randomly, of course, you'd get garbage. Apply a little bit of selection pressure, though, and what do you get?
I often like to think of the world of programming (from humble shell scripts to obscure assembly constructs) as an ecology. We all continually adapt and combine our little text constructs to produce new forms, some good, some bad. Rinse, lather, repeat.
The problem I have with GUI's is that I just don't see how they can easily mirror this important process of continual refinement and renewal. They're just too clunky. For example, I can show you a trick, like
for i in `find . -iname "*.php"`; \
do perl -pi -e "s|.*ddate.*||;" $i; \
done
and you can easily adapt and reuse this idea in ways I would never guess. Is there any kind of analogue to this type of rapid sharing of adaptable information in the GUI world? If so, please clue me in, because I don't see it.
--Lawrence Lessig for Congress!
Telling customers/users/potentials that you product should only be used for one service and that all otehr creative and necessary uses make them pansies...that's a great idea. Wow, you should stop posting on Slashdot and start writing advertising slogans!
I'm going to wager that you don't work in a Sales or Marketing department, right?
------
Let me give you the lowdown
IceWM has had a command line built into its double height taskbar for years, that's mostly why I use it. I could be editing a file or reading some docs and I want to look something up in a man page or bring up my editor. Ctl+Alt+Space, type in my command, and I'm off. It may not be that smart or have a history, but that's why I have terminal windows.
I think it's called the DISPLAY environment variable.
I/O Error G-17: Aborting Installation
--------
Carmack is an elitist, pseudonerd bastard.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Hmmm...I thought that the UNIX philosophy was "no news is good news"...meaning that in this case tar should only show something if an error occurred.
"sweet dreams are made of this..."
Symbolics' Genera operating system used a system called Dynamic Windows, that nicely integrated the command processor and GUI. The command processor was both simpler and more powerful than Unix shells. Simpler, because scripting was provided by the Lisp interpreter. More powerful, because commands didn't just return a result code -- they returned entire objects (or multiple objects!). The presentation manager was responsible for formatting those objects in an appropriate manner. The Show Directory command returned a list of pathname objects, which would be shown as a list. The nice thing is that the GUI knew what they were, and they remained active objects: You could right-mouse-click on a pathname and get a menu of appropriate actions (Edit, Show, Delete, etc).
Similarly, the commands themselves were integrated into the GUI. For example, the Command Processor knew that the Show File command took a pathname as argument. If you typed Edit File (without hitting return) all the pathname objects in the window would become active, and you could click on one to send it to the Edit File command. Or you could hit Ctrl-? to pop up a list of possibilities.
If a command needed some more complicated interaction, it could send a dialog object to the command processor, who would append it to the window, allow the user to fill it out, then send the results back to the command.
Full GUI apps were easy as well, even a GUI application had the same basic model, it just needed to turn off scrolling, turn off command echo, change the menu to an application-specific one, and send Dynamic Windows whatever presentation objects it needed to get cranked up. Menu entries, mouse clicks and other gestures, and accelerator keys were translated into commands and sent to the application's Command Processor.
There was a lot more to the whole thing, of course, and this short description doesn't begin to touch richness of the system, but the closest I can imagine a stream-based system getting is via XML, which is again an awfully low-level way of attacking the problem.
/*If you look into the history of UNIX you will see that it has always favored stability over speed, and a small program that does what it is supposed to do rather than one large bloated 'featureful' program*/
Like EMACS?
If you were me, you'd be good lookin'. - six string samurai
Interesting ideas, but couldn't a new branch of standard unix tools, sh (you choose your fav) for one, be an answer? Maybe a good answer would be versions of several tools to behave similar to emacs, with a console-only version and an X enabled version? It would be easy to implement the changes which he mentioned, but the tools should never be made to be X only, unless they are specificly gui tools. I have no idea how many times I have been modifying my XF86Config and fscked it up, if I couldn't edit from the console I would be fscked. It'd be just like windoze...
Spring is here. Don't believe me, look outside!
That's one problem with Linux GUIs in general. There's no *synergy* Even though you have all these GUI tools, the CLI versions are just plain more powerful. There is no reason for this, it just happens to be that way, because people think CLI first, GUI on top. It shouldn't be the other way, either. They should co-exist peacefully. I want to be able to draw a picture in my graphics apps, then run a script from the command line to do my favorite transform. I want to be able to manage my contacts graphically, but script it so I can add a hundred contacts with a simple program. Oh, wait, I just described BeOS's scripting environment!
A deep unwavering belief is a sure sign you're missing something...
Just my 2p... I have been using PC's since I was 7 (thats 14 years, by my reckoning), and by PC I mean personal computers, not IBM compats. I have worked asa technician for several years, and as a programmer. And in that time, I have found that installing Windows on two IDENTICAL machines (even down to the mobo and RAM etc are from the same production run on each machine!) Windows will display problems on one, and not the other! I follow the recommended installs for each driver, in the order MS told me too, and BANG! One falls down. However, I recently installed Debian on a notebook from some unknown Japanese origin. Installed XF86_SVGA and ALSA, and a working, not crashing, machine was mine in little under half an hour. So, % of Windows installs that a stable after new install: 10%, % of Linux installs stable after new install: 95%. And believe me, I have done a LOT of installs!
ALT-F2 gives you a line to type in a console
command from. It's pretty simple
Most of what the article is really talking about
already exists in KDE 2, but I hope it's only a
start.
--Matthew
Of any serious developer who doesn't code their GUI to be fully scriptable.
This one area where I think that MS has done a pretty good job - most of their apps come with an OLE automation model that allows programmatic access to the same functions exposed by the GUI.
Note that this is more than driving the GUI with some kind of fake console (a la OS/2 HLLAPI; or VM/SP POP) - issue with these is a glitch in the GUI normally shags your app......
**Vanuatu or bust**
GUI's are like mules. All GUI's have been born of text; but they, in and of themselves, cannot reproduce.
--Lawrence Lessig for Congress!
I wrote about this some time ago. (Actually, I devoted about four months of my life to writing about it, which never went anywhere. Thus, Dan Learns The First Rule Of Design: If Thou Can't Code, Nothing's Gonna Change :-)
Details available at http://www.doxpara.com/cluehunting.html.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
C'mon... Let's get away from escape codes, since you'ld need replacements for all the standard tools anyways, you might as well have the new tools output XML, which can the be sent to whatever graphical components the new xterm wants to create. Or read out. Or neither.
See the XMLTerm project or LinuXML for more ideas along these lines... Then volunteer your time to help make them work. Or else!
Later,
Blake.
I think one of the most useful implementations of CLI-GUI integration is how under Mac OS X (or NeXTStep) you can just run open somefile from a terminal and the correct application will open somefile in the GUI. Very simple, and probably easy to implement, but I don't think Linux has the infrastructure to support something like this yet.
I don't understand people griping about 'who linux is meant for' and going off about how it's meant to be used by hackers and admins, etc... Like, what up? If you need a gui-centric environment then you deserve to use an OS that costs money? Whatever! A shell is only a click away for me if I need it, and I kind of dig 'applets' like mini-commander (and I'm sure kde and other wm's have equivelent tools) that allow me to issue a quickie command if I need it. But what I love about linux is that at the end of the day the kernel can be used underneath whatever purpose it need be.
Reminds me of that dvorak piece in the unix haters handbook regarding absurd zealotry and unix.
Ouch, that is way better than my suggestion.
Way better. I like it.
--
SecretAsianMan (54.5% Slashdot pure)
Washington, DC: It's like Hollywood for ugly people.
if you drag a file from the gui into the tsch window, os x inserts the path at the cursor. very handy for long paths
if unix is a toolbox why arent gui tools part of the box? simple gui elements could be activated by switches, but more complex, general gui features should be separate tools that can be piped to other commands
of course wed need a standard gui...
the animal doesnt even have opposable thumbs, focker!
UNIX doesn't have one UI it has dozens of UIs. Some of them (Gnome, KDE) are quite good. Some are a bit more primitive. Each perfectly suits the needs of a small group of users. Most of them provide limited compatibility with the alternatives (meaning that typically applications will run but will not integrate well with other applications). The solution to this problem does cannot be found in creating another GUI but in getting GUI creators to agree on basic standards: how to cut and paste, how to embed components, how to define a menu structure, how to put an icon on the desktop, etc. As long as there's more than one way of doing things, there will be inconsistencies making UNIX user unfriendly
Jilles
He is right.
Why are you more productive working with UNIX?
Why do very few of us really want to use WINDOWS?
I do not want to see a Linux with a Windows GUI, I want an easy way to combine UNIX's CLI-power with the advantages of a GUI. Most of the time I feel restricted by the limited (and uncreative) way of working using only a GUI.
So let's look for ideas an do sth. about it. Why not have a 'expert-user' CLIGUI ?
Well, I'd really like the text and/or URL of said reg hack, but really, since Windows touts itself as a 'user friendly' environment, such things shouldn't be needed. Personally, I don't mind mucking around in the registry, but lots of folks do. Admitedly, LInux is no better here, but they flat out tell you that you need to do or deal with such things at least. M$ just whistles and looks the other way.
As for BSOD, I don't get THOSE too much, but I do get lockups of various degrees as my memory leaks away. Hopefully the situation will improve when I up my mem size [128 now, 384 soon]. As for Win2k, anyone know where I can get a copy [full install] for under $50? If not, M$ is ripping folks off yet again.
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
Lots of people say "bad idea, junk, we don't need no stinkin' gui!". But you're forgetting that with time there willl be more and more command-line-untrained people who want to use linux but don't want to spend the extra time learning stuff that has nothing to do with their work.
Imagine a designer switching from Windoze of Mac to Linux. A guy who wants a sound studio to edit music. Many people out there use computers for completely command-line unrelated work. And Unix has to cater for these people if it wants to become a standard.
Imagine, years from now, that we go into outer space in our little spaceships. The pilot can't be concerned with typing the right command. There's an emergency, aliens flying around, asteroids bumping against the hull, the captain screaming "Turn left 20 degrees! Now right! Up, up, up!!!", and the pilot is writing 'trun left' "no, sh**, that's not right!", 'turn lef', "damn, damn!!!!!"
--insert explosion--
Oh well, maybe a little drastic, but you get my drift. We are just at the begginning of the information age. There's no way we'll be writing and rewriting the OS forever. There will be a time when all we do is add layers and layers, most of it below the GUI that will eventually become the standard.
Might as well do the GUI right, now.
shana
There are lots of CLI users who want to be able to influence GUIs with their CLI and KDE 2 may allow them to do this, but it is still not much really a GUI revolution.
Specifically, there is little "transfer" from the tricks the users has learned unde the GUI to the tricks they will learn under the CLI, i.e. using the GUI dose not teach you to use the dcop CLI. The relevent quote from your own thread would be "Wow! I had no idea you could do this." If it is possible for a users who knows about CLIs to not understand that they could use the CLI then something is wrong.
We could have a much more tightly integrated CLI and GUI if the widget set automatically provided a CLI for every window and all menus had direct interpretations via the CLI, i.e. much like the old autocad interface where all menu commands caused CLI commands. This allows you to build commands with the menus and edit/reuse them from the history.
Actually, you could take this one step further by eliminating widget based menus in favor of an improved cut and paste. The idea here is that cut and paste is critically importent to the usability of any computer interface so it must be optimized for speed (this crtl-C ctrl-V shit dose not cut it). The way to make shure that your cut and paste is good enough is to force the simulation of menus via cut and paste commands to the window's CLI. I think that Plan 9 dose with their editor.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Tar should be a staticly linked program. Ever try to rebuild a system when its librarys are hosed?
I'm a long time AutoCAD user, since Rel. 9.
When I started using it, you had the command line, screen menu, & tablet menus. Over the years, they added pull-down menus & dialog boxes; then in the Unix version (may it rest in peace...) & Windows versions added toolbars & pop-up menus.
It's highly customizable, with custom menus, linetypes, hatch patterns, and even fonts (although it takes a lot more talent than I've got to construct a font using a numeric drawing language).
Eventually I learned how to program, first using scripts, DIESEL macros in menus, then AutoLisp, & DCL for dialog boxes. Now you can use C, C++, VBA, and Visual Lisp as well.
Each version kept backwards compatibility for the UI, customization, & programming (not file formats unfortunately).
When commands eventually got dialog boxes, you could still use the CLI version by prefixing the command with an _. The CLI version was used automatically if called from an AutoLisp routine. The foreign language versions of AutoCAD could still use all the English commands by prefixing them with a period(? IIRC).
I think a lot can be learned from AutoCAD about making efficient GUIs. It uses a good combination of GUI & CLI that just makes sense. I think XMLterm is pretty good in this respect, and Nautilus looks interesting (haven't tried it personally yet).
Regardless, we'll see a lot of progress in this area in the next year or two. Especially as people start using XML as a technology instead of a buzzword.
If you can come up with a system that allows *NIXes to load different libraries based on the state of the UI, you can have tar bring up a completion bar.
When this is done, It won't matter what UI, as long as there is a 'display' library set built to provide the 'proper' UI eye candy, the "appropriate" display will be made.
Whether this should be done or not is the developers problem. I wouldn't use it.
---
Unix/X is like DOS/Win9x, the windowing stuff is bolted ontop of the CLI environment. In the Mac, the windowing stuff is default, but there is no CLI. Anyone who remembers the Amiga wil know it used windows by default, but the initial interface was a CLI - IN A WINDOW. The standard startup initialised the Workbench graphical shell and closed the initial CLI but did not have to do this. I still miss this flexibility and having the CLI as an integrated part of the windowing environment. UNIX desktops come close though, but the windowing is still an afterthought. I'm not sure how Be handles this, maybe someone can provide that info. If there is a way for a program to figure out if it has access to a GUI, then it can present a suitable interface (although a CLI switch should be available to supress that). I guess that would provide a best-of-both-worlds interface, CLI users get words, GUI users get windows (unless they say otherwise). Just my 2p worth...
Remeber that this "No News" policy was partly based on the fact that the output device was a teletype machine (tty).
The mix between GUI and CLI was tried -sort of- by Apple long ago with the Commando system that came with AU/X (their very first Unix).
The goal was to keep the familiar MacOS GUI on top of Unix.
Every Unix command had a dialog box in which you could check the desired options. Some commands had several panels, due to the abundance of options.
One of the field in the box showed the actual command being built, so that you could learn the CLI syntax while using the GUI.
There was a File Selction box available (to specifiy find's starting point for example).
Even better, you were able to invoke Commando from the shell, and upon leaving Commando, the command just built in the GUI was pasted in the shell.
I personally found it a very good way to learn Unix commands syntax.
More recently, another attempt at bringing the power of CLI to the GUI has been made by SGI.
In their own version of Motif, the file selection boxes have the filename completion (with the space bar).
Allow me to spew my NeXT worship here and say that the "Services" menu, acting like a GUI version of a pipe, made for quite a powerful tool. Anyone who has used MOSX know if something like this is included? T'would be cool.
For a good example of a development tool that uses command line and GUI together, check out MS Visual Foxpro. All commands can run from the command window as single-line or multi-line blocks. I find myself rarely needing to even use the menu, and being able to scroll back to a previous command is lightning fast.
Yet the Command Window can be replaced with menus/dialogs if one wishes. I know some developers who never use the Command Window.
Finally, the Command Window is a great learning tool. You can fire up any object or data session and do all kinds of experimenting without having to build a project or executable to do it. Python (or any command-line interpreter) is basically the same thing.
Fox's Command Window is one reason I loathe developing in any other tool right now...
What Would Sutekh Do?
i just found this today on freshmeat. ROX-filer has a popup CLI, much like EFM. also there is a popup selection, and dir moving. also if you need a xterm it's a click away!
it's homepage is http://rox.sourceforge.net/
nmarshall
The law is that which it boldly asserted and plausibly maintained..
nmarshall
The law is that which it boldly asserted and plausibly maintained..
--Colonel Burr 1783
- What if I'm logged in remotely? Doesn't this assume I have a graphic terminal?
- Won't this cause random stuff popping up when, say, cron scripts run?
No, boneheads! Just provide a standard switch that means "don't do that GUI shit". That may be a problem for our current set of Unix tools, since it is probably impossible to find a switch that is unused in all Unix tools. But that doesn't preclude someone from implementing this idea in their new operating system, where the switch meanings aren't set largely by tradition.--
SecretAsianMan (54.5% Slashdot pure)
Washington, DC: It's like Hollywood for ugly people.
i thought thats why they have such things as konsole, xterm, gnometerm and many other things.. so you can use CLI commands from the GUI.. i dont know about you people but i run my gui which i love and i still open up a console and do alot of things from there because its faster/easier/more powerful then the gui frontends that do the same thing.. there is no need to reinvent the wheel here, you just have to use what you already have...
why should something like tar need to implement anything to do with a gui? that is the reason tools on other platforms are *so* bad ... the gui is the focus, and takes away from the principle of simplicity. the basic concept of having a gui that can give information about the status of a tool like tar isn't flawed, but thinking that tar should have anything to do with the implementation is. simplicity in the basic tools is one of the foundations of the unix philosophy.
... like a console window, or a wrapper that takes the stdout/err and displays progress. don't fsk with the good stuff ;P ... the componentisation of unix is what makes it so good. that and stability, power, and the many freedoms it can provide.
if a gui on tar is needed, then the best route to it is to provide an easy way for the functionality to exist for free
mx
It became a standard way of getting things thrown at you here in Cambridge, UK at the Linux group - a project such as, well,
the CLUG   3-D GUI   project...
(we never seriously got around to it, BTW...)
The idea is a "console" with two joysticks and two footpedals. The screen shows the file system hanging like a chandelier and voice recognition is used to speak unix command lines which act on the file or directory tree which the "crosshairs" are pointing at.
You would swoop around the virtual 3-D space as if in a spaceship and could "fly" down networks to be working inside distant servers.
To get work done such as writing a document, a virtual head-up display (ie a virtual-virtual!) would flip up say the emacs front end.
One imagines sweeping through your workspace "flying" the computer, no longer being at all aware of the interface as the whole thing becomes instinctive.
I think unix is a strong powerful platform which invites a much more powerful interface than the WIMPs which "grace" the systems which they match, such as the "Windows" family of systems and the pre-OSX Mac-OS's
The inspiration for the 3-D virtual interface concept and "flying" the computer obviously belongs to the novel "Neuromancer" and its author William Gibson. I am suggesting that the unix platform and the power of hardware now is enough to realise the vision. Add virtual reality goggles so that you can "look around" as you navigate and that takes the computer interface into a new generation.
I think this is a valid argument. For example, when I log into my school UNIX account to use Matlab from the console, I use the program as a console program. When I log in while in X, Matlab detects that and allows me to use all the nifty graphical stuff too. I know there are other programs that do this same thing too... emacs, etc.
Why couldn't "normal" programs do the same thing. It wouldn't hurt cron jobs and the like (as everybody keeps complaining about), because the cron isn't run on a terminal per se, and therefore the cron programs wouldn't have access to X.
I'm sure there could be an easy way to implement a "i-don't-want-this-program-to-use-x"... perhaps a simple alias would work. example) alias tar="tar --noX" or something like that. The only problem I see with this is that it would require a rewrite of a bunch of stuff, but I'm sure there are coders who enjoy stuff like this (I'm up for it if people will help).
It would make the GUI more informative. On "other" desktops, when I'm copying a bunch of files and it's going to take a while, I get a nice little progress bar... I like that. I know it's standard in UNIX that "no output is a good thing". But if a User is sitting behind a GUI, it's obvious that they're looking for output when things are going to take a while.
Just my $0.02.
what if this wasn't newsworthy?
wait, it isn't.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
Please don't tell me what are and are not "valid uses" for my computer / operating system. If I want to send and receive email, browse the web, chat on IRC, play games, or balance my checkbook that's my business and if you try telling me it's not then I'll make you bleed.
You may go back to your little "serious linux" nazi meeting now. Run along child.
Still works in 95/98.
Maybe not in ME, never tried it lately.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I like this idea. I once though having a clipboard where contents of it would always be in ~/.etc/clipboard/text/html where the filename would also tell content type. This way you could still have your copied text in clipboard while in between using it to transfer an image (as ~/.etc/clipboard/image/jpeg). In addition clipboard would be persistent between sessions.
However there is a one little but... If we want to be backwards compatible we need to have network transparency. If I start my netscape as a remote client (in my X-server that is - I still wonder who decided this naming convetion) and select copy from my netscape menu where should the copy go? Should it be ~/.etc/text/plain or remote_box:~/.etc/text/plain. Also should I type cat /somepath/windows/netscape/1/content/text/plain in my local system or remote system to get window's content as text?
Before this I would rather see user land mount. I mean something like mount ftp://ftp.kernel.org/ ~/kernel.org without root. If I can copy same contents with an ftp client why should this be even a security issue (of course mount "driver" should be user land program running as me)? Support for at least ftp, http and ssh2 "file systems" would be nice. Of course authentication would be a little tricky, but we have kerberos and all in the future.
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
I like this idea, especially where it would be just as useful from the command line. Eg "locate -u --tracking" would output:
locate:complete=10%
locate:complete=20%
etc
In this format it would be easy to track even a complex statement of piped commands. It would also be easy for a GUI application to parse this and display it visually.
Phillip.
Property for sale in Nice, France
How does one post on Advogato? It appears to be a Slashdot-like system, but I can't figure out how to participate...
I agree with almost everything you say. But as an example of a better approach than the GUI-over-CLI I would rather point to the Amiga OS. Like the Mac, the Amigas GUI ("Workbench") is a fundamental part of the OS. It is not simply an add-on. However, you can choose not to run Workbench, thus you have the total freedom of choice. CLI-only, GUI-only, or both at once. And it is this last choice that makes the Amiga so special. When you run Shells in Workbench, these shells have access to everything on the Amiga. It is a totally 100% different approach than the Windows DOS-prompt. The DOS-prompt lives a life of its own, and can't interact with the GUI at all. Not so on the Amiga! Not at all. You can also have lots of shells (seemingly unlimited) and have them all communicate with eachother. And with Arexx, you can use the Shell to send commands to your favorite MP3 player or any other GUI-app that supports Arexx (which is the majority of apps). With the AmigaOS the CLI and the GUI works TOGETHER. They are NOT different worlds. And also the Amiga OS actually allows the user to do stuff you can never do with a Mac. The Amiga user can do almost anything with his machine (hardware, not software was the limiting factor). At work I run Win2k, and I see no point in using Linux today (that will get me flamed!!). The Linux-world seriously needs to think about user-friendliness. The attitude that it is a power-user-only OS, will not get Linux anywhere. The Amiga was on the right track. The OS the Amiga had was the best OS I have ever used, and I still think AmigaOS 3.1 (3.5 is out now) is better than Win2k or Linux. That is, for *my* use. The AmigaOS is *NOT* a Server OS. It is weak on security-issues, and I don't think it is great on stability (but probably better than Win2k). And graphically AmigaOS was dull, but that is besides the point. It was USEFUL. Now we all know Commodore took the Amiga down the drain, and was far too incompetent to give the Amiga the place it deserved. Hardware-wise it was criminally limited, but OS-wise, it was excellent. And I really miss my Amiga(s).. :(
-Apollo
It would be nice, but in general case this is impossible. Think about something simple like "cat * | sort". How could cat know how many bytes there is still to read after reading 50% of filenames given as parameters? (It could be 99 files of 1 byte and last one of 1GB... and another process could be appending the last one!) Even less can sort say anything about how long it takes before it ends, because it has even less information about information to be sorted. Now think something like "cat /dev/urandom | grep a"...
It's however a great advantage to be able to work with files arbitrary large because pipelined programs only need commands like "read next 4000 chars" and "output these 100 chars". If OS can support 10TB files these little programs will do also. Of course sort doesn't work with arbitrary large files because it needs all data at once. Using pipeline also decreases memory requirements because commands are run in paraller and if program outputs more data than next one can handle it will sleep until next process is ready to process data again. No need to store all data by a single process.
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
Something like an entirely dynamic GUI has been done. Its a GUI contructed from macro code but widgets execute more macro code and thus can generate more widgets. And the syntax can do any combination of options and sequence of commands.
Check the eShell of the package for it. The GUI is there to serve as a frontend to a database but it could be a general purpose unix shell gui. Moreover it is in primitive "plain TeX" level yet, meaning that it is rather "raw" but great things can be built on it.
Check it out.
The author.
>The only time I've had to reboot Windows 2000 is because I installed some crap video drivers
There's one problem. An eterprise leve OS that explodes because of video driver problems.
That's why X is optionally separate from the kernel. When X explodes, worst it's supposed to do is freeze the console (unless you are running it all as root... which as we all know is bad).
Solution: Telnet/ssh into the box. Kill the X server. Fix the problem. Start up the X server again. Don't tell the clients, they won't even know it happened.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
It's funny to see people lying about Windows just as much as Microsoft does about linux. Honestly, you are no better than Microsoft's team of liars
So you do accept that MS people are lying! So when they talk about how wonderful their OSes are they are lying(I think I can imply that from your own sentence), that means their OSes are not as good as they tell us. And that is why you see so many people "lying" about Windows: because their daily experience is one of frustration.
You can't have it both ways: if two people talking about the same thing have completely opposite opinions one of them is either lying, misinformed or deluding herself (that is lying without intention). In your first sentence you say both MS an Linux people are liars which obviously is a contradiction.
I have many computers. I have run one with Windows 95 for about 3 years with no major problems (and no regular blue screens except when messing with shady software), I had a P133 with 32MB of memory, and that was enough to run what I did, which included photo editing, Internet Explorer 4, Netscape 4.5, etc. Really, it wasn't that bad. I recently got another computer that is running Windows ME, which I have had no significant problems as well. I have gotten more blue screens than I did on Windows 95, but even then I'd say I've had a total of 4 in the past month. That also is from dealing with shady software (god damn you zsnes!)
Well, I have 5 computers at home, 2 of them run W98, one is dual booting between W98 and Linux and one (the router/firewall/mailserver,etc) runs only Linux.
The three machines running Windows crash at least once every 2 days (they have all the recommended service packs and two of them have nothing but MS software). One of them just becomes stupid and stops doing networking,have not done anything but what MS says and no joy (reboot solves the problem temporarily).
My Linux machines crash on average once every month and this during experiments for settings for new hardware or while testing new drivers.
At work my desktop Windows NT machine has to be rebooted once a week because it becomes absolutely useless. At the same time we have UNIX boxes that have been running for one year and a half and we expect them to go down in one year time when moving building. I don't mention NT servers because I have not regular contact with them, but they for sure go down once a month for software upgrades (our email has to be stopped because we rely on a NT machine for that, grrrrr!).
If you are going to compare MS stuff at least use Windows server stuff against Linux/Unix stuff, then some useful argumentation can be made.
To even attempt to compare W95-98-Me in terms of stability against Linux just shows a profund lack of knowledge and exposure to OS technology: Linux is so good and flexible that an attempt can be made to make it a Desktop OS, Windows 95-98-Me are not enterprise OSes, serious and wealthy companies don't even bother to consider them as alternatives in their desktops(some even ban them altogether, while allowing Linux experimentation), neither do MS that clearly markets them as home OS.
Linux brings enterprise class resilience to your desktop for free. The lower MS OSes are not in the same league.
I have many other computers that have had nearly no problems as well. Maybe you are having so many problems because you fucked up your windows installation. Just because you don't know what you are doing with Windows doesn't mean that it is completely unreliable.
Nearly no problems is not good enough for many people: the frustration that comes with every time you are in the middle of something time consuming and complex and your machine dies is enormous.
And to suggest that Linux people, which in general have a far better understanding of computer technoloy than the average Windows user, will not figure out how to solve problems in Windows as well, is disingenious to say the least.
More often than not I have seen people knowing Linux/UNIX solve problems with Wintel machines (even if they don't work with them in a regular basis) than the other way around.
IANAL but write like a drunk one.
You need xterm, mozilla, an image viewer, a mp3 player (optional), and fvwm2.
Hell, throw in gimp and gnumeric for fun.
I swtiched back to win98 for a while to play games, and discovered that I did all my work in IE or a terminal. I realized that I didn't need GNOME, KDE, or any of this.
Let us all sing:
X is for xterm, that's good enough for me,
Oh, X is for xterm, that's good enough for me,
Oh, X is for xterm, that's good enough for me,
Oh, xterm, xterm, xterm starts with....c?
having any assumption about interface as a fundamentally part of the os is a BAD THING. most unixes do it right by issolating all user services from the core of things ... this is the beauty of it.
... and windows made the same mistake holding shell.dll so close to its own testicles. bad sepparation and assumptions about the user groups has brought about an operating system barely useful for everyday use ... and butt-ass-useless for server applications. mac OS-9 and less have similar problems ... a poor core, with a tightly integrated gui system ... no sepparation, no flexibility.
the problem with windows wasn't only that it was built on dos, more that dos had the cli integrated with its own core
mx
There's no reason you have to be doing all that stuff with the mouse. I'm sure there are plenty of window managers out there that give good keyboard shortcuts and don't get in your face (of course, some may be <COUGH>evil</COUGH>).
What I want to write some day is my (and probably many other people's, though I don't see anyone writing one) tool builder idea: executables represented as icons on the desktop, with 3 nodes (stdin, stdout, stderr), each of which you can drag a line from, to a similar node on a different executable.
Some sort of selection on the elements would allow you to set command options (incl all standard shell position expansion etc). Once the tool's complete, you group them together and it writes a little shell script that calls things in the right way, which itself then becomes a little icon with 3 nodes.
Whether it would work or not, I don't know. I'll write it some day. Unless someone beats me to it (likely).
The idea when designing GUIs is; if a feature is not found it does not exist. A GUI with lots of pop-up-menus and stuff will be slow and confuse the user. So what is the result? You cant: "Drag-and-drop" -F -R and this IS a problem. Even if I know exactly what I want to do with with a large folder with different permissions, the GUI does not allow it. There is no way to do powerful stuff to files in windows the way you can with rm, mv, cp, chmod etc in UNIX. (copy, xcopy, scopy is a joke) Sometimes this can be fixed by scripting but what happens to performance... And, have you ever been able to write a comment in a GUI program (for managing DHCP, users, WINS, network adapeters, whatever)? I write a lot of comments in my UNIX config files... ...of course a GUI can be easier to use for a beginner. I lack control when using linuxconf for configuring LILO.
People seem to forget that
Graphics arent necessarily the opposite of CLI.
There is also TUI (fullscreen texmode apps, that can use mouse, are event driven, can support quite a lot.
Turbo Vision apps / RHIDE / Free Pascal IDE etc are nice examples of that.
"Imagine if you type 'ln -s /etc/foo.cfg .foorc' and you see a red line appear in a GUI reflecting the symlink"
Actually, displaying symlinks with a line in the GUI is already available if you use IRIX/4DWM.
Nobody seems to have mentioned XMLTerm.
It's a Mozilla spinoff. Think of it as xterm with icons. The usual Unix commands (ls,...) are hacked to emit XML and Javascript, and the XMLTerm renders it accordign to your favoutirte stylesheet.
So ls can produce hyperlinked icons, and you can process the XML through filters,...
I find it very interesting though very hard to realize.
Have you tried it?
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Look, a lot of people complain that there is too much "bloat" in some software (like tar with the z option), especially with GNU tools. But what these people dont realize is that a lot of this stuff doesn't add to code bloat at all! For instance, the z option in tar is just like 2 lines of source code to make a call to the gzip library! Now, if tar were compiled statically, yeah, this would cause bloat. But that kind of stuff is almost always dynamically compiled, so it really doesnt add anything at all to tar!
So dont complain about bloat when there isn't any! The joy of shared libraries!
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
The system itself didn't crash. I could bring the system to sleep and back and it would realign the screen. But I didn't want to do that every few days.
As for X exploding, have you ever tried to mess around with the refresh rates in the XF86Config file? At least with Windows, it tells me if a refresh rate I'm attempting to use isn't safe, and if necessary, defaults to a 256 VGA screen (or even 16-colors in emergencies). X will let you run an evil refresh rate, and fry your monitor.
Trust me, it does happen in real life. I experimented with a 15 inch throwaway monitor on a 486 box. Do you have any idea what its like to hear your monitor *crackling*?
--------
Carmack is an elitist, pseudonerd bastard.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
ive been playing with this same idea all day! my idea was mroe this tho: that a system should do away with the text interface, but allow keyboard interface with the modern GUI. really tho, EVERYTHING needs redone.
Question
http://www.ironfroggy.com/
I think the guy who wrote the advogato article had a good point, but expressed it in such a way that Slashdotters would be quick to skewer him.
What he is TRYING to express is that the CLI needs an update, it needs a more rich set of user feedbacks. Instead of just 'write and wait', why not have indicators? Why not have a better, easier, cleaner syntax for doing complex things? Why not have feeback loops, designed to scale to your level of competence?
While bash has been around a long time, most people use linux in a GUI... not that this is BAD, i usually end up using the GUI to display a lot of terminals w/vi... but I think we are missing an opportunity to make a GOOD interface to the command line.
Signs point to the power of CLI+GUI: EFM was neat. XMLterm is cool. Cisco IOS/Kermit have a neat interface... we can combine these disparate interfaces to make a GOOD interface to empower people; not to talk down to them but rather to let them more easily use the powerful tools of UNIX.
Lets face it, we are a conservative bunch. We like the fact that 'ls' gives us a list of files, even though it takes a newbie a while to know this... and it knowledge to make 'cdl' do a cd to a dirtectory, then a listing of that directory.... something that should be simple, but is hidden from the user.
The guy is just saying that we should update our tools. Simple as that.
hiyah guys,
:-)) the typical mac / windows app is a gui app;
that is a not problem because most users (even sys admins) like gui
apps. therefore, while the gui evolved, the de-complexification (can
you say that?) didnt; in fact, windows apps are *too* tied with the
gui. everybody reinvents the wheel. when MS came up with their component model, they should have sort
of forced people to abstract the problem domain (PD) from the user
interface - it was a good oportunity. but either due to bad
programming habits or just due to bad programming, a lot of their code
is a set of components that cannot be separated from the UI.
thats very nice, until you want to do something complicated. those
components invalidate any code reuse efforts as if you're not happy
with the interface, you cant just use the PD objects; and since you
got no source, you're stuck.
:-D
i think when people start flaming unix for not having a decent interface they are right; in some ways we are light years behing mac's and window's and some other OS's. but i also think we have an advantage they havent got which is we are used to break down complexity. let me elaborate on this
now, we think exactly the other way around: the basic unit is the shell utility, and it must play well in a team. source is freely available and reuse is a must; unfortunately, UI is crap because the elders didnt think it was necessary. nevertheless - and although miguel was flaming unix for not having a component model - i think its probably fair to say unix has an informal component model. its informal, but its very strong; everybody respects it. and because of that, we have identified and built most of the components of an OS - and here i think we can all agree unix is cutting edge. its just that they dont look that nice, interfacing with them is hard. but work-wise they are excellent, they get the job done efficiently.
IMHO what we need to do now is to abstract the shell UI from the component. the CLI its a very thin layer of UI, but its still UI and it gets in the way. we need corba, or something like it. i know, i know, its slow. but think of the advantages! for example, we could have a corbalized cp, where the CLI interface is just a perl script that calls the c code. the c code only accepts requests via corba; and to make every one happy, an xml switch allows using xml for data interchange. so your [insert file browser name here] can make a call to the same code that cp uses and we all focus in improving that code and the corba server. maybe its slow, but multithreading it is not that hard... and surely you can have a call back that tells you the progress of the copy (corba geeks correct me if i'm wrong). to make cp look GUI under X would be a case of, when running the perl script, testing for X and taking appropriate action.
this doesnt solve policy problems; those, IMHO have to be dealt with by a standard for graphical toolkits - one that ensures you can make any toolkit look&feel like anyother. one that covers themes, keybinding, standard widgets, etc. and i think its probably better to leave this for another time
all&all, i'm not saying its an easy job; but its much easier for unix than it is for anyone else.
soup, the dragon.
soup, the dragon.
dna.h:include "std_disclaimer.h"
(Before I comment, I would like to point out that I know very very little.)
I have 2 computers at the moment. This one (1GHz Amd processor, 256MB RAM, running Windows ME) and a little crap thing my parents bought me to do assignments on in high school.
The small one has never crashed or had major problems to the best of my knowledge. Not surprising, as its an old Apple Mac LCIII, with less hard drive than I currently have RAM, so there isn't enough on it to make very much happen anyway.
This one, however, has caused plenty of problems. I won't go into too many details, because anecdotal evidence isn't necessary. I will point out that I am visiting Slashdot through Internet Explorer. At the moment I am only running Windows, as Red Hat wouldn't install properly (My fault though, I need to find the right video card drivers). Anyway, I'm just trying to say that I am not a Linux zealot, I've never used it.
I've had a total of 4 BSODs in the past hour, once over things that weren't even running at that stage. Windows isn't that reliable. It might be easy to use, but its a horrible bitch if you want to actually use your computer to its capacity. People aren't lying about the faults in Windows, they just find the ones in Linux easier to deal with, so they dont require bitching about.I do know what I'm doing with windows, Linux however is confusing the crap out of me at the moment, But I'm still trying to get it working because I would like to be able to use the machine I paid $3500(AUD) for as more thatn a glorified CD player.
by now I've forgotten my main point in replying to this, so I'll just click one of these buttons and accept my karma.
The Road goes ever on and on,
Down from the door where it began.
Why yes, all my base are belong to you.
How did you guess?
Yep, thanks.
I wish someone enhanced one of the linux shells and made it similar to 4dos.
-- The ballad of arrivederci
Oh well, but unlike you, I do see a point in using Linux (I agree with Squid that the Windows UI feels like the Amiga done wrong, there are some things that are downright un-intuitive about it all, text highlighting being the worst offender as far as I am concerned).
It's quite interesting that the OS used in the Amiga was derived from Amiga's second choice of OS (The first was killed by budget/time restrictions).
The Amiga also had another strength, in that you could throw the OS in the bin if you didn't want to use it, and hit the hardware directly (Not feasible with the diversity of PC architecture these days, but oh well...). But I do really miss the level of integration. My WB *always* had a shell at the bottom (Until DOpus changed my life, but that's another story). The integreation was such that an operation performed in the CLI was *instantly* available in the GUI, and vice versa.
Personally, I think OS development has proceeded so far down the Windows path that a quick volte-face is unlikely. It's one of the things that has seriously dampened my enthusiasm for computers these past 5 years.......
- "How do we do it? Volume!" - The Bursar of Unseen University.
I love the design of the classic Unix tools. The architecture is flexible and allows you to accomplish complex tasks easily ... find, grep, xargs, sed, etc. I mean just look at how dialup works in linux ... it's all a bunch of small programs strung together with scripts. Pretty incredible.
... I often found it necessary to look in /var/log/messages to figure out why the dialup script quit. Basically there's no mechanism for feedback.
My biggest problem with the architecture has been that it's distinctly "feed forward". What I mean by that is that you can pass data ahead to the next program (through a pipe). What I've allways found lacking is the feed back. Again to go back to the example of dialup
That is the biggest problem in integrating these tools into gui's. If we can create core algorithmic components that can be called either cli or hooked into gui's you could provide small reusable components that can be used either cli or gui while still adhering to the unix philosopy.
Hi. Every since that article that was put up a couple days ago about Jef Raskin's ideas put forth about user interfaces, I've been fascinated with the notion of creating a new kind of user interface. I picked up the book "The Humane Interface" by Raskin, and it reall "blew my mind" so to speak. I'm surprised that noone on advogato or slashdot has mentioned his amazing work. I think a lot of what he has to say can apply to these questions.
:)
:)
If everything he suggests is implemented, the system would not be any operating system that we know of. I've been thinking it would be cool to start a project that would probably be a competitor to gnome and kde, because it could be that they are going down the wrong track by copying the windows/mac style interface. In fact, I would say those interfaces are a disaster. (Read the book, you will see what I mean.)
The question then becomes, do I try to make it mix in with unix so that you can run it as a GUI for unix, or should it be its own environment altogether (with Raskin, there is no such thing as a file. In unix, "everything is a file.") If so, should I build it to run on top of unix or should I just start with some microkernel and ditch unix altogether. If I used unix, should I code it for x, berline, or a generic frame buffer? What language should I use (i'm leaning towards C++), and if I embed a language in the environment, what language should I use (perhaps python, or perhaps "any language" would be better (like scripts in unix can be)).
Then there are all the design decisions for the system itself. After all I'm "not a user interface expert" as Raskin would point out to me I'm sure.
I would love to talk to anyone who has read Raskin and knows what I'm talking about.
There's a summary of the book here, but it doesn't do the book justice IMHO. (The book has more time to explain what it means. (If you read it and think "huh?"))
http://www.jefraskin.com/summary_of_thi.html
I was looking at sourceforge and doing searches on the web. I can't find anyone doing any work on this concept...
cat somefile > /somepath/window/new
/somepath/window/1
Should open a window with the text of somefile in it...
rm
Could close the window with ID of 1.
This reminds me a lot of the program "hey" for BeOS. It's extremely useful for both scripting and interactive use. Sample commands:
$ hey Tracker get Title of Window [0]
(Tracker is the equivalent of the Finder on MacOS). Or maybe something like:
$ hey StyledEdit set Frame of Window 0 to "BRect(107,76,607,476)"
I admit I don't know that much about it, but check out http://www.beosbible.com/bos/ch_scripting6.html
--
I thought tar piped the file through gzip and unpacked the files, thus no shared library used at all, but I'm not really into the details so I can't say for 100% sure. Codebloat: No, you're on the spot there. Featurebloat: Maybe. An alias- or option system should be sufficient for those who don't want to pipe everything.
Btw, shared libraries has very little to do with the "UNIX-way" (IO and pipes). Small and compact binary utilities do.
What I think is flawed with the "UNIX-way" is the utter dependance of a non-standardized option-system. Fix that and a couple of outdated man-pages, and we may have a winner implementation.
- Steeltoe
http://www.debunkingskeptics.com/
That's exactly how Konqueror, the KDE file manager, works.
It's pretty slick - you can also change directory in the GUI portion, and the commandline window changes the directory. Nice.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
does the os/2 workplace shell and rexx fit into this discussion?
One way to implement such things would be to write a replacement for xterm and define a new terminal type. Just as xterm has escape codes to set the foreground and background colors, the new termi nal could have additional escape codes to create or update certain display widgets. I'd rather such widgets were part of the terminal window than poppped as separate windows, which sounds somewhat uncontrollable. You'd also need a good scheme to kill the widgets if the process that requested them dies . If done this way, the gui enhancement would still work well over a 300 baud modem.
If you're using a terminal that doesn't support these capabilities, the termcap database wouldn't return any codes for them, and everything would work as it used to.
I used to use AutoCAD heavily, and I liked its interface, which was something like a Unix shell with the ability to mix mouse clicks with words, and to see the results of commands after you typed them. Imagine if you type 'ln -s
Some people here obviously haven't been reading their "Dummies" books -- You can add a keyboard shortcut to any shortcut icon in the Start menu.
Just look at the properties for the Command Prompt shortcut and set one!
When I hear the word 'innovation', I reach for my pistol.
lol :) Thanks for pointing that out.
:)
Like I said, I've got the flu a I'm rather feverish
Thanks again,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Justing adding my voice to that of EulerX07. I work at a computer store where we spend most of the day repairing computers. The majority of the problems we come across are software based caused by Windows. I am not about to go counting the number of times I see the blue screeen of death in a single day - but I assure you it is extremely high.
I tell you it is a real pleasure to finally get home to see my Linux box sitting there already running, no errors or reboots for weeks at a time
I am not saying Linux is perfect - far from it. I have still had a couple of fatal crashes in my time that required the use of the power button, although they didn't require any further work to resolve the problem.
Saying your OS is the best because more people use it is like saying MacDonalds make the best food
I got seriously into the Mac back in 1984. One thing that always struck me as wrong was the way Windows was built on top of DOS.
I mention the following because it is quite a different philosophy that is probably foreign to most unix people.
Similarly to DOS/Windows, but without so many problems (or maybe with different problems), X is built on top of unix.
In Mac, the GUI is fundamentally part of the OS. There is no command line. Period. Well okay, there is. It's MPW. But it's an optional add on. But it runs on top of the OS and GUI. It is a powerful CLI environment with a rich set of utilities, compilers, disassemblers, make, sed, grep, command piping ala. unix, etc., ad nauseam. MPW's cli is executed in a window(s), but NOT in the same manner as Xterm, as you might expect. (Take too long to explain here.)
The important point is that the CLI is on top of the GUI, not underneath of it.
Please don't misinterpret me here. I'm not suggesting that one way or the other is wrong. Both have advantages. Linux is great as an embeddable OS. Just change the init scripts, or even the init program itself. You can use the OS for completely non-gui things. (Or non-cli for that matter.)
A property of Apple's approach is that the GUI is not an afterthought. User friendliness is thought of first and foremost in everything. (The mouse, it's drivers, etc. are fundamental parts of the system -- not add on's.) This may be why the Mac has the legendary ease of use. And why it took so long for Microsoft with their opposite approach to achieve a similar level of friendliness.
If you want to build gui-less tools (on Mac) that cannot be run by end users, then compile your program as an MPW tool. Most end users don't bother to get MPW. So your gui-less program automatically has a very limited audience. Just try writing a gui-less program for the mac. There just are no such concepts as "standard input", "standard output", etc.
It's interesting that Apple is completely turning the system on it's head in Mac OS X. This is probably a good thing for software portability. But a large part of the world is missing having studied the different approach of the classic Mac OS. (Not that it's necessarily right, it's just different. Observing the workings of other systems, languages, etc. enriches you.)
I'll see your senator, and I'll raise you two judges.
Maybe the separation between the cli and the gui is artificially imposed by the window manager and all those windows. Lately I've gotten annoyed by all the dragging, resizing, mousing, and shading that my mouse and hand are perpetrating, and I was thinking, cant we get rid of these windows? Did the invention of the mouse lead us down the wrong path? I'm sure I've never seen a mouse on any of the Star Trek shows.
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
I like this sort of hybrid CLI/GUI. I use a GUI to read my email and do the communication stuff and some of the work that I do I have multiple xterms open and Im hopping around different windows doing my thing. It is easier to type tar -zxvf bob.tar.gz than to double click on the file then a windows pops up with the stuff in listed since it uncompressed it to a temp file then select the directory where I want to put it by clicking through some crap. When the Nevada DMV switched from a terminal based interface to a nice easy to use GUI the lines suddenly became insanely long the DMV used to be a 1.5 - 2 hour trip now it is a full day event just because of the user interface. My current employer has a beautiful CLI program that has been around since the 80's its fast and powerful but it does require some training.
Travis
Look at linuxconf (not that I like linuxconf, but it does what you're talking about)
If you run linuxconf from a tty, it uses a curses style text interface. If you run it from an xterm, it uses a GUI. All it does is check if $DISPLAY is set.
0 1 - just my two bits
This is often mentioned as an advantage of GUI, but the odd thing is that this has nothing to do with the graphical nature of GUI, and could be easily done with CLI. The problem is that the data structures that control this are totally intertwinded into the GUI code on both Unix and Windows.
Windoze at least provides a command-line program called "start". We really ought to copy this, with a few Unix additions:
Just typing "start x" will act as though you double-clicked the file x in a typical GUI. Typing "start prog" where prog is executable would be the same as "prog&".
"start" would redirect it's I/O to gui programs that popup simple displays when the first text is printed or requested. Possibly an error terminal that is red. If the i/o of start is redirected already this is not done, allowing it to be used in pipes.
The GUI's should be rewritten to run "start" rather than their own code. This would go a long way to making KDE and Gnome cooperate on launching programs. "start" would of course be quite complex as it needs to understand the databases set up by kde and gnome, but perhaps a single better standard could be invented later.
Eventually I expect shells to automatically run "start" if the user types the name of a file on a line by itself.
Indeed it is.
I serve porn files from my linux box.
I relay porn mail from my linux box.
Hell, there's grandma porn there somewhere.
Are you saying I can't look at porn on my linux box?!
It makes me play with my tool. Does that make it a toy?
A use is "valid" because it's well-suited to the capabilities of the tool, but much of the charm of software in general and open-source software in particular is that these capabilities aren't fixed. They grow and develop over time.
I use software tools for writing letters to grandma and balancing my checkbook today. What's the point of saying that Linux shouldn't be one of those tools? Sure, it's not ideally suited for those purposes today, but I have to construe that as a defect and not a feature.
If UNIX is ever to ship with a GUI as good as the one in Windows, the challenge is not to construct a new GUI (why invent the wheel time after time), but to change every program in the system so that it can deal with a GUI. I'm not too experienced in programming, but I can imagine something like redefining stdin, stdout and stderr so that the program will communicate with the GUI, instead of with the user.
So, the question is, who's going to do that? I don't expect the big companies like IBM and HP to start that change. Simply because their systems aren't used by desktop users, but by UNIX professionals. And the majority of them prefer a character-based shell. Companies that provide UNIX systems for use on the desktop are the ones I expect to initiate the revolution. Guys like Redhat, SuSE, Caldera, VALinux. They're the ones that would benefit a lot from a system that can be deployed on the desktop. Nowadays companies use UNIX-based servers because of obvious advantages, but Windows-based desktops because UNIX is too difficult for most "ordinary" users. If this would change so that -for example- Linux would be as user-friendly as Windows, I can imagine that a lot of organisations would give VALinux (just to mention one) a call to provide them with a complete IT-infrastructure based on one single system. Cheap and efficient. Stable servers, cheap desktops, specialists for just one platform and great compatibility.
Woefdram, l'apprenti sorcier
Just as a remark: The viedo drivers *must* be in the kernel (they are in *nix too, that is why X can crasha a box).
The Win32 API set is probably what you refer to, as needing the GUI.
There is another set of API, NT's native's APIs (All start with Nt) that doesn't need it.
Most of the Win32 talks to NT's native API.
NT DDK (Driver Development Kit) can produce native applications, it's a bit more work than writing normal application, and you'd better be working in MS to do it (About only 10% of the native APIs are documented)
But it's pretty cool to toy with it.
--
Two witches watched two watches.
Which witch watched which watch?
There were some good points made in the article. But should we be bloating programs like tar with window manager cooperability? Hell no! I don't even think that tar should have the -z option, as it can just be piped to gzip anyways. I see no problem with an alias to do it, but tar should be considered a completed product, it does what *it is supposed to do*. This is a major accomplishment with a program. If you want it to do something else build a script that runs on the UI.
The power of UNIX is that it has all of these 'infrastructure' type programs upon which so much more can be built. There is no reason to build an extra program within a program. This just adds complexity which the UNIX design is against. If you look into the history of UNIX you will see that it has always favored stability over speed, and a small program that does what it is supposed to do rather than one large bloated 'featureful' program. Why should we get rid of the UNIX design philosophy when making a UI? It doesn't seem logical. As UNIX is an bottom up system so should be the UI (and it has been).
People who are selling UNIX by saying that our UI is just a good as XX's are morons. We are really forgetting our strengths. A person could build an excellent windowed compression/decompression program that can drag and drop to other programs, without having to know how to write a compression program, how to write a window environment, or how to figure out drag and drop. To them, it is all pipes. I'm not saying that XX's products don't have these characteristics, but to UNIX it is so much easier to do. Lets not ignore this power.
Taking the gecko engine (or whatever they call it now, 'nslayout or something') and making your browsers render with it rather than writing a new engine for yours, using X to render rather that using the framebuffer in different ways (it seems really stupid to me to make a window manager in UNIX that can't be networked), or making a script to run tar and gzip in a friendly graphic way is my opinion on how UNIX GUI's can be a sucess. Adding a completion bar to tar and using a --nodisplay flag is not.
Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
In the past six years that I've been using Linux I've had a total of maybe 20 crashes. I have intentionally run DOS attacks on my own machines to see how hard it is to get back control and intentionally misconfigured hardware to see how the machine would respond. Every one of those crashes was caused by faulty hardware or pre-beta kernel patches (such as agpgart over a year ago). My production servers were down only when they were being moved and had an average uptime of 150 days or so. (I was also running a web and mail server on a 486DX/33. Try that with Windows.) I had heard that W2K was stable, now you a MS zealot are bragging that you only had one crash per week. There is no way I would consider running a system so unstable for my personal systems.
I personnally have never claimed that Linux is as easy to learn as Windows. I do find it a great deal easier to use. I don't have to reboot to change IP addresses, I can easily change the MTU on a specific route, I can quickly and easily map the same ethernet card to three ip addresses. I can quickly do things on a nice, advanced, command line. I don't give a damn if it's easy to use. Plug and play slows down the boot process. When RedHat introduced it to Linux, I turned it off. I know my hardware and I compile my kernels to support it exactly. Cute menus to configure things can sacrifice the readability of the configuration files. If easy to learn sacrifices easy for an advanced user to use, I don't want it in Linux.
I've been designing a new windowing system for Linux. Any suggestions for how to integrate console support or features I should add would be appreciated.
Life is a psychology experiment gone awry.
writing tools with the assumption "ok everybody has a gui" is wrong. many machines are just servers mounted on a rack. they don't have guis, they probably don't even have x installed. and the only things that run on them are commands that can be invoked at the comand line. if all the tools assumedthe existence of a gui, we get what we all hate most: a certain os from the northeast :)
I have a car. Sometimes said car is a tool, getting me to and from work, appointments, etc. Sometimes said car is a toy, simply being used to drive about the country side on a nice day, or perhaps to get me to a beach. By your logic, my car should only be one or the other. Either it gets me to work, or it gets me to the beach, but somehow doing both is not kosher. This strikes me as obviously false.
Oh, BTW, its fine for Linux to relay mail, but not to compose them? Another obvious falicy.
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
Actually, this doesn't do what you want. If your directory has 'a.txt', it will do 'mv a a.txt.html', not 'mv a.txt a.html'. What you wanted was 'for i in *.txt; do mv "$i" "${i%%.txt}.html"; done' Sometimes a buggy one-liner is harmless, but sometimes it can really muck things up :(. The lesson: don't operate heavy scripts under the influence, or sick with the flu.
XMLTerm is a terminal program designed to replace xterm and its descendents. It is a command line interface, but the output is in XML pagelets instead of ASCII text in a VT100 emulator, with embedded images, web page style formatted text, clickable links, etc.
It requires Mozilla to work, as it uses the Mozilla engine for rendering.
Meldroc, Waster of Electrons
I think the writer of the article is missing a number of critical points about Unix.
People use Unix for servers in part because of the command-line. I could be administering a server under a DoS attack with the CPU under and incredible load, and I can still securely log in and administer the box.
Administering Windows with PCAnywhere or VNC, that would be almost impossible.
Even at home, I value being able to check my e-mail and perform other useful functions on a remote box while at the same time downloading gigs of cruft over a 256K DSL connection. I also enjoy being able to work on a remote box without ever having to worry about the speed of my connection. Copying a bunch of files with
cp *.out *.bak ~/foo
is a hell of alot faster and easier than opening up Windows Explorer via VNC and cutting and pasting.
What would be of benefit would be to build hooks into commonly-used command line tools that would lend themselves easily to an event-based model. Then whoever wanted to build a GUI for these tools would be more than welcome.
Personally, I think a term that would take
cat photo.png page.html
and render the image and/or HTML on the page would be a wonderful addition to the command-line toolset. However, the ability to work in text-only mode is a critical part of the appeal of Unix.
I see this same common misperception that gave rise to this article amongst alot of non-technical business-types that wander through a Unix shop. They see the command-line and think that it looks incredibly primitive and atavistic.
What they don't realize is that there are GUI tools that do the same thing as gzip, tar, top, ls, cp, rpm, and other command-line mainstays, but that noone who uses a Unix system professionally uses them. And there's a reason for that.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
The hell with the GUI, I want an OOUI. One problem that I've noticed with the graphical environment in Linux is that it crashes a lot and there isn't a way to restart it. A whole lot of good it does if you programs are still running but you can't see them. That's my only beef.
My favourite WM has been mosquito (similar to wm2) although CDE etc. are probably more pragmatic. I think *wm95 should be outlawed for people's own good ;-)
--
Never try to teach a pig to sing. It wastes your time and annoys the pig.
ToiletDuk
Protector of the Wastes
This is already possible and has been done with Gnome, I read it here on slashdot, but forgot what it was... The CLI can be used but GUI boxes can be used too, but w/o a window manager and desktop, the idea someone was talking about with a bash box on gmc would be sweet, I use X all the time, but i do admit they need to be merged because I always have a bash terminal open, but I use gmc for everything thats click and drag, so we need to start integrating the two. Just the command line is giving up the power of a GUI, but totally GUI like that OTHER OS compromises too much functionality...
my Karma ran over my Dogma
Acutally, when you look at the various uses of a PC, you see that it is used for both a PC and a car. The computer is used to controll the functions of all new vehicles on the road today. Though it is not a PC per say, it is still a computer. The nice part about a car, I don't have to worry if it's running some damn *nix or windows. It doesn't run either!!! hahaha. Just goes to show that you don't need either to have a computer that runs complex calculations. Thank god I don't have to worry about my car's computer crashing everyday, every other day, every month, every year, or ever! Computers are in every facit of our world these days. I'm glad they did not stop evolving with the vacuum tube. Command lines are great, but ever so tedious when trying to do a lot of things at the same time and have to type out some long a$$ command to get it accomplished. I work tech support for a company of about 1000 people (2 techs in my group) and I get maybe a call a day for all of those win9x/win2k boxes out there. On the server side where all the production is going on our *nix boxes crash quite often (many times due to hardware failure, crappy RISC boxes. not saying RISC is bad, just the hardware we have sucks). It takes 45 minutes to boot those damn *nix boxes with all the configuration we have ser up on them. Same with our AIX boxes. Same with our Windows servers. I haven't seen any viable advantage to running any of those OS's as an enterprise server. Typical server support call for *nix box: Get call that server is hosed. Log in to figure out what's wrong. System is locked up for some reason, no way to remote in to kill off bad job due to main system being hosed (not just the console). Reboot and wait. When system comes up, go through error logs and figure out what went wrong. Go fix said program or call apps support. Everything fine and dandy for a while. Typical Windows server call: Call due to system being hosed. Tell operations staff to hit reset switch and wait. Dial in and check error logs. Find out it's some lame program a developer wrote that has massive memory leakage. Call apps support and tell them to fix it. Everything fine and dandy for a while. Typical AIX call: Fucking hardware toasted again!! Call hardware support vendor to fix and fail over to other box for duration of down time. You see, most of the problems experienced in a fortune 500 company with their servers is application based, not the OS's fault (save AIX, that for some reason just plain sucks). For the 3 years I've worked for this company I've only seen 2 NT 4.0 boxes rebuilt due to corrupted exchange databases (can we say virus attacks?!? arg!) and about 2 *nix boxes for other reasons (if I remember right they just all in out failed, probably some app that did the dirty deed). We run a mix because we have differing needs throughout the company that work better on one OS or the other.
Death, Life...One is tolerable, the other is not.
I do not think that this article is talking about routers. It seems very clearly to be referring to desktop systems.
There are people out there who prefer command lines, but there are also people who prefer a GUI. Its fair enough to say that you can mistakes by clicking in the wrong place (although this does not really apply to a keyboard driven GUI, did you read the article properly?). But one thing that I find really frustrating is the precision of the command line. I am a shocking speller, and it often takes me 3 or 4 goes as a complex command before I get it right. With a GUI, I don't need to worry about syntax, I can let the system handle that, and interact with it on a higher level of abstraction.
This is most certainly a desktop-only concept, it is all about usability and making things easier. And there is definately a place for that. The GUI will never do everything a CLI will do, but then the same is true the other way around. Different tools for different jobs.
The status bar for tar was just an example. This article doesn't really explore all the possibilities very well. The concept here is that the GUI and CLI interact in a seamless way. Its not about loading more eye candy for the sake of it. It is really about bridging a gap, to improve the GUI so that you can acheive more with it. I say this is a good thing, and could well add more power to a desktop environment, making more of the UNIX tools readily available to the GUI user.
"Me and my girl named bimbo . . . limbo . . . spam" - Captain Beefheart.
Your luckier than I am then. Windows is good most of the time, but there is software that I can't run under ME (Such as Unreal) because of the brain-damaged Voodoo3 driver that I have, that are supposidly MS certified (and yes, it's the latest version.) I also get blue screens, though I'll admit, they're not as bad as they were in Windows 95, though they're worse than Windows 98 SE.
It would be nice if programs wanting to do GUI could represent drawing and writing and receiving menu choices and clicks, as ascii streams to and from a general purpose GUI client window. That way the GUI streams could be redirected to a second program, if you wanted to use the functionality without the GUI.
That wouldn't work well for everything, since it would limit what you could do with custom window painting and event handling, but for simple, mostly text- and icon-based GUIs, it might be sufficient.
This is all wrong -- The last thing I want is tools that don't work unless there is a GUI. Often you have headless servers, or your GUI just isn't working, or whatever, and you need the plain old console to get things done. Additionally, why pay for the Graphics hardware (and software) on a headless server? If we went this way, we would be one step closer to NT.
rr
Quidquid latine dictum sit, altum videtur.
is that it can be used for nearly every task. Other than a TV or a car you can use it for whatever you want. Its all in the box: gaming, surfing, communication, pron, and flying to the moon. At least thats what brought me into computing. I had that C-64 and i was playing games, one day i started programming the beast and was flattered of all the possibilities. The fact that *nix can be even more flexible is the fact why im using it. I dont use Windows because it IS limiting me in some way. So use your PC the way you want to, ill keep using mine like i always did, AND i like games too.. Argh, this ignorance makes me soo mad... Lispy
Think about it; anywhere in the GUI, you could pop-down the console and type a command.
In Windows, add a shortcut to command.com or bash.exe to the top level of the start menu. Name it `cmd and you can pull up a prompt by pushing Win and then `.
In POSIX environments running X11, assign a hotkey to pull up an rxvt running bash or ksh.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Both serve their purpose, but there is no real way to blend them. After years on Macs, and now years on Unix/Linux, I see no real way to blend the two. GUIs are a good representation, but there is no way to do something like history|grep sgmltools|grep html To find a command you used to format a document 10 days ago. Both Gnome and KDE are fantastic GUIs, but I always have (and will have) a shell open.
Republicans are Nazis. LetsRiot!
Maybe I'm too demanding, but I can't agree with that. Windows is the only game in town for some things, that is its ONLY advantage in my mind at this point. As soon as I can free myself from those needs, I will free myself from Windows. Why? Well, for one thing, Windows forces me to reboot far too often [on the order of once every 2 or 3 days if I do nothing else besides web browsing, much much more frequently if I'm coding at all, or playing demanding games]. Worse, it can't tell you when this is necessary, you simply have to try and see if it will blow up [my 'free resources' are almost always listed on the mid 80% range, despite obvious and significant performance and stability differences]. Those two facts alone make me want out soon. on a perfect OS, I would only need to reboot to recompile a kernal or install new hardware. Failing that, the OS should at the very least tell me plainly and accurately when it needs to be cleaned up [rebooted] so I can do so before problems arise. Until Windows can do one of those two items, it will never, in my opinion, work well.
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
One of the reasons for Windows instability is because the GUI is inseperable from the bulk of the "kernel". Adding a GUI to the kernel would make it A LOT more complex, incompatible with non-rebuilt versions, unlikely to be ported to other OSes, and just plain clunky.
willis/
there is no thing
what else could you want?
In the article the author wrote Ceci n'est pas une pipe.
I just find it funny that in french this could mean: This is not a blow job.
Sorry, I had to say it.