Re: General-Purpose Server for Debian Stable
Linux-Fan wrote: > I am constantly needing more computation power, RAM and HDD storage such > that I have finally decided to buy a server for my next "workstation". The > reasoning is that my experience with "real" servers is that they are most > reliable, very helpful in indicating errors (dedicated LEDs next to the > PCIe slots for instance) and modern servers' noise seems to be acceptable > for my working envirnoment (?) > they are loud - for me it is unacceptable to have it in some living space > I currently use a Fujitsu RX 1330 M1 (1U server, very silent) and it > clearly is not "enough" in terms of RAM and HDD capacity. A little more > graphics processing power than a low-profile GPU would be nice, too :) > Servers usually do not have a good GPUs - they are mostly not used. Why don't you split your setup into powerful workstation and your current server? > Rack-Mountability is a must, although I am open to putting another tower > in there, sideways, should that be advantageous. > > In terms of "performance" specifications, I am thinking of the following: > > * 1x16-core CPU (e.g. AMD EPYC 7302) > > * 64 GiB RAM (e.g. 2x32 GiB or 4x16 GiB) > > I plan to extend this to 128 GiB as soon as the need arises. > As I am exceeding the 4T mark, I am increasingly considering the > use of ZFS. > > Currently, I have the maximum of 32 GiB installed in the > RX 1330 M1 and while it is often enough, there are times where I > am using 40 GiB SSD swap to overcome the limits. > > * 2x2T HDD for slow storage (local Debian Mirror, working data), > 2x4T SSD for fast storage (VMs, OS) > I will do software-RAID1 (ZFS or mdadm is still undecided). > I possible, I would like to use the power of the modern NVMe PCIe > U.2 (U.3?) SSDs, because they really seem to be much faster and that > may speed-up the parallel use of VMs and be more future-proof. > > * 1-2x 10G N-BaseT Ethernet for connecting to other machines to share > virtual machine storage (I am doing this already and it works...) > > * a 150W GPU if possible (75W full-sized card would be OK, too). > > Typical workloads: > data compression (Debian live build, xz), > virtual machines (software installation, updates) > you could off load your virtual machines to dedicated hardware. Depends on the number and configuration you indeed may need a server for that - better look at the requirements of the VM software manufacturer (VMWare or Oracle or whatever else) > Rarely: > GPGPU (e.g. nVidia CUDA, but some experimentation with OpenCL, too) > single-core load coupled with very high RAM use (cbmc) > > Some time ago, there was this thread > https://lists.debian.org/debian-user/2020/06/msg01117.html > It already gave me some ideas... > > I am considering one the following models which are AMD EPYC based (I > think AMDs provide good performance for my types of use). > > * HPE DL385 G10 Plus > * Dell PowerEdge R7515 > > I have an old HP DL380 G4 in the rack and while it is incredibly loud, it > is also very reliable. Of course, it is rarely online for its excessive > loudness and power draw, but I derive that HPE is going be reliable? > Before the Fujitsu, I used a HP Z400 workstation and before that a HP > Compaq d530 CMT and all of these still "function", despite being too slow > for today's loads. > Servers are loud - same for DL380 G10, same for the PowerEdge > I am also taking into consideration these, although they are Intel-based > and I find it a lot harder to obtain information on prices, compatibility > etc. for these manufacturers: > > * Fujitsu PRIMERGY RX2540 M5 > * Oracle X8-2L > (seems to be too loud for my taste. especially compared to the others?) > > I have already learned from my local vendor that HPE does not support the > use of non-HPE HDDs in the server which means I would need to buy all my > drives directly from HPE (of course this will be very expensive). > Additionally, none of the server manufacturers list Debian compatibility, > thus my questions are as follows: > > * Does anybody run Debian stable (10) on any of these servers? > Does it work well? > > * Is there any experience with "unsupported" HDD configurations i.e. > disks not bought from the server manufacturer? > HPE does not support means not that you can not do it - rather you will not have warranty/support in case of troubles. If you can live with it? > I would think that during the warranty period (3y) I best stay with > the manufacturer-provided HDDs but after that, it would be nice to be > able to add some more "cheap" storage... > They use Seagate or Samsung disks - I am not sure ATM. Disks are disks you can put whatever you want there. The disks they sell seem to be manufactured specifically for HPE and likely are tested/certified by HPE, although here one disk failed after 1,5y of operations in a conditioned server room where the machine did not have much disk load. I mena it is good to stay for the 3y with their hardware. > * Of course, if there
Signing emails, was Re: General-Purpose Server for Debian Stable
On Fri 02 Oct 2020 at 01:15:36 (+0200), Linux-Fan wrote: > Dan Ritter writes: > > Linux-Fan wrote: > > [...] > > OT: Message signature is still invalid, but I could track it down to some > weird changes in space characters between what I send to and what I receive > from the list. I have now idea how to solve it, though... Looking back at this signed post, https://lists.debian.org/debian-user/2020/08/msg00741.html I see the following lines: On Sat 22 Aug 2020 at 00:17:19 (+0200), Linux-Fan wrote: > Teemu Likonen writes: > > * 2020-08-21 20:24:29+02, Linux-Fan wrote: > > [...] > > The copy I receive from the list does not verify correctly here, either. > It seems somewhere along the path the e-mails content is actually mangled. > -- some additional newlines are introduced compared to my local copy from > the "Sent" folder which verifies correctly. > > Attached are `sent.txt` (and `sent.eml`) and `received.txt` -- the very same > e-mail as seen in my Sent folder and Inbox respectively... Interestingly, if > I split out the signatures and message contents, I get bad signature for > both variatns despite the fact that the e-mail client can somehow verify the > sent e-mail... > > ??? > Linux-Fan > --=_pte5-5038-1598034269-0003 > Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" > Content-Disposition: inline > Content-Transfer-Encoding: 7bit This is the header for the "sent" file. You appear to be sending 8bit data without encoding it. AIUI that contravenes "all data signed according to this protocol MUST be constrained to 7 bits (8-bit data MUST be encoded using either Quoted-Printable or Base64)". It's possible that your mailer set Content-Transfer-Encoding: 7bit because this message happened not to contain any 8bit characters. In my mutt, a message like that would be sent with: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline whereas one containing 8bit chars would be sent with: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit (Of course, I'm allowed to send 8bit because I'm not signing it.) Whatever—somewhere in the chain of transmission, the email gets encoded into Q-P: > --=_pte5-5038-1598034269-0003 > Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable Unfortunately, the Content-Transfer-Encoding is AIUI part of the signed message, so the "received" file can never match the "sent". For whatever reason, by the time your email reaches my mailbox, the "sent" unencoded attachment has been encoded as Q-P, and the "received" Q-P attachment doesn't need it. As a result, the texts of the two attachments look very similar, with their complementary headers. Summarising, as displayed by mutt: [-- Attachment #2: sent.txt --] [-- Type: text/plain, Encoding: quoted-printable, Size: 1.8K --] Content-Disposition: attachment; FILENAME="sent.txt" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --=_pte5-5038-1598034269-0003 → Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" → Content-Disposition: inline → Content-Transfer-Encoding: 7bit and: [-- Attachment #3: received.txt --] [-- Type: text/plain, Encoding: 7bit, Size: 1.8K --] Content-Disposition: attachment; FILENAME="received.txt" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit --=_pte5-5038-1598034269-0003 → Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" → Content-Disposition: inline → Content-Transfer-Encoding: quoted-printable These → lines are signed. This is just my interpretation of RFCs 3156 and 3676. A lot of these RFCs is about Flowed and Delsp. I've assumed that that's all being implemented correctly. (Mixing Q-P and Flowed is tricky at best, disallowed at worst.) BTW, I know nothing about .eml files. I'm just happy not to see tnef files anymore. Cheers, David.
Re: General-Purpose Server for Debian Stable
Dan Ritter writes: Linux-Fan wrote: [...] > * HPE DL385 G10 Plus > * Dell PowerEdge R7515 You should also look at machines made by SuperMicro and resold via a number of VARs. My company is currently using Silicon Mechanics and is reasonably happy with them. We have a few HPs as well. > I have already learned from my local vendor that HPE does not support the > use of non-HPE HDDs in the server which means I would need to buy all my > drives directly from HPE (of course this will be very expensive). It's ridiculously expensive. Also, note that HPE won't ship empty drive sleds for free. You can buy them aftermarket for about $15-30 each, depending. > Additionally, none of the server manufacturers list Debian compatibility, > thus my questions are as follows: > > * Does anybody run Debian stable (10) on any of these servers? > Does it work well? Yes, and yes. Avoid buying HP's RAID cards. > * Is there any experience with "unsupported" HDD configurations i.e. > disks not bought from the server manufacturer? They all work. They tend to be more finicky about RAM. Buy SuperMicro, from a VAR not too far away from you who can supply a next-day parts warranty for cheap. Thank you very much for these hints. I will surely add Supermicro to the consideration. The hints wrt. RAM and RAID cards are appreciated! OT: Message signature is still invalid, but I could track it down to some weird changes in space characters between what I send to and what I receive from the list. I have now idea how to solve it, though... Linux-Fan
Re: Debian 9.13 perl-5.24-1 compile from source dist/Time-HiRes Warning: No Makefile!
On Thu, 1 Oct 2020 at 07:11, David Christensen wrote: > On 2020-09-30 03:31, David wrote: > > On Wed, 30 Sep 2020 at 14:57, David Christensen > > wrote: > >> I have installed the source code for the 'perl' package: > >> $ apt-get source perl > I read: > debian/README.Debian > debian/Documentation > debian/README.source > README > README.linux > Unfortunately, none provide simple instructions for building on Debian. >From what I have observed, I think your expectation that such instructions would be provided in that location is inconsistent with the practice and aims of the Debian project. Debian is basically a software packaging project. Your apt-get source command downloaded a source _package_. The purpose of a source _package_ is to build installable (aka binary) packages, and Debian provides instruction on how to do that. If you want to work with un-packaged source code, you would obtain it from the upstream Perl project (not from Debian), and also be responsible yourself for ensuring that all its build dependencies are present. When source code has complex dependencies, then I find it easier to be lazy and just take advantage of the work that has already been done by the Debian maintainers to satisfy that requirement. > > I suggest you try the usual method > > using debuild here: > >https://wiki.debian.org/BuildingTutorial#Rebuild_without_changes [...] > After 42 minutes, it seems to have worked: And during that 42 minutes, you can do something more interesting than trying to solve build dependency problems :) [...] > Hopefully, that will be sufficient for now. Great, I'm glad to hear it worked for you so that you could move closer to your goal.
Re: General-Purpose Server for Debian Stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ‐‐‐ Original Message ‐‐‐ On Thursday, October 1, 2020 9:37 PM, Linux-Fan wrote: > - Dell PowerEdge R7515 I've had very good luck with Dell for a very long time. I've needed nothing close to what you're looking for, but the boxes have been flawless (Intel Xeon, though, not AMD). And they do sell servers with no Winders tax... -- Glenn English -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJfdl7DACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG MYKsjDKSkwgAunI5BIIu1SryhcOFLoWOD8Lb03Oh4+R9WcfHyHH4WbehtyBs Ynuxnc1SYxYT/xZthbUyVs33DdvOO/sZQirOHr63VrOr2/nWEbCs1xD64REh CzisXdO+oXAxjFg/uirCq+1s/IdF0eHaf30AkrZNgedI5EEezPz22ITsx4C+ Dg2l/GAtBceag/ua44Rn6hg7pjdfRrnXzlEJRfVNk9xLX5FokQhIRUXl7srJ NLP1OIKug1pV1almD7RV8vvOUUEHwybD8KUgSY52zH+ksBbgx1HElh+gTKPz 0OpdVnHjCn5ElBRRwKHldYJPsceRB9N62rqgjTl25YVuipeGfdSgdg== =V8tu -END PGP SIGNATURE-
Re: General-Purpose Server for Debian Stable
Linux-Fan wrote: > In terms of "performance" specifications, I am thinking of the following: > > * 1x16-core CPU (e.g. AMD EPYC 7302) > * 64 GiB RAM (e.g. 2x32 GiB or 4x16 GiB) > * 2x2T HDD for slow storage (local Debian Mirror, working data), > 2x4T SSD for fast storage (VMs, OS) > I will do software-RAID1 (ZFS or mdadm is still undecided). > I possible, I would like to use the power of the modern NVMe PCIe > U.2 (U.3?) SSDs, because they really seem to be much faster and that > may speed-up the parallel use of VMs and be more future-proof. > > * 1-2x 10G N-BaseT Ethernet for connecting to other machines to share > virtual machine storage (I am doing this already and it works...) > * a 150W GPU if possible (75W full-sized card would be OK, too). > > I am considering one the following models which are AMD EPYC based (I think > AMDs provide good performance for my types of use). > > * HPE DL385 G10 Plus > * Dell PowerEdge R7515 You should also look at machines made by SuperMicro and resold via a number of VARs. My company is currently using Silicon Mechanics and is reasonably happy with them. We have a few HPs as well. > I have already learned from my local vendor that HPE does not support the > use of non-HPE HDDs in the server which means I would need to buy all my > drives directly from HPE (of course this will be very expensive). It's ridiculously expensive. Also, note that HPE won't ship empty drive sleds for free. You can buy them aftermarket for about $15-30 each, depending. > Additionally, none of the server manufacturers list Debian compatibility, > thus my questions are as follows: > > * Does anybody run Debian stable (10) on any of these servers? > Does it work well? Yes, and yes. Avoid buying HP's RAID cards. > * Is there any experience with "unsupported" HDD configurations i.e. > disks not bought from the server manufacturer? They all work. They tend to be more finicky about RAM. Buy SuperMicro, from a VAR not too far away from you who can supply a next-day parts warranty for cheap. -dsr-
General-Purpose Server for Debian Stable
Hello fellow list users, I am constantly needing more computation power, RAM and HDD storage such that I have finally decided to buy a server for my next "workstation". The reasoning is that my experience with "real" servers is that they are most reliable, very helpful in indicating errors (dedicated LEDs next to the PCIe slots for instance) and modern servers' noise seems to be acceptable for my working envirnoment (?) I currently use a Fujitsu RX 1330 M1 (1U server, very silent) and it clearly is not "enough" in terms of RAM and HDD capacity. A little more graphics processing power than a low-profile GPU would be nice, too :) Rack-Mountability is a must, although I am open to putting another tower in there, sideways, should that be advantageous. In terms of "performance" specifications, I am thinking of the following: * 1x16-core CPU (e.g. AMD EPYC 7302) * 64 GiB RAM (e.g. 2x32 GiB or 4x16 GiB) I plan to extend this to 128 GiB as soon as the need arises. As I am exceeding the 4T mark, I am increasingly considering the use of ZFS. Currently, I have the maximum of 32 GiB installed in the RX 1330 M1 and while it is often enough, there are times where I am using 40 GiB SSD swap to overcome the limits. * 2x2T HDD for slow storage (local Debian Mirror, working data), 2x4T SSD for fast storage (VMs, OS) I will do software-RAID1 (ZFS or mdadm is still undecided). I possible, I would like to use the power of the modern NVMe PCIe U.2 (U.3?) SSDs, because they really seem to be much faster and that may speed-up the parallel use of VMs and be more future-proof. * 1-2x 10G N-BaseT Ethernet for connecting to other machines to share virtual machine storage (I am doing this already and it works...) * a 150W GPU if possible (75W full-sized card would be OK, too). Typical workloads: data compression (Debian live build, xz), virtual machines (software installation, updates) Rarely: GPGPU (e.g. nVidia CUDA, but some experimentation with OpenCL, too) single-core load coupled with very high RAM use (cbmc) Some time ago, there was this thread https://lists.debian.org/debian-user/2020/06/msg01117.html It already gave me some ideas... I am considering one the following models which are AMD EPYC based (I think AMDs provide good performance for my types of use). * HPE DL385 G10 Plus * Dell PowerEdge R7515 I have an old HP DL380 G4 in the rack and while it is incredibly loud, it is also very reliable. Of course, it is rarely online for its excessive loudness and power draw, but I derive that HPE is going be reliable? Before the Fujitsu, I used a HP Z400 workstation and before that a HP Compaq d530 CMT and all of these still "function", despite being too slow for today's loads. I am also taking into consideration these, although they are Intel-based and I find it a lot harder to obtain information on prices, compatibility etc. for these manufacturers: * Fujitsu PRIMERGY RX2540 M5 * Oracle X8-2L (seems to be too loud for my taste. especially compared to the others?) I have already learned from my local vendor that HPE does not support the use of non-HPE HDDs in the server which means I would need to buy all my drives directly from HPE (of course this will be very expensive). Additionally, none of the server manufacturers list Debian compatibility, thus my questions are as follows: * Does anybody run Debian stable (10) on any of these servers? Does it work well? * Is there any experience with "unsupported" HDD configurations i.e. disks not bought from the server manufacturer? I would think that during the warranty period (3y) I best stay with the manufacturer-provided HDDs but after that, it would be nice to be able to add some more "cheap" storage... * Of course, if there are any other comments, I am happy to hear them, too. I am looking into all options although a fully self-built system is probably too much. I once tried to (only) get a decent PC case and failed at it... I can only imagine it being worse for rackmount PC cases and creating a complete system composed of individual parts? Thanks in advance Linux-Fan pgp1pA_ASNOFF.pgp Description: PGP signature
Re: Firefox over JACK in Debian Testing
On 6/6/2020 11:25 PM, riveravaldez wrote: AFAIK Firefox lacks JACK support (in the sense that you can start JACK and then Firefox and then, automatically, all I/O audio-ports Firefox generated, appear as available JACK connections, let's say) Join in if you like to do so https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844688 . Cheers, Olivier
Re: Mail transfer agent (debian-user-digest Digest V2020 #932)
On Wed 30 Sep 2020 at 23:26:20 -0500, David Wright wrote: > On Sat 26 Sep 2020 at 10:50:11 (+0300), Andrei POPESCU wrote: > > > > > > It ought to—I have no idea whether mutt can even use it, though > > > I suppose it's possible—but AIUI the file belongs to exim4-config. > > > It "needs" a dot to prevent your being nagged about its lack, and > > > having an @ in it could screw up any use exim makes of it. > > > (I use it to set exim's HELO.) So I thought it best to mention it. > > > > As far as I recall[1] /etc/mailname is Debian specific[2], to be used by > > all softwares (typically MTAs and some MUAs like mutt) that need a > > domain part to construct a full e-mail address, when one isn't provided. > > > > [1] too lazy to check where it's documented, quite likely in Debian Policy > > [2] as in Debian specific patches to support it > > Your ¹ is correct. Specifically, from > > file:///usr/share/doc/debian-policy/policy.html/ch-customized-programs.html#mail-transport-delivery-and-user-agents > > If your package needs to know what hostname to use on (for > example) outgoing news and mail messages which are generated > locally, you should use the file /etc/mailname. It will contain > the portion after the username and @ (at) sign for email addresses > of users on the machine (followed by a newline). > > Such a package should check for the existence of this file when it > is being configured. If it exists, it should be used without > comment, although an MTA’s configuration script may wish to prompt > the user even if it finds that this file exists. If the file does > not exist, the package should prompt the user for the value > (preferably using debconf) and store it in /etc/mailname as well > as using it in the package’s configuration. The prompt should make > it clear that the name will not just be used by that package. For > example, in this situation the inn package could say something > like: > > Please enter the "mail name" of your system. This is the > hostname portion of the address to be shown on outgoing news and > mail messages. The default is syshostname, your system's host name. > > Mail name ["syshostname"]: > > where syshostname is the output of hostname --fqdn. exim4 says: The 'mail name' is the domain name used to 'qualify' mail addresses without a domain name. Sending to brian or cc'ing or bcc'ing brian would go to br...@axis.corp. I interpret the above to apply to email addresses *only*. EHLO (HELO) would not be involved. > So on this system, its value is axis.corp, which you can see in the > header of this email. It certainly shouldn't be an email address, > containing a local part and @. Correct. Users do do that; most of the time it hasn't any consequence because they do not send to or cc brian. The complete address is used. > > I wasn't aware that there is a (somewhat old) wiki page which is > supposed to list all the MTAs (which I understand as including > programs which submit mail using SMTP) and how they interpret > /etc/mailname. For some reason, mutt is treated under the heading > for exim4. Half a dozen headings have no information listed, and > I don't know whether there are packages/programs missing altogether. I've always been aware of that page. The exim4 documentation is more useful, however. > There are at least three or four important fields that involve various > interpretations of "from-ness": EHLO, envelope (MAIL_FROM), From: > and Sender:. (That's ignoring Resent* and so on.) How these relate > to each other is not straightforward, particularly for home users' > machines, and their values can be an important factor in whether > their emails make it into the Internet and on to their destination. > What works for one person may not for another. (That's also > ignoring intranet emails.) exim4 gets the EHLO from /etc/hosts, not /etc/mailname. -- Brian.
Verifying checksum and signature
Hi, I want to reinstall Debian but first verify the signature of the installer checksum and the signature file. I am working with Windows and based this process on this video by Crypto Dad: https://www.youtube.com/watch?v=N7oE0QaK540 I was able to download the GPG4Win and verify it with the Shasum Checker, also as per Crypto Dad: https://www.youtube.com/watch?v=QZ2GrQA_ye8 I followed his instructions to check the signature and checksum for the Debian installer in (GNU Privacy Assistant). I get the message that there is no public key. When I follow his process to retrieve the public key at https://www.debian.org/CD/verify I get the message in GPA "No keys were found" for all the IDs and fingerprints on the page. Should I be obtaining the public key elsewhere? Or should I do something else differently? If you need more details please let me know. Thanks for your help, Leonard
Fwd: Confusion on how to do it.
This went only to John whereas I meant to send it to both John and the list. -- Forwarded message - From: Andrew Cater Date: Thu, Oct 1, 2020 at 4:57 PM Subject: Re: Confusion on how to do it. To: John Brumby Hi John, Everything in one would be 40 odd DVDs worth but you can get the first DVD to install a complete OS (with some internet access being helpful thereafter as necessary). DVD 1-3 would give you some of the applications that are less used, but, to be honest, if you have adequate Internet access, you can use a Debian netinst CD. IF you have no internet access for one particular machine / need for a completely isolated network with no external connectivity, then there are two large .iso files you can create - one 16GB Stick or one Blu-Ray 25GB file - both of which can be written directly to a USB stick. Both of these large files require a Linux system and network access to a Debian mirror to generate but can be used independently thereafter. Note: the 16GB stick might require a larger 32GB USB - many USB sticks which are nominally 16GB are about 14.5GB capacity. All the very best, Andy C. On Wed, Sep 30, 2020 at 11:54 PM John Brumby wrote: > Dear Team, > > Is there such a thing as a Full Debian Os ISO to be downloaded. > The lists are so confusing that I see. > > John Brumby >
Re: Firefox over JACK in Debian Testing
On 6/8/20, Christopher David Howie wrote: > On 6/6/2020 11:25 PM, riveravaldez wrote: >> Hi, here's the thing: >> >> AFAIK Firefox lacks JACK support (in the sense that you can start >> JACK and then Firefox and then, automatically, all I/O audio-ports >> Firefox generated, appear as available JACK connections, let's say) >> >> Is there any Debian package that can serve this purpose? > > If JACK is already running when pulseaudio starts, pulseaudio will > create a single JACK sink and JACK source that redirects audio to/from a > matching JACK source/sink. > > I then use the following script to create additional sinks in PA that > each have an independent source in JACK: (...) Thanks a lot, Chris, I've finally found the time to try this, and these are the steps that seems (at least for now) to be working: 0. An installed and functional JACK and PulseAudio. 1. Install package: pulseaudio-module-jack 2. Close anything that requires PA. 3. Kill PA: $ pulseaudio --kill 4. Start JACK (in my case, through qjackctl). 5. Then start Firefox (this should start PA). 6. Then load (as seen in [1]) the source/sink modules[2] to have I/O audio through PA administered/connected by JACK (these will appear in its Connections): $ pactl load-module module-jack-sink/source 7. Use JACK as usual. 8. After stop/exit JACK remember to kill/restart PA in order to it to retake control of Audio Device. There are other methods (some more complex) there [3] and there [4]. I couldn't find these steps or Chris' explanations neither in [5] nor in [6]: should it be added? Let me know what you think. Thanks a lot to everybody for all your useful and kind help. I had no idea before this that this was possible and so easily achievable. Best regards. [1] https://wiki.debian.org/PulseAudio#Echo_test:_hearing_the_microphone [2] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#jackconnectivity [3] https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_PulseOnJack [4] https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_through_JACK [5] https://wiki.debian.org/PulseAudio [6] https://wiki.debian.org/JACK
Re: crc not installed but rsync using it? ...
David Wright writes: > On Tue 29 Sep 2020 at 15:50:35 (+0200), Albretch Mueller wrote: >> But how could you have some assurance that that data relates to what >> their users thought of to be? > > You can't. That's not what CRCs are for. They're not cryptographic, > so they are useless for any type of assurance that the data is intact. More precisely, hashes that are not cryptographic-grade are useless for assurance that the data has not been modified by a third-party. They can still be useful for assurance that data has not been altered by wire issues and other physical (non-human) issues. -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Confusion on how to do it.
Hi, John Brumby wrote: > Is there such a thing as a Full Debian Os ISO to be downloaded. Afaik, there is no single ISO which contains all packages. The usual advice is to download the first three DVD sized ISOs. In case of 64-bit x86 computers: https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/ But there are sets with large volume sizes, so that already the first ISO of the set contains about everything you might ever want to install: 16 GB: https://cdimage.debian.org/debian-cd/current/amd64/jigdo-16G/ 25 GB: https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/ 50 GB: https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dlbd/ They need program jigdo-lite for download. If you already have a Debian system or one which offers this program, then you may follow these instructions: https://wiki.debian.org/JigdoOnLive#Install_package_jigdo-file Andrew Cater gives motivations and instructions in: http://flosslinuxblog.blogspot.com/2020/07/a-quick-post-on-how-to-use-jigdo-to.html Debian's official documentation and hands-on example: https://www.debian.org/CD/jigdo-cd/ https://tldp.org/HOWTO/Debian-Jigdo/downloadingyourfirstimage.html If you have no opportunity to install jigdo-lite on your current operating system, consider to download a Debian Live ISO, boot it, install jigdo-lite, and download the big ISO to the computer's hard disk: https://wiki.debian.org/JigdoOnLive Have a nice day :) Thomas
