newco...@aa.csc.peachnet.edu (Dan Newcombe) writes: >Steve Jones <srjo...@infi.net> wrote: >>One of the Win95 beta reviews pointed out that when the "version" >>command is issued to the Win95 kernel (if you can call it that) it >>will return MSDOS ver 7.0. Food for thought.
>Let's see: >C:\WINDOWS>ver
>Windows 95. [Version 4.00.347]
If you write a DOS program that asks the current DOS revision number (int 0x21 fn whatever), under Windows 95 that program will report 7.0. But the fun doesn't stop there; if you write a 16-bit Windows program that asks for the current Windows revision number, under Windows 95 it will report 3.95. (Reporting 4.0 here broke some badly written programs.) If you write a 32-bit Windows program, it will report the above sorts of numbers.
I'm sure this is all frightfully important; surely the revision number that INT 21 reports back will directly affect benchmark performance, not to mention resource limits and the fundamental ability to multitask.
-- larry hastings, the galactic funkster, funks...@hyperion.com "Mmmm... Tony Danza!" --Lorne Michaels, SNL, ingesting an SNL Re-Run Pill <a href="http://www.hyperion.com/~funkster">My WWW homepage</a>
In article <1995Mar31.220640.8...@mars.ic.iaf.nl>, abig...@mars.ic.iaf.nl (Martian) writes: |> f...@cwi.nl (FJ!!) writes:
|> |> ==m...@wavelet.apl.washington.edu (Mike Kenney) writes: |> ==> graph -a 1.0e-3 0 -x 0 2 datafile | plot2tek |> |> ==How long did it take you to learn the itmes in this string, and that |> ==they could be connected in this way? How did you know what the switches |> ==were and what the attributes mean? |> |> man graph |> |> |> Abigail
You are, of course, assuming Mr. Newbie knows about the 'graph' command. (Mr. Newbie = a user that has no experience with Unix in any way shape or form and very little experience with computers or DOS. No relation expressed or implied. :-) )
If he's given the pipeline, no problem. But if he's given instructions to "plot the results into a window using the data in this file", then what?
There is also the issue of piping with the '|' operator (which I think DOS supports, in its clumsy way). 'man sh' takes care of that, but will Mr. Newbie know what that is?
At this point I would probably advocate that Mr. Newbie read a good introduction to Unix book. (Maybe 'apropos' will work; I have no experience with it on the Unix and Linux systems I work with.)
And some things in Windows are probably at least as painful. Especially if Mr. Newbie has a sound card and has to tinker with AUTOEXEC.BAT or CONFIG.SYS or SYSTEM.INI or WIN.INI.
Or tries to locate and run his favorite DOS executable using the Program Manager.
Or tries to set up a network protocol stack.
*barf*
-- -------------------------------------------------------------- eric_willi...@mentorg.com My views!
Did someone say computers were labor-saving devices? Sure coulda fooled me ... :-)
In article <3lq1h0$...@netnet2.netnet.net>, Ben A Lindstrom <mour...@netnet.net> wrote:
>Danial Rubin (ru...@infinet.com) wrote: >: >: >Hell yes. Just think... no more Jack playing with the config.sys file >: >: >and Jill screwing up the password list. No more word processor crash- >: >: >ing and destroying 4 hours work. >: > >: >: Are you actually claiming that Unix WPs never crash? Are you kidding? >: > >: > Yes. No I'm not kidding. WP 6.0 has NEVER crashed under my Linux box. >: >And this isn't even a Linux port but a SCO version!
>: One of many good things about UNIX is when an application bites the dust >: and produces a core file nobody else on the machine knows about it.
Any sane sysadmin with non-developers for users can make the default core file size 0 too.
>: It is pretty hard for an application not running as root to bring down >: the system unattentionaly. With Windows on the other hand crashing the >: entire machine is easy to do, what a nightmare for fileservers...
>: If you have a stable UNIX and a secure setup tons of users can work on a >: UNIX box without worrying about a crash. Trust me...
>Mind you that if the UNIX system does not have process limiting or memory >limiting per user. You can do something really simple like:
>main() { malloc(100); main() }
>And it wil bring the machine down to it's knees (I know SunOS, NeXT, and >Linux it does. =-)
Script started on Sat Apr 8 02:06:10 1995 chmod: /dev/ttyp0: Operation not permitted chopper% cat t.c main () {malloc (100); main(); } chopper% cc t.c chopper% ./a.out Segmentation fault chopper% uname -a Linux chopper 1.2.4 #6 Sat Apr 8 00:29:23 MDT 1995 i486 chopper% exit exit
Script done on Sat Apr 8 02:06:31 1995
This demonstrates two things : 1. Configured correctly, Linux does fine.
2. My clock is about two hours fast.
-- Four boxes : soap, ballot, jury, ammo. Use in that order.
>(argument supporting Word Processing on Unix/Linux)
>>Would I want Jack and Jill doing word processing on unix? Fucking >>oath I would.
>But you give a best case scenario. In the REAL WORLD, no _SANE_ >administrator would first decide to upgrade their 500 PC network to >486s with 16megs of RAM and a hefty HD to run UNIX, get a humungous >network server, hire three security experts, and four more >administrators (and get this by his boss!) The idea of using UNIX
16 megs? Well, for basic text editing, and basically all the text stuff I did it ran fine in 4 megs of RAM. It ran X slowly but okay enough. With 8 megs it runs *very* quickly 8-). *stuff on configuration* Well, these configs are for *all kinds of things*; for just letting people word process, mount drives, and print you could delete probably 75% of these files 8-). Plus, hey, they *are* all in /etc 8-)
>Sure it would be a great day when a Unix will be released that really >is as easy to manage in large groups and was as resource efficient. I >would switch over quick, but currently such a solution is not viable in >the school or workplace.
Well, I think it is but if you are used to Netware, use Netware 8-).
>BTW: Running UNIX as a secretary's PC would never work since UNIX >simply has the shittiest printing system in existence. And that is >good enough reason for me.
I agree... the printing system *sucks* 8-). I do think that is something sorely needed, just that little bit of glue to make printing easier; the standard format for printing seems to be Postscript, so something that transparently takes the PS, converts it for your non-Postscript printer (if it is non-postscript 8-) and dumps it. It would use a configuration file 8-). I think the programs to do this are standard (Ghostscript mostly) but a configuartion and a glue program to make it easier would be good 8-).
--- (Thanks to Doug Sewell (d...@cc.ysu.edu) (http://cc.ysu.edu/doug) for this .sig 8-) It's reported that Canter & Siegel search for and archive all articles that contain their names or "Green Card". This .sig is to help them. Henry Wertz (He...@chop.isca.uiowa.edu)(1-319-337-6746 Linux 1.2.0 & I'm Root)
:In article <3m1tsd$...@ionews.io.org> cbbr...@io.org (Christopher B.
:Browne) writes:
:> Something cannot "become intuitive." The quality of being intuitive :> is either present or absent. : :I do not agree. :You have to learn how to use a mouse, what is an icon, why those stupid :rects on the sreen are called 'windows', what comportment you have to :expect when you clic on thoses other rects called 'Buttons' and so on.
Browne is right, you are wrong. By defintion, "intuitive" means you don't have to "learn", it works as expected.
By this defintion, the nipple is the only "intuitive" user interface.
In article <1995Apr8.045452.2...@mars.ic.iaf.nl> abig...@mars.ic.iaf.nl
(Martian) writes: > do...@zeke.lanl.gov (Mark D. Doyle) writes: > ==In NeXT's Edit.app: > ==1) double click on { (highlights to matching } ) > ==2) hit delete key, or command-x
> ==> Now imagine the vim editor: the fastest I can think of is... > ==> 1) /{ > ==> 2) v}d > ==Doesn't seem faster to me. > It would for me. /{d% removes the text between 2 matching parenthesis. > Very fast to type. Much faster than aiming the mouse pointer, of which > I always have problems with.
Aiming the mouse for a lot of people can be much faster than if your cursor in vi isn't on the first parenthesis and there are several intervening ones.
> ==Collapse regions of code into cells that can expanded and hidden > ==at will? With Edit you can pipe a highlighted region through > ==any Unix pipe or define your own commands and macros, use > ==emacs key bindings, etc > I've seen vi-macros expanding and hide text (but I won't claim it was > very pretty). However, vi is *very* powerful in piping regions through > unix pipes/commands.
Yes, only the first example was meant to be something that is rare in CLI editors. I added the others to show that there are generally powerful features to be found in GUI editors. People seem to have the impression that there aren't powerful GUI editors that can access the full power of the underlying Unix as easily as you can in something like vi.
In article <797387696-0-1...@henry.henry.net>, Henry Wertz <He...@panda.uiowa.edu> wrote:
>In note <3m58hm$...@potogold.rmii.com>, dko...@rct.com (D. Kobey) writes: >>BTW: Running UNIX as a secretary's PC would never work since UNIX >>simply has the shittiest printing system in existence. And that is >>good enough reason for me. > I agree... the printing system *sucks* 8-). I do think that is something >sorely needed, just that little bit of glue to make printing easier; the >standard format for printing seems to be Postscript, so something that >transparently takes the PS, converts it for your non-Postscript printer (if it >is non-postscript 8-) and dumps it. It would use a configuration file 8-). I >think the programs to do this are standard (Ghostscript mostly) but a >configuartion and a glue program to make it easier would be good 8-). >>D. Kobey >>d...@gwhs.denver.k12.co.us >>dko...@rct.com
This is bullshit. Where I work, we use a Linux server for printing, both from within Linux and from all the WFWG machines. The lp daemon works flawlessly and transparently.
For text files such as C sources, I use psnup which gives them a nice format with multiple logical pages per physical page, frames around the text, page numbers, date stamps, etc.
Printing under UNIX is no harder than under anything else.
Mark D. Doyle (do...@zeke.lanl.gov) wrote: : In article <3m0vag$...@manuel.anu.edu.au> nath...@bin.anu.edu.au (Nathan
: Hand) writes:
: > You dont use vi very often do you?
: You haven't used a good GUI editor have you?
: In NeXT's Edit.app:
: 1) double click on { (highlights to matching } ) : 2) hit delete key, or command-x
: > Now imagine the vim editor: the fastest I can think of is... : > : > 1) /{ : > 2) v}d
I agree that this line of argument is a bit silly, but I must add to it anyway.
The fact that you have to move your hands from the keyboard to grab and position the mouse will ALWAYS make a GUI slower. I am willing to bet a well versed vi user will be done 20-80% faster with edits than a GUI user with equivalent commands...has to do with the speed of the interface. Ten fingers moving millimeters wins over one hand moving centimeters.
So, it all boils down to what you do, and how often you do it. If you edit a file once a day for 10 minutes, vi is not worth it; high learning curve. However, if you edit a file 6-8 hours a day, a well designed keyboard interface is going to be the way to go (wheter it be vi, emacs, brief, whatever).
Several GUI editors have been built that have good alternative keyboard interfaces (which have the same learning curve, when it comes down to the power commands, as vi), but I have yet to find one that offers any significant advantage (speed wise) to a power user. The disadvantage, however, is that a machine may already be limited in resources (running a compile/download/etc), and running vi (at 200k, text interface) is NOT going to further that problem, where a GUI (1MB+, graphics operations) will.
> >Actually, the point I was trying to make is that a CLI is no harder to > >learn than a GUI. Neither interface is "intuitive" to someone who has > >never used a computer before.
> Well, it depends--to somone who's totally illiterate, a GUI is certainly > more likely to be...I refuse to use the word ``intuitive'' in this > context, so lets just say, likely to be usable.
Mike is correct. Neither interface is intuitive. That would imply that someone who had never seen a computer in their life would be able to use the computer right there and then. No, people still have to learn to use a computer.
The difference between Mac and DOS or Unix is that Mac is much easier to learn (and I'm not sure how or why anyone could say otherwise).
Look at it this way: with the Mac you start off with basic pointing skills. You learn how the pointer works in combination with clicks and drags and double clicks. Since this interaction with the computer carries over to every other program, it is very easy to learn how to use a new program. The Edit menu is always in the same place and always does the same thing.
Files and folders are represented by clear icons. People remember and retain pictures much easier than word or abbreviations... even short ones like 'ls'. While it may not be immediately intuitive to use the pointer to select the image of a file and drop it in a folder, it is an easy action to remember.
If you forget a command, it is easy to remember that if you select an item and examine the menus, you see what you can do to that item
On CLI, OTOH, one must learn a single command for each and every action. There is no quick reference to see if the command you want is available (closest thing is man and apropos).
On the Mac, deleting a folder and deleting a file are pretty much the same action. Even if you forget that it is the same thing, you can make a pretty good guess. In Unix, for instance, you must know that rm and rm -r are different commands. On the Mac, you know that certain things work the same way between programs. This is not the case with Lotus 123 2.2 and WordPerfect 5.1, for instance. For Lotus and WordPerfect, you must learn a separate command set for each one.
Dont'cha just hate it when someone brings literacy and illiteracy into a discussion about computers? For *anything*--computers or no--one is pretty limited in what one can do if one is illiterate.
> The difference between Mac and DOS or Unix is that Mac is much > easier to learn (and I'm not sure how or why anyone could say > otherwise).
Because it ain't necessarily so...
Unix now has a number of graphical interfaces, Motif, and OpenLook amongst them, which make every-day interaction with the computer almost as intuitive as with the Mac. Unix also has another GUI, NEXTSTEP, which IMHO (as an ex- Mac-user) makes HCI easier and more intuitive than the Mac.
The power that Unix has over the Mac is that it has the CLI underneath for when the going gets tough, or for when you outgrow the GUI. This makes most Unix variants preferable to the Mac in the long term, and NEXTSTEP unbeatable.
==|> ==|> ==m...@wavelet.apl.washington.edu (Mike Kenney) writes: ==|> ==> graph -a 1.0e-3 0 -x 0 2 datafile | plot2tek ==|> ==|> ==How long did it take you to learn the itmes in this string, and that ==|> ==they could be connected in this way? How did you know what the switches ==|> ==were and what the attributes mean? ==|> ==|> man graph ==|> ==|> ==|> Abigail
==You are, of course, assuming Mr. Newbie knows about the =='graph' command. (Mr. Newbie = a user that has no experience ==with Unix in any way shape or form and very little experience ==with computers or DOS. No relation expressed or implied. :-) )
1) I don't *want* a system designed for newbies. Long time ago I was Miss Newbie, for maybe half a year. But the last 12 years I can call myself experienced, and I hope to be experienced for a long time to go. People just happen to be newbies for only a small amount of time. When I started learning how to bike, my father walked next to my bike, holding the bike whenever needed. But nowadays, it would be quite a slow down if he would still walk next to the bike. 2) The same problem happens on a GUI. Or do you seriously expect every Newbie knows what icon to click on to get something going? Whatever system, you need to know what command does what. And whether you get the details via 'man' or via selecting help does not matter much.
==If he's given the pipeline, no problem. But if he's given ==instructions to "plot the results into a window using ==the data in this file", then what?
==There is also the issue of piping with the '|' operator (which ==I think DOS supports, in its clumsy way). 'man sh' takes ==care of that, but will Mr. Newbie know what that is?
Of course does Mr. Newbie not know that. But he won't know that in a GUI either. (Sure, sure, now you come with that nifty application on a particular OS which just happens to combine the above given example, but that's just a coincidence.)
==At this point I would probably advocate that Mr. Newbie read ==a good introduction to Unix book. (Maybe 'apropos' will ==work; I have no experience with it on the Unix and Linux ==systems I work with.)
==And some things in Windows are probably at least as painful. ==Especially if Mr. Newbie has a sound card and has to tinker ==with AUTOEXEC.BAT or CONFIG.SYS or SYSTEM.INI or WIN.INI.
==Or tries to locate and run his favorite DOS executable using ==the Program Manager.
==Or tries to set up a network protocol stack.
I doubt that any newbie on a Unix system needs to know that. Heck, even I wouldn't know how to do that, but that's probably because I've never needed to do that.
Paul_Ly...@plsys.com (Paul Lynch) wrote: >In article <3m6sj0$...@cville-srv.wam.umd.edu> rsrod...@wam.umd.edu (R S >Rodgers) writes: >> In article <1995Apr8.094419.4...@seer.demon.co.uk>, >> Paul Lynch <Paul_Ly...@plsys.com> wrote: >> >Hardly. Folklore has it that IBM were looking for a CP/M equivalent to >> >run on their new micro, and ended up with DOS rather than CP/M86. i.e. >> >theye were already commited to a micro based system, and the discussion >> >was on using which version of CP/M.
>> >IF IBM hadn't adopted a limited clone of CP/M, then the possibility >would >> >have been open for CP/M86 to evolve into a reasonable multitasking OS.
>> What makes you think that CP/M would have evolved any differently than >> MSDOS did?
>Because it did. MP/M, etc. Of course, it might have been different if >IBM had gone with Kildall, but that is only a might have been.
MP/M was a response to CP/M's dwindling market. DRI decided that they'd try to revive a dead duck. They tried the same strategy later with DOS, incidentally, and it was a flop as well. I doubt they would have done anything of the sort had they not been in dire straights -- as the evolution (or lack thereof) of CP/M prior to it's annhiliation by MSDOS shows.
>> IMHO, you're talking through your hat. MSDOS didn't evolve because it >> didn't have to. CP/M didn't evolve _even when it *did* have to_, and >because >> of this, it's a fossil.
>It did evolve, more than DOS at any rate. IMHO, you are arguing a priori; >things happened the way they did, so they had to happen, right? I am >afraid that is arrogant (and dumb).
And you're taking the position that MSDOS is bad, and MS is bad, so another company (in your mind "good") in the same situation would have acted differently *despite* what the way CP/M was handled *before* MSDOS shows us. This is not only arrogant and dumb, it is shortsighted, emotionally-biased, and stupid.
>> >So yes, DOS and business oportunism retarded computing.
>> You're so right. Personal computers and DOS, two things that were >inexorbicably >> tied in the early to mid-eighties, retarded the world of computing.
>Not like me to misspell opportunism.
>What were great looking advances in the early eighties now look like heavy >shackles. I was there doing it, and it all seemed like a good idea at the >time.
Perhaps because it was.
>To consider what might have happened without DOS and the IBM PC would be a >good idea. Personal computers in general, and Apple in particular, would >have done as well as they did.
Which, all in all, was not particularly well compared to what the PC did. Apple's toys wouldn't have put PCs into the business world and hurtled IBM into decline. If MSDOS is crippled and weird, AppleDos and ProDOS were downright unlearnable by the typical user.
Wait, I know, let's find the head's position by walking it back to track 0!
>S100 & CP/M micros might have lasted
S100, which was worthless to any business user because although it was a common bus, you still had to get device drivers. Ask any post-1979 S100 owner about how good the S100 bus was. Wait, ask me, and I'll tell you how useful it was on a Z100.
Sure they would have lasted. And meandered. And stumbled until somebody finally released a machine that wiped all the other away. It would have happened, and it would likely, given the technology at the time and when it would have had to have happened (e.g., before the Amigas and the STs and the rest), been very much like the PC and MSDOS. It very well could have *been* MSDOS -- what if the Rainbow, the Zenith Z100 or any other non-IBM _business_ PC had taken off? Same story.
>longer and evolved as they would have had to do. The possibility exists >that there might not be an effective monopoly of desktop computing.
What makes you think so? Given the crap (fun, but still crap) that was being sold in those days, anything less-than-awful would have done exactly what the PC did -- wiped the slate clean. The bygone days of heterogenous computing that old-timers dream about with wistful fantasies of a world centered around hobbyists with a multitude of models and manufacturers has never happened in any industry anywhere at any time in hostory. It's a fantasy, a delusion, held by people who are unwilling to let go of their false notions that the world was better off with Apple IIs and Atari 400s, let alone H-8s and H-89s.
That's the problem with people who judge merit by how diverse and how creative something is, and not by what it actually does for people. These people are easy to identify: they blame everything on business oppurtunism (measured by how commercially successful -- which is, by the way, a measure of how valuable it was _to people_ -- the company was).
>So >yes, I'll say again, DOS and business opportunism retarded computing.
You can say it all you want. History provesd you wrong. Reality';s answer to such silly notions is:
The hell it did.
-- "Amiga is IBM-compatible, too. A simple piece of software teaches Amiga to emulate the IBM operating system, so you can run most IBM programs. You'll have instant access to the largest library of business software in the world..." [Ad for Commodore Amiga, Dec 1985]
In article <lV$XlO9Rt-u707...@wam.umd.edu> rsrod...@wam.umd.edu (Robert
Rodgers) writes: > MP/M was a response to CP/M's dwindling market. DRI decided that > they'd try to revive a dead duck. They tried the same strategy later > with DOS, incidentally, and it was a flop as well. I doubt they would > have done anything of the sort had they not been in dire straights -- > as the evolution (or lack thereof) of CP/M prior to it's annhiliation > by MSDOS shows.
MP/M86 certainly was. MP/M was around in some form in the '70s. DRI may have been in poor form as a business; but PC-DOS was not superior in any way to the (already on the way) CP/M 86.
> >It did evolve, more than DOS at any rate. IMHO, you are arguing a priori; > >things happened the way they did, so they had to happen, right? I am > >afraid that is arrogant (and dumb).
> And you're taking the position that MSDOS is bad, and MS is bad, so > another company (in your mind "good") in the same situation would have > acted differently *despite* what the way CP/M was handled *before* > MSDOS shows us. This is not only arrogant and dumb, it is > shortsighted, emotionally-biased, and stupid.
DOS isn't/wasn't good. MS isn't good. A monopoly isn't good. CP/M wasn't any worse than DOS; and the advantage of DRI being less capable than Microsoft was that they were unlikely to form a monopoly. You too have your biases; I know what mine are.
> >To consider what might have happened without DOS and the IBM PC would be a > >good idea. Personal computers in general, and Apple in particular, would > >have done as well as they did.
> Which, all in all, was not particularly well compared to what the PC > did. Apple's toys wouldn't have put PCs into the business world and > hurtled IBM into decline. If MSDOS is crippled and weird, AppleDos > and ProDOS were downright unlearnable by the typical user.
Most Apple II's in business ran CP/M. Lisa was already on the way. Personal computers would have hit the business world regardless of IBM's prestige, and the odds are that there would not have been a single supplier (IBM) in a monopoly position, stifling design evolution. Without IBM back then, it seems far more likely that a range of personal computers would have shared the market.
> >S100 & CP/M micros might have lasted
> S100, which was worthless to any business user because although it was > a common bus, you still had to get device drivers.
Sounds the same as the PC bus to me.
> >longer and evolved as they would have had to do. The possibility exists > >that there might not be an effective monopoly of desktop computing.
> What makes you think so?
Because the possibility does exist; that's the thing about possibility.
> >So > >yes, I'll say again, DOS and business opportunism retarded computing.
> You can say it all you want. History provesd you wrong. Reality';s > answer to such silly notions is:
> The hell it did.
Back to a priori again. I think you've proved that you still have a chip on your shoulder. Bye, I've got better things to do.
Paul -- Paul Lynch (NeXTmail) p...@plsys.com Tel: (01494)671501 9 Stable Lane, Seer Green, Fax: (01494)680228 Bucks, HP9 2YT, UK
>>>>> "Dave" == G David Kuhlman <dkuhl...@netcom.com>
Dave> What? Give up bash? I *want* a command line. I want to be Dave> able to write scripts in Perl. I want to use make and zip and a Dave> whole lot of other commands.
Sure. I've been using NEXTSTEP (or NeXTSTEP or NeXTstep or ...) for years, with bash as shell, with perl and make and all that jazz. That's the nice thing about a well-crafted GUI on top of UNIX: you can have both.
Dave> And, I do not want to have to drag and drop when I want to Dave> manipulate files, especially lots of files.
I'm actually surprised that I use the file manager, drag-n-drop, etc., as much as I do; I thought I'd prefer the shell window *always*. Turns out I use the file manager some on the time and the shell some of the time. I can do whatever I feel like at the moment. Small things such as the "open" command makes this work smoothly ("open foo" means: "do whatever would have happened if I'd dbl-clicked on foo in the file manager". It's nice in a shell window, and it's real neat for scripts.
Dave> The powerful command line, powerful commands, and powerful tools Dave> is the main reason I use Linux.
Sure. But would you refuse to have a real good file manager, really integrated graphical tools, in *addition* to that?
Heck, when I'm using Linux or Solaris or whatever, most of the time I'm using the display, all the X stuff, as little more than a glorified tty. Lots of xterm and emacs windows all over the place. Sure, it's nice, and it's great to have xterms on 12 boxes at a time, but it can't hurt to use X for a bit more than that.
Dave> I don't want to have to sacrifice power for prettiness.
I'd venture that this tradeoff is largely a myth created by bad design.
Dave> Let's leave MS Windows for users who want pretty and simple, and Dave> keep Linux for us other users.
I've seen Windoze, and it's neither pretty nor simple.
Dave> BTW, why is it that we can expect lots of users to master very Dave> complex video games, but not a complex set of commands and Dave> tools?
Because in a game, getting it *wrong* part of the spec. Games are designed specifically so that you'll only know how to get it right after a series of trials-and-errors. You wouldn't want a word processor that'll only let you print your document after you managed to find the Excalibur and used it to track down and kill the troll who stole "print" icon, now, would you?
/Lars -- Lars P. Fischer, fisc...@dina.kvl.dk, http://www.dina.kvl.dk/~fischer On the Internet, everybody will get their 15 megabytes of flame
Fabien Roy <Fabien_...@free.fdn.org> wrote: >nath...@bin.anu.edu.au (Nathan Hand) wrote: >>Now imagine the vim editor: the fastest I can think of is...
>> 1) /{ >> 2) v}d
>>[deleted]
>With NEXTSTEP Edit.app >1) double click the { with the mouse >2) hit the delete key
>Pretty fast isn't it :-)
I hate to rain on your parade, but you left out the step where you FIND the "{" character.... how do you "click" on something that you can't find?
Sorry, vim is faster!
/jjs
-- (Thanks to Doug Sewell (d...@cc.ysu.edu) (http://cc.ysu.edu/doug) for this .sig 8-) It's reported that Canter & Siegel search for and archive all articles that contain their names or "Green Card". This .sig is to help them.
In article <3m58hm$...@potogold.rmii.com>, D. Kobey <dko...@rct.com> wrote: >In article <3lg819$...@manuel.anu.edu.au>, nath...@bin.anu.edu.au >says...
>(argument supporting Word Processing on Unix/Linux)
>>Would I want Jack and Jill doing word processing on unix? Fucking >>oath I would.
>But you give a best case scenario. In the REAL WORLD, no _SANE_ >administrator would first decide to upgrade their 500 PC network to >486s with 16megs of RAM and a hefty HD to run UNIX, get a humungous >network server, hire three security experts, and four more >administrators (and get this by his boss!)
Apparently you don't know much about UNIX - for example, to run linux:
1. you don't need 486 - a 386sx will do just fine 2. you don't need a "hefty HD" - I've set up many intel boxes with full-on networking, mail and news, c/c++ and X in a 70 MB partition. In fact, you could run diskless, and run all the apps from a server... 3. you don't need 16MB RAM - 8 MB is just fine for normal use 4. no "humongous network server" needed - whatever machine you are using as your novell server will certainly run linux! 5. with the added convenience of being able to log into every single machine from your desk (can't do that from novell, guy) your system administration load should be less, not more -
>BTW: Running UNIX as a secretary's PC would never work since UNIX >simply has the shittiest printing system in existence. And that is >good enough reason for me.
hmmm - that's odd - our pc-nfs network is pretty cool - without the UNIX machines, there would be no printing or anything else happening! works for us, maybe you got some bad information somewhere...
/jjs
-- (Thanks to Doug Sewell (d...@cc.ysu.edu) (http://cc.ysu.edu/doug) for this .sig 8-) It's reported that Canter & Siegel search for and archive all articles that contain their names or "Green Card". This .sig is to help them.
In article <3m9k5b$...@galaxy.ucr.edu> j...@dostoevsky.ucr.edu (Joe Sloan) writes:
> In article <1995Apr6.180426.16...@free.fdn.org>, > Fabien Roy <Fabien_...@free.fdn.org> wrote: > >With NEXTSTEP Edit.app > >1) double click the { with the mouse > >2) hit the delete key
> I hate to rain on your parade, but you left out the step where you > FIND the "{" character.... how do you "click" on something that you > can't find?
Depends. You have to find it in your CLI editor as well. Usually your are looking at what you are editing and your cursor is in the area, but not at the right place. Using the mouse is faster if there is a series of intervening parantheses to navigate past. But you can always do command-f { or whatever pattern you need to match to. Just like you don't have to use arrow keys to move in vi, you don't have to scroll through the window with the mouse.
d...@sws5.CTD.ORNL.GOV (Dave Sill) writes: >> r...@belvedere.sbay.org (David E. Fox) writes:
>>> Performance is better than look-and-feel. The look-and-feel of /bin/sh >>> may be very dated, but it works, and works well.
>> I assume you still use ForTran, carefully written to not waste your >> precious and very expensive CPU cycles then!
> What really matters is what the tool (whether > it's hardware or software) can do. The interface is icing on the > cake: it can make the tool easier (or harder) to use, but it can't > give it new capabilities (without becoming a tool itself).
if we give the task to a robot, yes. but if you give one clerk TeX and vi, and another one MacWrite v1.0, I'll bet the one with MacWrite _will_ produce more desiable documents in any reasonable amount of time.
interface can so easily hide functionality, it's like giving it back when it works.
> I'd rephrase David's statement as: functionality is more important > than appearance.
if this is at the level of `a /bin/sh with colors but no wildcards is not as good', then "duh" -- of course. but you can trade away a lot of functionality which is hidden before it impacts most people.
and this _is_ about Unix, after all -- where the correct solution to the problem is almost never as important as one which is easy to do.
(did you read _Unix Haters_? I've got to write to Next in Line's book reviewer who said it should just be laughed off... there are benefits to realizing that correct software is more valuable than fast software, most of the time) -- Russell Schulz russ...@alpha3.ersys.edmonton.ab.ca ersys!rschulz Shad 86c
Martian <abig...@mars.ic.iaf.nl> wrote: >cbbr...@io.org (Christopher B. Browne) writes: >==I've used *really fast* mouse-based stuff for file browsing with >==good success. *Far* more responsive than anything keyboard-based >==would be likely to be. (And I am *not* one to knock using the >==keyboard.)
>Rubbish. If you don't know in advance where to look for, you would >have to *read* the text to know where to stop. And then it hardly >matters if you use a mouse, scrollbar or keys to wade throught the >text. Your reading speed will be the bottleneck.
Being able to scroll rapidly through huge files can be quite effective. People's editing styles differ, so it may not well work for *you*. But (for example), the brain can often pattern-match quite effectively without reading the majority of the text scrolling by.
In article <950409213756.214AACUE.malc@daneel> mmalcolm Crawford <m.crawf...@dcs.shef.ac.uk> writes: >> The difference between Mac and DOS or Unix is that Mac is much >> easier to learn (and I'm not sure how or why anyone could say >> otherwise).
>Because it ain't necessarily so...
>Unix now has a number of graphical interfaces, Motif, and OpenLook amongst >them, which make every-day interaction with the computer almost as intuitive >as with the Mac. Unix also has another GUI, NEXTSTEP, which IMHO (as an ex- >Mac-user) makes HCI easier and more intuitive than the Mac.
>The power that Unix has over the Mac is that it has the CLI underneath for >when the going gets tough, or for when you outgrow the GUI. This makes most >Unix variants preferable to the Mac in the long term, and NEXTSTEP >unbeatable.
>Have fun,
>mmalc.
This NEXTSTEP thing sounds perfect for someone I've been trying to introduce to Linux... is it Free/Shareware or commercial? -- <>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> | Rob Scott | "I've been thinking Hobbes." -- Calvin | | isc...@bud.peinet.pe.ca | "On a weekend?" -- Hobbes | | Prince Edward Island, | "Well, it wasn't on purpose..." -- Calvin | | Canada. | | <>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <>
>But you give a best case scenario. In the REAL WORLD, no _SANE_ >administrator would first decide to upgrade their 500 PC network to >486s with 16megs of RAM and a hefty HD to run UNIX, get a humungous >network server, hire three security experts, and four more >administrators (and get this by his boss!)
This rather begs the questions -- why would anyone other than an idiot upgrade their 500 PC network to 486s with 16MB RAM and a hefty HD to run M$ Word...? And then hire any number of "consultants" to get them all "networked" together and occasionally able to spool to one of the shared printers without crashng...? And all this with almost no form of system security...?
FYI -- our University-wide policy is now that, in order to run a "workable" Window$ set-up, we should now aim for a minimum spec of 486 with 16MB RAM...
>>> [ ... ] >>>And the use of the mouse speeds up things. Period.
>>This statement must qualify for the most inaccurate generalisation yet >>posted to this newsgroup (c.o.l.a.). Why do you think accelerator keys >>are called 'accelerators' or sometimes 'shortcuts'?
>"Accelerator keys" tend to 'shortcut' things, which *does* speed >things up.
Umm, yeah, my point exactly.
>>Okay, suppose I have a 50,000-line document. I want to find a particular >>sentence in that document. Do you honestly expect me to drag the mouse >>through the document and search for the sentence myself? I don't think so.
>If you aren't sure what the regexp ought to look like, then a *fast* >mouse dragging algorithm may be more effective.
Hmmm. Seems to me that if you don't know what you're looking for, then no matter how good an editor you've got, you're sunk :-) Seriously though, I see what you mean - the human brain is better at "fuzzy searching" than a computer is.
Even so, I'd say that 3 or 4 attempts at a regexp you're not quite sure of is still better than searching a 50,000 line document by hand :-) It doesn't make any difference how fast you can scroll through the document, you're still looking for the pattern manually, when you've got a computer in front of you which is very good at that sort of tedious task.
-- Des Herriott, Micro Focus, Newbury, UK / "Fashion is something so ugly it d...@mfltd.co.uk / has to be changed every 15 minutes" http://www.mfltd.co.uk/~dnh / -- Senser
