Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 22:35:58 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 05:47:21PM -0700, Alexander Hvostov wrote: On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Hardware support is what is necessary to do what you described (in your previous message) at this time. What you described above sounds more like user-mode Linux. That's what I was describing. I had forgotten the name. Thanks! Regards, Alex.
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Regards, Alex.
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 16:48:05 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Debian packages require root privileges for installation. While you could unpack a .deb in your home directory and use the files in it, you would lose most of the advantages of using a packaging system (file tracking, autoconfiguration, etc.). If you use it this way, a .deb is no better than a .tar with binaries in it. I suppose you could install most simple .debs in a chroot environment where you owned everything, but many packages (notably those which run daemons, cron jobs, etc.) expect to be able to perform tasks as root. That said, .debs _are_ a good addition to .tar.gz for distribution. This is what Debian developers (in general) do: create and distribute .debs. One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. This could also be useful for Debian developers. This way, they could not only develop their packages on Debian machines (on which they don't have root), but also test them. I imagine quite a few packaging bugs in unstable would be wiped out that way. ;) For that to work, you'd also need to set up a base system for each and every developer. That would waste a lot of disk space in a hurry. Perhaps copy-on-write file links would do the trick here, allowing root to keep a central repository of a prototypical base system, and allowing each developer to change it at will, but without wasting disk space unless something actually changes. Of course, that means big changes in the kernel's VFS code and possibly elsewhere, but copy-on-write links would be way cool for other reasons as well[1-2]. Has anyone heard of an effort to do something like that?[3] [1] As some of you may notice, Quake 2 demands that it run in a directory with _all_ of its data files -- some of which normal users may change (eg, baseq2/config.cfg), and some of which normal users will probably never change, but might (eg, baseq2/pak?.pak). As it's done now, symlinks are created to files users are unlikely to change, and files users are likely to change are copied. With copy-on- write links, all files would be copy-on-write links, and the user can change any file, without wasting any more disk space than actually necessary. [2] The files in /etc/skel that get copied to new users' home directories might be changed by root from time to time, for whatever reason. Not all users are knowledgeable enough to change them, and of those who are, only some understand that they need to remove a symlink and copy the source file and edit that. With copy-on-write links, `adduser' would simply create copy-on-write links to the files in /etc/skel in a new user's home directory, and that new user can play with those files if they wish, and if they don't, they'll automatically receive updated versions of those files whenever root changes them in /etc/skel. [3] I understand Microsoft has done something like that in one of their operating systems or another. It was on Slashdot a while back. Most people said that what they `invented' are really just symlinks, but the major difference is that they're copy-on- write, whereas writing to a symlink on Unix will write to the file pointed to, but overwriting a symlink will overwrite the symlink, not the file pointed to; this is a pseudo-copy-on-write behavior, but not real copy-on-write like what MS did. Of course, they attached some lame marketroid buzzword TLA to it, but `copy-on-write link' works for me. ;) Regards, Alex.
Re: Bug#95430: acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Wed, 2 May 2001 23:22:29 -0700 Zack Weinberg [EMAIL PROTECTED] wrote: Okay, I'll concede that this exploit is only theoretical on Linux at this time. Remember what was on the L0pht website... L0pht, making the throetical practical since [some year I care not to remember] This probably has absolutely no relevance to this thread, and I probably sound like an idiot, but I decided to send this anyway. Feel free to make fun of me at will. Regards, Alex.
Re: rfc1149
On Thu, 3 May 2001 16:56:08 +1000 Sam Couter [EMAIL PROTECTED] wrote: Marcin Owsiany [EMAIL PROTECTED] wrote: No need to create a section for them. Birds can sit on the tree directly. But what about now that we have pools? Will they drown? Being birds, I assume they would (attempt to) bathe in them... Regards, Alex.
Re: Gnome bug 94684
On 26 Apr 2001 14:09:51 +0800 zhaoway [EMAIL PROTECTED] wrote: You guys are getting more and more bureaucratic. That's sad. Bureaucracy is integral to an organization such as Debian. you're going to have to learn to live with it. The package maintainer is a volunteer, and he knows you are also a developer. His being a volunteer does not excuse him from performing his duties. It actually gives him less of an excuse -- if you don't want to do your job as a volunteer than be polite and give maintainership to someone else who can. [snip] I agree that if you're a noname random clueless mere user then the package maintainer shouldn't just close this usibility bug blindly. The package maintainer shouldn't close bugs blindly in any case. Regards, Alex.
Re: Gnome bug 94684
On 27 Apr 2001 12:12:14 -0700 [EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote: [snip] 2) Does your statement mean you will *never* forward wishlist items either? From my experience, Christian pretty much ignores wishlist items. If you don't want to change your configuration each time you did a apt-get upgrade, then install potato. testing/unstable is for real men (tm). You don't get it. A user who upgrades from *potato* to the eventually released *woody* will get all these bugs. It is good that they can be caught now, but they don't just bite users of unstable, they bite users of *stable* at the point the upgrade occurs. You should also mention that unstable is for real men (tm), whereas testing is for, uh, power users. Regards, Alex.
Re: Intent to package intel-rng-tools.
On Thu, 26 Apr 2001 09:15:39 +0530 Viral [EMAIL PROTECTED] wrote: On Wed, Apr 25, 2001 at 01:14:22PM -0700, Alexander Hvostov wrote: Isn't there a kernel driver for that? Yes, but one needs the daemon to use the driver. One could activate it from /proc, but that was removed and moved to a userland daemon. As long as it isn't too bothersome for you, would you mind explaining why the kernel doesn't activate it by default? Or why it isn't a `make config' option? And why is a daemon needed for it? Regards, Alex.
Re: ITP: darj - arj archive unpacking tool
On Thu, 26 Apr 2001 13:10:48 +0300 Richard Braakman [EMAIL PROTECTED] wrote: darj - arj archive unpacking tool I've started writing a free version of unarj. I have unarj installed in case I come across .arj files on the net or on old floppies, and vrms listed it once too often :) Cool! So this is more of an intent to write than intent to package, but I do intend to package it once it is done. Maybe it should have been `ITW:' then. ;) I will duplicate unarj's interface as closely as I can (except for the banner), both for ease of regression testing and in case there are scripts that parse unarj's output. I considered going the other way and making it behave like a proper unix utility, but... maybe in version 2. Why not put the core into a library (libdarj.so or something)? This sounds like something that could be used by a multitude of programs (eg, Nautilus). This would also allow you to make one program that wraps the library and behaves like a proper unix utility, and then another that mimics unarj. Its current state is that it can list the files in an archive, but can't uncompress or extract them. I'm not looking for help (I'm having fun writing this), but if you have any unusual arj archives lying around then I would appreciate a copy for testing. Are you planning to make a compressor at some point? I imagine if you can figure out the format well enough to extract from it, it wouldn't be much harder to be able to create/modify archives as well. Of course, that's a less-needed feature than decompression (zip, tar/gzip, and tar/bzip2 are more standard than arj these days), so it would be a rather low-priority goal, but it might be useful... Regards, Alex.
Re: Intent to package intel-rng-tools.
On Wed, 25 Apr 2001 14:35:37 +0530 Viral [EMAIL PROTECTED] wrote: I am working on packaging intel-rng-tools. It is the daemon to utilise the RNG on i810 boards. Let me know if anyone is working on this. I shall otherwise upload it tonight. Isn't there a kernel driver for that? Regards, Alex.
Re: VA Debian banner old
On 25 Apr 2001 17:23:50 -0700 Evan Prodromou [EMAIL PROTECTED] wrote: RB == Roland Bauerschmidt [EMAIL PROTECTED] writes: Not to mention that it's a grodie patented GIF. ~ESP, fan of http://burnallgifs.org/ It's not compressed, and therefore not patented. I say this because `libungif' can read it. Or can libungif read LZW compressed gifs but not write them? Regards, Alex.
Re: Why does typing navigator run mozilla?
On Mon, 23 Apr 2001 14:52:00 -0400 Timothy H. Keitt [EMAIL PROTECTED] wrote: What's next? A talking paper-clip pops up when I type xterm? :-) Remember `vigor'? Please, please, PLEASE don't give anyone any ideas... ;) Regards, Alex.
