On 11/07/2019 20:59, Alan Grimes wrote:
'ey, I have the 2.3 months into an 8-month computation blues...
[...]
So basically all gentoo updates will have to be done at the end of this
run, I'm not really sure when, sometime in the December-January timeframe.
I guess you should have written your
On 11/07/2019 20:03, Ian Zimmerman wrote:
What is the cleanest way to handle the situation when a new sysctl knob
is introduced by a kernel release and I want to use it, but I also have
older kernels around?
What's the point of that?
> So the solution is to just use "xscreensaver" by jwz. Which can be
> configured to just blank the screen etc. as wanted by the op. See
> also
> the FAQ: https://www.jwz.org/xscreensaver/faq.html
>
> HTH,
> -dnh
>
Except I use xscreensaver myself and it in no way prevents VT switch,
which is
Hello,
On Thu, 11 Jul 2019, Laurence Perkins wrote:
>You could also leave DontVTSwitch on all the time and set a keyboard
>shortcut to run chvt (man 1 chvt) with appropriate permissions and
>parameters instead. Keyboard shortcuts shouldn't get processed if the
>screen is locked.
The screensaver
On Thursday, 11 July 2019 23:31:51 BST Jack wrote:
> I'm hoping the cumulative wisdom of the assembled masses might be able
> to figure out what I'm clearly missing, assuming there IS something I'm
> missing.
>
> I've recently assembled a new PC, with an MSI B350-Tomahawk motherboard
> and a
I'm hoping the cumulative wisdom of the assembled masses might be able
to figure out what I'm clearly missing, assuming there IS something I'm
missing.
I've recently assembled a new PC, with an MSI B350-Tomahawk motherboard
and a Ryzen 5 2600 CPU. (We'll skip that I ended up actually
You could also leave DontVTSwitch on all the time and set a keyboard
shortcut to run chvt (man 1 chvt) with appropriate permissions and
parameters instead. Keyboard shortcuts shouldn't get processed if the
screen is locked.
LMP
On Thu, 2019-07-11 at 21:01 +, artur.tamm...@gmail.com wrote:
>
I tried to google if it is possible to change xorg serverflags in runtime,
but was unable to find anything. I think that would be a cleaner solution
(changing the DontVTSwitch option before locking and then restoring later).
Artur
Ian Zimmerman writes:
On 2019-07-11 09:57, Ian Zimmerman
On 2019-07-11 09:57, Ian Zimmerman wrote:
> > setxkbmap -option srvrkeys:none
> > i3lock -c 003355 -n
> > setxkbmap -option ''
>
> Thanks for the idea! It won't work as is for me because I already use
> some non-default xkb options. But it is closer than anything that has
> come up yet. I'll
On 2019-07-10, François-Xavier CARTON wrote:
> On 7/10/19 7:03 PM, Ian Zimmerman wrote:
>> Here is my next "low information" question, haha.
>>
>> I use i3lock which is like Xscreensaver but much much simpler; it plays
>> no movies or games, just blanks the screen with a configured color or
>>
>You could still use USGCB (or which ever standard the auditors regard highly)
>but then document the differences with a
>note explaining why. For USGCB I'd add another column to the spreadsheet with
>options of compliant/non compliant with
>mitigations/non compliant/not applicable and another
'ey, I have the 2.3 months into an 8-month computation blues... I
stupidly fired up my number theory code which grows at roughly 3^x
(where X = 49 right now...).
(current position in the search space:
0x149b87d9 ) 0 hits so far, the set I'm
looking for is
What is the cleanest way to handle the situation when a new sysctl knob
is introduced by a kernel release and I want to use it, but I also have
older kernels around? I think the error is not fatal so I can simply
add it to sysctl.conf, but the message is going to be ugly.
--
Please don't Cc: me
On 2019-07-10 23:46, artur.tamm...@gmail.com wrote:
> #!/bin/bash
> setxkbmap -option srvrkeys:none
> i3lock -c 003355 -n
> setxkbmap -option ''
Thanks for the idea! It won't work as is for me because I already use
some non-default xkb options. But it is closer than anything that has
come up
On 2019-07-11 10:43, Adam Carter wrote:
> > No, it's my way to run things as root, in general. I distrust su, sudo
> > and friends.
> >
>
> su is mature, well understood and the standard way of doing things. If you
> had run an extra term in your X session that had been su'd to root, you
>
On Wednesday, 10 July 2019 18:40:04 BST Mick wrote:
> Normally, I don't think any of the above is required. From what I recall
> akonadiserver runs mysql_upgrade each and every time akonadiserver is
> launched. However, if akonadi can't run the kdepim mysql following a
> database version
On Wednesday, 10 July 2019 18:40:04 BST Mick wrote:
> On Wednesday, 10 July 2019 14:31:19 BST Peter Humphrey wrote:
> > On Wednesday, 10 July 2019 10:06:01 BST Peter Humphrey wrote:
> > > On Wednesday, 10 July 2019 00:06:43 BST Adam Carter wrote:
> > > > > I've just tried upgrading mariadb again
17 matches
Mail list logo