Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021/09/27 at 11:07pm, Grant Edwards wrote: > On 2021-09-27, Spackman, Chris wrote: > > > If it is still working, that is great news for users of > > Chromium-based browsers that aren't Google Chrome, but I don't think > > it is safe to expect the behavior to continue. > > It's Google. It's not safe to expect _any_ behavior to continue. :) It's funny because it's true. *Sigh* -- Chris Spackman (he / him) ch...@osugisakae.com ESL Coordinator The Graham Family of Schools ESL Instructor Columbus State Community College Japan Exchange and Teaching Program Wajima, Ishikawa 1995-1998 Linux user since 1998 Linux User #137532
[gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021-09-27, Spackman, Chris wrote: > If it is still working, that is great news for users of Chromium-based > browsers that aren't Google Chrome, but I don't think it is safe to > expect the behavior to continue. It's Google. It's not safe to expect _any_ behavior to continue. :)
Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021/09/27 at 07:31pm, Neil Bothwick wrote: > On Mon, 27 Sep 2021 11:23:58 -0700, Mark Knecht wrote: > > I couldn't (easily - I'm very busy right now) figure out how to get > > Chrome and Chromium to sync bookmarks and passwords and I want > > Windows, Android and Linux (all flavors) to be in sync if possible. > I use Chromium on my computers and Chrome on my phone and the > bookmarks are kept in sync without any action on my part. It seems > there is no difference between Chrome and Chromium in this regard. Is sync still working? I thought that Google had closed whatever loophole had allowed not-Chrome browsers to sync with Google Chrome. https://support.google.com/chrome/thread/122570052/sync-and-login-no-longer-works-in-chromium?hl=en https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed I also remember that on the Twit network, either This Week In Tech or maybe Security Now talked about Google closing that "bug". If it is still working, that is great news for users of Chromium-based browsers that aren't Google Chrome, but I don't think it is safe to expect the behavior to continue. -- Chris Spackman (he / him) ch...@osugisakae.com ESL Coordinator The Graham Family of Schools ESL Instructor Columbus State Community College Japan Exchange and Teaching Program Wajima, Ishikawa 1995-1998 Linux user since 1998 Linux User #137532
[gentoo-user] Dovecot config
I'm trying to configure dovecot to give me a mix of virtual and real
users. It's working fine for my real id.
But it's not working for my antlists virtual id :-(
I know it's the authentication messing up, but I don't know what or how
to fix it - I don't use anything more complicated than /etc/passwd, and
it looks like it's desperate to use pam.auth and getting itself all in a
twist.
If I create the dovecot passwd file with
antlists:{PLAIN}password
thunderbird complains that there's a problem with the server.
But if I use htpasswd to create the entry in the passwd file, it complains
pam_faillock(imap:auth): User unknown
So as a complete guess, I'm thinking maybe htpasswd and dovecot are
using different encryptions? I just don't have a clue how to get them on
the same page ...
Cheers,
Wol
Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On Mon, 27 Sep 2021 11:23:58 -0700, Mark Knecht wrote: > Yes, I tried that. In my case it just made no difference. Everything > worked on Chromium as suggested but I couldn't (easily - I'm very busy > right now) figure out how to get Chrome and Chromium to sync bookmarks > and passwords and I want Windows, Android and Linux (all flavors) to > be in sync if possible. I use Chromium on my computers and Chrome on my phone and the bookmarks are kept in sync without any action on my part. It seems there is no difference between Chrome and Chromium in this regard. -- Neil Bothwick Profanity, The Language of Computer Professionals. pgpfPpxs5E1JU.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On Mon, Sep 27, 2021 at 10:48 AM Grant Edwards wrote: > > On 2021-09-27, Mark Knecht wrote: > > On Mon, Sep 27, 2021 at 7:25 AM Grant Edwards > > wrote: > >> > >> But now the "Use system title bars and borders" option doesn't work. > > > > Strangely the dragging a tab problem has never occured for me on > > Kubuntu. > > I think the window dragging problem only happened with some window > managers. > > [regarding titlebar breakage] > > I run stable so I haven't seen the fix in Chrome beta yet but > > good to know it's coming. In my case I took Frank's suggestion > > and implemented the window on a virtual desktops and now I > > don't have to mess with my mouse and the title bar pin. > > Did you try the fix mentioned elsewhere: go to chrome://flags and > disable something with the words "ozone" and "X11" in it? > > That fixed the titlebar problem for me. > > -- > Grant Yes, I tried that. In my case it just made no difference. Everything worked on Chromium as suggested but I couldn't (easily - I'm very busy right now) figure out how to get Chrome and Chromium to sync bookmarks and passwords and I want Windows, Android and Linux (all flavors) to be in sync if possible. For me Frank's Meta-a solution is a really good one for right now. Will investigate more in a few weeks when my workload gets more normal. Cheers, Mark
[gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021-09-27, Mark Knecht wrote: > On Mon, Sep 27, 2021 at 7:25 AM Grant Edwards > wrote: >> >> But now the "Use system title bars and borders" option doesn't work. > > Strangely the dragging a tab problem has never occured for me on > Kubuntu. I think the window dragging problem only happened with some window managers. [regarding titlebar breakage] > I run stable so I haven't seen the fix in Chrome beta yet but > good to know it's coming. In my case I took Frank's suggestion > and implemented the window on a virtual desktops and now I > don't have to mess with my mouse and the title bar pin. Did you try the fix mentioned elsewhere: go to chrome://flags and disable something with the words "ozone" and "X11" in it? That fixed the titlebar problem for me. -- Grant
Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On Mon, Sep 27, 2021 at 7:25 AM Grant Edwards wrote: > > On 2021-03-12, Grant Edwards wrote: > > Yesterday afternoon, both Chrome and Chromium started behaving oddly. > > > > When I drag a tab out of it's parent window to create a new window > > (this is something I do a lot, every day), it works normally until I > > release the mouse button. Then, instead of staying where it's put the > > new window will follow the mouse cursor around the desktop anytime > > Chrom(e|ium) has focus. > > It looks like this has been fixed! > > But now the "Use system title bars and borders" option doesn't work. > > -- > Grant > Strangely the dragging a tab problem has never occured for me on Kubuntu. I run stable so I haven't seen the fix in Chrome beta yet but good to know it's coming. In my case I took Frank's suggestion and implemented the window on a virtual desktops and now I don't have to mess with my mouse and the title bar pin. Cheers, Mark
Re: [gentoo-user] console scrollback (kernel 5.14)
On Mon, Sep 27, 2021 at 12:51 AM Dale wrote: > > Jorge Almeida wrote: > > On Sun, Sep 26, 2021 at 6:24 PM antlists wrote: > > Hello, Wol and Dale > >> When you rebuild it, get a surge protector and then put a UPS behind > >> that ... snag is that's all extra expense :-( > >> > Hope that info helps. Also hope you can find something to prevent > future problems. > Thanks, Dale and Wol. I'll give it some thought. First thing is to replace the PSU and see how it goes. I may ask for your opinions before buying UPS & surge protector when I'll have it sorted out. Jorge
[gentoo-user] Re: Chrome - no system title bar or boarders
On 2021-09-25, Spackman, Chris wrote: > > I use Fluxbox and had the same issue. Found this today: > > https://piunikaweb.com/2021/09/23/google-chrome-94-use-system-title-bar-and-borders-checkbox-broken/ > > To fix the problem: > > > > you will need to head over to the chrome://flags page and find the > “use-ozone-platform” setting. > > Make sure to change it from default to disabled, restart your Chrome > browser and you will be good to go." > > > > I can confirm that this worked for me here. Fixed it for me (openbox). -- Grant
[gentoo-user] Re: Chrome - no system title bar or boarders
On 2021-09-23, Mark Knecht wrote: > Starting yesterday morning both of my KDE machines no longer show a system > title bar or border for Chrome, and only Chrome. All other apps are fine. Same here, but I don't have any "desktop environment". I just use the openbox window manager. At least they fixed the bug where dragging a tab to form a new window resulted in a window that didn't stay where it was dropped: instead it used to follow the mouse around until you hit a key. > Right clicking the Chrome tab area has a checkbox for 'Use system > title bar and borders' but it does nothing. Same here > Chrome version 94.0.4606.54. Version 94.0.4606.61 (Official Build) (64-bit) The 'Use system title bar and border' options still works fine in Chromium Version 94.0.4606.54 (Developer Build) (64-bit) -- Grant
[gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021-03-12, Grant Edwards wrote: > Yesterday afternoon, both Chrome and Chromium started behaving oddly. > > When I drag a tab out of it's parent window to create a new window > (this is something I do a lot, every day), it works normally until I > release the mouse button. Then, instead of staying where it's put the > new window will follow the mouse cursor around the desktop anytime > Chrom(e|ium) has focus. It looks like this has been fixed! But now the "Use system title bars and borders" option doesn't work. -- Grant
Re: [gentoo-user] How to compress lots of tarballs
On Monday, 27 September 2021 14:30:36 BST Peter Humphrey wrote:
> On Monday, 27 September 2021 02:39:19 BST Adam Carter wrote:
> > On Sun, Sep 26, 2021 at 8:57 PM Peter Humphrey
> >
> > wrote:
> > > Hello list,
> > >
> > > I have an external USB-3 drive with various system backups. There are
> > > 350
> > > .tar files (not .tar.gz etc.), amounting to 2.5TB. I was sure I wouldn't
> > > need to compress them, so I didn't, but now I think I'm going to have
> > > to.
> > > Is there a reasonably efficient way to do this?
> >
> > find -name \*tar -exec zstd -TN {} \;
> >
> > Where N is the number of cores you want to allocate. zstd -T0 (or just
> > zstdmt) if you want to use all the available cores. I use zstd for
> > everything now as it's as good as or better than all the others in the
> > general case.
> >
> > Parallel means it uses more than one core, so on a modern machine it is
> > much faster.
>
> Thanks to all who've helped. I can't avoid feeling, though, that the main
> bottleneck has been missed: that I have to read and write on a USB-3 drive.
> It's just taken 23 minutes to copy the current system backup from USB-3 to
> SATA SSD: 108GB in 8 .tar files.
I was premature. In contrast to the 23 minutes to copy the files from USB-3 to
internal SSD, zstd -T0 took 3:22 to compress them onto another internal SSD. I
watched /bin/top and didn't see more than 250% CPU (this is a 24-CPU box) with
next-to-nothing else running. The result was 65G of .tar.zst files.
So, at negligible cost in CPU load*, I can achieve a 40% saving in space. Of
course, I'll have to manage the process myself, and I still have to copy the
compressed files back to USB-3 - but then I am retired, so what else do I have
to do? :)
Thanks again, all who've helped.
* ...so I can continue running my 5 BOINC projects at the same time.
--
Regards,
Peter.
Re: [gentoo-user] Chrome - no system title bar or boarders
On Sun, Sep 26, 2021 at 5:58 PM Mark Knecht wrote: > > > > On Sun, Sep 26, 2021, 8:19 AM Frank Steinmetzger wrote: >> >> Am Thu, Sep 23, 2021 at 09:53:57AM -0700 schrieb Mark Knecht: >> >> > Starting yesterday morning both of my KDE machines no longer show a system >> > title bar or border for Chrome, and only Chrome. All other apps are fine. >> > Right clicking the Chrome tab area has a checkbox for 'Use system title bar >> > and borders' but it does nothing. Chrome version 94.0.4606.54. >> > >> > Losing the title bar means losing (as far as I know) the ability to pin an >> > instance of Chrome to all virtual desktops which I use for browser streamed >> > media - YouTube, Netflix, etc. >> >> Not a solution, but a workaround: >> I’ve been using keyboard shortcuts for this kind of function for many years. >> >> Super+A = Window on all desktops >> Super+F = Fullscreen >> Super+Shift+F = Toggle window border >> Super+S = Shade window >> Super+T = Window on top Worked like a charm Frank. Thanks very much. One individual on AskUbuntu says the problem is fixed in a beta release of Chrome but your solution works for all apps which is nicer. Cheers, Mark
Re: [gentoo-user] How to compress lots of tarballs
On Monday, 27 September 2021 02:39:19 BST Adam Carter wrote:
> On Sun, Sep 26, 2021 at 8:57 PM Peter Humphrey
>
> wrote:
> > Hello list,
> >
> > I have an external USB-3 drive with various system backups. There are 350
> > .tar files (not .tar.gz etc.), amounting to 2.5TB. I was sure I wouldn't
> > need to compress them, so I didn't, but now I think I'm going to have to.
> > Is there a reasonably efficient way to do this?
>
> find -name \*tar -exec zstd -TN {} \;
>
> Where N is the number of cores you want to allocate. zstd -T0 (or just
> zstdmt) if you want to use all the available cores. I use zstd for
> everything now as it's as good as or better than all the others in the
> general case.
>
> Parallel means it uses more than one core, so on a modern machine it is
> much faster.
Thanks to all who've helped. I can't avoid feeling, though, that the main
bottleneck has been missed: that I have to read and write on a USB-3 drive.
It's just taken 23 minutes to copy the current system backup from USB-3 to
SATA SSD: 108GB in 8 .tar files.
Perhaps I have things out of proportion.
--
Regards,
Peter.
