copy and paste, under Wayland, and to and from an XTerm, was relating to dl audio and video
18 Aug
2020
18 Aug
'20
6:54 a.m.
Hello Craig,
Many thanks for your excellent posts, I am learning more. However I
have Debian 10, nominally up to date, and it has Wayland with Gnome as
the desktop. I am finding it very frustrating that I cannot copy and
paste to and from the XTerm window. I used to be able to do with
earlier terminal emulation under the XWindows system. I used it to be
able to copy text from a terminal into an email, and commands back
from email, ensuring that I did not make typos. I do understand that
there can be security issues if used without a measure of care and
thoughtful, but it also has much merit when coping with some of the
regular expressions that come up as examples in email and on web
pages.
Regards,
Mark Trickett
30 Aug
30 Aug
4:48 a.m.
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark Trickett wrote:
Many thanks for your excellent posts, I am learning
more. However I have
Debian 10, nominally up to date, and it has Wayland with Gnome as the
desktop. I am finding it very frustrating that I cannot copy and paste to
and from the XTerm window.
Sorry, i don't use Wayland, have no idea what could be going wrong with this.
I can't see the point of Wayland. TBH, it seems like the systemd of X - a
half-arsed crappy partial implementation of only the stuff that the devs
personally use because there's no way that anyone else could ever need
anything they don't use.
Also, CADT syndrome: never fix anything. toss out the old garbage, make way
for the shiny new garbage. Fixing bugs is boring. Reimplementing from scratch
every year or two is fun and exciting and it'll be perfect. For sure, this
time.
I used to be able to do with earlier terminal
emulation under the XWindows
system. I used it to be able to copy text from a terminal into an email, and
commands back from email, ensuring that I did not make typos.
That's weird. i'd be surprised if Wayland was actually incapable of doing
something as basic as copy and paste between terminal windows, so it's
probably a bug or a configuration error.
Maybe try a different terminal instead of xterm. There are dozens to
choose from. I mostly use roxterm (full-height apart from the space used by
xfce4-panel, full-width, approx 250x60 depending on font size - great for
viewing log files), but sometimes I use xfce4-terminal if i want a tall,
narrow window (80 or 132 x 60) to fit beside something else.
I do understand that there can be security issues if
used without a measure
of care and thoughtful, but it also has much merit when coping with some of
the regular expressions that come up as examples in email and on web pages.
the "security issues" comes from blindly executing code/commands that you
don't understand.
treat everything as just an example that needs further research. never execute
something posted by someone else(*) unless you know what it does and how and why.
(*) ANYONE else. even if they're trustworthy and not malicious, they could be
wrong, they might have made a mistake.
craig
--
craig sanders <cas(a)taz.net.au>
5:01 a.m.
On Sun, 30 Aug 2020, Craig Sanders wrote:
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark
Trickett wrote:
It theoretically is not safe to simple paste the selection into an editor
before vetting it. Through CSS and javascript, what you select in a
browser and what ends up in the copy-paste buffer are frequently
different.
That copy paste buffer may contain ANSI-escape sequences to exit your
editor and run a command directly.
https://news.ycombinator.com/item?id=10554679
https://security.stackexchange.com/questions/39118/how-can-i-protect-myself…
--
Tim Connors
I do understand that there can be security issues
if used without a measure
of care and thoughtful, but it also has much merit when coping with some of
the regular expressions that come up as examples in email and on web pages.
the "security issues" comes from blindly executing code/commands that you
don't understand.
treat everything as just an example that needs further research. never execute
something posted by someone else(*) unless you know what it does and how and why. 
5:16 a.m.
On 30/8/20 3:01 pm, Tim Connors via luv-main wrote:
It theoretically is not safe to simple paste the
selection into an editor
before vetting it. Through CSS and javascript, what you select in a
browser and what ends up in the copy-paste buffer are frequently
different.
I notice that XUbuntu 20.04 now has a paste preview window that shows up
any time you paste data containing at least one carriage return so you
can decide whether to permit the paste or block it. Very useful!
Cheers,
Andrew
--
mailto:andrew@sericyb.com.au Andrew Pam
https://sericyb.com.au/ Manager, Serious Cybernetics
https://glasswings.com.au/ Partner, Glass Wings
8:55 a.m.
On Sun, Aug 30, 2020 at 03:01:50PM +1000, Tim Connors wrote:
It's true that there's a risk if you're copying from a web page (or something
else that does css and/or javascript - or any kind of scripting, there's a
difference between "dead" static data and active scripting, which is one of
the reasons I hate over-use of javascript in the web, it's analagous to the
difference between a live virus and a dead one). Especially so if you're
just copying from some random site you have no reason to trust....and less
so if you're copying from a well-known, mostly-trustworthy site like one of
the stack-exchanges (but remember that this still doesn't protect you from
errors).
not true if you're copying plain text from a text mail client like mutt.
also not much of a risk if instead of copy-paste, you save the email or web
page or whatever to a text file and then extract what you need from the text
file.
craig
--
craig sanders <cas(a)taz.net.au>
On Sun, 30 Aug 2020, Craig Sanders wrote:
> the "security issues" comes from blindly executing code/commands that you
> don't understand.
ok, yeah, I should have started that line with "MOST OF"
treat
everything as just an example that needs further research. never execute
something posted by someone else(*) unless you know what it does and how and why.
It theoretically is not safe to simple paste the selection into an editor
before vetting it. Through CSS and javascript, what you select in a
browser and what ends up in the copy-paste buffer are frequently
different.
7:24 a.m.
Hello Craig,
On 8/30/20, Craig Sanders via luv-main <luv-main(a)luv.asn.au> wrote:
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark
Trickett wrote:
I did not choose Wayland, nor systemd, but that is now the Debian
defaults. There are good reasons behind the changes, or at least I
have seen some support that I will concur with on why Wayland over
xwindows. However I do not find benefit in systemd, the current
install (Debian 10.5) is missing a piece of firmware, but I cannot
read the message in time during boot, nor find it in the logs. I think
it is for the network on the motherboard.
Many thanks for your excellent posts, I am
learning more. However I have
Debian 10, nominally up to date, and it has Wayland with Gnome as the
desktop. I am finding it very frustrating that I cannot copy and paste to
and from the XTerm window.
Sorry, i don't use Wayland, have no idea what could be going wrong with
this.
I can't see the point of Wayland. TBH, it seems like the systemd of X - a
half-arsed crappy partial implementation of only the stuff that the devs
personally use because there's no way that anyone else could ever need
anything they don't use. Also, CADT syndrome: never fix anything. toss out the
old garbage, make way
for the shiny new garbage. Fixing bugs is boring. Reimplementing from
scratch every year or two is fun and exciting and it'll be perfect. For sure, this
time.
I used to be able to do with earlier terminal
emulation under the
XWindows
system. I used it to be able to copy text from a terminal into an email,
and
commands back from email, ensuring that I did not make typos.
That's weird. i'd be surprised if Wayland was actually incapable of doing
something as basic as copy and paste between terminal windows, so it's
probably a bug or a configuration error. From my reading of pages found by a google search,
there is a choice
by the development team based on (in)security of casual copy and
paste. I thought that it was likely a configuration issue, but cannot
find. I tried a number of teminals, but not a lot, to find one that
appears to be reasonable. I still need to do more research, when life
leaves the time from the real world.
Maybe try a different terminal instead of xterm.
There are dozens to
choose from. I mostly use roxterm (full-height apart from the space used by
xfce4-panel, full-width, approx 250x60 depending on font size - great for
viewing log files), but sometimes I use xfce4-terminal if i want a tall,
narrow window (80 or 132 x 60) to fit beside something else.
That is why it is not implemented, even for those of us who do
carefully look over such before copying and executing. I cannot make
sense of a line of perl at this time, but there are some folks I will
trust, such as you and Russel Coker. I do not expect you to be
perfect, but that you do know more than I, and from what I have seen,
not malicious. I do try to comprehend even your examples first, but
have to trust that you do know that much more in the subject of
concern.
I do understand that there can be security issues
if used without a
measure
of care and thoughtful, but it also has much merit when coping with some
of
the regular expressions that come up as examples in email and on web
pages.
the "security issues" comes from blindly executing code/commands that you
don't understand. treat everything as just an example that needs further
research. never
execute
something posted by someone else(*) unless you know what it does and how and
why.
(*) ANYONE else. even if they're trustworthy and not malicious, they could
be
wrong, they might have made a mistake.
Anyone can make a mistake, unfortunately some people are a mistake.
craig
Regards,
Mark Trickett
9:32 a.m.
On Sun, Aug 30, 2020 at 05:24:39PM +1000, Mark Trickett wrote:
I did not choose Wayland, nor systemd, but that is now
the Debian
defaults. There are good reasons behind the changes, or at least I have seen
some support that I will concur with on why Wayland over xwindows. However I
do not find benefit in systemd,
most of my machines run systemd now. all but one, which just fails to boot at
all if i try to boot it with systemd rather than sysvinit. I'm not entirely
happy with that but i've given up fighting against it, i just don't have the
energy for that.
I don't actually mind systemd as an init system, i.e. starting and stopping
services - it's pretty good at that. it's all the other stuff (like ntp and
dns and cron) that it tries to do that pisses me off, especially since it does
such a shitty job of them.
I just disable as much of that systemd borg shit as I can and run the required
services as extra daemons, like ntpd for ntp and unbound for dns resolution
(I still use bind9 on a different IP address for serving my zones) and vixie
cron.
the current install (Debian 10.5) is missing a piece
of firmware, but I
cannot read the message in time during boot, nor find it in the logs. I
think it is for the network on the motherboard.
try something like 'journalctl -xe -b0', or 'dmesg | less'. You may be
able
to find the message you want by searching through that.
From my reading of pages found by a google search,
there is a choice by the
development team based on (in)security of casual copy and paste. I thought
that it was likely a configuration issue, but cannot find. I tried a number
of teminals, but not a lot, to find one that appears to be reasonable. I
still need to do more research, when life leaves the time from the real
world.
that would be kind of fucked up if they've disabled copy-paste into terminals
or text editors entirely. so fucked up that that i can't believe anyone would
do that deliberately...there has to be some way to do it, or some way to
re-enable it.
off-by-default is merely annoying, but no big deal. off-forever would be
inexcusable.
I cannot make sense of a line of perl at this time,
perl's really not that hard. if you have some basic scripting capability
(or an ability to understand algorithms and flow control), and some passing
familiarity with shell scripts or sed or awk, then perl is easy.
it's nowhere near as difficult as some people like to make out. and learning
some perl is at least as useful as learning sh and sed and awk put together.
just ignore all the dickheads who say bullshit like "perl is write-only" or
that it "looks like line-noise". they have no idea what they're talking
about
- at best, they're just scared of the sight of regexps as operators - beware
the wild regexp, cage it in a function call or it'll get you.
but there are some folks I will trust, such as you and
Russel Coker. I do
not expect you to be perfect, but that you do know more than I, and from
what I have seen, not malicious. I do try to comprehend even your examples
first, but have to trust that you do know that much more in the subject of
concern.
oh. I didn't mean me. you can trust anything i say, i'm perfect and
never make a mistake.
btw, i have a nice bridge i'd like to sell you cheap.
craig
--
craig sanders <cas(a)taz.net.au>
10:09 a.m.
Hello cRAIG,
On 8/30/20, Craig Sanders via luv-main <luv-main(a)luv.asn.au> wrote:
I think it may be possible to copy and paste between GUI editors and
other windows, but not the terminal. As I said, there is a discussion
that I found about the different text buffers, and security issues and
how many and how they are implemented. It looks to me like they have
thought about these issues, but not fully thought things through. They
do have cogent arguments about security and the like, but again, I
consider that they are still half assed. I would like both the sysV
init and xwindows back, even if I have to make a change after the
primary install. Making it this difficult is a black mark on the
Debian development community. I can understand, and even sympathise
that it is a lot of work, maybe too much, to keep the older stuff
available, but I strongly disagree with the making it so unpleasantly
difficult. That may partially be due to moving things in and out of
the kernel, but it is also too much "feature creep" by the likes of
systemd. As to Wayland, again I would like to see more of the
discussion as to why to totally scrap the older xwindows.
I want to learn, but meatspace is taking me away too much. I am now 65
and looking to working less, eventually. The people I do Traffic
Control keep looking for more staff, but it is difficult. I have
proven to be reasonably reliable while the younger ones come and go,
some voluntarily, some just stupid and drugs. I have a bit of super,
but not enough that I can sit back and scratch the itch to learn. I
also need to keep practicing to maintain what I learn.
Again, anyone can make a mistake, some are a mistake.
On Sun, Aug 30, 2020 at 05:24:39PM +1000, Mark
Trickett wrote:
I tried looking through dmesg, but could not find any of the first
screen before the splash screen and login. The original Unix design
was well considered. I regard systemd as a Microsoftian Borg
intrusion. There are other distros based on Debian that go back to the
older init systems. I do not mind a slightly slower boot when it makes
the system more stable and maintainable.
I did not choose Wayland, nor systemd, but that
is now the Debian
defaults. There are good reasons behind the changes, or at least I have
seen
some support that I will concur with on why Wayland over xwindows. However
I do not find benefit in systemd,
most of my machines run systemd now. all but one, which just fails to boot
at
all if i try to boot it with systemd rather than sysvinit. I'm not entirely
happy with that but i've given up fighting against it, i just don't have
the
energy for that.
I don't actually mind systemd as an init system, i.e. starting and stopping
services - it's pretty good at that. it's all the other stuff (like ntp and
dns and cron) that it tries to do that pisses me off, especially since it
does
such a shitty job of them.
I just disable as much of that systemd borg shit as I can and run the
required
services as extra daemons, like ntpd for ntp and unbound for dns resolution
(I still use bind9 on a different IP address for serving my zones) and
vixie
cron.
the current install (Debian 10.5) is missing a
piece of firmware, but I
cannot read the message in time during boot, nor find it in the logs. I
think it is for the network on the motherboard.
try something like 'journalctl -xe -b0', or 'dmesg | less'. You may be
able to find the message you want by searching through that. From my
reading of pages found by a google search, there is a choice by
the
development team based on (in)security of casual copy and paste. I
thought
that it was likely a configuration issue, but cannot find. I tried a
number
of teminals, but not a lot, to find one that appears to be reasonable. I
still need to do more research, when life leaves the time from the real
world.
that would be kind of fucked up if they've disabled copy-paste into
terminals
or text editors entirely. so fucked up that that i can't believe anyone
would
do that deliberately...there has to be some way to do it, or some way to
re-enable it.
off-by-default is merely annoying, but no big deal. off-forever would be
inexcusable. I cannot make
sense of a line of perl at this time,
perl's really not that hard. if you have some basic scripting capability
(or an ability to understand algorithms and flow control), and some passing
familiarity with shell scripts or sed or awk, then perl is easy.
it's nowhere near as difficult as some people like to make out. and
learning
some perl is at least as useful as learning sh and sed and awk put
together.
just ignore all the dickheads who say bullshit like "perl is write-only" or
that it "looks like line-noise". they have no idea what they're talking
about
- at best, they're just scared of the sight of regexps as operators -
beware
the wild regexp, cage it in a function call or it'll get you. but there are
some folks I will trust, such as you and Russel Coker. I do
not expect you to be perfect, but that you do know more than I, and from
what I have seen, not malicious. I do try to comprehend even your
examples
first, but have to trust that you do know that much more in the subject
of
concern.
oh. I didn't mean me. you can trust anything i say, i'm perfect and
never make a mistake.
btw, i have a nice bridge i'd like to sell you cheap. craig
Regards,
Mark Trickett
11:25 a.m.
On Sunday, 30 August 2020 8:09:16 PM AEST Mark Trickett via luv-main wrote:
I tried looking through dmesg, but could not find any
of the first
screen before the splash screen and login. The original Unix design
was well considered. I regard systemd as a Microsoftian Borg
intrusion. There are other distros based on Debian that go back to the
older init systems. I do not mind a slightly slower boot when it makes
the system more stable and maintainable.
One feature of systemd is fast boot, unless it has an error and gets you 90
second timeouts etc.
What I like are the better security features. One example is terminal
control. If you have an init script that launches a daemon under a different
UID then if that daemon isn't started by runuser or something similar then the
daemon can push characters into the keyboard buffer of the shell.
ps axo pid,sess,comm|grep $$
The above command shows processes in the same session group as your shell.
Now you can modify all scripts to use runuser, but that's going to be a pain.
systemd does all this for you.
Also systemd allows blocking daemons from accessing /home and other security
features. When it does those sorts of things they are in a standard format so
you can grep service files to make sure that all daemons meet the security
goals that you have instead of having to read lots of shell scripts written by
different people for such things.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
1:13 p.m.
On Sun, Aug 30, 2020 at 09:25:08PM +1000, Russell Coker wrote:
One feature of systemd is fast boot, unless it has an
error and gets you 90
second timeouts etc.
It can be (and often is) worse than just 90 seconds. I've had both bootups and
shutdowns delayed by 10s of minutes or longer while it retries and retries for
progressively longer times. it's really fucking annoying. and you can't even
hit Ctrl-C or something to force it to abort.
A few times i've let systemd try to shutdown or reboot for HOURS, just out
of curiousity to see if it will ever just give up on whatever's failing, and
reboot anyway. AFAIK it would have gone on retrying forever if i hadn't
power-cycled it.
also, i don't reboot very often (on average, every two months or so. or even
less often - e.g while my desktop machines got kernel upgrades about a week
ago to 5.7.0-2-amd64 from debian sid, my main server/gateway box was last
rebooted 201 days ago and is still running 5.3.0-3-amd64). saving a few
seconds every year is hardly worth writing home about, and is more than offset
by how long it takes to shutdown or reboot (IME that's *always* slower under
systemd, usually by several minutes)
What I like are the better security features. One
example is terminal
control. If you have an init script that launches a daemon under a
different UID then if that daemon isn't started by runuser or something
similar then the daemon can push characters into the keyboard buffer of the
shell.
and if you're running a daemon or something that does that, then you've got
greater problems to worry about - anything that could install a compromised
daemon already has root access and doesn't need access to your keyboard
buffer.
i'm not saying that this kind of separation is worthless, just that it's not
enough by itself.
To start with, don't install packages from untrusted repositories and NEVER
use brawndo-installer, which is a favourite of idiot devs (usually python or
ruby or nodejs devs, but not exclusively) and looks something like this:
curl URL | sudo bash
or as a function, highlighting all of its "features":
brawndo() {
curl $1 | sudo /usr/bin/env bash
}
ps axo pid,sess,comm|grep $$
The above command shows processes in the same session group as your shell.
or you could use namespaces and lsns or pgrep --ns
Now you can modify all scripts to use runuser, but
that's going to be a pain.
systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs
didn't think or use themselves. or deliberately disallow. in that situation,
you're fucked.
Also systemd allows blocking daemons from accessing
/home and other security
features.
no, the kernel does that. systemd just makes use of kernel namespace features.
it's not alone in being able to do that - containerd and docker and firejail
and many other programs make use of namespaces.
When it does those sorts of things they are in a
standard format so you can
grep service files to make sure that all daemons meet the security goals
that you have instead of having to read lots of shell scripts written by
different people for such things.
I really don't get why systemd fans are so terrified of shell scripts.
especially when systemd is so poorly documented. it's not as if systemd unit
files are paragons of clarity, or that there's any easy way to get an overview
of the dependency relationship between units.
craig
--
craig sanders <cas(a)taz.net.au>
3:22 p.m.
On Sunday, 30 August 2020 11:13:55 PM AEST Craig Sanders via luv-main wrote:
If you have a daemon that is written and maintained by honourable people who
have made a mistake in their coding (which happens to all programmers) then a
compromised instance of the daemon could spawn a child process that waits for
the sysadmin to restart the daemon and then escalates that to root compromise.
Which situations are you thinking of?
The "kill processes in user session when they logout" was a good feature for
some use cases and it was annoying that last time I checked the Debian systemd
maintainers had disabled it instead of leaving it as a configuration option.
Yes, but systemd has a configuration option for it.
Because I've worked on so many shell scripts written by other people.
What I like
are the better security features. One example is terminal
control. If you have an init script that launches a daemon under a
different UID then if that daemon isn't started by runuser or something
similar then the daemon can push characters into the keyboard buffer of
the
shell.
and if you're running a daemon or something that does that, then you've got
greater problems to worry about - anything that could install a compromised
daemon already has root access and doesn't need access to your keyboard
buffer. i'm not saying that this kind of separation is
worthless, just that it's not
enough by itself.
It's often not enough to be worth worrying about for one daemon when your
whole system is like that. But having it work correctly for the entire system
is nice.
To start with, don't install packages from
untrusted repositories and NEVER
use brawndo-installer, which is a favourite of idiot devs (usually python or
ruby or nodejs devs, but not exclusively) and looks something like this:
curl URL | sudo bash
If you trust someone who's written the daemon then trusting their install
script is no more risk.
Now you can
modify all scripts to use runuser, but that's going to be a
pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd
devs didn't think or use themselves. or deliberately disallow. in that
situation, you're fucked. Also systemd
allows blocking daemons from accessing /home and other
security features.
no, the kernel does that. systemd just makes use of kernel namespace
features. it's not alone in being able to do that - containerd and docker
and firejail and many other programs make use of namespaces. When it does
those sorts of things they are in a standard format so you
can
grep service files to make sure that all daemons meet the security goals
that you have instead of having to read lots of shell scripts written by
different people for such things.
I really don't get why systemd fans are so terrified of shell scripts. especially when systemd is so poorly documented.
it's not as if systemd unit
files are paragons of clarity, or that there's any easy way to get an
overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
5:23 p.m.
On Mon, Aug 31, 2020 at 01:22:32AM +1000, Russell Coker wrote:
part of my point is that anyone who suggests using brawndo-installer to install
their code can not be trusted. they clearly fail the competence test.
Which situations are you thinking of?
being able to manually change the exact order that particular daemons/services
are loaded.
Yes, but systemd has a configuration option for it.
so do other programs that make use of namespaces.
systemd devs like to pretend that their baby is the only program capable of
doing certain things, when that's not even remotely true.
half the things they claim as wonderful features exclusive to systemd are
re-implementations of ideas from other programs. and most of the rest are
things that an init system has no business doing anyway.
So have I. I've also had to fix several broken unit files. It's possible to
create shit with any tool.
The reason i mention it is because "shell scripts are bad" is a common reason
brought up to prove that systemd is great and why it's better than any other
init. to me, cretinous statements like that say a lot more about the person
saying it than about either systemd or shell scripts. or sysvinit. etc.
Also, IME, shell scripts are easier to understand and fix when required.
They're easier to modify, easier to temporarily enable/disable parts of them
when testing stuff, easier to add diagnostic code, and more. lots of things
are easier with shell scripts.
They're not scary at all. sh scripting is a useful tool. systemd devs are
doing everyone a great dis-service by teaching them that they're scary and
difficult.
that tells you what happened during the current boot session. it doesn't tell
you what WILL happen during the next reboot.
AFAIK there's no way of listing which unit files will be loaded, or in what
order. e.g. definitive answers to questions like "will docker load before or
after zfs.mount?", not just "maybe. reboot and find out".
you can get that just by doing 'ls -l' of an /etc/rc[0-6].d/ directory. The
Snn and Knn symlinks tell you the *exact* order that the scripts will run at
boot or shutdown time, and you can override the default with insserv and the
script's INIT INFO comments.
BTW, i used that example (of zfs.mount and docker) for a reason. My main
server runs docker configured to use zfs. Every reboot it's a gamble whether
docker will start before or after zfs.mount. If it starts after, it works
fine. That's what's supposed to happen. If it starts after zfs.mount, it
breaks. and it creates and populates a fresh new /var/lib/docker directory,
which prevents my zfs docker dataset from being mounted (I have to manually
stop docker, and delete the directory before I can zfs mount /var/lib/docker
and restart docker).
this kind of shit is one of the reasons i'm reluctant to reboot my main server
if i can possibly avoid it (and why i'd NEVER use systemd on a remote machine
that I didn't have easy physical access to). There's always half a dozen or so
little annoying things like this that I have to fix manually before the system
is in its normal operating state.
and finding out WHAT happened this time with systemd-analyze critical-chain
doesn't tell me what will happen next time. and it doesn't tell me anything
about WHY it happened or HOW to fix it permanently.
craig
--
craig sanders <cas(a)taz.net.au>
curl URL |
sudo bash
If you trust someone who's written the daemon then trusting their install
script is no more risk. Now you can modify all scripts to use runuser, but
that's going to be a
pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd
devs didn't think or use themselves. or deliberately disallow. in that
situation, you're fucked. The "kill processes in user session when they
logout" was a good feature
for some use cases and it was annoying that last time I checked the Debian
systemd maintainers had disabled it instead of leaving it as a configuration
option.
actually it was a terrible anti-feature. one that has little reason to
exist, and certainly should never be enabled by default. are the systemd devs
completely ignorant of decades of normal *nix usage? they certainly act like
it sometimes.
anyone who needs or wants that kill-all-my-processes-when-i-logout
functionality can do it in their .bash_logout (or equivalent for whatever
shell they run).
for everyone else, it's an extremely unpleasant surprise to find that the
program they deliberately left running with nohup or screen or tmux or
whatever was killed when they logged out. nobody expects their processes to be
killed just because they logout. that's not how things are supposed to work.
Also systemd allows blocking daemons from accessing
/home and other
security features.
no, the kernel does that. systemd just makes use of kernel namespace
features. it's not alone in being able to do that - containerd and docker
and firejail and many other programs make use of namespaces. I really
don't get why systemd fans are so terrified of shell scripts.
Because I've worked on so many shell scripts written by other people. especially
when systemd is so poorly documented. it's not as if systemd
unit files are paragons of clarity, or that there's any easy way to get an
overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy. 
10:07 p.m.
Mark Trickett via luv-main <luv-main(a)luv.asn.au> writes:
Many thanks for your excellent posts, I am learning
more. However I
have Debian 10, nominally up to date, and it has Wayland with Gnome as
the desktop. I am finding it very frustrating that I cannot copy and
paste to and from the XTerm window. I used to be able to do with
earlier terminal emulation under the XWindows system. I used it to be
able to copy text from a terminal into an email, and commands back
from email, ensuring that I did not make typos. I do understand that
there can be security issues if used without a measure of care and
thoughtful, but it also has much merit when coping with some of the
regular expressions that come up as examples in email and on web
pages.
Are you sure this is a Wayland issue? There are a lot of issues that
constantly trick me with copy and paste under X. e.g.
* Clipboard vs primary. https://www.jwz.org/doc/x-cut-and-paste.html
* Copy text. Close source application. Open destination text. Past text.
Text is gone because closing source application killed copy buffer.
* Some text applications can have mouse support and "steal mouse" and do
their own thing. For example, in vim sometimes I have to use shift
click to mark or paste text. But now I try to reproduce this on demand
and I can't ... go figure. Google says the config value is "set
mouse=a"
* Probably others I can't think of right now.
I don't know what happens with these under Wayland. But in short copy
and paste is complicated.
I have not used Wayland yet. But only because I have been lazy. But I
note that there is now a i3 tiling manager in Debian testing that looks
like it would be worth trying:
https://swaywm.org/
https://github.com/swaywm/sway
For a more complete list of window managers under Wayland see
https://wiki.archlinux.org/index.php/Wayland#Tiling
--
Brian May <brian(a)linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
10:14 p.m.
Brian May <brian(a)linuxpenguins.xyz> writes:
* Some text applications can have mouse support and
"steal mouse" and do
their own thing. For example, in vim sometimes I have to use shift
click to mark or paste text. But now I try to reproduce this on demand
and I can't ... go figure. Google says the config value is "set
mouse=a"
Oh, I found out why this is confusing me. Turns out if I ssh into a
Debian account as root, by default I get mouse=a - so I have to use
shift click everywhere, but with my own custom config I have mouse=
--
Brian May <brian(a)linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
31 Aug
31 Aug
12:57 a.m.
On Monday, 31 August 2020 8:14:57 AM AEST Brian May via luv-main wrote:
Brian May <brian(a)linuxpenguins.xyz> writes:
# cat /etc/vim/vimrc.local
let g:skip_defaults_vim = 1
This is how I solved that problem. Presumably any more specific mouse
settings could go into that file instead and will apply when logged in as root
or any other user.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
* Some text applications can have mouse support
and "steal mouse" and do
their own thing. For example, in vim sometimes I have to use shift
click to mark or paste text. But now I try to reproduce this on demand
and I can't ... go figure. Google says the config value is "set
mouse=a"
Oh, I found out why this is confusing me. Turns out if I ssh into a
Debian account as root, by default I get mouse=a - so I have to use
shift click everywhere, but with my own custom config I have mouse=
672
days inactive
685
days old
14 comments
6 participants
participants (6)
-
Andrew Pam -
Brian May -
Craig Sanders -
Mark Trickett -
Russell Coker -
Tim Connors