begin quoting Darren New as of Mon, Jun 11, 2007 at 08:30:00PM -0700: > Paul G. Allen wrote: > >On Mon, 2007-06-11 at 15:07 -0700, Darren New wrote: > > > >>It has a universal component model, leading to a variety of universal > >>scripting languages. > > > >Linux has many scripting languages available to it that are older than > >Windows is. > > So does Windows. That wasn't the question. X11 has a scripting language?
> What universal component model will let me write a script that runs vi > edits over an open-office spreadsheet whose data is automatically pulled > out of a database? :-) What's the common scripting language I can use > to drive open office, emacs, and the Gimp all at once? > > IBM (and Amiga) had REXX. Windows has WSH. If there's something like > that on Linux, I'd love to hear what it is. Expect. (What, some programs won't play? Well, not all programs play with REXX either -- you had to add in hooks to make it play nice. Non-compliant programs are, well, non-complaint.) > >>It has a more powerful file system as well as a > >>more powerful permissions system. > > > >Maybe in the past, but certainly not today. There's a long list of file > >systems for Linux as well as ACL support.... > > Er, as far as I know, for example, Linux still only has an owner integer > and a group integer on a file. Depends on the filesystem. > This means that if you have a file on > removable media (like a USB drive), and you plug it into a different > machine, you may suddenly find it has different owners. USB drives are generally FAT ... no owners at all, I thought. > If there's a way > to have (say) a small home network where this sort of thing works, where > I can move my backup disk from machine to machine, other than simply > making sure all the user names map to the same ID numbers on all the > machines, I'd like to hear how to work it. You'd rather match up arbitrary strings? That won't work at all. On some machines, my user account is "stremler", others is "stewart", still others is "sjs", and so on and so forth. You're _always_ going to have a synchronization problem. > It also lacks multiple streams on a file, altho I believe there's a > limited name/value capability, as long as you don't want support from > the rest of the OS (like, say, the copy command, I/O redirection, etc.) Multiple streams from a file is an abomination. Use a directory. That's what they're there for. (That being said, a segment directory, a la PRIMOS, might be fun.) > It also lacks, as far as I know, the ability to delete the beginning of > a file, altho that one I'm not sure about. Does it still work to write > all zeros over the beginning of a file to deallocate those blocks? Last > I checked, it only worked if you seek() past an area of the file and > never wrote to it. Performance optimization. Nice to have, but it adds complexity, and thus falls out of the minimally useful set of operations. > I also don't know anything that lets me (for example) query for the list > of files that were deleted or had their permissions changed since the > last time I ran this program without scanning the entire disk drive. That's a filesystem feature, isn't it? Not everyone wants to devote disk space to storing information they will never use. Perhaps Ext3Cow would do this for you. > There's no way to tell if a file was renamed, or if the file was simply > deleted and replaced with another file that takes the same i-node. Any difference that makes no difference isn't a difference. Same file name, same owner, same inode, same file. > Indeed, as far as I can see, the interface for detecting files changing > when you *are* running is barely usable for showing explorer-style > windows updating in a GUI. WTF is "explorer-style"? You mean like a file manager? > And, as far as I could tell, there's no convenient way to (for example) > copy files over the network while retaining the ACLs, or back up and > restore files while retaining stuff like the bits that say "Mary is > allowed to append to the file, Joe and Sue are allowed to read but not > write, Frank is allowed to write but not read, and Fred is allowed to > back it up but not allowed to read it." UNIX in general lacks the concepts of "append (only)" permission. This is a deficiency, even more so than the lack of "truncate from start of file". Backing up constitutes "reading". You *can* have programs that allow a user to invoke an operation that backs up a file but doesn't allow that user to examine that file, with the magic of setuid, and that doesn't even involve the filesystem. > AFAIK, Linux also doesn't have something like BITS standard. I don't Never heard of it. Google doesn't help either. > know how you configure Linux to download something slowly and only when There's "nice", "renice", and "trickle". > the network stack isn't handling other traffic, and how to have it do When did network stacks become the bottleneck again? I thought systems these days could swamp the network without seriously impairing the network stack. > that only when your connected, My what? Oh, wait, a UNIX system that is only sometimes on the network. How quaint! The network *is* the computer, haven't you heard? :) For when it isn't, "wget --continue" -- but this isn't automatic either. I'm not sure that "automatic" is a good idea... what if you got blown off the network because of excessive usage? > and have it launch your program on the > result when it's finished downloading. wget $url && ./myprogram > Sure, you can write it, but it > isn't ubiquitous as something like cron is, and that makes a big > practical difference. Actually, && is quite ubiquitous, I think. > I'm not sure how you configure something in Linux so that it doesn't > slow down other processes with disk access. I.e., I don't know the > equivalent of "nice" for disk access. Can you tell me which FM to R? UNIX and disk is a peeve of mine. What do you mean I affect system performance when formatting a disk? Why should that make any difference? > Linux also seems to lack an EFS that can encrypt individual files in a > directory, or have different files in a directory encrypted by different > people. This is something I'd really like to have on my laptop, altho > granted it's somewhat less of a problem with Linux, since things tend > not to spray files randomly all over the file system, so mounting your > home directory and /tmp and /usr/tmp and ... as encrypted partitions > probably works fairly well. Loopback helps too. Each user can mount a loopback encrypted filesystem in $HOME/encrypted if they desire... > It also lacks the ability to clean up temp files when your program > crashes or when you log out. Granted, Windows doesn't either AFAIK, but > I've worked on systems where this sort of thing was standard and it > always bugged me that nobody in the small-computer OS biz ever got that > right. Many systems can be configure to clean out /tmp on a regular basis, and .logout can do the same thing. And a tempfs handles system crashes too. > >>The features of the file system and > >>permission system are actually well-integrated into the tools. > > This is the "backup" part, see. I haven't found any program that will > back up files with ACLs and the other magic "append only" type bits intact. There is no "append only" magic in *nix-land, so far as I know. But rsync on Linux has -A or --acls (nonstandard). [snip] > >....including journaling file systems. > > What's the system call that lets me create and fill three files and not > let anyone see the first one in the directory before the third one is > created and closed? What's the call that lets an aborted transaction in > a database delete the three files? What's the call that makes those > three files disappear (and indeed never show up) when my program core > dumps while writing the third file? I'd really like to know, because > I've looked for this functionality and I was unable to find it. You want to use a transactional database to store your data, not a filesystem. > >What is Linux lacking again? But now we digress. Linux lacks much. But everything is a tradeoff, and adding in what is lacking may take away some things that are desirable. It doesn't bother me that Linux -- or UNIX -- lacks features. That's a design choice early on, and reflected in the choice of name. > I think you're putting your hands over your ears. Just saying > "Journaling file system" doesn't do what I described. If it did, there > wouldn't be any need for programs to write new versions to a .tmp file > and then rename them over top of the old version, just to keep from > corrupting the file if they crashed in the middle. Indeed. Most journalling filesystems tend to preserve metadata, not the real data; but ext3cow says it lets you roll back to anytime-in-the-past, so that might do something. Leopard appears to providing similiar functionality... so maybe this sort of data-journalling will become more prevalent over time. [snip] Not everything neat and useful needs to be in one toolbox, lest the toolbox as a whole become so heavy so as to cease being useful and neat. -- Against one tool for all purposes. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
