[CentOS] schily tools

Let me comment some questions in one single mail: > My basic requirement with what I'm doing is to use standard tools and > formats so that archives I write today can be readable in 10 years. Star becomes 30 in 4 months, any archive created since it's early beginning in summer 1982 can still be

Re: [CentOS] schily tools

Dennis Clarke wrote: > >> I don't think there is any such general consensus. Are you reading > >> something that favors Solaris/*bsd over GNU based systems? > > > > Schily tools (and in special star) implement support for Linux specific > > extensions. This is what you do not get from gtar at al

Re: [CentOS] schily tools

Les Mikesell wrote: > On Tue, Feb 7, 2012 at 9:26 AM, Joerg Schilling > wrote: > > > > When I implemented incremental restores for star in September 2004, I wrote > > a > > simple script for a incremental testcase and tested the deltas with > > ufsdump/ufsr

Re: [CentOS] schily tools

Les Mikesell wrote: > >> My testcase for star was moving a subdirectory of what my backup runs > >> covered onto a mounted volume.  Star failed and I stopped testing it > >> any further. > > > > So you tried to do something that cannot work for a filesystem oriented > > program. > > It does work

Re: [CentOS] schily tools

Les Mikesell wrote: > > In general, this does not work with gtar. You are exactly in the area that > > caused my conclusion that gtar is not useful at all for incremental > > backups. > > > > > No, a general file-oriented case would handle FAT and NTFS filesystems, and > continue to work even if

Re: [CentOS] schily tools

Les Mikesell wrote: > > Well, I verified that gtar fails with even a simple case and I did not see > > any > > problem with star since 6 years even with thousands of incremental > > restores. > > So I am not sure what you are talkin about. > > > > Gtar doesn't fail, it just requires some extra st

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Pete Geenhuizen wrote: > Initially Bourne was used because it was typically a static binary, > because the boot process didn't have access to any shared libraries. > When that changed it became a bit of a moot point, and you started to > see other interpreters being used. When dynamic linkin

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > On Fri, Apr 24, 2015 at 08:32:45AM -0400, Scott Robbins wrote: > > Wasn't Solaris, which for awhile at least, was probably the most popular > > Unix, using ksh by default? > > Solaris /bin/sh was a real real dumb version of the bourne shell. > Solaris included /bin/ksh as

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > Bash was bigger than ksh in the non-commercial Unix world because of ksh88 > licensing problems. Back in 1998 I wanted to teach a ksh scripting > course to my local LUG, but AT&T (David Korn himsef!) told me I couldn't > give people copies of the shell to take home. AFAI

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > Solaris /bin/sh was a real real dumb version of the bourne shell. If you like to create portable scripts, you can do this by downloading: https://sourceforge.net/projects/schilytools/files/ and using "osh" as a reference implementation. Osh is the old SunOS Bour

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > > AFAIR, ksh was OSS (but not using an OSI approved license) since 1997. > > Since > > In 1998 each user had to sign a license; you couldn't give away copies > to other people. > >Date: Wed, 20 May 1998 14:09:30 -0400 (EDT) >From: David Korn > >If you are go

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

wrote: > Fascinating. As I'd been in Sun OS, and started doing admin work when it > became Solaris, I'd missed that bit. A question: did the license agreement > include payment, or was it just restrictive on distribution? Everything other than ksh93 is closed source. The POSIX shell used by vari

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Gordon Messmer wrote: > I'm reasonably certain that a script with no shebang will run with > /bin/sh. I interpret your statement to mean that if a user is using ksh > and enters the path to such a script, it would also run in ksh. That > would only be true if you "sourced" the script from yo

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

John R Pierce wrote: > oh fun, just did some tests (using c6.latest). if you're in bash, > ./script (sans shebang) runs it in bash. if you're in dash or csh, > ./script runs it in sh.if you're in ksh, it runs it in ksh. See my other mail. The scripts (unless marked) are run by the curr

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Valeri Galtsev wrote: > > > #!/bin/sh > > readlink /proc/$$/file > > > ( note that that "file" is because I'm using FreeBSD /proc, for Linux you > may need to replace the line with something like: > > readlink /proc/$$/exe And on a platform that implements a correct procfs-2, y

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > On Fri, Apr 24, 2015 at 10:38:25AM -0400, m.r...@5-cent.us wrote: > > Fascinating. As I'd been in Sun OS, and started doing admin work when it > > became Solaris, I'd missed that bit. A question: did the license agreement > > include payment, or was it just restrictive on

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Stephen Harris wrote: > On Fri, Apr 24, 2015 at 09:47:24AM -0700, Gordon Messmer wrote: > > On 04/24/2015 03:57 AM, Pete Geenhuizen wrote: > > >if you leave it out the script will run in whatever environment it > > >currently is in. > > > > I'm reasonably certain that a script with no shebang wi

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

wrote: > Ah. I don't remember if I was using csh, or ksh, and didn't realize about > bash. I *think* I vaguely remember that sh seemed to be more capable than > I remembered. If you like to check what the Bourne Shell did support in the late 1980s, I recommend you to fetch recent Schily tools f

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Fri, Apr 24, 2015 at 3:04 PM, wrote: > > > > > My first RH was 5, late nineties. First time I looked at linux and > > installed, it was '95, and slack. (We'll ignore the Coherent that I > > installed on my beloved 286 in the late 80's). > > > > You mean you missed all

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Warren Young wrote: > On Apr 27, 2015, at 4:38 AM, Joerg Schilling > wrote: > > > > This is the SVr4 Bourne Shell, so you need to take into account what has > > been > > added with Svr4: > > Is there any difference between your osh and t

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 10:07 AM, Joerg Schilling > wrote: > > > > > I would be interested to understand why Heirloom seems to so well known and > > my > > portability attempts seem to be widely unknown. > > > > Not sure why

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Warren Young wrote: > > The schily tools act as a container to publish the current code state. > > There is > > no such maintained web page. > > I was referring to the summary on the SourceForge page, where you just list > the contents of the package without explaining why one would want to do

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 10:46 AM, Joerg Schilling > wrote: > > > > > And the problem is the GPL. I recommend you to work on making all GPL code > > freely combinable with other OSS. > > Of course the problem it the GPL. Glad you recognize

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 11:16 AM, Joerg Schilling > wrote: > > > > > You should read the GPL and get help to understand it. The GPL does not > > forbid > > this linking. In contrary, the GPOL allows any GPLd program to be linked > >

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Warren Young wrote: > Yes, I realize that osh is closer to the original Bourne shell. My point is > that you can?t expect people to just know, without having been told, why they > want bsh, or osh, bosh, or smake, or? > > Most of these tools compete with tools that are already in CentOS. If y

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 11:41 AM, Warren Young wrote: > > > > >>> 4. CDDL annoys a lot of people. > >> > >> The CDDL does not annoy people, this is just a fairy tale from some OSS > >> enemies. > > > > The following irritates me, I am a ?people,? and I am not an OSS enemy:

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 12:10 PM, Joerg Schilling > wrote: > > > > > If you combine ZFS and Linux, you create a permitted "collective work" and > > the > > GPL cannot extend it's rules to the CDDLd separate and independend

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 11:57 AM, Joerg Schilling > wrote: > > >> > >> You can't distribute GPLd programs unless 'the work as a whole' is > >> covered by the GPL. There can't be a distinction between binary and >

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 1:02 PM, Joerg Schilling > wrote: > > > > > The GPL makes claims that are in conflict with the law because these claims > > are > > not amongst what the list in the law permits and that are thus void. > > Th

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 1:46 PM, Always Learning wrote: > > > >> Yes, in english, 'work as a whole' does mean complete. And the normal > >> interpretation is that it covers everything linked into the same > >> process at runtime unless there is an alternate interface-compa

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

wrote: > First, I was not aware that the US had declared any part of the GPL null Just ask US lawyers. one of them sits on the other side of the corridor of my office, another is the well known Lawrence Rosen. For Europe check the reasoning of the cases from Harald Welte. One of them is v

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 2:28 PM, Joerg Schilling > wrote: > > > > > >> > "as a whole" means generally BUT allowing for exceptions. > >> > >> OK, great. That clears it up then. > > > > Maybe thi

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 2:13 PM, Joerg Schilling > wrote: > > > >> The GPL is all that gives you permission to distribute. If it is > >> void then you have no permission at all to distribute any covered > >> code. > >

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 4:04 PM, Joerg Schilling > wrote: > >>> > >> Yes, if you mean what is described here as 'the original 4-clause' > >> license, or BSD-old: > >> http://en.wikipedia.org/wiki/BSD_licenses > &

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 4:19 PM, Joerg Schilling > wrote: > > > > > >> > Do you like to discuss things or do you like to throw smoke grenades? > >> > >> The only thing I'd like to discuss is your reason for not addin

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 4:34 PM, Joerg Schilling > wrote: > > >> > >> No, you posted some ranting misconceptions about why you don't see a > >> need for it. But if you actually believed any of that yourself, then > >>

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Gordon Messmer wrote: > On 04/27/2015 12:28 PM, Joerg Schilling wrote: > > Up to now, nobody could explain me how a mixture of GPL and BSD can be > > legal as > > this would require (when following the GPL) to relicense the BSD code under > > GPL > > in ord

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Les Mikesell wrote: > On Mon, Apr 27, 2015 at 2:13 PM, Joerg Schilling > wrote: > > Les Mikesell wrote: > > > > There was no court case, but VERITAS published a modifed version of gtar > > where > > additional code was added by binary only libraries from V

Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts

Joerg Schilling wrote: > > If you did read the CDDL, you did of course know that the CDDL places "work > limits" at file limits and that the CDDL does not try to impose any > restriction on sources that are not in a file marked as CDDLd. So the CDDL of > cou

Re: [CentOS] Native ZFS on Linux

Chuck Munro wrote: > I have a question that has been puzzling me for some time ... what is > the reason RedHat chose to go with btrfs rather than working with the > ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, political, etc? There is no licensing issue, but there are OpenSource

Re: [CentOS] Native ZFS on Linux

Ray Van Dolson wrote: > Licensing, IMO. Redistributing ZoL is likely fraught with a bit of > legal peril, or at best, technical peril if you want to try and skirt > the legal edges. Oracle is notoriously litigious and having a target > liked Red Hat would probably have their lawyers whetting th

Re: [CentOS] Native ZFS on Linux

Chris Adams wrote: > Once upon a time, Chuck Munro said: > > I have a question that has been puzzling me for some time ... what > > is the reason RedHat chose to go with btrfs rather than working with > > the ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, > > political, etc? > > Lic

Re: [CentOS] Native ZFS on Linux

Johnny Hughes wrote: > On 06/01/2015 06:42 AM, Joerg Schilling wrote: > > Chuck Munro wrote: > > > >> I have a question that has been puzzling me for some time ... what is > >> the reason RedHat chose to go with btrfs rather than working with the > >>

Re: [CentOS] Native ZFS on Linux

Johnny Hughes wrote: > > Could you explain why you did not reply to the mail fropm Chris Adams who > > introduced a false claim about so called "opinions of a number of lawyers"? > > > > As mentioned: lawyers explain why there is no problem with ZFS integration. > > If > > you don't like usel

Re: [CentOS] Native ZFS on Linux

Andrew Holway wrote: > > > > > > OK, plese note that I am not willing to tolerate anti-oss claims and will > > continue to correct similar false claims. If you don't like those > > discussions > > at all, you should try to avoid false claims and the need for corrections. > > > > If I were RedHat,

Re: [CentOS] Native ZFS on Linux

Chris Adams wrote: > Once upon a time, Joerg Schilling said: > > Note that it is without doubt that ZFS was not derived from the Linux > > kernel > > and thus cannot be a derived work. > > All that matters for CentOS is: > > 1: Red Hat doesn't

Re: [CentOS] trying to recover an audio CD...

Fred Smith wrote: > I'm trying to recover data from an audio cd. it is a recording of a live > session, made on a professional cd recorder, on the fly. Do you have any working CD from that drive? If yes, you could call: cdrecord -minfo to get the state and to find out whether it write

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > Copying a CD with k3b is no problem, except I want to include on my copy > the cbbd data (from freedb.org). I've configured k3b's cddb section > according to instructions at > and read every article google could find about "k3b cddb freedb

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > Thanks for your reply. As late as November 2012 I always used the CLI > for copying *data* CDs, using cdrecord and readcd. But though I read > and studied manpages and scads of documentation, I never had any luck > cloning a music CD using these commands. So I'd doubt I could f

Re: [CentOS] k3b -> cddb doesn't work

on mkisofs -version If you are using original software, you will see someting like: Cdrecord-ProDVD-ProBD-Clone 3.01a16 (i386-pc-solaris2.11) Copyright (C) 1995-2013 Joerg Schilling If one of the commends does not print a message like this, you should be careful. BTW: cdrtools-2.01 is from Sep

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > > There is nothing like: cdrtools-2.01-10.7.el5 > > [cdrtools-2.01-10.7.el5 ist einmalig???] > > You're saying this is the preferred package, yes? and it will have the > functionality needed? If yes and yes, where does one get that package? > > Note that my rpm command output abov

Re: [CentOS] k3b -> cddb doesn't work

Les Mikesell wrote: > On Mon, Aug 19, 2013 at 3:23 PM, Joerg Schilling > wrote: > > > > >> > Would you like to run a Linux kernel from 2004 today? > > Has the CD format changed since 2004? This is why you are happy with buggy software from 2004 shipped by redha

Re: [CentOS] k3b -> cddb doesn't work

Les Mikesell wrote: > On Mon, Aug 19, 2013 at 3:54 PM, Joerg Schilling > wrote: > > >> >> > Would you like to run a Linux kernel from 2004 today? > >> > >> Has the CD format changed since 2004? > > > > This is why you are happy with buggy

Re: [CentOS] k3b -> cddb doesn't work

Les Mikesell wrote: > On Mon, Aug 19, 2013 at 4:32 PM, Reindl Harald wrote: > > > > maybe you do not know who Joerg Schilling is > > > > he is the one person claiming he is the only one writing a > > working cd-burning software on earth and his fights against

Re: [CentOS] k3b -> cddb doesn't work

Keith Keller wrote: > On 2013-08-19, Joerg Schilling wrote: > > > > Redhat had more than 100 bugs filed against the "cdrtools" version they > > ship. > > All these bugs could be avoided by upgrading to a recent original version. > > Redhat clos

Re: [CentOS] k3b -> cddb doesn't work

Reindl Harald wrote: > > Please do not write false claims! > > says the one on his fight against Linux and GNU since years Do you like to prove that you cannot stay with the truth? You also wrote a false claim. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Be

Re: [CentOS] k3b -> cddb doesn't work

Keith Keller wrote: > On 2013-08-19, Joerg Schilling wrote: > > If you know about problems, send evidence > > The problem seems to be that you would rather rant about distributions' > licensing and packaging decisions than help the OP. It seems like he > would be p

Re: [CentOS] k3b -> cddb doesn't work

Alexander Dalloz wrote: > If there is a problem with a software package provided by CentOS (base / > updates), then it can only be solved if a ticket and case is opened with > the upstream dsitribution as CentOS just rebuilds what Red Hat offers in > their RHEL package set. There have been more

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > On 08/20/2013 04:57 AM Joerg Schilling wrote: > > I told him that if his distro does not do it's homework, he needs to compile > > himself. The URL is in my signature and in contrary to many autoconf based > > sources, my software compiles out if the

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > On 08/20/2013 04:57 AM Joerg Schilling wrote: > > As mentioned before: I deliver something that compiles and runs out of the > > box > > on aprox. 30 OS platforms (not counting the CPU and OS-version variants). > > It is not my duty to deliver binary pa

Re: [CentOS] k3b -> cddb doesn't work

ken wrote: > Keith, > > I was wondering if anyone would notice. Thanks. what problem do you have? You have been pointed to compile and install recent original software. Did you do that? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-b

Re: [CentOS] k3b -> cddb doesn't work

John R Pierce wrote: > On 8/20/2013 1:47 AM, Joerg Schilling wrote: > > Reindl Harald wrote: > > > >>> > >Please do not write false claims! > >> > > >> >says the one on his fight against Linux and GNU since years > > Do you like to

Re: [CentOS] k3b -> cddb doesn't work... cdfs?

ken wrote: > Then too of course there'd need to be a way to ascertain if there was > any substantial differences in the outputs. There's some code out there > since kernel version 2.2 called cdfs which doesn't seem to be on my > (v.5.9) system. This allows mounting an audio CD or a disk imag

Re: [CentOS] k3b -> cddb doesn't work

Marko Vojinovic wrote: > So if you want your software to be used by the majority of Linux > distros without license-related hiccups, you can always just re-license > it to GPL and everyone will be happy. You seem to be missinformed: When cdrtools have been 100% GPL, it was attacked by Debian _b

Re: [CentOS] k3b -> cddb doesn't work

wwp wrote: > > You seem to be missinformed: When cdrtools have been 100% GPL, it was > > attacked > > by Debian _because_ it was 100% GPL and because the GPL is a frequently > > missinterpreted license. > > > > ...so I decided to choose a less problematic license than the GPL. > > > > > sof

Re: [CentOS] k3b -> cddb doesn't work

Les Mikesell wrote: > > You seem to be missinformed: When cdrtools have been 100% GPL, it was > > attacked > > by Debian _because_ it was 100% GPL and because the GPL is a frequently > > missinterpreted license. > > > > ...so I decided to choose a less problematic license than the GPL. > > The G

Re: [CentOS] k3b -> cddb doesn't work

Reindl Harald wrote: > > > Am 21.08.2013 18:42, schrieb Joerg Schilling: > > The GPL is discouraged by Debian... > > You should think about why you did not help to defend the GPL in 2005 > > *bruhaha* half of the debian distribution including the > kernel *is*

Re: [CentOS] k3b -> cddb doesn't work

Les Mikesell wrote: > > I was attacked by Debian _for_ using the GPL and it seems that you did not > > help > > at that time. I will not use a license again after I was attacked _because_ > > I > > used this specific license. > > Umm, have they dropped perl? It seems that Larry was in a differ

Re: [CentOS] k3b -> cddb doesn't work

John R Pierce wrote: > On 8/21/2013 4:15 AM, Joerg Schilling wrote: > > Why do you believe this? > > Do you believe that centos delivers inconstsistent libraries? > > if you replace the stuff thats under RPM package management with code > you self compile and simply cop

Re: [CentOS] k3b -> cddb doesn't work... cdfs?

Keith Keller wrote: > It's worth investigating. If k3b does indeed compile against cdrtools > libraries then you may be out of luck. Writing optical media is a task that needs special privileges. Calling e.g. cdrecord as a separate program gives prilviege separation and prevents you from bein

Re: [CentOS] k3b -> cddb doesn't work

Lamar Owen wrote: > Whee. Here we go again. > > There are properly built and packaged RPMs for Jorg's (sorry, android > keyboard I'm using doesn't have the proper marking for the o there) cdrtools, > for EL6. I'm using them on a few installs where wodim just simply does the > wrong thing and

Re: [CentOS] k3b -> cddb doesn't work

Marko Vojinovic wrote: > But as far as my memory serves, the issue was not that cdrtools were > GPL, but that the toolchain for building cdrtools source (was that > called "schilly-tools"?) was non-GPL. And the dispute was about the > interpretation of the GPL --- does it require you to license t

Re: [CentOS] k3b -> cddb doesn't work

Marko Vojinovic wrote: > While Joerg certainly knows better... I think the issue was that > cdrtools could be built only with the schilly-toolchain (or whatever > the exact name), and that was *not* GPL. So according to some > interpretations of the GPL, while cdrtools was claiming to be > GPL-li

Re: [CentOS] k3b -> cddb doesn't work

John R Pierce wrote: > On 8/21/2013 10:05 AM, Joerg Schilling wrote: > > But Debian attacked cdrtools for using the GPL when it has been 100% GPL. > > I find this an extremely odd assertation. I am not nor ever have been a > Debian user, but I know Debian is based on the Linu

Re: [CentOS] k3b -> cddb doesn't work... cdfs?

ken wrote: > > This cdfs does not deliver better quality than from using the "read audio" > > ioctls from the kernel. Cdda2wav gives much better quylity in case of > > non-optiimal media and cdda2wav gives you the meta data you need to make a > > decent copy. You don't get that from cdfs. > > > >

Re: [CentOS] iso burn

Rejy M Cyriac wrote: > If you can find a Linux box, get to command line > > sha256sum > > compare output with provided hash > > if they match, burn the dvd with the following command > > cdrecord -v -sao ... make sure not to use the defective "fork" from Debian that is unmaintained since May

Re: [CentOS] pstack

Eero Volotinen wrote: > 2014-07-15 21:55 GMT+03:00 Clovis Tristao : > > > Hi, > > > > How to install pstack in CentOS 6.5? Which repository or package it is > > part? > > Thanks a lot, > > > > > > gdb pstack is a Solaris command from the p-tools

Re: [CentOS] pstack

Reindl Harald wrote: > > pstack is a Solaris command from the p-tools group. It works nicely even > > when > > the binary is stripped. You cannot replace it by something as limited as > > gdb > > that needs a binary compiled with -g in order to print a useful stacktrace > > with function par

Re: [CentOS] libre office

Hakan Koseoglu wrote: > On 11 July 2012 13:06, Steve Clark wrote: > > I think it is more the fact the Oracle seems to be two faced in their > > dealings with foss as > > opposed to IBM. > So correct. Way back in 2001, in London I was there when IBM clearly > stated they are going to spend one b

Re: [CentOS] compare zfs xfs and jfs o

Nux! wrote: > ZFS on linux is still highly experimental and has received close to no > testing. > If you are in mood for experiments EL6.3 includes BTRFS as technology > preview for 64bit machines. Give it a try and let us know how it goes. Using BTRFS now is like using ZFS in 2005. ZFS is ad

Re: [CentOS] compare zfs xfs and jfs o

Reindl Harald wrote: > face the truth! > > there is no ZFS for linux > there will never be > > that you do not like GPL, Linux etc. at all will > not change anything, not now and not in the future What do you expect from spreading lies against me? You are off topic, so please stop this nonsense

Re: [CentOS] compare zfs xfs and jfs o

Karanbir Singh wrote: > On 08/04/2012 05:06 PM, Joerg Schilling wrote: > > Using BTRFS now is like using ZFS in 2005. > > ZFS is adult now, BTRFS is not > > Can you quantify this in an impartial format as relevant to CentOS ? At > the moment your statement is just a rant

Re: [CentOS] compare zfs xfs and jfs o

Nux! wrote: > On 04.08.2012 20:32, joerg.schill...@fokus.fraunhofer.de wrote: > > Karanbir Singh wrote: > > > >> On 08/04/2012 05:06 PM, Joerg Schilling wrote: > >> > Using BTRFS now is like using ZFS in 2005. > >> > ZFS is adult now, BTRFS is not

Re: [CentOS] compare zfs xfs and jfs o

John R Pierce wrote: > > Theres one big issue with NFS that requires a workaround... XFS requires > 64 bit inodes on a large file system ('inode64'), and by default, NFS > wants to use the inode as the unique ID for the export, this doesn't > work as that unique ID has to be 32 bits, so you ha

Re: [CentOS] compare zfs xfs and jfs o

Fernando Cassia wrote: > On Sat, Aug 4, 2012 at 4:32 PM, Joerg Schilling > wrote: > > What is the age of BTRFS? > > BTRFS presentation, mid-2007 > https://oss.oracle.com/projects/btrfs/dist/documentation/btrfs-ukuug.pdf > > That makes it 6 years in development. N

Re: [CentOS] compare zfs xfs and jfs o

Fernando Cassia wrote: > > "Possibly some. Samba has been asking for streams support for a while, > and if reiser4 leads the way in an implementation that does not break > unix file semantics, jfs (and possibly other file systems) may follow." Microsoft tried to advertize their "stream" concept

Re: [CentOS] compare zfs xfs and jfs o

John R Pierce wrote: > integrated so growing a file system is a one step process that takes > care of both the LVM and JFS online in a single command. > > # chfs -size=+10G /home > > hard to be much simpler than that! > > ZFS is simpler than that ;-) If you enabled the zpool autoexpand fea

Re: [CentOS] compare zfs xfs and jfs o

John R Pierce wrote: > On 08/05/12 3:06 AM, Joerg Schilling wrote: > > Your claim is aproximately correct for NFSv2 (1988) but wrong for other NFS > > versions. > > The server was using NFS V3/V4 in CentOS 6.2 earlier this year, and > various clients, including Solaris

Re: [CentOS] compare zfs xfs and jfs o

Karanbir Singh wrote: > On 08/04/2012 08:32 PM, Joerg Schilling wrote: > > I would not call it a rant but a food for thought. > > agreed! > > > ZFS was distributed to the public after it turned 4. > > ZFS is now in public use since more than 7 years. > > but

Re: [CentOS] compare zfs xfs and jfs o

John R Pierce wrote: > > Again: > > > > - NFSv2 (from 1988) allows 32 Bytes for a NFS file handle > > > > - NFSv3 (from 1990) allows 64 Bytes for a NFS file handle > > > > - NFSv4 (from 2004) has no hard limit here > > > > With the 32 byte file handle, there are still 12 bytes (including a

Re: [CentOS] compare zfs xfs and jfs o

Pasi Kärkkäinen wrote: > > The ZFS code base is stable, the problem is the VFS interface in Linux and > > that > > applies to all filesystems > > > > Hello, > > Care to explain what's the problem in Linux VFS layer ? The VFS layer was introduced in 1980 by Bill Joy when he started the UFS

Re: [CentOS] compare zfs xfs and jfs o

Gordon Messmer wrote: > On 08/04/2012 07:01 AM, ashkab rahmani wrote: > > i want to share it on network via nfs. > > which file system is better for it? > > I have a hard time imagining that you'd get useful information from > cross-posting this to the FreeBSD and CentOS lists. Their > impleme

Re: [CentOS] compare zfs xfs and jfs o

Dennis Clarke wrote: > > A little data never hurts. Even if the numbers mean little. > > test 1 - Debian Linux 6.0.5 on x86_64 Given the fact, that you did not run star -no-fifo, you compare an insecure implementation (gtar never calls fsync(2)) with a secure by default implementation (star).

Re: [CentOS] compare zfs xfs and jfs o

Dennis Clarke wrote: > > Given the fact, that you did not run star -no-fifo, you compare an > > insecure > > implementation (gtar never calls fsync(2)) with a secure by default > > implementation (star). > > Comparison numbers are only valid of the tests run are the same. > > So here is the U

Re: [CentOS] compare zfs xfs and jfs o

Dennis Clarke wrote: > > > > Comparison numbers are only valid of the tests run are the same. > > > > > > So here is the UFS test once more without the compression and > > > with -no-fifo : > > > > > > jupiter-sparc-SunOS5.10 # ptime /opt/schily/bin/star -x -xdir -xdot > > -no-fifo -U file=../

Re: [CentOS] vi defaults in 6.x

Gordon Messmer wrote: > On 08/16/2012 04:55 PM, SilverTip257 wrote: > > vi is generally a symlink to vim these days. > > Actually, it's a shell alias. And then, only if "vim" is installed, > which it isn't in some configurations. IIRC, desktop systems have him > by default, but server install

Re: [CentOS] vi defaults in 6.x

Reindl Harald wrote: > > > Am 20.08.2012 13:07, schrieb Joerg Schilling: > > Gordon Messmer wrote: > > > >> On 08/16/2012 04:55 PM, SilverTip257 wrote: > >>> vi is generally a symlink to vim these days. > >> > >> Actually, it's

Re: [CentOS] vi defaults in 6.x

William Hooper wrote: > On Mon, Aug 20, 2012 at 7:19 AM, Joerg Schilling > wrote: > > > > Reindl Harald wrote: > > > you are aware that you are posting to the CENTOS-list? > > > > Of course > > > > > the topic is about "vi default in

Re: [CentOS] vi defaults in 6.x

Reindl Harald wrote: > > This just verifies that you don't have a vi > > boah how often should we explain it until you > understand taht on CENTOS there is NO vi package > > there is only VIM Nice to see, that you finally realized it too. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (

Re: [CentOS] vi defaults in 6.x

wrote: > This just verifies that you're playing word games. If you want vi that's > not vim, may I ask which *version* of vi you would consider to be vi - one > from, say, Sun OS 3? Or from the Irix that ran on our Indigo in the > early/mid-nineties? or one from Tru-64 in the late nineties? or we

  1   2   >