Re: [gentoo-user] Re: Is gnome becoming obligatory?
On Friday, December 15, 2017 2:25:29 AM CET Marc Joliet wrote: > Am Freitag, 15. Dezember 2017, 02:12:08 CET schrieb R0b0t1: > > On Thu, Dec 14, 2017 at 6:35 PM, Peter Humphrey > > wrote: > > > On Thursday, 14 December 2017 16:03:19 GMT Ian Zimmerman wrote: > > >> I'll try not to feed this monster thread any longer, I promise. > > > > > > Ah, but will you succeed?:) > > > > List, in my weakness, I felt compelled to make the 77th post, as seven > > is a holy number indeed. 7 doesn't have any holes, so it can't be holy... > > Cheers, > > > > R0b0t1 > > Hah, and *right* before I sent my own monster mail, too! So it seems I'm > poor number 78... (and 79 now, too, I guess) 8 and 9 do have holes... you made a holy number :)
Re: [gentoo-user] Re: Is gnome becoming obligatory?
On Friday, December 15, 2017 4:05:41 AM CET Kai Krakow wrote: > Am Thu, 14 Dec 2017 08:54:59 +0100 schrieb J. Roeleveld: > >> Some historical correctnesses about Canek: > >> > >> - He has been here for years - He has contributed here for years - He > >> supports systemd and has offered more help and explanation about > >> systemd to it's users on this list than any other single person, bar > >> none - He has never, not once, slagged off SysV Init, OpenRC or any > >> other init system, ot the creators or the users - He has never posted > >> rude or inflamatory comments about anyone arguing against him - He has > >> never resorted to ad-hominem and never posted any knee jerk opinions > >> about any other poster wrt their stance on init systems > > > > +1 I may not agree with Canek on all things: > > - I do dislike systemd, especially on Centos where disabling services > > doesn't always work past a reboot > > Well, I think you're falling the pitfall expecting "disable" makes a unit > unstartable. That is not the case. Disabling a unit only removes it from > the list of units starting on your own intent. It can still be pulled it > as a (required) dependency. Makes sense > If you really want it never being started, you need to mask the unit. > It's then no longer visible to the dependency resolver as if it were not > installed at all. This is not listed anywhere easy to find in google. > The verbs disable and enable are arguably a bit misleading, while the > verbs mask and unmask are not really obvious. But if you think of it, it > actually makes sense. Actually, it doesn't. But lets not discuss naming conventions. A lot of tools have ones where I fail to see the logic. It's a shame that option is not easily findable. And not knowing it exists, means checking man-pages and googling for them doesn't happen either. > If you "rc-update del" a service, you wouldn't > prevent it from being started neither, just because OpenRC is still able > to pull it in as a dependency. True, except with OpenRC, all the config is located together. Not mostly in / usr/ somewhere with overrides in /etc/... I dislike all tools that split their config in this way. > So it's actually not an argument for why you'd dislike systemd. ;-) The lack of easily findable documentation on how to stop a service from starting, even as a dependency, is a reason. (not singularly against systemd). Systemd, however, has an alternative. -- Joost
[gentoo-user] Re: Is gnome becoming obligatory?
Am Thu, 14 Dec 2017 08:54:59 +0100 schrieb J. Roeleveld: >> Some historical correctnesses about Canek: >> >> - He has been here for years - He has contributed here for years - He >> supports systemd and has offered more help and explanation about >> systemd to it's users on this list than any other single person, bar >> none - He has never, not once, slagged off SysV Init, OpenRC or any >> other init system, ot the creators or the users - He has never posted >> rude or inflamatory comments about anyone arguing against him - He has >> never resorted to ad-hominem and never posted any knee jerk opinions >> about any other poster wrt their stance on init systems > > +1 I may not agree with Canek on all things: > - I do dislike systemd, especially on Centos where disabling services > doesn't always work past a reboot Well, I think you're falling the pitfall expecting "disable" makes a unit unstartable. That is not the case. Disabling a unit only removes it from the list of units starting on your own intent. It can still be pulled it as a (required) dependency. If you really want it never being started, you need to mask the unit. It's then no longer visible to the dependency resolver as if it were not installed at all. The verbs disable and enable are arguably a bit misleading, while the verbs mask and unmask are not really obvious. But if you think of it, it actually makes sense. If you "rc-update del" a service, you wouldn't prevent it from being started neither, just because OpenRC is still able to pull it in as a dependency. So it's actually not an argument for why you'd dislike systemd. ;-) -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: Is gnome becoming obligatory?
Am Freitag, 15. Dezember 2017, 02:12:08 CET schrieb R0b0t1: > On Thu, Dec 14, 2017 at 6:35 PM, Peter Humphrey wrote: > > On Thursday, 14 December 2017 16:03:19 GMT Ian Zimmerman wrote: > >> I'll try not to feed this monster thread any longer, I promise. > > > > Ah, but will you succeed?:) > > List, in my weakness, I felt compelled to make the 77th post, as seven > is a holy number indeed. > > Cheers, > R0b0t1 Hah, and *right* before I sent my own monster mail, too! So it seems I'm poor number 78... (and 79 now, too, I guess) Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Is gnome becoming obligatory?
Am Donnerstag, 14. Dezember 2017, 16:52:59 CET schrieb Ian Zimmerman: > On 2017-12-14 11:57, Marc Joliet wrote: > > I could list specific features of systemd that I like and make use of > > (such as socket activation, autofs integration, user units, nspawn, or > > the journal), but thinking about it, it's a "more than the sum of its > > parts" kind of deal. Managing a system with systemd is just overall > > pleasant for me. > > I am probably not the only one who would still dearly like such a > detailed list, from someone I don't see as biased to start with. I > understand this is a drain on your time, so I'll understand if you > decline. I don't mind per se, but whether I'm inclined to do so depends on the attitude of who's asking. If I'm asked politely the way you did then I don't mind at all, in fact it can be quite pleasant :) (and it also serves to refresh my memory). Before I begin, to avoid making this sound all rainbows and glitter, I will mention one thing that annoys me about systemd: regressions. None of them have been horrible, and I think I was only ever hit by 2 or 3 over the course of by now several years, but they're still annoying. The one I'm currently waiting on is the systemd-run bug when both cgroup V1 and V2 trees are mounted. I could work around it (by deactivating cgroup V2 support or some such), but I don't miss systemd-run so much that I could be bothered to. Regardless, I wish upstream would handle them better. Also, this is just my perspective as a hobbyist (although I've used systemd in a professional context). I could recommend some presentations that provide a different perspective (e.g., by a company that uses systemd in IP cameras, where the cgroups based resource management features of systemd came in very handy). There's also a presentation by Klaus Knopper of Knoppix fame that is overall more negative, but still mostly fair -- though IMHO not completely -- and as I recall one of the better criticisms I've seen. His perspective is that of somebody trying to provide a Linux OS for computers destined for poorer countries, where he has to deal with less capable hardware (i.e., no SSDs, booting from CD/DVD). (Also also, sorry in advance for the wall of text, this kind of, uh, spun out of control. Sorry also to Ian and Peter for continuing to feed the monster thread ;-) .) Alright, so here's what I can think of now, starting off with what I listed above and then continuing with anything else I can remember. This includes more or less verbose descriptions of what the features bring to the table, including specifically how they help *me*. 1.) Socket activation sounds like a detail, but it has several positive side effects. It can make dependency specifications unnecessary, thus making unit files simpler, and it increases the number of services that can start in parallel. It also enables on-demand services á la (x)inetd, only generalised for all system services (I use SSH this way by only enabling the socket unit). You can't use systemd without using this feature, something's bound to use it. This is the main reason systemd can boot so fast (on flash storage, at least). That may not be important to some people, but it is to me (and embedded projects). 2.) Autofs integration via automount units allows dynamic mounting (and optionally unmounting) of file systems, which I use on my desktop to asynchronously mount my data dump (a 2x1TB btrfs RAID1). To be honest, I mostly did this to speed up boot time (I think I mention timings in the Email thread I referenced), but it also makes boot-up finish independent of mount failures. On my home server (an old Mac Mini) I use it for a USB drive for the same reasons (although boot time isn't so important there). [ Just to be clear: autofs is a Linux kernel feature, systemd just exposes it in an easy to use way. That is, BTW, a theme with systemd. ] 3.) Personally I find user units (systemd units that run as your user) super practical. There is a system location for them, but you can place your own in your home directory under ~/.config/systemd/user/ and have them start when you log in. If you configure your user session -- which is basically a systemd instance running as your user -- as "lingering", you can have persistent user services that run as long as your computer is on (strictly speaking, for as long as your user session is active). For example, my desktop looks like this: > % systemctl --user list-units -t service -t timer -a > UNIT LOAD ACTIVE SUB DESCRIPTION > > ctags.service loadedinactive deadRegenerate ctags files > > gpg-agent.service loadedactive running Start gpg-agent (with > SSH support) > mpd.service loadedactive running Music Player Daemon >
Re: [gentoo-user] Re: Is gnome becoming obligatory?
On Thu, Dec 14, 2017 at 6:35 PM, Peter Humphrey wrote: > On Thursday, 14 December 2017 16:03:19 GMT Ian Zimmerman wrote: > >> I'll try not to feed this monster thread any longer, I promise. > > Ah, but will you succeed?:) > List, in my weakness, I felt compelled to make the 77th post, as seven is a holy number indeed. Cheers, R0b0t1
Re: [gentoo-user] Re: Is gnome becoming obligatory?
On Thursday, 14 December 2017 16:03:19 GMT Ian Zimmerman wrote: > I'll try not to feed this monster thread any longer, I promise. Ah, but will you succeed?:) -- Regards, Peter.
Re: [gentoo-user] openrc : autoload kernel modules
On 12/14/2017 03:30 PM, David Haller wrote:
>
> Does openrc-run (or the old way) support adding to strings? I.e.:
>
>
> modules+=" foo"
> modules+=" bar"
>
>
> or must one use
>
>
> modules="${modules} foo"
> modules="${modules} bar"
>
>
> or must it even be one single string? Does that support embedded
> linebreaks?
It's all shell script that gets passed through /bin/sh, so you can get
away with anything that will work in your /bin/sh. If you plan on
distributing your changes, though, then you should stick to POSIX sh
because you never know what the end user will be running.
Re: [gentoo-user] openrc : autoload kernel modules
Hello,
On Thu, 14 Dec 2017, Michael Orlitzky wrote:
>On 12/14/2017 12:43 PM, Helmut Jarausch wrote:
>>
>> I have added the following lines to /etc/conf.d/modules
>>
>> modules="enhanceio"
>> modules="enhanceio_lru"
>> modules="enhanceio_fifo"
>> modules="enhanceio_rand"
>>
>
>"modules" is a variable name, and it's being overwritten on each line.
>The /etc/init.d/modules script does something like
>
> for module in $modules; do
>load $module
> done
>
>but in your case, "modules" will contain only the last thing you set it
>to, namely modules="enhanceio_rand".
Does openrc-run (or the old way) support adding to strings? I.e.:
modules+=" foo"
modules+=" bar"
or must one use
modules="${modules} foo"
modules="${modules} bar"
or must it even be one single string? Does that support embedded
linebreaks?
I think this should be documented better in the file.
-dnh
PS: I've had the opposite problem: modules automatically got loaded
and I blacklisted them in /etc/modprobe.d/*.conf ;)
--
I find all proselytisation to be misguided at least. The way I see it, it's
not the Enlightened or the Chosen trying to save me or anyone, but just some
meme trying to survive in the great war for brain real estate.
-- Maarten Wiltink
Re: [gentoo-user] openrc : autoload kernel modules
On 12/14/2017 07:43:55 PM, Michael Orlitzky wrote: On 12/14/2017 12:43 PM, Helmut Jarausch wrote: > > I have added the following lines to /etc/conf.d/modules > > modules="enhanceio" > modules="enhanceio_lru" > modules="enhanceio_fifo" > modules="enhanceio_rand" > "modules" is a variable name, and it's being overwritten on each line. The /etc/init.d/modules script does something like for module in $modules; do load $module done but in your case, "modules" will contain only the last thing you set it to, namely modules="enhanceio_rand". Many thanks, Michael and Mick. It turned out that I had to write modules="vboxdrv vboxnetflt vboxnetadp enhanceio enhanceio_lru enhanceio_fifo enhanceio_rand" i.e. all modules in one string assignment to the variable 'modules' Helmut
Re: [gentoo-user] Re: openrc : autoload kernel modules
On Thu, Dec 14, 2017 at 8:11 PM, Hartmut Figge wrote: > Helmut Jarausch: > >>I have added the following lines to /etc/conf.d/modules >> >>modules="enhanceio" >>modules="enhanceio_lru" >>modules="enhanceio_fifo" >>modules="enhanceio_rand" >> >> >>but these modules don't get loaded at boot time. > > Looking in my /etc/conf.d/modules there are > > # for a list of modules and their options. > modprobe vboxdrv > modprobe vboxnetflt > modprobe vboxnetadp > modprobe vboxpci > > Hm? ;) > > Hartmut > > You want to verify the way you built and installed your external modules against this doc, https://www.kernel.org/doc/Documentation/kbuild/modules.txt. See if you overlooked anything.
Re: [gentoo-user] openrc : autoload kernel modules
On Thursday, 14 December 2017 18:43:55 GMT Michael Orlitzky wrote: > On 12/14/2017 12:43 PM, Helmut Jarausch wrote: > > I have added the following lines to /etc/conf.d/modules > > > > modules="enhanceio" > > modules="enhanceio_lru" > > modules="enhanceio_fifo" > > modules="enhanceio_rand" > > "modules" is a variable name, and it's being overwritten on each line. > The /etc/init.d/modules script does something like > > for module in $modules; do > load $module > done > > but in your case, "modules" will contain only the last thing you set it > to, namely modules="enhanceio_rand". Change your entries to: #Modules for enhanceio enhanceio enhanceio_lru enhanceio_fifo enhanceio_rand -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] openrc : autoload kernel modules
On 12/14/2017 12:43 PM, Helmut Jarausch wrote: > > I have added the following lines to /etc/conf.d/modules > > modules="enhanceio" > modules="enhanceio_lru" > modules="enhanceio_fifo" > modules="enhanceio_rand" > "modules" is a variable name, and it's being overwritten on each line. The /etc/init.d/modules script does something like for module in $modules; do load $module done but in your case, "modules" will contain only the last thing you set it to, namely modules="enhanceio_rand".
[gentoo-user] Re: openrc : autoload kernel modules
Helmut Jarausch: >I have added the following lines to /etc/conf.d/modules > >modules="enhanceio" >modules="enhanceio_lru" >modules="enhanceio_fifo" >modules="enhanceio_rand" > > >but these modules don't get loaded at boot time. Looking in my /etc/conf.d/modules there are # for a list of modules and their options. modprobe vboxdrv modprobe vboxnetflt modprobe vboxnetadp modprobe vboxpci Hm? ;) Hartmut
[gentoo-user] openrc : autoload kernel modules
Hi, could anybody please explain me how to setup autoloading of some kernel modules of mine. I'm using openrc. My modules reside in /lib/modules/`uname -r`/extra/enhanceio/ . I have added the following lines to /etc/conf.d/modules modules="enhanceio" modules="enhanceio_lru" modules="enhanceio_fifo" modules="enhanceio_rand" but these modules don't get loaded at boot time. The modules are OK since using 'depmod' works fine. What am I missing? Many thanks for a hint, Helmut
Re: [gentoo-user] Cleaning the SSD
On Thu, Dec 14, 2017 at 05:20:18PM +0100, Alain Didierjean wrote: > Just about to install gentoo on a used SSD (Samsung SSD 840 120G). > How to proceed to get a clean, like new SSD ? > Could the --security-erase or --security-erase-enhanced hdparm options do the > job or should I use something more sophisticated (or more efficient) ? > Hi, Have you looked at https://wiki.gentoo.org/wiki/SSD ? I suppose what exactly you are asking for, is to make new filesystems on your SSD, mount them and then do "fstrim ". But the article suggests to run that regularly rather than once. Hope that helps. signature.asc Description: Digital signature
[gentoo-user] Cleaning the SSD
Just about to install gentoo on a used SSD (Samsung SSD 840 120G). How to proceed to get a clean, like new SSD ? Could the --security-erase or --security-erase-enhanced hdparm options do the job or should I use something more sophisticated (or more efficient) ?
[gentoo-user] Re: Is gnome becoming obligatory?
On 2017-12-13 10:06, Alan McKinnon wrote: > A good healthy dose of manners like your Mama taught you is in short > supply around here right now. The worst insults are stated without any foul language. Indeed, I'll say that in general "insulting" is an attribute of ideas, not of words. Some of the time, at least, people who resort to swearing do so in reaction to such soft-spoken insults. (Equally on all sides of all issues). I'll try not to feed this monster thread any longer, I promise. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
[gentoo-user] Re: Is gnome becoming obligatory?
On 2017-12-14 11:57, Marc Joliet wrote: > I could list specific features of systemd that I like and make use of > (such as socket activation, autofs integration, user units, nspawn, or > the journal), but thinking about it, it's a "more than the sum of its > parts" kind of deal. Managing a system with systemd is just overall > pleasant for me. I am probably not the only one who would still dearly like such a detailed list, from someone I don't see as biased to start with. I understand this is a drain on your time, so I'll understand if you decline. This is also equally directed at Neil, who also posted a similar abbreviated list of features. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: [gentoo-user] Re: xcdroast 0.98alpha16: Empty CD
Hartmut Figge wrote: > I can imagine that finding the issue was tricky. It was hard to trace as the problem is a result of a non-matching variable <-> format string in the option parser and the incorrect variable was not "outfd" but "userverbose". Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
[gentoo-user] Re: xcdroast 0.98alpha16: Empty CD
Joerg Schilling: >Hartmut Figge wrote: >> Starting xcdroast with -d 10 shows the problem: >> >> DGB1: spawning: /usr/lib/xcdroast-0.98/bin/xcdrwrap CDDA2WAV -D "2,1,0" >> -J -g -Q -H -v toc,summary,sectors,titles >> DGB10: readtoc: cdda2wav: Invalid argument. Cannot open output fd 0. > >This is a bug in cdda2wav that only hits when compiled in 64 bit mode. For >this >reason, it has not been detected for a long time as Solaris by default uses 32 >Bit applications as 64 bit application on an orthogonal CPU are usually >slower... Ah, therefore it doesn't occur in a chroot to an old Gentoo. >The bug has been fixed on March 28, 2017 and published in schilytools. > >Today, I published a separate source ball cdrtools-3.02a09. Thanks, Joerg. In the meantime I had played a little, for the first time, with an overlay to get the exact versions of the relevant programs and was a little baffled that it didn't help. I can imagine that finding the issue was tricky. Hartmut
Re: [gentoo-user] Re: xcdroast 0.98alpha16: Empty CD
Helmut Jarausch wrote: > Perhaps you create an strace log and I'll compare that to one on my > machine. > My whole machine is on "Gentoo unstable" - though it's very stable. Since the problem is an "int" variable that should have been "long", there is no chance to detect the problem with syscall tracig. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [gentoo-user] Re: Is gnome becoming obligatory?
Am Mittwoch, 13. Dezember 2017, 20:37:47 CET schrieb Alan Mackenzie: > > > I've no idea how good systemd is. It's not been through the normal > > > process of choice and selection that other successful packages have. It > > > was forced on people. But being forced to have a binary system log, > > > being forced (so I have heard) to have an http server running, , > > > doesn't make it an attractive package for me. > > > > *All* of this is "so I have heard". What happened to researching stuff as > > the better alternative to speaking out of your ass? > > What have I done to deserve this abusive style of repartee? I have never > doled this out to anybody on this list in the past, and have no intention > of doing so in the future. You're right, you received the brunt of my built up aggression from this thread. I'm sorry for that. > Yes, there are a lot of "so I have heard"s in my posts. Asking people on > this list to confirm or refute things is a form of research, and a lot > more efficient than many other ones. > > There are several tens of thousands of packages in Gentoo, and I lack the > time personally to investigate each one. Asking people who already use > them and post on this list is a normal thing to do. Answering questions > about packages one oneself uses is the flip side of that coin. Except that you're not exactly asking questions, now are you? You asked Neil one, but only after a longer to and fro. If you *had* actually started out asking questions, as opposed to spouting hearsay and then even literally saying that you couldn't be bothered to research systemd yourself, my response would have been drastically different. Remember that everybody is here on their own time, and not everybody wants to spend it responding to questions that can easily be answered by reading documentation. I'm already wasting oodles of time writing this as is. If you *really* are interested, there is a longer thread on gentoo-amd64 where I wrote about my experience switching to systemd [0] (keep in mind, however, that a bunch of it is outdated by now, such as how I manage networking and backups). It could be interesting especially since it's mostly about actually solving problems. I could list specific features of systemd that I like and make use of (such as socket activation, autofs integration, user units, nspawn, or the journal), but thinking about it, it's a "more than the sum of its parts" kind of deal. Managing a system with systemd is just overall pleasant for me. [ And I never again have to deal with the state of a service being misreported by OpenRC because a daemons PID file has the wrong PID in it, or with stopping a service not actually stopping it, both of which I had experienced multiple times. ] [0] https://archives.gentoo.org/gentoo-amd64/message/ 58c67218a203b84318d52a39c3c67f73 Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: xcdroast 0.98alpha16: Empty CD
On 12/13/2017 10:24:14 PM, Hartmut Figge wrote: Helmut Jarausch: >On 12/13/2017 07:36:54 PM, Hartmut Figge wrote: >I have app-cdr/cdrtools 3.02_alpha07-r1 installed here. At the moment 3.02_alpha06, but I've tested the unstable version of cdrtools also. >Did you go to 'Setup' / 'Device-Scan' / 'Rescan devices' > >Is your device listed there? Yes to both. It seems that readtoc wishes to write to 'fd 0' instead to '-'. Perhaps I should mention also that there is no desktop environment on my machine. Only icewm. I'm using Icewm myself. Perhaps you create an strace log and I'll compare that to one on my machine. My whole machine is on "Gentoo unstable" - though it's very stable. Helmut
Re: [gentoo-user] Re: xcdroast 0.98alpha16: Empty CD
Hartmut Figge wrote: > Helmut Jarausch: > >On 12/13/2017 07:36:54 PM, Hartmut Figge wrote: > > >I have app-cdr/cdrtools 3.02_alpha07-r1 installed here. > > At the moment 3.02_alpha06, but I've tested the unstable version of > cdrtools also. You need at least 3.02a08 that has been published in: schily-2017-03-30.tar.bz2 today, a separate cdrtools-3.02a09 has been shipped. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [gentoo-user] xcdroast 0.98alpha16: Empty CD
Hartmut Figge wrote: > Greetings, > > on my current machine xcdroast fails to recognize an inserted CD in the > CD-reader. I do not often burn CDs and had switched to cdw which works > fine. Nevertheless, xcdroast was once my favorite and I am curious. :) > > Starting xcdroast with -d 10 shows the problem: > > DGB1: spawning: /usr/lib/xcdroast-0.98/bin/xcdrwrap CDDA2WAV -D "2,1,0" > -J -g -Q -H -v toc,summary,sectors,titles > DGB10: readtoc: cdda2wav: Invalid argument. Cannot open output fd 0. This is a bug in cdda2wav that only hits when compiled in 64 bit mode. For this reason, it has not been detected for a long time as Solaris by default uses 32 Bit applications as 64 bit application on an orthogonal CPU are usually slower... The bug has been fixed on March 28, 2017 and published in schilytools. Today, I published a separate source ball cdrtools-3.02a09. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
