> While I don't > know any female Linux Pros...I do know a few Female Solaris Pros
Now that you mention it, root@cs.dal.ca, my school's sysadmin, is a woman. (and she does a great job:) OTOH, there seem to be very few women in the local linux users group. I'm not female, so I don't know, but it seems to me that most women are happier to use what works, instead of going out of their way to change things if they don't have to to get their work done. I'm exactly the opposite of that. I spend hours tweaking things, writing programs, and stuff like that. Linux has reached a point where it is good enough that it can get the job done out of the box, without a lot of effort tweaking it (especially if a kindly guru helps with install-time decisions and choosing software packages.) This may be why more women are using Linux than previously. So, ladies of linux, am I anywhere near the mark on this? I'm not saying that women are usually too dumb to change things to their liking, but they do _typically_ seem to be more willing to use what they have, unlike chronic malcontents such as myself who like to do things the best way possible (like taking the time to install putty on a lab computer to ssh into the server on the same campus), even if it takes longer than the simpler, but non-optimal solution of using telnet (which everyone else is doing).
Maybe the ssh thing is a bad example, because anyone concerned about security would do the same. Keep in mind that I don't care too much about that account, since I don't keep stuff I care about on there. I do keep that stuff on my home linux box. A whole bunch of other people use telnet, so I wouldn't be opening up the server to more attack than already done by the guy next to me using telnet to the same machine. #define X(x,y) x##y
Well, you can wait 10 times longer for them to download! Available network bandwidth is a very real limit on many things. Of course, you can save CPU time by decompressing once and saving the PCM audio data for future playback, like a cat page vs. a man page. #define X(x,y) x##y
10 000Gb is "only" 1.25 terabytes. You can buy RAID arrays with more than that on them. Maybe it should be enough, but for various reasons it isn't. Some of the reasons are actually logical, like experimental data or satellite images. (as opposed to wasteful users on a big file server) #define X(x,y) x##y
This technology is even higher density than current hard drives, which are _much_ denser than hard drives several years ago. Things like this keep making good old fashioned hacking harder. I mean, how is anyone supposed to get started on one of these with just an ordinary magnet! Sheesh...
I can't wait to have a CPU with mass storage inside the case. They didn't say whether this stuff is as fast as RAM, but I'd assume it isn't, since IIRC magnetizing something is usually a lot slower than flipping the charge on a capacitor. Read performance should be impressive, though, and in any case reads and writes should be orders of magnitude better than hard disk seek times. (HDs have decent sequential access performance, but are miserable for random access.) #define X(x,y) x##y
Do you want to run Linux and do a marginal job of everything, or split
up your tasks and get everything done right? It seems like a clear cut choice to me.
most people have only two arms, and one head. This means it is hard to use more than one computer at the same time. In any case, most people don't have 3 or 4 good computers to switch between to do their different tasks. Divide and conquer is exactly the way to go with user space software, no question about that. Unix command line tools prove that for the things they are good at doing (file/text manipulation, scripting, pretty much anything that can be batch-done:). For operating systems, it doesn't work. Are you going to turn your chair around and say "I'll use my Windows machine now because it has plug & play support for my video decoder card.", then say "ok, now I'll start downloading this video at streaming speed in real time with OpenBSD, because it has kick ass networking code", then realize that you want to be doing more things at once, so you turn around again to your Solaris box. Yeah, works for me like a hole in the head. multi booting on the same machine is even more annoying. I sure as hell don't want to have to wait for some other OS to boot every time I want to do something different. You basically need a single OS that does all the stuff you want to do, unless you are willing to be annoyed constantly. #define X(x,y) x##y
What is *BSD's net code better for, and how and why? 2.4 isn't out yet, so we don't know exactly what its networking code is like. (Of course, it will be pretty darn close to the code in pre-2.4 releases, so you could have looked at those; Did you? What did you find?)
I admit I haven't looked at either of them, but I'm not going to believe you unless you give me a reason. (threadedness, correctness, efficiency, code clarity/cleanliness, or something. Stuff isn't usually just plain "Better", especially when it is as complicated as networking code.) #define X(x,y) x##y
He meant to say ECP and EPP, not UDMA. UDMA is for IDE hard drives, not parallel ports. EPP (Enhanced Parallel Port) is an io port on the parallel port controller which writes into a FIFO, and the pport controller does the handshaking while sending from this buffer. ECP is the same, but with DMA. AFAIK, these were supported by earlier kernels. You can pass io= and dma= on the command line to the parport_pc module, and you can echo 7 >/proc/parport/0/irq to set lp0 using interrupt-driven operation with IRQ 7. I've sent the author an email to let him know about the error, so don't flood his mailbox! #define X(x,y) x##y
To quote JWZ: Linux is only free if your time is worthless -- Jamie Zawinski
I have found that the fun I have with computers was worth the time investment. I use computers a lot. For people who don't use computers regularly, or for more than one thing, the flexibility is not needed. Redhat goes some way toward catering to the people who just want a few things. I use Debian myself, because it gets your stuff configured for you if you answer the questions, but you can easily hack anything if you want. I recommend Debian to programmers and CS majors. For some people, all the commons OSes out there are too complicated. Windoze confuses _lots_ of people. It's only user friendly when you don't have to do something incredibly obscure to get it to work. From what I hear, BeOS is the OS for people who don't need to know how to program and learn about devices and all the arcane (to them) stuff that we revel in. #define X(x,y) x##y
True, Linux does have driver support issues. Some things aren't interesting to enough programmers to get the job done, and no company has bothered to tell one of their programmers to do it. Other times, the company won't release specs. In the latter case, it's not our _fault_, but it is still our problem.
As for the behaviour of idiots on/., I think that the programmers who write the device drivers are out writing them, and the non-programmers and dumb-asses make the cheap shots. I'm sure a lot of us are guilty of spending time on/. that would have been better spent writing some code. I know I am:( Damn you, CmdrTaco! #define X(x,y) x##y
You've got to be making that up, or micros~1 is even dumber than I thought. That kind of thing is _exactly_ the kind of thing the DoJ can kick their ass for, and I thought MS would be smart enough not to try to pull shit like that right now, when the DoJ is damn close to crushing them. Where did you hear that news, anyway? #define X(x,y) x##y
Ethernet _is_ the datalink layer. It isn't agnostic about itself! It _is_ agnostic about the everything above itself, which is of course the best way for things to be. Are you saying that Firewire isn't? It doesn't say "hey, that's IPX. We don't allow your kind here."
The point the original poster made is very important. It is great for higher level multimedia protocols to be able to ask the lower level protocols to guarantee performace. Any higher level protocol can do this, including IP.
For the price, ether is great for data. It is a good general purpose network, but it isn't so good for real time stuff. Don't forget that firewire comes built into some Macs now, as does 10/100 ethernet. Sounds cheap enough to me. My next computer will probably be a G4 tower to run Debian GNU/Linux on:) #define X(x,y) x##y
Choice is good, silly. The only time it's bad is if vendors make devices that only connect to one kind of network. Given the choice, I'd go with gig E:) (depending on price, though. It's good to let the consumer decide how much they want to pay for their stuff.) #define X(x,y) x##y
Are you planning to run ssh ab:cd:04:02:04 -l username to log in? You completely missed the point. Check out the post that's below the one you replied to. Firewire fits into the OSI model as a datalink layer protocol, which means that it doesn't get routed. You use a network layer protocol on top of it, like IP, to make routing happen. Conveniently, IP also gives us a way to associate names with numbers. That's called DNS. It's much handier than having to know the hardware addresses, which are unique globally, but _not_ heirarchical, so a router would have to know where every host on the whole network was to be able to route.
Probably an honest mistake on your part, and I hope you've figured it out now:) #define X(x,y) x##y
Re:...there's an easier way...
on
BeOS For Linux!
·
· Score: 1
I helped a friend set up a system with win, Be, and Linux. In/etc/lilo.conf, I put other=/dev/hda3 # the BeOS partition label=beos
BeOS can boot off its partition, like windoze. (and linux if you install a lilo boot sector at the start of the partition as well as on the mbr.) #define X(x,y) x##y
I'm always suspicious of people who say that linux users don't care about the free speech aspect, when that person doesn't use Linux themselves. (I'm assuming that be-fan is a Be user, and maybe an occasional linux user.) It's not surprising that the people who don't use linux are the ones who don't care about the free speech aspect of the license. I love having the kernel source. Even if I wasn't much of a programmer, I could recompile it to tune it for my hardware. I was recompiling the kernel before I'd looked at the source, so you don't have to be a programmer to do it or appreciate it. #define X(x,y) x##y
Linux is free enough for me. The difference between BSD's license and the GPL is only relevant if you want to write closed source software yourself. I don't, and it seems many/.ers don't either. Therefore, there isn't a good reason why Linux gets more press than the BSDs. Maybe it's that more people are using Linux, regardless of technical merit. I might try BSD sometime if Debian/FreeBSD ever materializes, but I don't have the time to jump into a whole new Unix. I concur that there are too many stories about very minor releases of Linux stuff, usually with nothing particularly interesting new in the release. (and definitely not mentioned in the article, even if some big important changes happened.) #define X(x,y) x##y
> Since this thread dropped off the list (I'm writing this on Thurs.) > not sure if you'll even see this response...;-)
I see ya:) I check for replies to my posts on/users.pl.
> I consider this a learning experience towards getting into finding my > way around a "commercial" UNIX.
I do that with Solaris on UltraSPARCs at school, and via ssh from home:)
Thanks, for the reply, BTW. Unless I missed it, you didn't say whether you were running the same window manager or not. I find GNOME makes things noticeably slow, even on reasonable hardware. ude/uwm or fvwm fly:) #define X(x,y) x##y
I thought it was funnier that it was non-anonymous, because then you _knew_ it was the same guy. Part of the reason it's funny is exactly the fact that he just posted them all himself. He was also partly serious, I think. He basically lampooned 3/4 of the posts on this story. (Which are even more repetitive than the threads on the Napster articles, except for the two guys who actually go to OSU, and can say something useful.) #define X(x,y) x##y
AFAIK, you have to be an IEEE member to read their standards docs. I don't like that too much, since it kind of goes in the face of open standards. At least membership is cheap, and there aren't requirements other than paying your money. (I think so. I'm not a member.) If you are a member, you already know where to go on standards.ieee.org. #define X(x,y) x##y
They might have had better luck if they'd asked before running the cable. I've been learning (the hard way:), that asking first usually makes admins happier. I guess if you're stuck with a dumb or lazy admin who won't help you, then you try to get away with it anyway:) #define X(x,y) x##y
Just because all those nice looking number keys on that number pad dedicated to them are there doesn't mean you have to use them in every word, you know. #define X(x,y) x##y
You are right, except for your point about text consoles. For the "power user", i.e. someone who uses a computer every day, text commands are useful because you can combine your knowledge of one command with your knowledge of another command to do really cool stuff. I wrote a big rant about this a couple weeks ago on a mailing list, and I'll post it here for your entertainment/edification: (I wrote it starting at about 2:00am, and finishing around 6, and I haven't spell checked it or read through it:)
\begin{rant}
Desktops are over-rated. You don't use a computer just for the sake of using a computer (unless you are trying to waste time, in which case you should read/. with your threshold at -1 and read _every_ comment, or you should read through the userfriendly.org cartoon archive right from the beginning. (hint, use wget to download the.gifs as you read:)). The reason you use a computer is to accomplish something. This is either something like preparing a document, writing some code, sending email, reading 'net news, browse the web, get mp3s, or various other things that amount to something which you either have to get done or you want to get done. I find this is best accomplished with a simple window manager. I saw somebody saw that "the reason for having a window manager is so you can have more xterms open." There are some programs that obviously benefit from a GUI, mostly programs that have anything to do with graphics or formatting. (i.e. xfig is great for doing diagrams. LaTeX's picture environment (where you use commands like \put and \line in a.tex file that you compile/run to create a.dvi, which can be converted to postscript or PDF, or viewed directly) is nice for things which need scale and precision, but you often have to draw the thing by hand on paper to figure out all the positions, lengths and angles if the diagram is anything at all complicated. xfig is great because it is a wysiwig vector drawing program, and can export as LaTeX commands for \include'ing in a LaTeX doc. (it also exports ps, eps, and various raster formats like jpg or pnm.))
Consider programs that do a non-interactive task, like list files in a directory. This is the classic type of command line Unix program. You run it, it does its thing, it exits. (The really classic ones which are part of the core Unix shell commands that all sytems have are almost always very terse. If part of its job description included printing info, then it does, otherwise is doesn't print anything except for errors. You check $? to see if it worked right, if you have any doubts or want to use it in a script. I'm not limiting the discussion to those commands, since that would be dumb. (they already work very well with no GUI.) I'm including programs like zip and unzip, which have a tendency to be chatty, but which are still very much one operation per invokation shell commands, and non-interactive (except for y/n overwrite confirm).)
For the class of programs described in the paragraph above, it is possible to implement a GUI version of the command by providing a window which shows information relevant to the task, and providing radio buttons and toggles which specify extra options. If there are a lot of options, there can be menus or tabs. For example, xrm, if it existed, would show you a list of files in the directory, and let you select one or more of them. It would have a toggle for recursive, a toggle for force, and an execute button which would delete the files/directories. It wouldn't exit after deleting one file, because that's not how GUIs are done. They let you do more operations with the options set the way you put them, usually.
For most programs with more than a couple options, a GUI is useful if it can present the options in a way that makes it easier and faster to get your task done than it would be to do the task from the command line.
There are several factors that go into deciding whether write the program as a GUI or as a command line tool. First, and extremely important in the whole philosophy of Unix, is that the programs like this are tools. programs that do a non-interactive task are the kind that can usefully be combined with other programs in a pipe, or as part of a script. What if the only command to delete files was to run xrm (which doesn't exist, so you'd be doubly screwed), and pick some options from its menus, then pick a file? If xrm didn't take command line options, or if it insisted on opening a window, then shell scripting would suck. (rm isn't really a good example, since a lot of scripts need it, even if they do something totally unrelated. Besides, the sysadmin would have to clean up/tmp every now and then, and would have to do it manually (since there is no way to script it with xrm!) unless she was a good hacker and thought of using mv -f file/dev/null to get rid of things.) GUI versions of things that are already handled well by command line programs have their uses, especially for people who don't need to use computers often, or for very long.
Note that GUI-versions-for-newbies of commonly used programs are a terrible idea, in my (NSH:) opinion. Newbies who expect to spend a significant amount of time using computers (i.e. want to become non-newbies, probably ASAP), do not benefit from a GUI wrapper for doing non-interactive simple tasks. It is much better for the aspiring newbie to learn to the command line syntax of relatively simple commands which do tasks which crop up all the time, like removing files with rm. Knowing how to use a GUI program to do something is one thing. You can't easily combine that knowledge with other programs. Knowing how to use a command-line tool is another thing, because once you know a few simple tools, you can use the shell to put them together with pipes, command substitution, xargs, etc. The capability gained from knowing how to use a GUI program which does a given task adds linearly with the capabilities gained from knowing other GUI programs which specific operations. The capability gained from knowing a command line tool to do a certain task _MULTIPLIES_ your previous total capability (well, probably not multiplies, probably some combinatorial function like the number of permutations of n commands blah blah,... (not to knock discrete structures or anything:) hehe.), because you can combine the newly learned command with any combination of other commands you know. (note that this capability product counts the capability to do many many useless tasks, like deleting all the files whose names is the rot13 codeing of a word which appears on a line in a text file which also contains the word "echelon". (i.e. rm -- $( grep -w echelon foo.txt | tr 'A-Za-z' 'N-ZA-Mn-za-m' ) ) Try doing that with a GUI character translator, a GUI pattern-searcher, and a GUI rm. You could, but you'd have to get the GUI programs to save their results to a file, then load it from the other GUI. Kinda slow, compared to the command line. (ok, I admit it took me about a minute to get the rot13 with tr right, but you'd have the same problem if your GUI character translator was as general purpose as tr, which it would almost have to be to be worth writing at all. (except for rot13 features in file viewers or editors, which could be used.) Keep in mind that once you figure out how to do it with tr, you can do it as many times as you want, grepping different files, with no extra effort, but to use the GUI tools again you'd have to do just as much work. (you could leave their windows open and the options set, but you'd still have to save to a file and move to the next tool, or cut and paste if there wasn't too much text. That introduces even more chance for human error.)) GUIs for things only a few very commonly used options, to do a simple task, are good only for people who won't be spending enough time with computers to justify the learning time. Learning command line tools is a long term investment which gains value the more you learn how to do more different things from the command line. (i.e. not just processing files into other files.) For example, you can do a lot with wget and one-line sed and/or awk scripts. (I don't know much perl yet (working on it, though:), and my computer isn't very fast, so awk and sed are great.)
Note that xrm is becomming the poster-child for dumb things to have a GUI's for.
Another factor in determining the whether a GUI is useful for knowledgeable users is how complex the options are. Programs with lots of different seldom-used options, like find, could benefit from a GUI. (of course, find gets regular use from the command line, usually with -name, -mtime, or -size, so the command line version is very important to have, especially for scripting. However, it _would_ be useful to have a GUI frontend to construct a command line for find. A powerful, not a flashy or user-obsequious, GUI is required. find is used often enough that remembering how to get what you want out of a relatively powerful GUI which lets you string together multiple conditions is not too hard. Very importantly, a GUI for an experienced user would be centered around searching for files named x. Everyone knows how to do that anyway, so it would be stupid to write the GUI assuming that's what most people would use it for. People would use the GUI mostly for complicated find commands most people would have to read the man page for every time they wanted to construct such a command. For use in scripting, a button to print the constructed find command on stdout could come in handy. (I'm going to have to write a GUI front end for find sometime... Cool. I should start a useful-GUIs-for-hackers project.:)
This leads my argument to the point that another factor in the usefulness of a GUI is how often the task is done, with respect to the complexity of the command line arguments. For things which are done regularly like deleting files, a GUI is a complete waste of time. For complicated things which get done all the time, like grep, a GUI is not needed. This is a case where newbies might be attracted to a graphical searcher, because they keep forgetting the command line arguments to grep. (which one makes it search for non-matching lines...? -n? (nope, that prints line numbers. -v is the one to inVert the search...) However, grep is such a powerful scripting tool and can be put to good use so often that it really must be learned by anyone who plans to use computers regularly. Another program, wget, has very many command line options, most of them difficult to remember. (the --long-options forms aren't much easier to remember, I find.) For simple use, the command line wget works fine. For more complicated tasks with patterns for accept-lists, etc., it is usually necessary to check the man page. It might well be possible to make a GUI version or front end for wget which made it easier to choose the right options to get the job done. The critical question is whether it is faster to use the GUI or to check the man page. I'm not sure whether there would be much benefit to having a GUI for wget. I think there might be, since wget isn't used very often, and there are a _lot_ of options which nobody remembers unless they've just spent the last couple minutes putting together a wget command that does what they want. Even then, you'd never remember all of them. You might remember that wget has a certain feature, but not know the relevant command line option. OTOH, a GUI is not a panacea for this problem. Some things are just complicated. However, it is often easier to figure out how to do something when the options to choose from are all sorted into categories. For example, a GUI can't make pattern matching much easier than grep, unless it limits itself to a less expressive pattern language than regular expressions. I can't picture how a GUI would be faster for stringing together sub-patterns, etc. This is especially true when you consider that you usually need to go back and tune your pattern to match exactly what you wanted it to, unless you are using a simple enough pattern that a regular expression for it would be easy to make up. Allowing for small changes to the composed pattern would probably leed to an overcomplicated GUI. Another example of a task that isn't done very often is uudecoding. The uudecode program doesn't need a GUI because it doesn't have many options. You just give it the filename. If find that you need to read the man page, it's probably because your about to do something that will end up using it a lot shortly after, so it's worth your time to gain the speed of the command line.
The value of a GUI for a task which could be done by a non-interactive command is in the amount of time it saves getting the job done. The time to use the command line version must take into account the time to read the man page and figure out what command line options to use, if necessary. Obviously, for commands that get used all the time with simple arguments, like rm filename [more filenames], a GUI is useless. For doing tasks which require a lot of choice of options, especially tasks which are done infrequently enough that the command line syntax isn't usually remembered from the last time you figured it out, a simple GUI which presents the options in a sensible manner can speed things up considerably.
GUIs are way over-rated, but they do have their uses.
\end{rant}
Note that the rant applies mostly to Unix environments, and others where a flexible, versatile command shell is available, and the tools runnable by the shell are powerfull enough that they _can_ be used to do almost everything, even things that aren't very convenient. This includes Windows with Cygwin32 bash + tools. Note that a shell environment itself benefits enormously from having a mouse to cut and paste text, ala xterm under X or gpm on a Linux text console. #define X(x,y) x##y
Both ways make sense. Some people are more visually oriented than others. A friend of mine (who is in CS, and uses Linux, so he isn't a dummy:), really likes having icons and buttons for things. I couldn't care less about icons. I'd much rather have a command line. That explains why he uses KDE, and I use the text console or a simple window manager (like uwm or fvwm2). (sorry, the UDE link seems to be down, but I can't find another page for it. It's in the Debian operating system's uwm package (which depends on the ude (unix desktop environment) package)).
I would be inclined to agree that we shouldn't over do it with extra buttons, and that language is good. (of course, I'm very much a text+command line+words oriented person. I use lynx because I don't care much about graphics, and I use love LaTeX because it lets me write good looking docs without using an annoying GUI.)
Here's an idea: There should be a row of function buttons which have any program can use for its own functions. This would be like the normal F[1-9][0-2]? keys, but they would have little LCD screens on the keyboard above the keys that could be have icons displayed in them by the program. There is no standard way to do this, so I think it would have to be in a USB keyboard or else be a horrible kludge of the keyboard protocol (it might not be, since I haven't looked into AT or PS/2 keyboard interfaces.) This would be the analog of the button bar at the top of a window, but you wouldn't have to reach for your mouse to use them. Of course, you could use loadkeys and showkey to bind them in console mode, and you could use xmodmap and xev to set them up under X. Apps could program the icons when they got the keyboard focus, I guess. This would be good because it keeps the people who want buttons happy, and it makes it very scaleable by allowing reuse of the same buttons for different apps. For novice users who don't understand how different programs have different windows and stuff, you could fix the keybindings the way they are in the AOL kbd:( #define X(x,y) x##y
Slashdot Mirror
> know any female Linux Pros...I do know a few Female Solaris Pros
Now that you mention it, root@cs.dal.ca, my school's sysadmin, is a woman. (and she does a great job :) OTOH, there seem to be very few women in the local linux users group. I'm not female, so I don't know, but it seems to me that most women are happier to use what works, instead of going out of their way to change things if they don't have to to get their work done. I'm exactly the opposite of that. I spend hours tweaking things, writing programs, and stuff like that. Linux has reached a point where it is good enough that it can get the job done out of the box, without a lot of effort tweaking it (especially if a kindly guru helps with install-time decisions and choosing software packages.) This may be why more women are using Linux than previously. So, ladies of linux, am I anywhere near the mark on this? I'm not saying that women are usually too dumb to change things to their liking, but they do _typically_ seem to be more willing to use what they have, unlike chronic malcontents such as myself who like to do things the best way possible (like taking the time to install putty on a lab computer to ssh into the server on the same campus), even if it takes longer than the simpler, but non-optimal solution of using telnet (which everyone else is doing).
Maybe the ssh thing is a bad example, because anyone concerned about security would do the same. Keep in mind that I don't care too much about that account, since I don't keep stuff I care about on there. I do keep that stuff on my home linux box. A whole bunch of other people use telnet, so I wouldn't be opening up the server to more attack than already done by the guy next to me using telnet to the same machine.
#define X(x,y) x##y
Well, you can wait 10 times longer for them to download! Available network bandwidth is a very real limit on many things. Of course, you can save CPU time by decompressing once and saving the PCM audio data for future playback, like a cat page vs. a man page.
#define X(x,y) x##y
Big deal, there's already a company that sells Exabyte tapes. Oh wait... maybe we should complain about the false advertizing. :(
#define X(x,y) x##y
10 000Gb is "only" 1.25 terabytes. You can buy RAID arrays with more than that on them. Maybe it should be enough, but for various reasons it isn't. Some of the reasons are actually logical, like experimental data or satellite images. (as opposed to wasteful users on a big file server)
#define X(x,y) x##y
I can't wait to have a CPU with mass storage inside the case. They didn't say whether this stuff is as fast as RAM, but I'd assume it isn't, since IIRC magnetizing something is usually a lot slower than flipping the charge on a capacitor. Read performance should be impressive, though, and in any case reads and writes should be orders of magnitude better than hard disk seek times. (HDs have decent sequential access performance, but are miserable for random access.)
#define X(x,y) x##y
> http://127.0.0.1:98
apt-get --purge remove linuxconf
:)
#define X(x,y) x##y
most people have only two arms, and one head. This means it is hard to use more than one computer at the same time. In any case, most people don't have 3 or 4 good computers to switch between to do their different tasks. Divide and conquer is exactly the way to go with user space software, no question about that. Unix command line tools prove that for the things they are good at doing (file/text manipulation, scripting, pretty much anything that can be batch-done :). For operating systems, it doesn't work. Are you going to turn your chair around and say "I'll use my Windows machine now because it has plug & play support for my video decoder card.", then say "ok, now I'll start downloading this video at streaming speed in real time with OpenBSD, because it has kick ass networking code", then realize that you want to be doing more things at once, so you turn around again to your Solaris box. Yeah, works for me like a hole in the head. multi booting on the same machine is even more annoying.
I sure as hell don't want to have to wait for some other OS to boot every time I want to do something different. You basically need a single OS that does all the stuff you want to do, unless you are willing to be annoyed constantly.
#define X(x,y) x##y
> rewritten networking - BSD's still better
What is *BSD's net code better for, and how and why? 2.4 isn't out yet, so we don't know exactly what its networking code is like. (Of course, it will be pretty darn close to the code in pre-2.4 releases, so you could have looked at those; Did you? What did you find?)
I admit I haven't looked at either of them, but I'm not going to believe you unless you give me a reason. (threadedness, correctness, efficiency, code clarity/cleanliness, or something. Stuff isn't usually just plain "Better", especially when it is as complicated as networking code.)
#define X(x,y) x##y
He meant to say ECP and EPP, not UDMA. UDMA is for IDE hard drives, not parallel ports. EPP (Enhanced Parallel Port) is an io port on the parallel port controller which writes into a FIFO, and the pport controller does the handshaking while sending from this buffer. ECP is the same, but with DMA. AFAIK, these were supported by earlier kernels. You can pass io= and dma= on the command line to the parport_pc module, and you can echo 7 > /proc/parport/0/irq to set lp0 using interrupt-driven operation with IRQ 7. I've sent the author an email to let him know about the error, so don't flood his mailbox!
#define X(x,y) x##y
To quote JWZ:
Linux is only free if your time is worthless -- Jamie Zawinski
I have found that the fun I have with computers was worth the time investment. I use computers a lot. For people who don't use computers regularly, or for more than one thing, the flexibility is not needed. Redhat goes some way toward catering to the people who just want a few things. I use Debian myself, because it gets your stuff configured for you if you answer the questions, but you can easily hack anything if you want. I recommend Debian to programmers and CS majors. For some people, all the commons OSes out there are too complicated. Windoze confuses _lots_ of people. It's only user friendly when you don't have to do something incredibly obscure to get it to work. From what I hear, BeOS is the OS for people who don't need to know how to program and learn about devices and all the arcane (to them) stuff that we revel in.
#define X(x,y) x##y
True, Linux does have driver support issues. Some things aren't interesting to enough programmers to get the job done, and no company has bothered to tell one of their programmers to do it. Other times, the company won't release specs. In the latter case, it's not our _fault_, but it is still our problem.
/., I think that the programmers who write the device drivers are out writing them, and the non-programmers and dumb-asses make the cheap shots. I'm sure a lot of us are guilty of spending time on /. that would have been better spent writing some code. I know I am :( Damn you, CmdrTaco!
As for the behaviour of idiots on
#define X(x,y) x##y
You've got to be making that up, or micros~1 is even dumber than I thought. That kind of thing is _exactly_ the kind of thing the DoJ can kick their ass for, and I thought MS would be smart enough not to try to pull shit like that right now, when the DoJ is damn close to crushing them. Where did you hear that news, anyway?
#define X(x,y) x##y
Ethernet _is_ the datalink layer. It isn't agnostic about itself! It _is_ agnostic about the everything above itself, which is of course the best way for things to be. Are you saying that Firewire isn't? It doesn't say "hey, that's IPX. We don't allow your kind here."
:)
The point the original poster made is very important. It is great for higher level multimedia protocols to be able to ask the lower level protocols to guarantee performace. Any higher level protocol can do this, including IP.
For the price, ether is great for data. It is a good general purpose network, but it isn't so good for real time stuff. Don't forget that firewire comes built into some Macs now, as does 10/100 ethernet. Sounds cheap enough to me. My next computer will probably be a G4 tower to run Debian GNU/Linux on
#define X(x,y) x##y
Choice is good, silly. The only time it's bad is if vendors make devices that only connect to one kind of network. Given the choice, I'd go with gig E :) (depending on price, though. It's good to let the consumer decide how much they want to pay for their stuff.)
#define X(x,y) x##y
Are you planning to run ssh ab:cd:04:02:04 -l username to log in? You completely missed the point. Check out the post that's below the one you replied to. Firewire fits into the OSI model as a datalink layer protocol, which means that it doesn't get routed. You use a network layer protocol on top of it, like IP, to make routing happen. Conveniently, IP also gives us a way to associate names with numbers. That's called DNS. It's much handier than having to know the hardware addresses, which are unique globally, but _not_ heirarchical, so a router would have to know where every host on the whole network was to be able to route.
:)
Probably an honest mistake on your part, and I hope you've figured it out now
#define X(x,y) x##y
I helped a friend set up a system with win, Be, and Linux. In /etc/lilo.conf, I put
other=/dev/hda3 # the BeOS partition
label=beos
BeOS can boot off its partition, like windoze. (and linux if you install a lilo boot sector at the start of the partition as well as on the mbr.)
#define X(x,y) x##y
I'm always suspicious of people who say that linux users don't care about the free speech aspect, when that person doesn't use Linux themselves. (I'm assuming that be-fan is a Be user, and maybe an occasional linux user.) It's not surprising that the people who don't use linux are the ones who don't care about the free speech aspect of the license. I love having the kernel source. Even if I wasn't much of a programmer, I could recompile it to tune it for my hardware. I was recompiling the kernel before I'd looked at the source, so you don't have to be a programmer to do it or appreciate it.
#define X(x,y) x##y
Linux is free enough for me. The difference between BSD's license and the GPL is only relevant if you want to write closed source software yourself. I don't, and it seems many /.ers don't either. Therefore, there isn't a good reason why Linux gets more press than the BSDs. Maybe it's that more people are using Linux, regardless of technical merit. I might try BSD sometime if Debian/FreeBSD ever materializes, but I don't have the time to jump into a whole new Unix. I concur that there are too many stories about very minor releases of Linux stuff, usually with nothing particularly interesting new in the release. (and definitely not mentioned in the article, even if some big important changes happened.)
#define X(x,y) x##y
> Since this thread dropped off the list (I'm writing this on Thurs.) ;-)
:) I check for replies to my posts on /users.pl.
:)
:)
> not sure if you'll even see this response...
I see ya
> I consider this a learning experience towards getting into finding my
> way around a "commercial" UNIX.
I do that with Solaris on UltraSPARCs at school, and via ssh from home
Thanks, for the reply, BTW. Unless I missed it, you didn't say whether you were running the same window manager or not. I find GNOME makes things noticeably slow, even on reasonable hardware. ude/uwm or fvwm fly
#define X(x,y) x##y
I thought it was funnier that it was non-anonymous, because then you _knew_ it was the same guy. Part of the reason it's funny is exactly the fact that he just posted them all himself. He was also partly serious, I think. He basically lampooned 3/4 of the posts on this story. (Which are even more repetitive than the threads on the Napster articles, except for the two guys who actually go to OSU, and can say something useful.)
#define X(x,y) x##y
AFAIK, you have to be an IEEE member to read their standards docs. I don't like that too much, since it kind of goes in the face of open standards. At least membership is cheap, and there aren't requirements other than paying your money. (I think so. I'm not a member.) If you are a member, you already know where to go on standards.ieee.org.
#define X(x,y) x##y
They might have had better luck if they'd asked before running the cable. I've been learning (the hard way :), that asking first usually makes admins happier. I guess if you're stuck with a dumb or lazy admin who won't help you, then you try to get away with it anyway :)
#define X(x,y) x##y
Just because all those nice looking number keys on that number pad dedicated to them are there doesn't mean you have to use them in every word, you know.
#define X(x,y) x##y
\begin{rant}
Desktops are over-rated. You don't use a computer just for the sake of using a computer (unless you are trying to waste time, in which case you should read /. with your threshold at -1 and read _every_ comment, or you should read through the userfriendly.org cartoon archive right from the beginning. (hint, use wget to download the .gifs as you read :)). The reason you use a computer is to accomplish something. This is either something like preparing a document, writing some code, sending email, reading 'net news, browse the web, get mp3s, or various other things that amount to something which you either have to get done or you want to get done. I find this is best accomplished with a simple window manager. I saw somebody saw that "the reason for having a window manager is so you can have more xterms open." There are some programs that obviously benefit from a GUI, mostly programs that have anything to do with graphics or formatting. (i.e. xfig is great for doing diagrams. LaTeX's picture environment (where you use commands like \put and \line in a .tex file that you compile/run to create a .dvi, which can be converted to postscript or PDF, or viewed directly) is nice for things which need scale and precision, but you often have to draw the thing by hand on paper to figure out all the positions, lengths and angles if the diagram is anything at all complicated. xfig is great because it is a wysiwig vector drawing program, and can export as LaTeX commands for \include'ing in a LaTeX doc. (it also exports ps, eps, and various raster formats like jpg or pnm.))
Consider programs that do a non-interactive task, like list files in a directory. This is the classic type of command line Unix program. You run it, it does its thing, it exits. (The really classic ones which are part of the core Unix shell commands that all sytems have are almost always very terse. If part of its job description included printing info, then it does, otherwise is doesn't print anything except for errors. You check $? to see if it worked right, if you have any doubts or want to use it in a script. I'm not limiting the discussion to those commands, since that would be dumb. (they already work very well with no GUI.) I'm including programs like zip and unzip, which have a tendency to be chatty, but which are still very much one operation per invokation shell commands, and non-interactive (except for y/n overwrite confirm).)
For the class of programs described in the paragraph above, it is possible to implement a GUI version of the command by providing a window which shows information relevant to the task, and providing radio buttons and toggles which specify extra options. If there are a lot of options, there can be menus or tabs. For example, xrm, if it existed, would show you a list of files in the directory, and let you select one or more of them. It would have a toggle for recursive, a toggle for force, and an execute button which would delete the files/directories. It wouldn't exit after deleting one file, because that's not how GUIs are done. They let you do more operations with the options set the way you put them, usually.
For most programs with more than a couple options, a GUI is useful if it can present the options in a way that makes it easier and faster to get your task done than it would be to do the task from the command line.
There are several factors that go into deciding whether write the program as a GUI or as a command line tool. First, and extremely important in the whole philosophy of Unix, is that the programs like this are tools. programs that do a non-interactive task are the kind that can usefully be combined with other programs in a pipe, or as part of a script. What if the only command to delete files was to run xrm (which doesn't exist, so you'd be doubly screwed), and pick some options from its menus, then pick a file? If xrm didn't take command line options, or if it insisted on opening a window, then shell scripting would suck. (rm isn't really a good example, since a lot of scripts need it, even if they do something totally unrelated. Besides, the sysadmin would have to clean up /tmp every now and then, and would have to do it manually (since there is no way to script it with xrm!) unless she was a good hacker and thought of using mv -f file /dev/null to get rid of things.) GUI versions of things that are already handled well by command line programs have their uses, especially for people who don't need to use computers often, or for very long.
Note that GUI-versions-for-newbies of commonly used programs are a terrible idea, in my (NSH :) opinion. Newbies who expect to spend a significant amount of time using computers (i.e. want to become non-newbies, probably ASAP), do not benefit from a GUI wrapper for doing non-interactive simple tasks. It is much better for the aspiring newbie to learn to the command line syntax of relatively simple commands which do tasks which crop up all the time, like removing files with rm. Knowing how to use a GUI program to do something is one thing. You can't easily combine that knowledge with other programs. Knowing how to use a command-line tool is another thing, because once you know a few simple tools, you can use the shell to put them together with pipes, command substitution, xargs, etc. The capability gained from knowing how to use a GUI program which does a given task adds linearly with the capabilities gained from knowing other GUI programs which specific operations. The capability gained from knowing a command line tool to do a certain task _MULTIPLIES_ your previous total capability (well, probably not multiplies, probably some combinatorial function like the number of permutations of n commands blah blah, ... (not to knock discrete structures or anything :) hehe.), because you can combine the newly learned command with any combination of other commands you know. (note that this capability product counts the capability to do many many useless tasks, like deleting all the files whose names is the rot13 codeing of a word which appears on a line in a text file which also contains the word "echelon". (i.e. :), and my computer isn't very fast, so awk and sed are great.)
rm -- $( grep -w echelon foo.txt | tr 'A-Za-z' 'N-ZA-Mn-za-m' )
) Try doing that with a GUI character translator, a GUI pattern-searcher, and a GUI rm. You could, but you'd have to get the GUI programs to save their results to a file, then load it from the other GUI. Kinda slow, compared to the command line. (ok, I admit it took me about a minute to get the rot13 with tr right, but you'd have the same problem if your GUI character translator was as general purpose as tr, which it would almost have to be to be worth writing at all. (except for rot13 features in file viewers or editors, which could be used.) Keep in mind that once you figure out how to do it with tr, you can do it as many times as you want, grepping different files, with no extra effort, but to use the GUI tools again you'd have to do just as much work. (you could leave their windows open and the options set, but you'd still have to save to a file and move to the next tool, or cut and paste if there wasn't too much text. That introduces even more chance for human error.)) GUIs for things only a few very commonly used options, to do a simple task, are good only for people who won't be spending enough time with computers to justify the learning time. Learning command line tools is a long term investment which gains value the more you learn how to do more different things from the command line. (i.e. not just processing files into other files.) For example, you can do a lot with wget and one-line sed and/or awk scripts. (I don't know much perl yet (working on it, though
Note that xrm is becomming the poster-child for dumb things to have a GUI's for.
Another factor in determining the whether a GUI is useful for knowledgeable users is how complex the options are. Programs with lots of different seldom-used options, like find, could benefit from a GUI. (of course, find gets regular use from the command line, usually with -name, -mtime, or -size, so the command line version is very important to have, especially for scripting. However, it _would_ be useful to have a GUI frontend to construct a command line for find. A powerful, not a flashy or user-obsequious, GUI is required. find is used often enough that remembering how to get what you want out of a relatively powerful GUI which lets you string together multiple conditions is not too hard. Very importantly, a GUI for an experienced user would be centered around searching for files named x. Everyone knows how to do that anyway, so it would be stupid to write the GUI assuming that's what most people would use it for. People would use the GUI mostly for complicated find commands most people would have to read the man page for every time they wanted to construct such a command. For use in scripting, a button to print the constructed find command on stdout could come in handy. (I'm going to have to write a GUI front end for find sometime... Cool. I should start a useful-GUIs-for-hackers project. :)
This leads my argument to the point that another factor in the usefulness of a GUI is how often the task is done, with respect to the complexity of the command line arguments. For things which are done regularly like deleting files, a GUI is a complete waste of time. For complicated things which get done all the time, like grep, a GUI is not needed. This is a case where newbies might be attracted to a graphical searcher, because they keep forgetting the command line arguments to grep. (which one makes it search for non-matching lines...? -n? (nope, that prints line numbers. -v is the one to inVert the search...) However, grep is such a powerful scripting tool and can be put to good use so often that it really must be learned by anyone who plans to use computers regularly. Another program, wget, has very many command line options, most of them difficult to remember. (the --long-options forms aren't much easier to remember, I find.) For simple use, the command line wget works fine. For more complicated tasks with patterns for accept-lists, etc., it is usually necessary to check the man page. It might well be possible to make a GUI version or front end for wget which made it easier to choose the right options to get the job done. The critical question is whether it is faster to use the GUI or to check the man page. I'm not sure whether there would be much benefit to having a GUI for wget. I think there might be, since wget isn't used very often, and there are a _lot_ of options which nobody remembers unless they've just spent the last couple minutes putting together a wget command that does what they want. Even then, you'd never remember all of them. You might remember that wget has a certain feature, but not know the relevant command line option. OTOH, a GUI is not a panacea for this problem. Some things are just complicated. However, it is often easier to figure out how to do something when the options to choose from are all sorted into categories. For example, a GUI can't make pattern matching much easier than grep, unless it limits itself to a less expressive pattern language than regular expressions. I can't picture how a GUI would be faster for stringing together sub-patterns, etc. This is especially true when you consider that you usually need to go back and tune your pattern to match exactly what you wanted it to, unless you are using a simple enough pattern that a regular expression for it would be easy to make up. Allowing for small changes to the composed pattern would probably leed to an overcomplicated GUI. Another example of a task that isn't done very often is uudecoding. The uudecode program doesn't need a GUI because it doesn't have many options. You just give it the filename. If find that you need to read the man page, it's probably because your about to do something that will end up using it a lot shortly after, so it's worth your time to gain the speed of the command line.
The value of a GUI for a task which could be done by a non-interactive command is in the amount of time it saves getting the job done. The time to use the command line version must take into account the time to read the man page and figure out what command line options to use, if necessary. Obviously, for commands that get used all the time with simple arguments, like rm filename [more filenames], a GUI is useless. For doing tasks which require a lot of choice of options, especially tasks which are done infrequently enough that the command line syntax isn't usually remembered from the last time you figured it out, a simple GUI which presents the options in a sensible manner can speed things up considerably.
GUIs are way over-rated, but they do have their uses.
\end{rant}
Note that the rant applies mostly to Unix environments, and others where a flexible, versatile command shell is available, and the tools runnable by the shell are powerfull enough that they _can_ be used to do almost everything, even things that aren't very convenient. This includes Windows with Cygwin32 bash + tools. Note that a shell environment itself benefits enormously from having a mouse to cut and paste text, ala xterm under X or gpm on a Linux text console.
#define X(x,y) x##y
I would be inclined to agree that we shouldn't over do it with extra buttons, and that language is good. (of course, I'm very much a text+command line+words oriented person. I use lynx because I don't care much about graphics, and I use love LaTeX because it lets me write good looking docs without using an annoying GUI.)
Here's an idea: There should be a row of function buttons which have any program can use for its own functions. This would be like the normal F[1-9][0-2]? keys, but they would have little LCD screens on the keyboard above the keys that could be have icons displayed in them by the program. There is no standard way to do this, so I think it would have to be in a USB keyboard or else be a horrible kludge of the keyboard protocol (it might not be, since I haven't looked into AT or PS/2 keyboard interfaces.) This would be the analog of the button bar at the top of a window, but you wouldn't have to reach for your mouse to use them. Of course, you could use loadkeys and showkey to bind them in console mode, and you could use xmodmap and xev to set them up under X. Apps could program the icons when they got the keyboard focus, I guess. This would be good because it keeps the people who want buttons happy, and it makes it very scaleable by allowing reuse of the same buttons for different apps. For novice users who don't understand how different programs have different windows and stuff, you could fix the keybindings the way they are in the AOL kbd :(
#define X(x,y) x##y