Re: KDE run Dolphin as root?
On Ma, 09 iun 20, 17:55:07, Default User wrote: > > Well, when I did an alternate Buster Stable install on a spare drive, > I was surprised (not happily) that when running from that setup, > various programs demand the root password, and will not accept the > user password. So, now I have to remember not one, but two "good" > passwords. And try to determine which one is being asked for. And > re-remember both every time they are changed. > > I am guessing this has to do with a change made for Buster. Perhaps > it is a "security thing". > > Maybe I am lazy, but I quite prefer to only have to remember and use > one password. And this feels like another step backward to me. > > Oh, well . . . I guess it's for my own good. After all, I'm sure > Debian developers know what is best for me, better than I do. After > all, these are the same people who actually thought systemd was a good > idea. And shouted down those who didn't. You are making some claims above without providing even one example. There might be simple explanations and / or solutions for what you experience... Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How long will this take?
On 6/9/2020 5:39 AM, Nicolas George wrote: How do you add "status=progress" to a process that has already been running for three days? You can't, of course. I was merely suggesting using this in future invocations. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: how to use high resolution display with radeon
On Tue, 9 Jun 2020 18:43:34 +0800 Cheng Yutong wrote: > i've tried to generate a Modeline with `cvt 2560 1440`, Try installing arandr. It will let you set it up graphically, and then export a shell script which will duplicate the setup. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: KDE run Dolphin as root?
On Sunday, Jun 7, 2020, at 12:11, Kushal Kumaran wrote: > >Running > > sudo sh -c 'unset SUDO_USER; KDE_FULL_SESSION=true > dolphin' > > from a shell gets a dolphin window. Thanks, Kushal. That does work. For Dolphin, anyway. > There is some advice at > https://forum.kde.org/viewtopic.php?f=223&t=161021#p425888 that > can arrange things so that you get an action on the right-click context > menu. Could not figure out how to get this to work. Whatever. > Sounds like you have your needs properly met with cinnamon and > nemo, and they seem to be available in debian. Is there a particular > reason you need to solve this problem with dolphin? I assume you > could have just installed nemo and used it even while using the plasma > shell as the desktop. Yes, I have been getting along fine with nemo on Cinnamon. Much better than the crippled nautilus that Gnome makes these days. I was just looking around, to see if there was anything better. I have heard people praise dolphin (and kde) lately. And dolphin does seem to be a little more configurable than nemo. Nemo does work from within kde: nemo as user sudo nemo for elevated privileges. Since I am the system administrator for my computer, I find myself having to do a lot of things as root. I can enter the snippet you provided, to run dolphin with elevated privileges. Or nemo. But it really does bother me the arrogant attitude of one or more kde developers: deliberately working to prevent users from deciding for themselves how to use their own systems, even after considerable user complaints. And that they apparently promised users they would change this, over a year ago! Sounds like "tell them whatever they want to hear, then ignore them until they get too tired to complain any more." On Jun 7, 2020, at 1:55 PM , Marco Möller wrote: > For me the task to handle files as root is not frequently coming up. If > so, then I simply use sudo and CLI commands. Besides on the CLI running > nano, cp, mv and rm, I figured out that many times using chown helps a > lot: if needing to manipulate many files as user root, then this is > usually caused because a bunch of files was received from a backup > storage directory or files on external storage devices come marked to be > owned as root, but if I am pretty sure (this is of course important) > that it will not do any harm to change the owner of those files or > directories to the group and name of a normal user then chown is fast to > do and afterwards I can continue to work with Dolphin as a normal user. > . . . > > Reminding on the question of the OP: > If in need to handle files with root permissions, I simply use sudo and > CLI commands. Remember the above mentioned comfort option to invoke a > root terminal by command 'sudo su -'. Then, besides on the CLI running > nano, cp, rm and mv, maybe having available mc, using the command chown > should be considered as well. If I am pretty sure (this is of course > important) that it will not do any harm to change the ownership of files > or directories to the group and name of my normal user, then chown is > fast to do and afterwards I can continue to work with Dolphin as my > normal user. Thanks for the explanation. - Now, a final note. When I did my main install, it was a day or two before the release of Buster 10.0. I immediately upgraded to Unstable. But it is still originally based upon Stretch. It was set up with both root and user passwords. And I use good quality, long passwords. : ) Here's the point: I can do everything requiring elevated privileges just by using the user password, and sudo in a terminal as needed. Never need to use the root password. Well, when I did an alternate Buster Stable install on a spare drive, I was surprised (not happily) that when running from that setup, various programs demand the root password, and will not accept the user password. So, now I have to remember not one, but two "good" passwords. And try to determine which one is being asked for. And re-remember both every time they are changed. I am guessing this has to do with a change made for Buster. Perhaps it is a "security thing". Maybe I am lazy, but I quite prefer to only have to remember and use one password. And this feels like another step backward to me. Oh, well . . . I guess it's for my own good. After all, I'm sure Debian developers know what is best for me, better than I do. After all, these are the same people who actually thought systemd was a good idea. And shouted down those who didn't. Have a nice day! : )
Re: How long will this take?
Jude DaShiell (12020-06-09): > To search disk drives. Are you still talking about binary search? To search disk drives for what? Binary search is for sorted data. There is nothing sorted on a hard drive. And binary search is when random access is fast; on mechanical hard drives, random access is much slower than sequential access. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: How long will this take?
To search disk drives. On Tue, 9 Jun 2020, Nicolas George wrote: > Date: Tue, 9 Jun 2020 14:27:46 > From: Nicolas George > Reply-To: debian-user@lists.debian.org > To: Jude DaShiell > Cc: l0f...@tuta.io, Debian User > Subject: Re: How long will this take? > > Jude DaShiell (12020-06-09): > > High security operations do this routinely. They properly don't trust > > parts are as labeled from manufacturers especially manufacturers that > > send any of their stuff or get any of their stuff from China. > > There is no trust to have. The previous contents would be overwritten on > the first actual write of a file. > > And if the filesystem reads a sector that has never been written, that's > a serious bug in the operating system. > > > I'm thinking of the binary search method and am wondering if disk > > operations of all sorts could be speeded up using it rather than > > sequential searches. Or is binary already used now? > > To search what? > > Regards, > > --
Re: How long will this take?
Jude DaShiell (12020-06-09): > High security operations do this routinely. They properly don't trust > parts are as labeled from manufacturers especially manufacturers that > send any of their stuff or get any of their stuff from China. There is no trust to have. The previous contents would be overwritten on the first actual write of a file. And if the filesystem reads a sector that has never been written, that's a serious bug in the operating system. > I'm thinking of the binary search method and am wondering if disk > operations of all sorts could be speeded up using it rather than > sequential searches. Or is binary already used now? To search what? Regards, -- Nicolas George signature.asc Description: PGP signature
Re: How long will this take?
High security operations do this routinely. They properly don't trust parts are as labeled from manufacturers especially manufacturers that send any of their stuff or get any of their stuff from China. I'm thinking of the binary search method and am wondering if disk operations of all sorts could be speeded up using it rather than sequential searches. Or is binary already used now? On Tue, 9 Jun 2020, l0f...@tuta.io wrote: > Date: Tue, 9 Jun 2020 14:08:34 > From: l0f...@tuta.io > To: Debian User > Subject: Re: How long will this take? > Resent-Date: Tue, 9 Jun 2020 18:08:47 + (UTC) > Resent-From: debian-user@lists.debian.org > > Hi, > > 8 juin 2020 ? 22:22 de treni...@pm.me: > > > I bought a new 4 terrabyte hard drive that is connected with a USB cable > > using USB2. It took about 32 hours to read every sector on the drive to > > look for bad sectors. I started blanking the sectors using /dev/zero last > > Friday night. > > > Out of curiosity, what is the purpose to wipe a brand new HDD? > Wouldn't formatting (or GPT overwrite) be sufficient? > > 9 juin 2020 ? 08:59 de dpchr...@holgerdanske.com: > > > Also as others have stated, writing zeros to an SSD may wear it out > > prematurely (depends upon internals of SSD). The best approach is to do a > > "secure erase". > > > It seems to be a hard drive here ;) > > Rather than wiping storage devices with GNU/Linux userland tools, your best > > bet is to use the manufacturer's diagnostic utility. In the ideal case, > > the utility sends a command to the drive controller and everything gets > > done internally at maximum speed. I prefer the bootable "Live" tools, if > > available. Each manufacturer has their own toolkit. Get the one for your > > drive brand. For example, SeaTools Bootable: > > > > https://www.seagate.com/support/downloads/seatools/ > > > Even more true for an SSD (and yet, I'm not sure we can say "secure" for sure > as those utilities are generally proprietary so we cannot verify what they do > exactly). > > Best regards, > l0f4r0 > > --
Re: Zoom- best practice?
Original post: family is using Zoom. No alternative for me to participate... Zoom or nothing. Thanks for the suggestion. Peter Ehlert On June 9, 2020 10:56:10 AM Alberto Sentieri <2...@tripolho.com> wrote: This is a long thread. I did not read it all. Did anyone suggest http://meet.google.com?
Re: How long will this take?
Hi, 8 juin 2020 à 22:22 de treni...@pm.me: > I bought a new 4 terrabyte hard drive that is connected with a USB cable > using USB2. It took about 32 hours to read every sector on the drive to look > for bad sectors. I started blanking the sectors using /dev/zero last Friday > night. > Out of curiosity, what is the purpose to wipe a brand new HDD? Wouldn't formatting (or GPT overwrite) be sufficient? 9 juin 2020 à 08:59 de dpchr...@holgerdanske.com: > Also as others have stated, writing zeros to an SSD may wear it out > prematurely (depends upon internals of SSD). The best approach is to do a > "secure erase". > It seems to be a hard drive here ;) > Rather than wiping storage devices with GNU/Linux userland tools, your best > bet is to use the manufacturer's diagnostic utility. In the ideal case, the > utility sends a command to the drive controller and everything gets done > internally at maximum speed. I prefer the bootable "Live" tools, if > available. Each manufacturer has their own toolkit. Get the one for your > drive brand. For example, SeaTools Bootable: > > https://www.seagate.com/support/downloads/seatools/ > Even more true for an SSD (and yet, I'm not sure we can say "secure" for sure as those utilities are generally proprietary so we cannot verify what they do exactly). Best regards, l0f4r0
Re: Trouble with 2011 iMac Sound Card On Debian
Will try, thx. --Keifer On Tue, Jun 9, 2020 at 12:26 AM Andrei POPESCU wrote: > On Lu, 08 iun 20, 16:11:02, Keifer Bly wrote: > > Hi all, > > > > So I installed Debian on a 2011 iMac and it is working ok, except for the > > sound. There is no sound from either the speaker or the headphone jack. > > > > When I go to the system settings, the volum option is completely greyed > out. > > > > Running cat /proc/asound/cards in UXTerm returned this: > > > > 0 [PCH ]:HDA-Intel - HDA Intel PCH > >HDA Intel PCH at 0xa890 irq 47 > > 1 [HDMI]: HDA-Intel - HDA ATI HDMI > > HDA ATI HDMI at 0xa884 irq 48 > > > > I am wondering why the speaker and headphone jack would not work when the > > sound card is recognized? Thanks very much. > > You could try poking around in alsamixer (package alsa-utils) to unmute > (M) channels or change volume levels. > > Hope this helps, > Andrei > -- > http://wiki.debian.org/FAQsFromDebianUser >
Re: Zoom- best practice?
This is a long thread. I did not read it all. Did anyone suggest http://meet.google.com?
Fw: How long will this take?
I have started the process over from the beginning. It seems to respond well to obs=4M as the write speed has gone from 3.7 MB/s to 28.2 MB/s, which is about the same as where it was with obs=1M. It should take a couple of days to complete this write process. The WD drive that I have, which is connected to a separate USB2 port, showed a write speed of 27.5 Mb/s. I am using: dd if=/dev/zero of=/dev/sdb obs=4M status=progress The read speed was faster, of course. name=Matthew%20Campbell&email=trenix25%40pm.me Original Message On Jun 9, 2020, 2:39 AM, Nicolas George wrote: > Christopher David Howie (12020-06-08): > I'd suggest simply adding > "status=progress" which gives you a summary every > second including bytes > written, elapsed time, and average transfer rate. How do you add > "status=progress" to a process that has already been running for three days? > Regards, -- Nicolas George
Re: Zoom- best practice?
On Tuesday, June 09, 2020 05:45:24 AM Nicolas George wrote: > to...@tuxteam.de (12020-06-09): > > Can we stop that already? Nobody proved you can't build Jitsi or > > BBB from source. Everyone here is just too friggin' lazy to even > > try. > > > > Can we give 'em the benefit of the doubt until someone really makes > > his hands ditry on that? > > You can be naïve and give them the benefit of the doubt. But I will not. > Jitsi is a big project, it claims the reputation benefits of being Libre > Software: the onus of proof is on it. +1 If a project is new, I'm willing to give a project the benefit of the doubt on the assumption that it is a statement of intent, and, as they recognize shortcomings, they will fix them. > I will state and repeat: until we see actual reliable proof, claiming > that Jitsi is Libre Software is wrong. > > > That's how fake news spread, btw. > > > > I think it's somewhat disgusting. Folks, put up... or shut up now. > > Your attempt at irrational shaming is dishonest. > > Regards,
Re: how to use high resolution display with radeon
Cheng Yutong wrote: > I'm using an old graphic card on my debian PC, which is HD 6770, > > and these days i've got a new display that support 2k resolution > (2560x1440), > > but on the Display Setting dialog, btw, my DE is XFCE4, the highest > resolution is 1920x1200. This suggests that the monitor is not sending an EDID block that supports 2560x1440. > i've tried to generate a Modeline with `cvt 2560 1440`, > Good. > # 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz > Modeline "2560x1440_60.00"?? 312.25?? 2560 2752 3024 3488?? 1440 1443 1448 > 1493 -hsync +vsync I hope it doesn't actually have ? question marks in it. > > and add it to the display, but when set it with `xrandr`, it does not work > well, i got an error message: > > > Input Signal Out ofRange! > > Current Mode: > > ?? H = 89.6kHz V = 60Hz > > Change Mode to: > > ?? 1920 x 1200 60Hz That's the monitor saying it doesn't like 2560x1440. What kind of monitor? -dsr-
how to use high resolution display with radeon
hello everyone, I'm using an old graphic card on my debian PC, which is HD 6770, and these days i've got a new display that support 2k resolution (2560x1440), but on the Display Setting dialog, btw, my DE is XFCE4, the highest resolution is 1920x1200. i've tried to generate a Modeline with `cvt 2560 1440`, ``` # 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz Modeline "2560x1440_60.00" 312.25 2560 2752 3024 3488 1440 1443 1448 1493 -hsync +vsync ``` and add it to the display, but when set it with `xrandr`, it does not work well, i got an error message: ``` Input Signal Out ofRange! Current Mode: H = 89.6kHz V = 60Hz Change Mode to: 1920 x 1200 60Hz ``` and i've installed the `firmware-amd-graphics` `firmware-amd-graphics/stable,stable,now 20190114-2 all [installed]`. could someone give some help?
Re: Zoom- best practice?
On Tue, Jun 09, 2020 at 06:41:33AM -0400, The Wanderer wrote: > (Please stop CCing me on replies [...] Sorry. [...] > FWIW, I have tried, at least in part. Thanks for taking the time to do, and thanks for reporting back. [...] > Even a successful build from a repository like that would not > demonstrate that you can actually completely rebuild the project from > scratch [...] Yes, this is a well-known problem with many facets. ISTR that there was a Lisp which only could build itself: the whole buildery (which, this being Lisp included everything, compiler, assembler and all) was written in Lisp, and took advantage of newer and newer features. A full bootstrap involved unearthing "old versions" and following the historical evolution of that thing. Some "ecosystems", like Java, tend to build up a huge network of dependencies on "well-known" components -- something I used to call it the "Java Disease". Until Javascript came with npm, or PHP with composer. It can get worse. Building something significant, like Jitsi, lands you in this hell, and to survive, you end up ingesting those dependencies (that's what is called "vendoring" -- imo the Euphemism of the Decennium). On the other end there are heroes, like the Guix folks [1], or the reproducible build folks [2] working relentlessly on disentangling those things. Debian packaging belongs into that class of heroism. So from my POV there is a lot to critizice there, and a lot to fix -- but "this is not free software just because I'm too lazy to check thoroughly", as some have basically said here is simply unfair -- and counterproductive. Cheers [1] https://guix.gnu.org/ [2] https://reproducible-builds.org/ -- tomás signature.asc Description: Digital signature
Re: Zoom- best practice?
On 2020-06-09 at 06:51, Nicolas George wrote: > The Wanderer (12020-06-09): > >> (Please stop CCing me on replies - especially to messages which I >> did not actually send - unless you're specifically trying to draw >> my attention to a particular message and think I may not notice it >> without the CC. Not only am I subscribed, I am in fact reading this >> thread on a multiple-times-a-day basis, as my multiple replies to >> it to date may have indicated.) > > Instead of writing this periodically, you could include: > Reply-To: debian-user@lists.debian.org > in your headers just like I did. Having to add that by hand to every single reply I make would be much more of a hassle than taking the time to request this explicitly on the relatively few occasions when people send such CCs with enough frequency for it to be a bother to me. > Properly configured mailing-list software does it by default for > subscribed users, but Debian is an exception. It fixes the issue of > annoying ccs once and for all. I subscribe to probably dozens of mailing lists, and I don't know of any way to configure things to add that header with a proper value automatically on a per-mailing-list basis. Otherwise, I'd probably have done this years ago, unless other considerations (e.g., UI for when I want to do this vs. when I really do want to reply to the sender or to all recipients) took precedence. For myself, I use the "Reply to List" button in (a now-old version of) Thunderbird, and avoid the issue of Reply-To settings entirely unless I actually do want to reply to something other than just the list. >> FWIW, I have tried, at least in part. >> >> For the individual broken-out projects (which may or may not be >> rolled up into the larger "master" project, I can't easily tell), I >> succeeded with one, and failed with another, but suspect that I >> could succeed with the latter with more effort. >> >> For the apparent "master" project, I admit that I didn't bother to >> try, because of the exact "too many prebuilt apparent-dependency >> objects with no apparent way provided to rebuild them" issue; >> unless we can rebuild those objects, not only can we not be sure we >> have the source for them, we can't be sure that building with a >> different version of that object will even work. >> >> Even a successful build from a repository like that would not >> demonstrate that you can actually completely rebuild the project >> from scratch; you'd have to actually track down the source for all >> of those individual prebuilt objects, rebuild each one, and pull >> the result in to the build in a way which will get picked up, and >> that's more effort than I'm willing to put in for the sake of a >> mailing-list discussion like this one. > > Thank you for these clarifications. > >> I don't fault the developers too much for providing a version of >> the project tree with prebuilt dependencies like that; it's a >> useful convenience for those who just want to get it to work and >> for whom farting around with trying to find the right dependencies >> and get them into place would be too much of a hassle. But for (as >> far as I can tell) providing the tree in *only* that form, and not >> providing (as far as I've found) *any* documentation on what these >> prebuilt objects are and why they're needed and how to get them >> separately and build them and so forth, there I do fault them, and >> consider that a ding against proper Free status. > > I state it that way: the knowledge of how to obtain and build these > objects is part of the source code of the project, just as much as a > makefile or configure script. Unfortunately, that bit of source code > only resides in the head of the developers, it is not distributed. > > Consider a minified javascript program with a GPL license header > slapped on top of it: should we consider it Libre Software? Of course > not. The same happens here: out of negligence probably, the authors > keep part of the source code for themselves. It is not Libre > Software. While I wouldn't necessarily take the argument as far as you appear to, I am inclined to agree in principle. That said, while this is an important aspect of the situation, it's technically a tangent from the question of whether people other than the developers can build the program and have the result be usable. If we assume that the developers don't routinely update or replace these prebuilt objects, and don't hack these objects themselves as part of working on the project, then the tree we have is the tree the developers build from - and if we can build a working program from it, then that narrower question is answered "yes". I just don't care to bother with doing that myself at present. Which, to an extent, turns things back to Tomas' point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable
Re: Zoom- best practice?
The Wanderer (12020-06-09): > (Please stop CCing me on replies - especially to messages which I did > not actually send - unless you're specifically trying to draw my > attention to a particular message and think I may not notice it without > the CC. Not only am I subscribed, I am in fact reading this thread on a > multiple-times-a-day basis, as my multiple replies to it to date may > have indicated.) Instead of writing this periodically, you could include: Reply-To: debian-user@lists.debian.org in your headers just like I did. Properly configured mailing-list software does it by default for subscribed users, but Debian is an exception. It fixes the issue of annoying ccs once and for all. > FWIW, I have tried, at least in part. > > For the individual broken-out projects (which may or may not be rolled > up into the larger "master" project, I can't easily tell), I succeeded > with one, and failed with another, but suspect that I could succeed with > the latter with more effort. > > For the apparent "master" project, I admit that I didn't bother to try, > because of the exact "too many prebuilt apparent-dependency objects with > no apparent way provided to rebuild them" issue; unless we can rebuild > those objects, not only can we not be sure we have the source for them, > we can't be sure that building with a different version of that object > will even work. > > Even a successful build from a repository like that would not > demonstrate that you can actually completely rebuild the project from > scratch; you'd have to actually track down the source for all of those > individual prebuilt objects, rebuild each one, and pull the result in to > the build in a way which will get picked up, and that's more effort than > I'm willing to put in for the sake of a mailing-list discussion like > this one. Thank you for these clarifications. > I don't fault the developers too much for providing a version of the > project tree with prebuilt dependencies like that; it's a useful > convenience for those who just want to get it to work and for whom > farting around with trying to find the right dependencies and get them > into place would be too much of a hassle. But for (as far as I can tell) > providing the tree in *only* that form, and not providing (as far as > I've found) *any* documentation on what these prebuilt objects are and > why they're needed and how to get them separately and build them and so > forth, there I do fault them, and consider that a ding against proper > Free status. I state it that way: the knowledge of how to obtain and build these objects is part of the source code of the project, just as much as a makefile or configure script. Unfortunately, that bit of source code only resides in the head of the developers, it is not distributed. Consider a minified javascript program with a GPL license header slapped on top of it: should we consider it Libre Software? Of course not. The same happens here: out of negligence probably, the authors keep part of the source code for themselves. It is not Libre Software. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
(Please stop CCing me on replies - especially to messages which I did not actually send - unless you're specifically trying to draw my attention to a particular message and think I may not notice it without the CC. Not only am I subscribed, I am in fact reading this thread on a multiple-times-a-day basis, as my multiple replies to it to date may have indicated.) On 2020-06-09 at 04:42, to...@tuxteam.de wrote: > On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote: >> If you cannot build an executable from source, you do not know >> whether the binary you downloaded represents the source >> faithfully. > > Can we stop that already? Nobody proved you can't build Jitsi or BBB > from source. Everyone here is just too friggin' lazy to even try. > > Can we give 'em the benefit of the doubt until someone really makes > his hands ditry on that? FWIW, I have tried, at least in part. For the individual broken-out projects (which may or may not be rolled up into the larger "master" project, I can't easily tell), I succeeded with one, and failed with another, but suspect that I could succeed with the latter with more effort. For the apparent "master" project, I admit that I didn't bother to try, because of the exact "too many prebuilt apparent-dependency objects with no apparent way provided to rebuild them" issue; unless we can rebuild those objects, not only can we not be sure we have the source for them, we can't be sure that building with a different version of that object will even work. Even a successful build from a repository like that would not demonstrate that you can actually completely rebuild the project from scratch; you'd have to actually track down the source for all of those individual prebuilt objects, rebuild each one, and pull the result in to the build in a way which will get picked up, and that's more effort than I'm willing to put in for the sake of a mailing-list discussion like this one. I don't fault the developers too much for providing a version of the project tree with prebuilt dependencies like that; it's a useful convenience for those who just want to get it to work and for whom farting around with trying to find the right dependencies and get them into place would be too much of a hassle. But for (as far as I can tell) providing the tree in *only* that form, and not providing (as far as I've found) *any* documentation on what these prebuilt objects are and why they're needed and how to get them separately and build them and so forth, there I do fault them, and consider that a ding against proper Free status. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Zoom- best practice?
to...@tuxteam.de (12020-06-09): > Can we stop that already? Nobody proved you can't build Jitsi or > BBB from source. Everyone here is just too friggin' lazy to even > try. > > Can we give 'em the benefit of the doubt until someone really makes > his hands ditry on that? You can be naïve and give them the benefit of the doubt. But I will not. Jitsi is a big project, it claims the reputation benefits of being Libre Software: the onus of proof is on it. I will state and repeat: until we see actual reliable proof, claiming that Jitsi is Libre Software is wrong. > That's how fake news spread, btw. > > I think it's somewhat disgusting. Folks, put up... or shut up now. Your attempt at irrational shaming is dishonest. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: How long will this take?
Christopher David Howie (12020-06-08): > I'd suggest simply adding "status=progress" which gives you a summary every > second including bytes written, elapsed time, and average transfer rate. How do you add "status=progress" to a process that has already been running for three days? Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Zoom- best practice?
On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote: > > > On 6/7/20 14:14, Russell L. Harris wrote: > > On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote: > >> Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi, > >> as shipped in those packages. > >> > >> Presumably, as those packages are for download from the authors' > >> Website, the authors are the ones who built them. Thus, this doesn't > >> demonstrate that anyone other than the authors have been able to build > >> Jitsi. > > > > So? It is an open-source alternative to Zoom, and it works. Of > > course, if you are worried that the builders put in something > > malicious or dangerous which is not in the open source repository, > > then you can turn to Zoom, or build your own, or do without... > > > > Though objectivity is prudent, we ought be promoting alternatives to > > Zoom, rather than torpedoing them. > > If you cannot build an executable from source, you do not know whether > the binary you downloaded represents the source faithfully. Can we stop that already? Nobody proved you can't build Jitsi or BBB from source. Everyone here is just too friggin' lazy to even try. Can we give 'em the benefit of the doubt until someone really makes his hands ditry on that? That's how fake news spread, btw. I think it's somewhat disgusting. Folks, put up... or shut up now. Cheers -- t signature.asc Description: Digital signature
Re: How long will this take?
On Lu, 08 iun 20, 20:09:54, Jude DaShiell wrote: > > From: Dan Ritter > People are suing Western Digital for sneaking those SMR disks into their > supply chain. They're supposed to be red in color if what I read in the > news is correct. > > > > https://www.ixsystems.com/community/resources/list-of-known-smr-drives.141/ According to that list it's only specific model numbers of WD Red and Blue. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Trouble with 2011 iMac Sound Card On Debian
On Lu, 08 iun 20, 16:11:02, Keifer Bly wrote: > Hi all, > > So I installed Debian on a 2011 iMac and it is working ok, except for the > sound. There is no sound from either the speaker or the headphone jack. > > When I go to the system settings, the volum option is completely greyed out. > > Running cat /proc/asound/cards in UXTerm returned this: > > 0 [PCH ]:HDA-Intel - HDA Intel PCH >HDA Intel PCH at 0xa890 irq 47 > 1 [HDMI]: HDA-Intel - HDA ATI HDMI > HDA ATI HDMI at 0xa884 irq 48 > > I am wondering why the speaker and headphone jack would not work when the > sound card is recognized? Thanks very much. You could try poking around in alsamixer (package alsa-utils) to unmute (M) channels or change volume levels. Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How long will this take?
On 2020-06-08 13:22, Matthew Campbell wrote: I bought a new 4 terrabyte hard drive that is connected with a USB cable using USB2. It took about 32 hours to read every sector on the drive to look for bad sectors. I started blanking the sectors using /dev/zero last Friday night. It still isn't done. Is there a way I can find out how much data a particular process has written to the disk? I'm using Debian 10.4. dd if=/dev/zero of=/dev/sdb ibs=4096 count=976754646 name=Matthew%20Campbell&email=trenix25%40pm.me Install 'nmon'. Then start a terminal and run 'nmon'. Press 'd' to display the disk monitoring screen. This will show read throughput, write throughput, and percent utilization. Alternatively, if you are using the Xfce desktop, add a Disk Performance Monitor applet to the panel and configure it for the correct device node /dev/sdX: Device /dev/sdX unchecked Label sdX Update interval(s) 1.000 Monitor Busy time checked Combine Read/Write data Then hover your mouse pointer over the applet and it will show you read, write, and total statistics for both throughput and for busy time. USB 2.0 ports have a maximum write speed around 25 MB/s. eSATA ports (version 1) get much closer to their theoretical maximum of 150 MB/s. USB 3.0 beats them both. Of course, you must have a fast drive and a fast program. When using dd(1) to write blocks to a raw drive, use a block size of 1M (e.g. 1 Mibabyte). As others have stated, a small block size of 4K will significantly reduce throughput due to I/O overhead. Also as others have stated, writing zeros to an SSD may wear it out prematurely (depends upon internals of SSD). The best approach is to do a "secure erase". Rather than wiping storage devices with GNU/Linux userland tools, your best bet is to use the manufacturer's diagnostic utility. In the ideal case, the utility sends a command to the drive controller and everything gets done internally at maximum speed. I prefer the bootable "Live" tools, if available. Each manufacturer has their own toolkit. Get the one for your drive brand. For example, SeaTools Bootable: https://www.seagate.com/support/downloads/seatools/ David