Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Not necessarily. Just as you have tableout as an external command (built-in or not) in Monad, you can have a Perl module to print things in a tabular manner, expanding the column sizes as needed (based on HTML::Format::Table or somesuch) But I doubt that'd be as simple as things are now. Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would create incompatibilities with other Unices ... Those are indications that this won't be done. What kind of incompatibilities? Obviously, some Monad clone can be done with its entire toolchain (monad-ls, monad-tableout) ... Why not ls --monad?
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would Well, if you can do it with Perl without overhead, you can of course also do it without Perl without overhead. In that case the 'structured' support would be included in the utility itself.
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Well, if you can do it with Perl without overhead, you can of course also do it without Perl without overhead. In that case the 'structured' support would be included Not exactly. Don't get me wrong, object component technology is a great thing, standing just next to sliced bread in the list of great things, but (just like sliced bread) it does not cure cancer. When I do my example inside of Perl, I am supposing whatever objects or handles the Perl interpreter has stay inside the interpreter's process; when you do a pipe like monad-ls *.ab | monad-fields name, size | monad-tableout If you do a pipe like that. But the functionality you showed in Perl could also be done completely inside ls itself.
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: There are a lot of scripts today in production use that use the output of ls, ps, in a text-way. If you want to put another command, or another switch to ls, ok, but the fact that you *can* do it does not mean that you *should* do it. (see below) Didn't you say (or someone else) say the output of these commands was (only) for human consumption? Obviously, some Monad clone can be done with its entire toolchain (monad-ls, monad-tableout) ... Why not ls --monad? If you want to fork and maintain forever util-linux, I have nothing to say about that. Why fork and not just change the 'real' util-linux? ;- But I *will* leave you (I'm going home from work now) with Occam's razor: Entia non sunt multiplicanda praeter necessitem. (Things shouldn't be multiplied without necessity) IOW: if it's not broken, don't fix it. If only it wasn't broken. Netstat for example suffers from truncation.
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On 6/13/05, Adam Heath [EMAIL PROTECTED] wrote: That's a stupid argument. It's not that stupid. If other files shouldn't be there, the specs should explicitly state that.
Re: TODO for etch ?
Nikita V. Youshchenko wrote: Since I can't find such a list, I'll try to write (a beginning of) one. Shouldn't such a list be maintained in a Wiki or at least on a web page? 100+ different posts with a few entries don't make sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Structured (XML-like) input/output for shell apps?
Hi, Many shell apps/scripts output data in tables, for example ls -l, ps aux, top, netstat, etc. At the moment, most of these apps use fixed-width columns with a variable-width last-column. This results in (unnecessary) truncation, for example: Debian- 11918 0.0 0.1 4428 1464 ?Ss Jun05 0:00 /usr/sbin/exim4 -bd -q30m tcp 0 0 TC218-187-80-45.2:35589 bananensaft.inline.:www ESTABLISHEDproxy 153239 Also, because the output isn't structured (in way easily readable by machines), using the data in a script isn't (very) easy and is likely to break due to strict dependency on the syntax. Are there already any plans to solve these issues? I was thinking, using structured output (and maybe input) in an XML-like way would solve these and allow neat post-processing. It also separates data generation and presentation, which would be an advantage if the presentation needs to be changed. Any thoughts? Greetings, Olaf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
Adam Majer wrote: Olaf van der Spek wrote: woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. Will this be fixed for Woody? I thought the plan was to provide security support for Woody for another year? AFAIK, there is no security support for Woody kernels for some time now. Use kernel.org and compile your kernels for security sensitive machines. What's the reason for this lack of support? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
On 6/10/05, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Thu, Jun 09, 2005 at 02:58:21PM +0200, Olaf van der Spek wrote: ifconfig is in /sbin and only in root's path. But ifconfig is runnable and useful for normal users, so it'd be nice if it could be added to the path of normal users too. The problem here is that ifconfig must be in sbin by FHS and by history (would break too many scripts). So moving is not an option. I can however Copying? put a symlink in /bin, however I am not sure how other DDs think about it, as this will set a bad precedence. What's bad about a symlink?
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Marco d'Itri wrote: On Jun 10, Bernd Eckenfels [EMAIL PROTECTED] wrote: The problem here is that ifconfig must be in sbin by FHS and by history (would break too many scripts). So moving is not an option. I can however put a symlink in /bin, however I am not sure how other DDs think about it, as this will set a bad precedence. Don't bother. This could be applied to most other programs in /sbin too... Is that an argument? And anyway ifconfig is deprecated, everybody should always use iproute which *is* in /bin. But it's not installed by default, is it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: kernel security bug #307900
woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. Will this be fixed for Woody? I thought the plan was to provide security support for Woody for another year? -- Olaf van der Spek http://xccu.sf.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Don Armstrong wrote: On Tue, 07 Jun 2005, Olaf van der Spek wrote: Petri Latvala wrote: 1) divert the other? what's the use of another package version then That depends on system-wide vs per-user vs per-environment. If you want something done per-user/per-environment, you can always use dpkg-deb -x foo.deb .; or whatever to unpack the version you want to run manually. What if that package depends on a library that conflicts with a library you have installed but you also don't want to uninstall the already installed library? What if you do not want to lose the automatic management of apt-get? Alternatively, you can have a chroot with the strange versions that you want. Having multiple versions system wide when you haven't explicitly planned for multple versions is just asking for madness. It's Who said it should be possible without explicitly planning? especially insane when there are already reasonable methods for having multiple versions of things installed when that is a reasonable thing to do. (Think libfoo2, autoconf2.13 or similar.) Don Armstrong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Javier Fernández-Sanguino Peña wrote: Ok, so sarge has been released! We should all thank the Release Team for their hard work in putting this major release together. But... how about we start discussing about what major release goals we want to set for Etch? I'd like to see: The ability to easily run multiple independent copies of a daemon. At the moment you'd have to manually edit init scripts and conf scripts but it'd be nice to see this automatically supported. The ability to have multiple versions of a package installed at the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Running daemons without root access?
Hi, Is it possible for a user to ensure that a certain app is (always) started after system start (and stopped before shutdown) without using root access? If so, how? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Petri Latvala wrote: On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote: The ability to have multiple versions of a package installed at the same time. (Sorry Olaf, for getting this twice, my fingers work too fast) No, dear $DEITY. This feature is the major thing I hate about rpms. It's so easy to get wrong and install a package's new version side-by-side when you meant to update the old one. And don't say just be careful when there are people in the world who are not seasoned sysadmin veterans who audit every init.d script and whatnot. Making installing another version on the side as a --force-this-I-really-want-to-kick-myself option would not be as bad, but still as bad. This just won't work. Both versions supply $PATH/$FILE, and then what? Supporting side-by-side file installation isn't (that) simple. But that doesn't mean it wouldn't be useful. A mechanism would be needed to specify which version of an application should be run. Should this be system-wide, per-user, per-environment? 1) divert the other? what's the use of another package version then That depends on system-wide vs per-user vs per-environment. 2) install to another dir / another name of the file? Again, what's the use 3) this is a library so it only has a .so file with another soname so no name clashes. Hey, oops, different library soname already means a different package (this, I think, is the reason why rpm supports multiple versions) Does it? I thought minor updates didn't change soname? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Whereabouts of missing maintainer shiju@infovillage.net (Shiju p. Nair)
Hi, Does anyone know about the whereabouts of the mrtg maintainer, Shiju p. Nair? The package has bugs that are multiple years old and no recent uploads by the maintainer. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mrtg -- Olaf van der Spek http://xccu.sf.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and LGPL issues for LCC, or lack thereof
On Fri, 17 Dec 2004 12:26:01 -0800, Bruce Perens [EMAIL PROTECTED] wrote: The LGPL requires that the creator of a derivative work provide the object code for relinking, and not prohibit relinking and reverse engineering. It does not, however, require that creator to take other necessary steps to make relinking possible, such as providing a JPEG loading tool for the FLASH Is that really JPEG? Or JTAG?
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 08:27:20 +0100 (CET), Andreas Tille [EMAIL PROTECTED] wrote: On Wed, 15 Dec 2004, sean finney wrote: Yes, but I do not want to store the password *anywhere* - it could even be removed from debconf database because it makes no sense to store it in case the local maintainer changes the database password the value is absolutely useless in any config file or debconf database. Moreover it is even a security risk to store a password in an additional place. If it's only readable by root, how much of a risk is it really?
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 14:22:25 +0100 (CET), Andreas Tille [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004, Olaf van der Spek wrote: Yes, but I do not want to store the password *anywhere* - it could even be removed from debconf database because it makes no sense to store it in case the local maintainer changes the database password the value is absolutely useless in any config file or debconf database. Moreover it is even a security risk to store a password in an additional place. If it's only readable by root, how much of a risk is it really? Why should I use md5 passwords if they are stored in /etc/shadow which is only readable by root? Because system passwords aren't 'needed' by any applications to authenticate themselves to the system, while database passwords are. IMHO, it is a good idea not to store passwords in clear text if there is no reason to do so. If a temporary file at install time suffices I just prefer this over permanent storage. True, but how many database apps work without storing the password?
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 14:55:29 +0100 (CET), Andreas Tille [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004, Olaf van der Spek wrote: Because system passwords aren't 'needed' by any applications to authenticate themselves to the system, while database passwords are. No, they are not needed in the file system. They are needed inside the database and they are save there (assumed that the database server safe? Yes, but that's the other side of the authentication end. This is about the client, not the server. has no bugs). True, but how many database apps work without storing the password? At least these that do authentification directly against the database should not store their passwords in an extra file. This is the case for the application I'm currently working on (GnuMed) where the client does the authentication via user interaction. Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user.
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 15:34:35 +0100 (CET), Andreas Tille [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004, Olaf van der Spek wrote: Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user. Can you tell me any reason why I should store a clear text password in a text file for *my* application only because *other* applications would require this? Nope. But for apps that do require that, it makes sense to do it so you can avoid asking the password multiple times in the case of upgrades or other things.
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland [EMAIL PROTECTED] wrote: On 16-Dec-04, 08:04 (CST), Olaf van der Spek [EMAIL PROTECTED] wrote: Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user. But there is (or at least, should be) a specific user for that forum application, with the minimum of rights needed for that application (e.g. SELECT and UPDATE) in a single specific database. You're talking about a DB *admin* password. Ah, k. It makes less/no sense to store that password. But I wonder, is there no way to use the 'power' of the root account to do such DB administration without password then?
Re: Re: LCC and blobs
Goswin von Brederlow writes: Because the former works after installing the deb without the user ever doing anything about firmware. How do you even know there is firmware? Maybe it is all hardcoded into the chip? Without taking the hardware apart you can't know. Call me ignorant but what I don't see does not exist describes perfectly how it should be treated. In the later case the user actively has to download the firmware from somewhere and add it to his system. The extra files taints his filesystems and makes it less free. For example you can't just make a live CD out of it anymore because the non-free firmware file makes it not DFSG free. Not free in what sense? What can the user not do, that he can do if the firmware was already on the device?
