Slashdot Mirror
Domain: dogmap.org
Stories and comments across the archive that link to dogmap.org.
Comments · 8
-
Re:But what about DCOM in my ActiveX?
They work across processes just fine when they're duplicated by the kernel -- such as with fork, or by passing them across a unix socket (sorry, not a pipe
If you want to try this trick out yourself, try Paul Jarc's fdtools -- the 'sendfd' app demonstrates its use http://code.dogmap.org/fdtools/
Plan 9 naturally does make heavy use of this trick, and has a sendfd syscall specifically for it. It's been ported to Linux too, part of Plan 9 From User Space. -
Re:I've got something to say!
-
Re:I've got something to say!
-
Re:Modifying packages to conform to FHS = bad
I'd rather live with the unmatched convenience of apt, than try to morph my system into some mix of Plan 9 and GNU/Linux.
apt is indeed a nice interface to package management; however, nothing about it is inherently tied to the FHS. It could be made to work with other package layouts.At the end of the day, all our software is designed to work with the FHS, and no amount of fraglie automated scripts to create compatability directories for binaries, include files, library files, man pages, info pages, gstreamer elements, pam modules, iptables modules, firmware, bonobo components, gimp plugins, browser plugins, and so on ad infinitum is going to circumvent that.
You'd be surprised how at how much less work it is than you think. sp-foreign is 5268 lines of Bourne shell scripting on my system. Compare this with dpkg and all the Debian packaing infrastructure. Granted, they have different requirements and different goals, but my point is that an non-FHS system is do-able. -
Re:Modifying packages to conform to FHS = bad
Any program that requires QT to live in
I don't care if UNIX integrators think it's ``broken.'' The reality is upstream maintainers will choose whichever package layouts they believe are best. You are living in a fantasy world if you think that someday, every package in the universe in going to conform to the FHS. Now given this reality, we are faced with the problem of trying to make interoperability among UNIX-style systems work. The solution is for us all to stop whining and support the standard names with symlinks.If you write your programs to #include , not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in
You're arguing that it's just fine to move files if the files are accessed with the help of search paths: $PATH, $MANPATH, $LD_LIBRARY_PATH, etc. There's no theoretical obstacle to building a complete system along these lines. But it's bad engineering: getting all the details right is a royal pain, and people inevitably screw it up. For example, what happens if you try to upgrade a ``local'' version of slrn by installing a ``system'' package? The program will be put inIf you are curious, you can always find out with dpkg --listfiles libqt3-mt.
What about on Red Hat? What about on SUSE? What about on the hundreds of other UNIX variants out there? Do you really think its feasible to demand that each package author be aware of where each of his dependencies lives on each different platform?If the packages dumped all their stuff in
No, you don't. I know because I do organize my systems this way. You can use symbolic links to make the files available at their expected locations.Something else that you'd lose the ability to do is to share out
It is wrong for sharability to determine the name by which a file is accessed. Sharability is not constant. Names must be constant. I can simply set up symlinks like
or vice versa to share arch-independent data via -
Re:Modifying packages to conform to FHS = bad
An alternative is to forsake the shared library cache alltogether, and maintain an ever-growing collection of PATH, LD_LIBRARY_PATH, etc, environmental variables.
A better alternative is to make your binary depend on the absolute library path of the shared library by passing gcc the -Wl,-rpath flag. This is extremely flexible because the absolute path can be a symlink to whichever version of the library you want your binary to use.For instance, let's say I am installing version 1.0 of foo in prefix
and I tell my binaries in foo-1.0 to always access bar.so by the absolute path(No need to consult
No environment variables necessary. And you certainly don't need to ship private copy of libraries with each package.
Please tell me: How would you accomplish this scenario with an FHS-compliant system (upgrade a dependency for a given set of packages and not others)?
I knowOh yeah, I symlink all commands into
-
Modifying packages to conform to FHS = badI was a Debian user for four years; I recently switched away because I got fed up with all the downstream futzing they do to their packages. I understand Debian's need to ensure high-quality packages, but making gratutious changes to package interfaces (e.g., moving and renaming files) just to conform to a hardline FHS policy is extremely detrimental in the long term.
Cross-platform compatibility is essential. If the upstream Apache maintainers say Apache can be stopped with apachectl stop, Debian should damn well support this interface. I don't care if they provide
The tremendous benefits of cross-platform compatibility come from a package's interface being exactly the same on every system. It is a relatively minor benefit for different packages to have similar interfaces. Breaking cross-platform compatibility, as Debian does, for the sake of cross-package similarity is a horrible idea.
I should point out that I'm picking on Debian here because they are especially bad about this, but almost every major Linux distribution is guilty of unncessarily violating cross-platform compatibility in some way.
-
Re:Filesystem Hierarchy Standard
Unfortunately, the FHS doesn't work. slashpackage is an attempt to remedy the fundamental problem plaguing the FHS, and there is even a new quasi-distribution based entirely on slashpackage! The revolution has begun!