Messages in this thread | | | Date | Sun, 21 Mar 1999 14:45:42 -0500 (EST) | From | Alexander Viro <> | Subject | Re: #!perl - alternative path to script interpreters - patch to 2.2 |
| |
On Sun, 21 Mar 1999, Albert D. Cahalan wrote:
> Alexander Viro writes: > > On Sun, 21 Mar 1999, Albert D. Cahalan wrote: > >> Alexander Viro writes: > >> > >>> And script written under Linux and using that feature will break > >>> *everywhere* else. Fun, fun... > >> > >> That would not be a Linux problem. > > > > Bullshit. Software locked on *any* platform is evil, for a lot of reasons, > > It is evil to ignore standard features in favor of proprietary ones, > thus forcing software developers to be locked in. > > It is not at all evil to provide new features. > > Your logic is warped. Was it also bad that BSD added long filename > support? Any archive with long filenames would be locked in. > I could go on, but this is silly. New features are just fine.
BSD folks did it after *big* pains and it wasn't harmless. Needed - yes, but just remember the fun we had with readdir() and friends. And that was ten years later. In the beginning it was horrible. Yes, it was needed. But adding new features at every whim is thoroughly rooten idea - if a year later you'll see that it should be done in a different way you are deep in it. In effect you'll have to remove it and add a new one. With all fun associated with featurectomy. Just look what had it done to NT. New features are *not* just fine when they modify the interface in any direction. May I remind you that we are in foo.<even>.bar now? BTW, if the software is written for Linux *only* it has much better chance to depend on a random boat anchor we'll try to remove/redo ten releases later. It is not locked just on Linux. It's locked on Linux foo.bar.baz--foo.bar.quux.
> >> One could have the kernel substitute any pathname for any other > >> pathname when executing a script. > > > > Or you can do it with sed when you install the software. > > You "forgot" this bit of my original post: > > # ln -s foo bar > ln: cannot create symbolic link `bar' to `foo': Read-only file system > > Perhaps you think sed will work? Send me a script you like... > (it is not physically possible to write to that filesystem)
Ex-cu-se me? WTF do you mean - that *script* is on R/O fs? And you cannot copy it away? Cool. And said R/O fs doesn't contain the things needed? 99:1 that it will break. The path to interpreter will be the last of your problems. Just for starters: fixed pathes in binaries. Fixed pathes unconditionally assigned to shell variables within said script. And that's aside of the general luserness of the software author that *will* show in their code. If you have such stuff on R/O /usr - shoot the luser who got root on the LAN or lusers who produced the distribution. It's ridiculous.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |