here's only a few novelists who have earned my hardcover trust
Gene Wolfe has a new book out in hardcover. This starts a new trilogy, The Book of the Short Sun. I bought it, read it, and am very happy I did. His prose is something to be savored, not rushed.
In the KDE article, I posted some notions about how to go about building something that's Unix-friendly instead of Winix-pandering. Rather than reposting the whole thing here, you can just follow the link.
Don't forget that you should always hire Fortran programmers to maintain your C++ code, Aural Basic programmers to maintain your Perl code, and Cobol programmers to maintain your Java code.
Why? Because that's what everyone's doing, at which point they bitch and moan about how their Fortran, Basic, and Cobol programmers can't understand the C++, Perl, and Java code you've written.
Funny thing.
They sometimes even have the unbridled audacity and incredible stupidity to demand that you convert your code to look like the languages that the "maintenance programmers" understand. I've never come up with a better answer than to suggest that people run very far, very fast from this all to prevalent mentality. The world is a strange place.
Some Answers to What a Unix User Wants
on
KDE 2.0 in Action
·
· Score: 2
Right now, all these systems are very Winix oriented. People have asked what a Unix user would want in a windowing system. Here are a few suggestions for how to make something that feels like Unix instead of Winix:
Make sure that in optimizing the program interface for the two-minute beginner, you haven't pessimized it for the two-year daily-user.
Keep it touch-typist friendly.
Let me keep my eyes on the screen at all times, not on the input peripherals.
Mimimize the context switches between mouse and keyboard. It slows me down. I can type much, much faster than I can mouse around.
Minimize all required mouse use, because it causes RSI. Let me keep my hands on the homerow as much as possible, not dancing around the funny keys that require me to look down to find, like HOME, END, PAGEUP, etc. Put those on real keys.
No prior Windows knowledge expected, required, nor in fact, even beneficial.
All programs, configurations, library functions, and interfaces must be completely documented.
Never make me do anything tedious and repetitive, like holding some an arrow key or a mouse for a long time just to move a large distance.
I shouldn't have to read the library code to figure out how Gtk works, nor existing themes to figure out how to make a new one
nor should I have to click on happycons to get some dribbled out set of web pages for how to run or configure a program
The documentation should searchable, indexable, typesettable, and printable.
Follow POSIX 1003.2 requirements that all commands have a minimal manpage.
Scriptability. Automatability. All the knobs need to be exposed either via raw text files or else normal CLI programs.
Respect for the user's existing preferences where applicable.
X defaults -- If I have *visualBell: on, then that should suffice for all applications.
stty settings -- If I think ^H is what I want to erase a character, don't make me use DEL or ^?, or worse still, the BACKSPACE key (which sends a ^H anyway) yet not Control-H). And if I have my werase set to ^W, pay attention to that, too.
Preferred editor -- if I have an editor setting in my environment, don't make me learn a new one just for your program. Most toolkits' text widgets have insultingly idiotic editing abilities -- pop up my preferred editor instead, or at least, give me that option. Perhaps prefered newsreader, shell, mailer, etc should come into play as well, but the sorry excuse for an editor is the most annoying thing.
A way to leverage existing knowledge of words. This may sound bizarre, but nothing is more frustrating to this Unix user than to have a program pop up a set of seventeen tiny graphical stickpin icons. Don't make me guess what your cutes idea of a neat bitmap for an exit or reload or search button is. Allow me the option of using real words, not happycons. And allow for keyboard shortcuts on all functionality.
Don't make me suffer through a tedious manual search through scads of cascading menus each time I want to find something. There is no way to search, analyse, or print a cascading menu system. This is insane. A common mechanism provided by the low-level toolkit and managed by the desktop or window manager must be invented. Life is too short for hunt and peck. For example, the window manager could provide a way to search the menus of the current focussed program for a particular text string. That way you never have waste your life on an idiotic recursive but linear visual search.
That's enough for now. I'm sure it's far too late to expect almost anyone to read this. You might want to check out the short Unix as Literature or the longer In The Beginning for more background on Unix culture.
I do believe it's distributions which are the real issue here, rather than kernel forking. The article, which does a good job making the point that it does, whatever factual errors aside, seems to consider kernel forking as the main issue and equivalent to the "Unix Wars" which I believe is a mistake. From a ISV point of view the distro differences are closer to the issues of the Unix wars than any kernel variations between distros.
That's right. It's not as though this flavor of Unix has read(2), write(2), and open(2), but that one doesn't. The kernel API wasn't so mutated. It was all the stuff in user-space, admin and set-up issues. And that's why all these versions of Linux make it hard for a lot of folks. I've had experiences similar to yours with regard to RPMs, but that's a tirade I'll save for later.
Since (if?) Mandrake Linux is a branch off of Redhat Linux, and Redhat Linux is a branch of Linux, and Linux is a branch of Unix, then the family tree is a huge collection of highly ramified dialects. There are places where these hundred millions flowers all blooming with varied scents is a burden, but others where it is a blessing. Let's just not call the violet a rose, because sweet though it is, it's not quite the same aroma.
That was sort of a harsh judgement of KDE, have you even used it?
Certainly. I've also used Gnome and CDE. They are all highly Winix-biased (intuitive and familiar to Windows people, confusing and unintuitive to Unix people) and worse still, wholly undocumented.
I prefer to use something whose documentation I can consult, and which doesn't assume prior Windows knowledge. I don't think that's too much to ask.
All my systems are configured with one of fvwm, twm, or tvtwm. I can set up Enlightenment, but until it's documented, it's not worth the time for me to learn how to configure it into a non-intruisive and user-friendly set-up.
And it too has the taint of Winix. I was very frustated at not being able to get a window ring going, and when Raster said words to the effect of "Just use ALT-TAB like always you dummy", I had to say "What t do you mean `ALT-TAB like always'?". Turns out that it's some Windows thing. How could I know that? I've never used Windows. This Winix stuff doesn't help me at all, although I'm sure it's friendly to those who like Windows. And also like Windows, there's no documentation. I myself finally put together a manpage for E, which Mandrake checked in.
Replacing CDE with KDE is like replacing one disgusting bucket of painful user-obsequiousness with another even flashier one. You aren't getting very far, very fast.
You've also got the most amusing perspective on "old". Things that are tried and tested, things that have withstood the tests of time, offer a streamlined stability you don't see in these fancy-pants distractions all full of glitter.
When you say "up" from twm, I think you're making some very amusing little assumptions. Nearly everything I've ever seen that isn't a twm derivative (and I include fvwm there), is just a waste of your time and attention. I don't know anyone who isn't a Winix kid (somebody raised on Windows and not happy until he hamstrings Unix into looking and feeling just like the hell he knows) who doesn't strongly prefer twm and friends. (And I even use it in uwm mode.:-) We all have a visceral dislike for CDE. Yes, you can get enlightenment to behave sanely, but it's a lot of hassle, and always huge.
But hey, maybe you're not distractable and like all that clutter. That's a gift many of us do not share with you. I can't even turn images on in a web browser, because if they move, they eat my brain and I can no more get anything done than if a chattering magpie were perched upon my shoulder. We each have our own gifts and our own challenges.
How does one define a hard drive? Does a RAID count? [...] How is the hard drive license enforceable and how are partitions dealt with?
That's an interesting question. One us2them style translator notes that when technical neophytes say "hard drive", they can mean any of
controller
disk
disk controller
disk drive
drive
file system
logical disk
mount point
partition
physical disk
And doubtless a good bit more. I have no idea what they think of a striped or concatenated filesystem. Well, yes I do. They don't.:-) Essentially, "hard drive" is nearly always used in a sloppy fashion by non-technical speakers to mean something rather different than its technical meaning. I would strongly avoid the term, if I were you, considering how messily overloaded it is.
Which academics "repeat their myth about linux=o/s=kernel" and why do they do it?
It's not really academics who are guilty of this, although it is a somewhat academic perspective to call whatever's in kernel space an operating system and nothing else. I'm sure I've been guilty of the same thing, especially back when I was doing a lot of kernel hacking. That's just how we think.
That's not the problem. It's not academics, really. Rather, the fault lies with those zealots who claim that anything running a Linux kernel Linux, as though that were all that mattered. Remember how they like to flame the BSD people for having 4 different operating systems while they steadfastly claim to have just one? It's a political stunt with no basis in matters practical. In fact, this whole "distro" jazz is a veiled euphemism to hide the fact that there are a zillion different Linux operating systems out there. Sometimes they're just repeating what they've heard, not understanding that "distro" is a cutsie dodge to avoid saying "operating system".
But to someone trying to develop, produce, test, distribute, configure, install, and adminstrate this applications software, they are different operating systems. Stop playing games to make your team seem less splintered than it is. The benefits of pretending the Emperor is wearing lovely new clothes are not, in my opinion, of greater import than the real-world ramifications of living a lie. People are trying to get honest work done, and this kind of crap just doesn't fly when you get down in the trenches.
An interesting question to some, perhaps, but even so, I suspect that this is far from the optimal forum in which to pose it, assuming you're interested in useful answers.:-)
But I have a question that might stand a chance of being answered here. It is this: What more could a Unix user want? Let us assume, for the sake of argument, that KDE suffices to mollify those vendors and users who are really just interested in Winix. But what about the real hackers? What do they want?
Today, the different Linux distros can cause a headache for people dealing with product installation issues, usually with scripts. This isn't so bad because most UNIX people are already used to that. But it does scare off software companies. Think about it, for Windows, you just buy InstallShield or Wise and most of the problems of OS differences are taken care of. Not true for Linux today.
You've definitely hit the nail on the head there. For all the ivory-tower surrealistis repeat their myth about linux=o/s=kernel, the stark reality is that those who must produce, test, distribute, install, and administrate regular software applications (not drivers) have absolutely no choice but to count most of the innumerable different Linuxes out there as different operating system. Self-serving sophistry aside, these people all have real work to do, and they can't get it done by pretending there is one coherent thing called "the Linux Operating System". Sure, there's a Linux kernel, but this is but a small part of the many significant platform considerations that producers and consumers of applications must keep aware of.
And yes, it makes this stuff hard, because it becomes a combinatoric nightmare. If people would
stop repeating this nonsense of there being One True Linux
recognize that the vendors like Redhat, Corel, SuSE, and all the rest of them will always try to differentiate themselves from one another
admit that for all the intents and purposes of people who are making and installing these applications, it is for them a different OS
If those steps could happen, then perhaps progress can be made. I don't think that they will be, however, because too many people have too much ego wrapped up in the myth. Which is a crying shame, because defining a problem out of Platonic existence rather than admitting its reality and repercussions helps nothing but the propaganda machine. It interferes with real people trying to get real work done. And it's so obviously a half-truth as to make plenty of folks look a lot more closely at other assertions held as Gospel.
I hate following up to my own postings, but a couple of errata are in order.
The first erratum is that when I said " everybody is unassailable", I of course meant that "everybody else is unassailable".
The other is that immediately prior to the sentence beginning "Consumer-targetted systems", you should insert this:
If on Unix, you don't have the source, then you can't the program on all your diverse systems. And if Unix programmers do not provide source, they cannot hope to have their program as widely used as it would otherwise be.
Somehow this slipped by in the posted copy, and it's an important point.
Finally, I fixed the latro links at the bottom, so you'll be able to see the real program. And yes, it works. Like nmap and other, um, security tools, this should of course only be used to verify the security of those systems that you yourself directly administer and have responsibility for. Not that it's apt to be sufficiently well logged to know what's really going on. It seems that POSTs never get their content logged. Play nice, and don't pick on the WinVictims.:-)
Gack, it's awful. Bring back slashdot green in all sections. Consistency is a GOOD THING.
Agreed. That's why in my slashdot user profile, I opt for low-impact (lynx friendly) transmissions, and then either use lynx (sometimes) or else Netscape with its "OBEY MY OWN COLORS" preference. Or simply run it through the color-stripping proxy.
viruses is more commonly used in the States while virii is more common in Europe
My own experience is that Europeans are more likely to have had a classical education than are Americans, and consequently less likely to reach for a misdeclension.
It's not like it's all the same, though. In English (assuming you deem England to be part of Europe:-), you have viruses, but in German, you have viren. Most curious of all, you in the Romance tongues have an invariant virus even in the plural, as in French les virus or Italian i virus. Given the historical provenance of the Romance tongues, I'd say that this invariance lends credibility to those scholars who opt for a 4th declension explanation of events.
The usage of "virii" as the plural of virus is older than the script kiddie phenominon. It is an instance of standard hacker word play, like the usage of "boxen" as the plural of "box", unices as the plural of unix, etc...
I understand what you're saying. In fact, you are probably even right.:-)
But it still begs the question of what a "virius" is, eh?:-(
I am getting tired about hearing how Linux is immune to computer viri [sic; you mean viruses], it simply isn't. The main thing preventing people from writing a Linux virus is good-will towards the operating system.
No, it's really far more complex than that.
You are correct that it is no mean trick to write a program that can damage the system it runs on, largely irrespective of what kind of system we're talking about. And so long as you can hoodwink some unwitting user into executing that program on their system, that program can, of course, cause damages commensurate with the privileges and capabilities of that user.
What you've failed to consider is how the dramatic cultural differences between Unix and the much-maligned consumerist toys serve to affect the issue to our benefit and their detriment.
Probably the most important of these cultural differences is that Unix has historically been a source-only world. Programs are distributed in the form of source code, code which shall be configured, built, and ultimately installed on the target machine. Programs solely accessible in machine language form fall immediately under a taint of mistrust.
Think back to the last time you read a notice from someone whom you've never heard of before that was asking you to go fetch some random binary program from some random place on the net and then to run that program under full sysadmin privileges? I can already see the incredulous Unix sysadmin reading that and bursting out in uncontrollable guffaws. Because the de facto standard for program interchange in Unix is as source code, a Unix programmer will be far less likely to fall for your ploy than would your average Prisoner of Bill, who has been lulled into gullibility by a binary-only culture.
But for the sake of the argument, let's say that you've found a way to effect this trick. Suppose you're an employee of some reasonably respected company that happens to produce a binary-only distribution of their commercial software, and you decide to sneak something wicked into the binary image. You manage to replace the standard, clean copy on your company's ftp or http server, or even floppies or CDs, with your own naughty version. People are accustomed to downloading from your company, or using your company's floppies, so they do as they've always done, run the installation as the superuser, and you thereby have your way with their system.
If this scenario were to play out, just how dangerous--how destructive--could it really prove? Whom could you harm, and who would be immune to your ploy? The answer is that you could only hurt those folks running the exact platform for which your binary had been compiled, and everybody is unassailable. By platform, I mean the whole feature vector that includes processor chip (eg Sparc vs Intel), operating system (e.g. SGI vs BSD), shared libraries (e.g. libc vs glibc), and site-specific configuration (e.g. shadowed vs non-shadowed password files.
Let's not get too full of ourselves and pretend that the Unix culture's predilection for source-only program distribution derives only, or even mainly, from altruism. We have no choice in this matter. Consumer-targetted systems from Microsoft or Apple are two instances are a static monoculture, as vulnerable to mayhap as a field of cloned sweet corn. It only takes one genetically engineered virus to bring down the whole field. Unix is different.
In his acclaimed essay, In The Beginning, Neal Stephenson writes:
It is this sort of acculturation that gives Unix hackers their confidence in the system, and the attitude of calm, unshakable, annoying superiority captured in the
Dilbert cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.
What made old epics like Gilgamesh so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again--making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved, and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. This is very difficult to understand for people who are accustomed to thinking of OSes as things that absolutely have to be bought.
There is no one thing called Unix. Instead, Unix comprises a diverse set of subtly (and often not so subtly) variant platforms. A nefarious binary laced with exquisitely designed evil bullets hidden inside it can hurt only a few of us. When Apple and Microsoft laugh at our diversity, be sure to remind them that is it their lack of the same that contributes to their incredible vulnerability--and to our strength. Hybrid vigor ultimately wins out over a monoculture, for the latter is too in-bred and fragile to prove long viable.
Let me now return to your particular suggestion, that of a malignant Perl program activated by a Makefile rule at installation time. Because you're talking source code, and because Perl tries rather hard to attain a high level cross-platform intercompatibility, this form of subterfuge would appear exempt from the inherent protections stemming from diversity in variant Unix platforms. So, could your trick be done? How much of a problem could this really be? What might happen?
The answer is that of course, it could be done. And in point of fact, a demonstration model is already available, courtesy of Abigail. Guess what? There's no reason to run around like a chicken with its head cut off: the sky isn't falling. This sort of approach stands little chance of making a big splash, because you aren't going to insinuate it into a place that can affect a lot of people. Sure, you might catch a few folks, but just how long to you think this kind of thing will go unnoticed? Remember, it's in source code. That means anybody who wonders what happened can just look at it. There's a very low barrier to entry. And even if the naughtiness removes itself from your copy once its dirty deeds are done, that naughtiness is still sitting there in plain view for easy inspection back wherever you got your copy from.
Is there a way around this? Well, yes, if you're as clever as Ken Thompson. Fortunately, you aren't, and neither are the crackers. If they were, they'd doubtless receive more Turing Awards for their vaunted efforts.:-)
The only way you're going to get good propagation is if your nastiness into a copy that a lot of people will download and install. There's a very fine reason why so many archives contain a checksum of the image. It's to help with this problem. Security of course depends on several matters, including the strength of the algorithm and the integrity of the authenticating agent. But better that than nothing.
Let's talk about propagation some more. I assume that the goal is to have a notable impact, which means you need to spread your bad code as widely as possible. A hacked up install script, even if all goes to your liking, just doesn't have a very high rate of reproduction. First of all, how often do how many people install this software? Secondly, how do you plan to trick them into doing so? It's not really much of a challenge to get one person to this, especially if they trust. If that's your goal, maybe you'll succeed. But the risk of being traced and apprehended is high.
So how come this stuff can spread like wildfire amongst the OS-challenged? Can't whatever mechanism that's used there be used to get at the rest of us, too?
Over the last few years, a frighteningly frequent conduit of contagion for viral infection on toy systems has been the implicit, automatic execution of code with little or not manual intervention on the part of the box's owner. DOWN THIS PATH LIES MADNESS!. That this can ever, ever happen is as a plain a symptom of complete and total cretinization in the toybox world as you are ever going to see. It's stupid, it's crazy, and it's dangerous. Any programmer who even suggests it needs to go back to flipping hamburgers. Any user who asks for this feature needs to be quietly taken into the back room by the doleful men in long trenchcoats, where he will be told in no uncertain terms that his request is not only in the best interest of no one but criminals, but that he also now has a permanent record even for asking about it.
No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training; they don't have the experience of seeing why automatic execution from untrustable source is the work of the Devil.
It's not as though we in Unix have never seen this issue before. In fact, we've seen it time and time again. And guess what? We recognized the problem and we addressed it. And we don't cater to that kind of lunacy anymore.
Here are a few concrete examples.
Remember when vi would--or at least, could--automatically execute macro commands embedded in a file in a specific way? That was a dubious feature called modelines. On my OpenBSD systems, if I type:set modeline, the program comes back and says set: the modeline option may never be turned on.
Another example of learning from our mistakes is the issue of shell archives. Instead of automatically running the sharfile through/bin/sh, there are specially made unshar programs that will do the common things, safely, and nothing else.
When CGI was first getting big, owners of toy systems would blindly install compilers and interpreters in such a way that these would easily execute arbitrary content coming in off the wire. Despite my pleas, both Netscape and Microsoft were actually advocating this! After a year of warning admins not to do this, and sending mail to the companies who were saying to just go ahead, nothing changed. So I released latro. Then and only then did various companies retract their suggestions, even though they'd been aware of the nature of the problem for a long, long time. Sure, you could be equally stupid on Unix, but for some reason, we weren't. History counts.
Implicit execution of untrusted material is simply stupid beyond words. And for some reason, the toybox people keep falling for the same chump moves, from MIME attachments to word processor and spreadsheet macros to embedded active scripting controls. I don't know quite why they just keep doing this crap. My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe. Maybe they don't hire people who come from a background in multiuser and/or networked computing systems. Maybe they don't hire people with real experience at all, just script-kiddies trying to make a buck legitimately but with no true understanding. Maybe the software makers simply can't say no to a customer request, no matter how suicidal they know that request to be. I don't know.
Whatever the cause, decades of history are completely and repeatedly ignored. They keep making the same mistakes, and they don't fix the underlying causes. Sure, there are things that are hard. Denial of service attacks are hard. People who know exactly all the ramifications of IP who go sending maliciously hand-crafted packets aren't much fun either.
But these highly technical ploys aren't why most folks on their toyboxes are being screwed up, down, left, right, and sideways. They're being screwed because of very simple matters. They don't have the notion of a protected execution mode. They don't have file permissions or memory protections. They automatically execute content willy-nilly, often with complete access to the whole machine. They expect a program to show up in binary not source form. They don't compare robust checksums from a strongly authenticated sources. They live in an infinitely vulnerable monoculture. They expect things to just magically happen for them without a thought or a care, and guess what? Their wishes are duly granted, much to their eventual dismay.
It is possible that mass-market factors may someday end up plaguing Unix systems in ways not so far removed from the stupidities that the toy boxes are riddled with. We just have to tell them no, and to condemn in the strongest and loudest possible terms any backsliding into insecurities that if we ever had, long ago banished. Looking at the Winix phenomenon, in which a dozen different vendors put together and ship their own Linux operating systems, all specifically constructed to be user-obsequious and Unix-hostile all in order to appease the lowered expectations of a hundred million Windows idiots, who, despite their numbers, really can still be wrong. The stupidity of the masses must never be underestimated.
Well done! Does anybody happen to have the exact formula for a properly scanning limerick? It would be nice to know the accepted rule rather constantly trying to match again the Man from Nantucket.:-)
Yes, the third declension noun rex has reges as its nominative plural, but vir ("man") was a pretty run-of-the-mill 2nd declension masculine noun ending in -r, like puer and magister.
Virus, well, wasn't.
Some sources report it as being an irregular 2nd declension neuter, like pelagus and vulgus. Other sources report that it was a 4th declension neuter, like status, impetus, or hiatus. None report that it declined as though it were a 2nd declension masculine, like dominus and abacus.
Check out the rest of the story. It contains links to the wonderful Perseus Project, which is devoted to on-line access to the Classics, including word searches and definitions. I think you'll like it. Here's my favorite entry point to them.
Every time I read the malformation *virii, my brain pronounces it as it does viri, which in English sounds pretty much just like "weary", which also describes my sentiment.:-)
It's odd that you "must speak up", yet refuse to divulge your identity.
It is my understanding that all this has happened at the bequest of Theo.
Goodness, I hadn't realized that he'd passed away! Or was that not in fact the word you were looking for? Try "behest", not "bequest"--unless you're trying to say something shocking.
MS OSs have negligible security. They were built for non-networked computers, where physical security is the most important type of security.
Unix was originally built for non-networked computers. Your point? MS has stuck most of the unsuspecting world with a form of technology that was already out of date before they came on the scene. And they've developed an entire culture in which people now expect this sort of shoddy craftsmanship. And then they wonder why they get burnt. There comes a time to throw out the old crap and do it right. That time is long, long, long past.
If the virus writer wants to attack Unix, assembler and a knowledge of the OS is a must.
Ah, and precisely which assembly language would that be? I'd dearly love to see the machine language virus that someone is going to use to attack my Sparc/OpenBSD system, my PowerPC/MkLinux(Mach) system, and my Intel/Redhat system all at once. Even if they get over the extreme and proven hurdles that I, a mundane user, am not privileged enough to take pot shots at random bits of memory or disk, they still have dramatically different kernels and instruction sets to contend with. It's not just inherent security keeping the script kiddies out of our recta.
Even if we were the idiots in Unix the way they are in slobbering consumerist MicroAppleSoft-land--and as some predict will inevitably occur if we `win'-- our hybrid vigor makes us strong. Their monoculture is an accident waiting to happen. And happen. And happen.
Apple figured this out, and are moving to a BSD platform. I've played with it, and it's nifty.
Slashdot Mirror
In the KDE article, I posted some notions about how to go about building something that's Unix-friendly instead of Winix-pandering. Rather than reposting the whole thing here, you can just follow the link.
Why? Because that's what everyone's doing, at which point they bitch and moan about how their Fortran, Basic, and Cobol programmers can't understand the C++, Perl, and Java code you've written.
Funny thing.
They sometimes even have the unbridled audacity and incredible stupidity to demand that you convert your code to look like the languages that the "maintenance programmers" understand. I've never come up with a better answer than to suggest that people run very far, very fast from this all to prevalent mentality. The world is a strange place.
- Make sure that in optimizing the program interface for the two-minute beginner, you haven't pessimized it for the two-year daily-user.
- Keep it touch-typist friendly.
- Let me keep my eyes on the screen at all times, not on the input peripherals.
- Mimimize the context switches between mouse and keyboard. It slows me down. I can type much, much faster than I can mouse around.
- Minimize all required mouse use, because it causes RSI. Let me keep my hands on the homerow as much as possible, not dancing around the funny keys that require me to look down to find, like HOME, END, PAGEUP, etc. Put those on real keys.
- No prior Windows knowledge expected, required, nor in fact, even beneficial.
- All programs, configurations, library functions, and interfaces must be completely documented.
- Never make me do anything tedious and repetitive, like holding some an arrow key or a mouse for a long time just to move a large distance.
- I shouldn't have to read the library code to figure out how Gtk works, nor existing themes to figure out how to make a new one
- nor should I have to click on happycons to get some dribbled out set of web pages for how to run or configure a program
- The documentation should searchable, indexable, typesettable, and printable.
- Follow POSIX 1003.2 requirements that all commands have a minimal manpage.
- Scriptability. Automatability. All the knobs need to be exposed either via raw text files or else normal CLI programs.
- Respect for the user's existing preferences where applicable.
- X defaults -- If I have *visualBell: on, then that should suffice for all applications.
- stty settings -- If I think ^H is what I want to erase a character, don't make me use DEL or ^?, or worse still, the BACKSPACE key (which sends a ^H anyway) yet not Control-H). And if I have my werase set to ^W, pay attention to that, too.
- Preferred editor -- if I have an editor setting in my environment, don't make me learn a new one just for your program. Most toolkits' text widgets have insultingly idiotic editing abilities -- pop up my preferred editor instead, or at least, give me that option. Perhaps prefered newsreader, shell, mailer, etc should come into play as well, but the sorry excuse for an editor is the most annoying thing.
- A way to leverage existing knowledge of words. This may sound bizarre, but nothing is more frustrating to this Unix user than to have a program pop up a set of seventeen tiny graphical stickpin icons. Don't make me guess what your cutes idea of a neat bitmap for an exit or reload or search button is. Allow me the option of using real words, not happycons. And allow for keyboard shortcuts on all functionality.
- Don't make me suffer through a tedious manual search through scads of cascading menus each time I want to find something. There is no way to search, analyse, or print a cascading menu system. This is insane. A common mechanism provided by the low-level toolkit and managed by the desktop or window manager must be invented. Life is too short for hunt and peck. For example, the window manager could provide a way to search the menus of the current focussed program for a particular text string. That way you never have waste your life on an idiotic recursive but linear visual search.
That's enough for now. I'm sure it's far too late to expect almost anyone to read this. You might want to check out the short Unix as Literature or the longer In The Beginning for more background on Unix culture.Since (if?) Mandrake Linux is a branch off of Redhat Linux, and Redhat Linux is a branch of Linux, and Linux is a branch of Unix, then the family tree is a huge collection of highly ramified dialects. There are places where these hundred millions flowers all blooming with varied scents is a burden, but others where it is a blessing. Let's just not call the violet a rose, because sweet though it is, it's not quite the same aroma.
I prefer to use something whose documentation I can consult, and which doesn't assume prior Windows knowledge. I don't think that's too much to ask.
All my systems are configured with one of fvwm, twm, or tvtwm. I can set up Enlightenment, but until it's documented, it's not worth the time for me to learn how to configure it into a non-intruisive and user-friendly set-up.
And it too has the taint of Winix. I was very frustated at not being able to get a window ring going, and when Raster said words to the effect of "Just use ALT-TAB like always you dummy", I had to say "What t do you mean `ALT-TAB like always'?". Turns out that it's some Windows thing. How could I know that? I've never used Windows. This Winix stuff doesn't help me at all, although I'm sure it's friendly to those who like Windows. And also like Windows, there's no documentation. I myself finally put together a manpage for E, which Mandrake checked in.
I hate Winix. I really, really do.
You've also got the most amusing perspective on "old". Things that are tried and tested, things that have withstood the tests of time, offer a streamlined stability you don't see in these fancy-pants distractions all full of glitter.
When you say "up" from twm, I think you're making some very amusing little assumptions. Nearly everything I've ever seen that isn't a twm derivative (and I include fvwm there), is just a waste of your time and attention. I don't know anyone who isn't a Winix kid (somebody raised on Windows and not happy until he hamstrings Unix into looking and feeling just like the hell he knows) who doesn't strongly prefer twm and friends. (And I even use it in uwm mode. :-) We all have a visceral dislike for CDE. Yes, you can get enlightenment to behave sanely, but it's a lot of hassle, and always huge.
But hey, maybe you're not distractable and like all that clutter. That's a gift many of us do not share with you. I can't even turn images on in a web browser, because if they move, they eat my brain and I can no more get anything done than if a chattering magpie were perched upon my shoulder. We each have our own gifts and our own challenges.
- controller
- disk
- disk controller
- disk drive
- drive
- file system
- logical disk
- mount point
- partition
- physical disk
And doubtless a good bit more. I have no idea what they think of a striped or concatenated filesystem. Well, yes I do. They don't.That's not the problem. It's not academics, really. Rather, the fault lies with those zealots who claim that anything running a Linux kernel Linux, as though that were all that mattered. Remember how they like to flame the BSD people for having 4 different operating systems while they steadfastly claim to have just one? It's a political stunt with no basis in matters practical. In fact, this whole "distro" jazz is a veiled euphemism to hide the fact that there are a zillion different Linux operating systems out there. Sometimes they're just repeating what they've heard, not understanding that "distro" is a cutsie dodge to avoid saying "operating system".
But to someone trying to develop, produce, test, distribute, configure, install, and adminstrate this applications software, they are different operating systems. Stop playing games to make your team seem less splintered than it is. The benefits of pretending the Emperor is wearing lovely new clothes are not, in my opinion, of greater import than the real-world ramifications of living a lie. People are trying to get honest work done, and this kind of crap just doesn't fly when you get down in the trenches.
But I have a question that might stand a chance of being answered here. It is this: What more could a Unix user want? Let us assume, for the sake of argument, that KDE suffices to mollify those vendors and users who are really just interested in Winix. But what about the real hackers? What do they want?
Obviously, it's not Winix. But what is it?
And yes, it makes this stuff hard, because it becomes a combinatoric nightmare. If people would
- stop repeating this nonsense of there being One True Linux
- recognize that the vendors like Redhat, Corel, SuSE, and all the rest of them will always try to differentiate themselves from one another
- admit that for all the intents and purposes of people who are making and installing these applications, it is for them a different OS
If those steps could happen, then perhaps progress can be made. I don't think that they will be, however, because too many people have too much ego wrapped up in the myth. Which is a crying shame, because defining a problem out of Platonic existence rather than admitting its reality and repercussions helps nothing but the propaganda machine. It interferes with real people trying to get real work done. And it's so obviously a half-truth as to make plenty of folks look a lot more closely at other assertions held as Gospel.The first erratum is that when I said " everybody is unassailable", I of course meant that "everybody else is unassailable".
The other is that immediately prior to the sentence beginning "Consumer-targetted systems", you should insert this:
Somehow this slipped by in the posted copy, and it's an important point.Finally, I fixed the latro links at the bottom, so you'll be able to see the real program. And yes, it works. Like nmap and other, um, security tools, this should of course only be used to verify the security of those systems that you yourself directly administer and have responsibility for. Not that it's apt to be sufficiently well logged to know what's really going on. It seems that POSTs never get their content logged. Play nice, and don't pick on the WinVictims. :-)
People have no sense of humor these days (Russ excepted :-).
It's not like it's all the same, though. In English (assuming you deem England to be part of Europe :-), you have viruses, but in German, you have viren. Most curious of all, you in the Romance tongues have an invariant virus even in the plural, as in French les virus or Italian i virus. Given the historical provenance of the Romance tongues, I'd say that this invariance lends credibility to those scholars who opt for a 4th declension explanation of events.
But it still begs the question of what a "virius" is, eh? :-(
You are correct that it is no mean trick to write a program that can damage the system it runs on, largely irrespective of what kind of system we're talking about. And so long as you can hoodwink some unwitting user into executing that program on their system, that program can, of course, cause damages commensurate with the privileges and capabilities of that user.
What you've failed to consider is how the dramatic cultural differences between Unix and the much-maligned consumerist toys serve to affect the issue to our benefit and their detriment.
Probably the most important of these cultural differences is that Unix has historically been a source-only world. Programs are distributed in the form of source code, code which shall be configured, built, and ultimately installed on the target machine. Programs solely accessible in machine language form fall immediately under a taint of mistrust.
Think back to the last time you read a notice from someone whom you've never heard of before that was asking you to go fetch some random binary program from some random place on the net and then to run that program under full sysadmin privileges? I can already see the incredulous Unix sysadmin reading that and bursting out in uncontrollable guffaws. Because the de facto standard for program interchange in Unix is as source code, a Unix programmer will be far less likely to fall for your ploy than would your average Prisoner of Bill, who has been lulled into gullibility by a binary-only culture.
But for the sake of the argument, let's say that you've found a way to effect this trick. Suppose you're an employee of some reasonably respected company that happens to produce a binary-only distribution of their commercial software, and you decide to sneak something wicked into the binary image. You manage to replace the standard, clean copy on your company's ftp or http server, or even floppies or CDs, with your own naughty version. People are accustomed to downloading from your company, or using your company's floppies, so they do as they've always done, run the installation as the superuser, and you thereby have your way with their system.
If this scenario were to play out, just how dangerous--how destructive--could it really prove? Whom could you harm, and who would be immune to your ploy? The answer is that you could only hurt those folks running the exact platform for which your binary had been compiled, and everybody is unassailable. By platform, I mean the whole feature vector that includes processor chip (eg Sparc vs Intel), operating system (e.g. SGI vs BSD), shared libraries (e.g. libc vs glibc), and site-specific configuration (e.g. shadowed vs non-shadowed password files.
Let's not get too full of ourselves and pretend that the Unix culture's predilection for source-only program distribution derives only, or even mainly, from altruism. We have no choice in this matter. Consumer-targetted systems from Microsoft or Apple are two instances are a static monoculture, as vulnerable to mayhap as a field of cloned sweet corn. It only takes one genetically engineered virus to bring down the whole field. Unix is different.
In his acclaimed essay, In The Beginning , Neal Stephenson writes:
There is no one thing called Unix. Instead, Unix comprises a diverse set of subtly (and often not so subtly) variant platforms. A nefarious binary laced with exquisitely designed evil bullets hidden inside it can hurt only a few of us. When Apple and Microsoft laugh at our diversity, be sure to remind them that is it their lack of the same that contributes to their incredible vulnerability--and to our strength. Hybrid vigor ultimately wins out over a monoculture, for the latter is too in-bred and fragile to prove long viable.
Let me now return to your particular suggestion, that of a malignant Perl program activated by a Makefile rule at installation time. Because you're talking source code, and because Perl tries rather hard to attain a high level cross-platform intercompatibility, this form of subterfuge would appear exempt from the inherent protections stemming from diversity in variant Unix platforms. So, could your trick be done? How much of a problem could this really be? What might happen?
The answer is that of course, it could be done. And in point of fact, a demonstration model is already available, courtesy of Abigail. Guess what? There's no reason to run around like a chicken with its head cut off: the sky isn't falling. This sort of approach stands little chance of making a big splash, because you aren't going to insinuate it into a place that can affect a lot of people. Sure, you might catch a few folks, but just how long to you think this kind of thing will go unnoticed? Remember, it's in source code. That means anybody who wonders what happened can just look at it. There's a very low barrier to entry. And even if the naughtiness removes itself from your copy once its dirty deeds are done, that naughtiness is still sitting there in plain view for easy inspection back wherever you got your copy from.
Is there a way around this? Well, yes, if you're as clever as Ken Thompson. Fortunately, you aren't, and neither are the crackers. If they were, they'd doubtless receive more Turing Awards for their vaunted efforts. :-)
The only way you're going to get good propagation is if your nastiness into a copy that a lot of people will download and install. There's a very fine reason why so many archives contain a checksum of the image. It's to help with this problem. Security of course depends on several matters, including the strength of the algorithm and the integrity of the authenticating agent. But better that than nothing.
Let's talk about propagation some more. I assume that the goal is to have a notable impact, which means you need to spread your bad code as widely as possible. A hacked up install script, even if all goes to your liking, just doesn't have a very high rate of reproduction. First of all, how often do how many people install this software? Secondly, how do you plan to trick them into doing so? It's not really much of a challenge to get one person to this, especially if they trust. If that's your goal, maybe you'll succeed. But the risk of being traced and apprehended is high.
So how come this stuff can spread like wildfire amongst the OS-challenged? Can't whatever mechanism that's used there be used to get at the rest of us, too?
Over the last few years, a frighteningly frequent conduit of contagion for viral infection on toy systems has been the implicit, automatic execution of code with little or not manual intervention on the part of the box's owner. DOWN THIS PATH LIES MADNESS!. That this can ever, ever happen is as a plain a symptom of complete and total cretinization in the toybox world as you are ever going to see. It's stupid, it's crazy, and it's dangerous. Any programmer who even suggests it needs to go back to flipping hamburgers. Any user who asks for this feature needs to be quietly taken into the back room by the doleful men in long trenchcoats, where he will be told in no uncertain terms that his request is not only in the best interest of no one but criminals, but that he also now has a permanent record even for asking about it.
No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training; they don't have the experience of seeing why automatic execution from untrustable source is the work of the Devil.
It's not as though we in Unix have never seen this issue before. In fact, we've seen it time and time again. And guess what? We recognized the problem and we addressed it. And we don't cater to that kind of lunacy anymore.
Here are a few concrete examples.
Remember when vi would--or at least, could--automatically execute macro commands embedded in a file in a specific way? That was a dubious feature called modelines. On my OpenBSD systems, if I type :set modeline, the program comes back and says set: the modeline option may never be turned on.
Another example of learning from our mistakes is the issue of shell archives. Instead of automatically running the sharfile through /bin/sh, there are specially made unshar programs that will do the common things, safely, and nothing else.
When CGI was first getting big, owners of toy systems would blindly install compilers and interpreters in such a way that these would easily execute arbitrary content coming in off the wire. Despite my pleas, both Netscape and Microsoft were actually advocating this! After a year of warning admins not to do this, and sending mail to the companies who were saying to just go ahead, nothing changed. So I released latro. Then and only then did various companies retract their suggestions, even though they'd been aware of the nature of the problem for a long, long time. Sure, you could be equally stupid on Unix, but for some reason, we weren't. History counts.
Implicit execution of untrusted material is simply stupid beyond words. And for some reason, the toybox people keep falling for the same chump moves, from MIME attachments to word processor and spreadsheet macros to embedded active scripting controls. I don't know quite why they just keep doing this crap. My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe. Maybe they don't hire people who come from a background in multiuser and/or networked computing systems. Maybe they don't hire people with real experience at all, just script-kiddies trying to make a buck legitimately but with no true understanding. Maybe the software makers simply can't say no to a customer request, no matter how suicidal they know that request to be. I don't know.
Whatever the cause, decades of history are completely and repeatedly ignored. They keep making the same mistakes, and they don't fix the underlying causes. Sure, there are things that are hard. Denial of service attacks are hard. People who know exactly all the ramifications of IP who go sending maliciously hand-crafted packets aren't much fun either.
But these highly technical ploys aren't why most folks on their toyboxes are being screwed up, down, left, right, and sideways. They're being screwed because of very simple matters. They don't have the notion of a protected execution mode. They don't have file permissions or memory protections. They automatically execute content willy-nilly, often with complete access to the whole machine. They expect a program to show up in binary not source form. They don't compare robust checksums from a strongly authenticated sources. They live in an infinitely vulnerable monoculture. They expect things to just magically happen for them without a thought or a care, and guess what? Their wishes are duly granted, much to their eventual dismay.
It is possible that mass-market factors may someday end up plaguing Unix systems in ways not so far removed from the stupidities that the toy boxes are riddled with. We just have to tell them no, and to condemn in the strongest and loudest possible terms any backsliding into insecurities that if we ever had, long ago banished. Looking at the Winix phenomenon, in which a dozen different vendors put together and ship their own Linux operating systems, all specifically constructed to be user-obsequious and Unix-hostile all in order to appease the lowered expectations of a hundred million Windows idiots, who, despite their numbers, really can still be wrong. The stupidity of the masses must never be underestimated.
PS: Congratulations for reading this far. :-)
Well done! Does anybody happen to have the exact formula for a properly scanning limerick? It would be nice to know the accepted rule rather constantly trying to match again the Man from Nantucket. :-)
Virus, well, wasn't.
Some sources report it as being an irregular 2nd declension neuter, like pelagus and vulgus. Other sources report that it was a 4th declension neuter, like status, impetus, or hiatus. None report that it declined as though it were a 2nd declension masculine, like dominus and abacus.
Check out the rest of the story. It contains links to the wonderful Perseus Project, which is devoted to on-line access to the Classics, including word searches and definitions. I think you'll like it. Here's my favorite entry point to them.
Every time I read the malformation *virii, my brain pronounces it as it does viri, which in English sounds pretty much just like "weary", which also describes my sentiment. :-)
Even if we were the idiots in Unix the way they are in slobbering consumerist MicroAppleSoft-land--and as some predict will inevitably occur if we `win'-- our hybrid vigor makes us strong. Their monoculture is an accident waiting to happen. And happen. And happen.
Apple figured this out, and are moving to a BSD platform. I've played with it, and it's nifty.