Is there a fetchmail.timer unit as well as a .service unit? Or, could
you have a crontab entry that is invoking it?
--
Please do not CC me for listmail.
👱🏻 Jonathan Dowland
✎j...@debian.org
🔗 https://jmtd.net
On 2024-12-28, Roger Price wrote:
>
> The process was alive for three months until I typed systemctl stop
> fetchmail. 6
> hours later I typed systemctl status fetchmail and systemd told me that the
> still running process had been "dead" for 6 hours.
I think
On 2024-12-28 19:08, Greg Wooledge wrote:
Perhaps there's a cron job that starts it.
I use getmail with various getmailrc files started by cron.
Perhaps OP did that with fetchmail and forgot.
crontab -e would show
mick
the daemon through /etc/default/fetchmail *before* stopping the
service.
On Sun, Dec 29, 2024 at 22:44:56 +0700, Max Nikulin wrote:
> John posted content of the service file *generated* for SysV init script.
A. I missed that context.
On 29/12/2024 20:50, Andy Smith wrote:
On Sun, Dec 29, 2024 at 02:16:42PM +0100, poc...@homemail.com wrote:
https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail
What is your point? There is a native systemd service unit for fetchmail
in the next release of Debian. Your constant
Hi,
On Sun, Dec 29, 2024 at 09:29:58AM -0500, Greg Wooledge wrote:
> On Sun, Dec 29, 2024 at 13:50:56 +, Andy Smith wrote:
> > On Sun, Dec 29, 2024 at 02:16:42PM +0100, poc...@homemail.com wrote:
> > > https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail
>
On Sun, Dec 29, 2024 at 09:50:31 +0100, Roger Price wrote:
> On Debian 12 the command systemctl status fetchmail now has a "CGroup" entry:
>
> ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
> Loaded: loaded (/etc/init.d/fetchmail; generated)
On Sun, Dec 29, 2024 at 13:50:56 +, Andy Smith wrote:
> Hello,
>
> On Sun, Dec 29, 2024 at 02:16:42PM +0100, poc...@homemail.com wrote:
> > https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail
>
> What is your point? There is a native systemd service un
Hello,
On Sun, Dec 29, 2024 at 02:16:42PM +0100, poc...@homemail.com wrote:
> https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail
What is your point? There is a native systemd service unit for fetchmail
in the next release of Debian. Your constant off-topic proselytizing of
A
poc...@homemail.com (12024-12-29):
> ExecStart=/usr/bin/fetchmail --pidfile /run/fetchmail/fetchmailrc.pid -f
> /etc/fetchmailrc
Debian uses --nodetach, which is a much better use of modern service
monitoring.
Regards,
--
Nicolas George
> Sent: Saturday, December 28, 2024 at 10:18 PM
> From: "John Hasler"
> To: debian-user@lists.debian.org
> Subject: Re: Correct way to stop fetchmail
>
> On Unstable:
>
> toncho/~ 20 systemctl cat fetchmail.service
> # /run/systemd/generator.late/fetchmai
On Sun, 29 Dec 2024, Michael wrote:
then make sure you run
systemctl disable fetchmail.service
otherwise it will start again at next boot.
Here is what happened when i tried "disable" on this Debian 11 machine.
root@titan ~ systemctl disable fetchmail
fetchmail.service is no
/etc/default/fetchmail, I have
START_DAEMON=no
I assume this also prevents fetchmail from restarting. Roger
On Sunday, December 29, 2024 11:30:30 AM CET, Roger Price wrote:
On Sun, 29 Dec 2024, Michael wrote:
I assume this also prevents fetchmail from restarting.
correct, as long as the init script is called by systemd and nothing
changes in said script.
to disable the service prevents it from
On Saturday, December 28, 2024 6:56:09 PM CET, Roger Price wrote:
And the fetchma+ process disappeared - I hope it no longer
rises from the dead.
then make sure you run
systemctl disable fetchmail.service
otherwise it will start again at next boot.
greetings...
On Sun, 29 Dec 2024, Max Nikulin wrote:
Commands that might help to discover what actually happened
journalctl -u fetchmail.service
Dec 28 10:37:58 titan systemd[1]: Stopping LSB: init-Script for system wide
fetchmail daemon...
Dec 28 10:37:58 titan
On Unstable:
toncho/~ 20 systemctl cat fetchmail.service
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail
On Sun, Dec 29, 2024 at 09:40:44 +0700, Max Nikulin wrote:
> On 28/12/2024 23:47, Greg Wooledge wrote:
> > On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote:
> > > root@titan ~ /etc/init.d/fetchmail --quit
> > > Not starting fetchmail daemon, disabled
On 28/12/2024 23:47, Greg Wooledge wrote:
On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote:
root@titan ~ /etc/init.d/fetchmail --quit
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.
The correct way to use a legacy sysv-rc init.d script to stop a service
is
On Sat, Dec 28, 2024 at 22:59:19 +0100, Nicolas George wrote:
> Roger Price (12024-12-28):
> > ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
> > Loaded: loaded (/etc/init.d/fetchmail; generated)
> > Active: inactive (dead) since Sat 2024-1
Roger Price (12024-12-28):
> ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
> Loaded: loaded (/etc/init.d/fetchmail; generated)
> Active: inactive (dead) since Sat 2024-12-28 10:37:58 CET; 6h ago
>Docs: man:systemd-sysv-generator(8)
>
On Sat, 28 Dec 2024, Greg Wooledge wrote:
On Sat, Dec 28, 2024 at 11:36:44 -0700, Charles Curley wrote:
On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
Roger Price wrote:
but fetchmail goes on fetching mail. What is the correct way of
stopping fetchmail?
Perhaps there is a fetchmail.timer unit
On Sat, Dec 28, 2024 at 18:56:09 +0100, Roger Price wrote:
> I tried 4 times. then I tried
>
> /etc/init.d/fetchmail stop
>
> but although dead for 6 hours, fetchmail continued to fetch mails.
> So I tried
>
> root@titan ~ ps -ef | grep fetch
> fetchma+1264
On Sat, Dec 28, 2024 at 11:36:44 -0700, Charles Curley wrote:
> On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
> Roger Price wrote:
>
> > but fetchmail goes on fetching mail. What is the correct way of
> > stopping fetchmail?
>
> Perhaps there is a fetchmail.tim
On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
Roger Price wrote:
> but fetchmail goes on fetching mail. What is the correct way of
> stopping fetchmail?
Perhaps there is a fetchmail.timer unit that is starting up
fetchmail.service from time to time?
systemctl status fetchmail.timer
You migh
Thanks for your replies. I tried
systemctl stop fetchmail.service
I tried 4 times. then I tried
/etc/init.d/fetchmail stop
but although dead for 6 hours, fetchmail continued to fetch mails.
So I tried
root@titan ~ ps -ef | grep fetch
fetchma+1264 1 0 Sep25 ?00:06:33
Hi, have you try
/etc/init.d/fetchmail stop
?
Cheers,
Jerome
On 28/12/2024 17:21, Roger Price wrote:
I would like to stop fetchmail on Debian 11. I tried command systemctl stop
fetchmail and system status fetchmail reported
● fetchmail.service - LSB: init-Script for system wide
On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote:
> ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
The correct way to stop a systemd service whose name you know is:
systemctl stop fetchmail.service
If you're entirely new to systemd, you can get
I would like to stop fetchmail on Debian 11. I tried command systemctl stop
fetchmail and system status fetchmail reported
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: inactive (dead) since Sat 2024
Fetchmail continues to retrieve my email successfully. Could your clock
possibly be skewed enough to affect TLS negotiation?
--Gregory
On Mon, May 08, 2023 at 01:39:14AM -0700, John Conover wrote:
>
> My fetchmail, (from the repository,) has started timing out with a
> SOCKET
My fetchmail, (from the repository,) has started timing out with a
SOCKET error on connections I've used for years. Both fetchmail and
openssl are from the repository.
fetchmail: 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5
openssl: 1.1.1n 15 Mar 2022
Anyone else having similar pro
Am Fri, Mar 03, 2023 at 10:09:42PM +0700 schrieb Max Nikulin:
> On 02/03/2023 22:27, Christoph Brinkhaus wrote:
> > Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> > > On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > > > I will just inform about the status. Everything is fine now
On 02/03/2023 22:27, Christoph Brinkhaus wrote:
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
h
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > I will just inform about the status. Everything is fine now. A word
> > about systemd-networkd-wait-online: With this service running there
> > has been even a delay of 1-2 seconds wh
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
has been even a delay of 1-2 seconds when switching from one console
to a different one (the consoles when X is n
Am Sun, Feb 26, 2023 at 01:21:07PM -0600 schrieb David Wright:
Hello David and Max,
> On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> > Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > > Now there are no
rious if fixing unbound and so network-online.target helped to avoid
> > 169.254.x.y address in your case. Can fetchmail work without a kludge you
> > added to achieve some delay? My expectation is that unbound.service may be
> > dropped from Requires= and After= in fetchmail.
in your case. Can fetchmail work without a kludge you
> added to achieve some delay? My expectation is that unbound.service may be
> dropped from Requires= and After= in fetchmail.service, but both fields
> should have network-online.target.
>
> I forgot that debugging of such issues
your case.
I am not sure because I have disabled/deinstalled stuff which
triggered the assignment of the 149.254.x.y address.
> Can fetchmail work without a kludge you
> added to achieve some delay? My expectation is that unbound.service may be
> dropped from Requires= and After= in
On 25/02/2023 19:49, Christoph Brinkhaus wrote:
Now there are no messages reported by journald as above.
I am curious if fixing unbound and so network-online.target helped to
avoid 169.254.x.y address in your case. Can fetchmail work without a
kludge you added to achieve some delay? My
On Mon, 12 Sep 2022 19:50:01 +0200, Gerard ROBIN wrote:
> Le Mon, Sep 12, 2022 at 09:06:08AM -, Bert Riding a écrit :
>> Date: Mon, 12 Sep 2022 09:06:08 - (UTC)
>> From: Bert Riding
>> To: debian-user@lists.debian.org
>> Subject: Re: fetchmail
>>
>
Le Mon, Sep 12, 2022 at 09:06:08AM -, Bert Riding a écrit :
> Date: Mon, 12 Sep 2022 09:06:08 - (UTC)
> From: Bert Riding
> To: debian-user@lists.debian.org
> Subject: Re: fetchmail
>
> On Sat, 10 Sep 2022 22:50:01 +0200, Gerard ROBIN wrote:
>
> > Hel
On Sat, 10 Sep 2022 22:50:01 +0200, Gerard ROBIN wrote:
> Hello,
> in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
> get:
>
> fetchmail: can't accept options while a background fetchmail is running.
> argc = 5, arg list:
> arg 1 = "-k"
Le Sun, Sep 11, 2022 at 09:24:27AM -0400, Greg Wooledge a écrit :
> Date: Sun, 11 Sep 2022 09:24:27 -0400
> From: Greg Wooledge
> To: debian-user@lists.debian.org
> Subject: Re: fetchmail
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bendel.debian.org
> X-Spa
On Sun, 11 Sept 2022 at 23:25, Greg Wooledge wrote:
> On Sun, Sep 11, 2022 at 12:14:15PM +0200, Gerard ROBIN wrote:
> > My problem is that I don't know what starts it.
> > Debian Bookworm (and Bullseye too) use systemd.
> Guessing the service name is non-trivial. Sometimes it's the same as
> t
t;.
Earlier in this thread, Nate posted the following output:
> $ systemctl status fetchmail.service
> ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
> Loaded: loaded (/etc/init.d/fetchmail; generated)
> Active: active (exited) since Sat 2022-09-10 15:37:33 CDT;
Le Sun, Sep 11, 2022 at 06:18:07AM +0200, to...@tuxteam.de a écrit :
> Date: Sun, 11 Sep 2022 06:18:07 +0200
> From: to...@tuxteam.de
> To: debian-user@lists.debian.org
> Subject: Re: fetchmail
>
> On Sat, Sep 10, 2022 at 10:45:23PM +0200, Gerard ROBIN wrote:
> > Hello,
On Sat, Sep 10, 2022 at 10:45:23PM +0200, Gerard ROBIN wrote:
> Hello,
> in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
> get:
>
> fetchmail: can't accept options while a background fetchmail is running.
> argc = 5, arg list:
> arg 1 = &quo
Le Sat, Sep 10, 2022 at 04:37:40PM -0500, Nate Bargmann a écrit :
> Date: Sat, 10 Sep 2022 16:37:40 -0500
> From: Nate Bargmann
> To: debian-user@lists.debian.org
> Subject: Re: fetchmail
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bendel.debian.org
> X-Spa
* On 2022 10 Sep 16:28 -0500, Gerard ROBIN wrote:
> Hello,
> in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
> get:
>
> fetchmail: can't accept options while a background fetchmail is running.
> argc = 5, arg list:
> arg 1 = "-k"
> ar
Hello,
in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
get:
fetchmail: can't accept options while a background fetchmail is running.
argc = 5, arg list:
arg 1 = "-k"
arg 2 = "--ssl"
arg 3 = "--mda"
arg 4 = "/usr/bin/procmail -d %T&qu
Hello,
in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
get:
fetchmail: can't accept options while a background fetchmail is running.
argc = 5, arg list:
arg 1 = "-k"
arg 2 = "--ssl"
arg 3 = "--mda"
arg 4 = "/usr/bin/procmail -d %T&qu
No, I forgot. I am ashamed. I ran update-grub and command grep ipv6
/boot/grub/grub.cfg | wc -l now returns 0. No more mention of ipv6.
I re-booted and fetchmail now talks to exim4 correctly. Command ss -lnt | grep
:25 now reports
LISTEN 0 20 127.0.0.1:25 0.0.0.0:*
LISTEN 0
On Sun, Jul 10, 2022 at 10:57:40PM +0100, Gareth Evans wrote:
> $ sudo reboot
> - set boot arg ipv6.disable=1
> - NB ipv6 addresses still in /etc/hosts
>
> $ telnet localhost 25
> Trying 127.0.0.1...
> Trying ::1...
> telnet: Unable to connect to remote host: Address family not supported by
> pr
On Sun 10 Jul 2022, at 18:28, Greg Wooledge wrote:
> Mine contains these lines:
>
> unicorn:~$ grep ::1 /etc/hosts
> ::1 localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
>
> They were put there by Debian. I didn't touch them.
[I got the ::1 and localhost the wrong way around in m
On Sun, Jul 10, 2022 at 05:12:18PM +0100, Gareth Evans wrote:
> On Sun 10 Jul 2022, at 15:38, Roger Price wrote:
> [...]
> > I removed the ipv6.disable=1 and rebooted, but this made no difference.
>
> I'm not sure if there may be other issues here too, but did you update-grub
> before rebooting?
Roger Price (12022-07-10):
> I have successfully used fetchmail and the MTA exim4 to receive mail on a
> Debian 9 machine for several years. I am now trying to migrate this to
> Debian 11, but fetchmail no longer talks to exim4.
I have never understood why fetchmail's default op
On Sun 10 Jul 2022, at 17:12, Gareth Evans wrote:
> https://unix.stackexchange.com/questions/407663/ipv6-socket-creation-failed-address-family-not-supported-by-protocol
FWIMBW, this explains how to disable ipv6 for exim4 (albeit on Deb 9) though
I'm not sure the advice re hosts file is universa
On Sun 10 Jul 2022, at 15:38, Roger Price wrote:
[...]
> I removed the ipv6.disable=1 and rebooted, but this made no difference.
I'm not sure if there may be other issues here too, but did you update-grub
before rebooting?
If not, does /etc/hosts currently contain
localhost ::1
?
If so, it
On 7/10/22 10:41, Roger Price wrote:
I have successfully used fetchmail and the MTA exim4 to receive mail
on a Debian 9 machine for several years. I am now trying to migrate
this to Debian 11, but fetchmail no longer talks to exim4.
systemctl status fetchmail reports
● fetchmail.service
I have successfully used fetchmail and the MTA exim4 to receive mail on a Debian
9 machine for several years. I am now trying to migrate this to Debian 11, but
fetchmail no longer talks to exim4.
systemctl status fetchmail reports
● fetchmail.service - LSB: init-Script for system wide
On Sun, 3 Jul 2022, to...@tuxteam.de wrote:
My hunch is that your synaptic is looking at a stale package database. Do an
"apt-get update" or whatever you have to do to synaptic to achieve the same
effect, perhaps the problem goes away.
Yes, I did "apt-get update" and the synaptic problem went
On Sun, 3 Jul 2022 at 21:11, Roger Price wrote:
> I would like to install fetchmail on Debian 11, but synaptic gives me the
> following error message:
>
> W: Failed to fetch
> http://deb.debian.org/debian/pool/main/f/fetchmail/fetchmail_6.4.16-4_amd64.deb
>
On Sun, Jul 03, 2022 at 01:11:04PM +0200, Roger Price wrote:
> I would like to install fetchmail on Debian 11, but synaptic gives me the
> following error message:
>
> W: Failed to fetch
> http://deb.debian.org/debian/pool/main/f/fetchmail/fetchmail_6.4.16-4_amd64.deb
>
I would like to install fetchmail on Debian 11, but synaptic gives me the
following error message:
W: Failed to fetch
http://deb.debian.org/debian/pool/main/f/fetchmail/fetchmail_6.4.16-4_amd64.deb
404 Not Found [IP: 199.232.178.132 80]
Is this temporary or do I need to look elsewhere for
On Thursday, 29 Apr 2021 at 08:24, Jonathan Siegle wrote:
> This is working for me on Debian Buster:
> http://galileo.phys.virginia.edu/compfac/faq/davmail.html
Thank you for this.
I have spent the past 2 days on this and have finally got davmail
working for me. Some issues with versions of fire
On Thursday, 29 Apr 2021 at 21:09, deloptes wrote:
> The admin says "F**k off" :D
Yep, that's pretty much what's happened (so far... I'm pushing).
--
Eric S Fraga via Emacs 28.0.50 & org 9.4.6 on Debian bullseye/sid
On Monday, May 03, 2021 10:03:39 AM Eric S Fraga wrote:
> On Monday, 3 May 2021 at 11:23, Andrei POPESCU wrote:
> > Get a computer monitor instead. In ten years most (if not all)
> > traditional TV stations will likely have switched to streaming via the
> > internet anyway ;)
>
> When I went to o
> I'm also interested to know how good a service you actually get within
> buildings, where most of us are most of the time. I see that wireless
> repeaters are recommended according to a home's floor area. Are they
> repeating 30GHz round the house, or conventional 2/5GHz? If the
> latter, there's
On Mon 03 May 2021 at 15:47:07 (-0400), Stefan Monnier wrote:
> > It doesn't seem sensible to put a cell-connection into each TV
> > when they're all immobile. OTOH cars and pets go places.
> >
> > And is 20GB of data per day a "reasonable usage" on a mobile data plan?
> > Whereas 1TB per month on
On Mon, 3 May 2021 21:03:51 +0100
Brian wrote:
> On Mon 03 May 2021 at 15:47:07 -0400, Stefan Monnier wrote:
>
> > > It doesn't seem sensible to put a cell-connection into each TV
> > > when they're all immobile. OTOH cars and pets go places.
> > >
> > > And is 20GB of data per day a "reasonable
On Mon 03 May 2021 at 15:47:07 -0400, Stefan Monnier wrote:
> > It doesn't seem sensible to put a cell-connection into each TV
> > when they're all immobile. OTOH cars and pets go places.
> >
> > And is 20GB of data per day a "reasonable usage" on a mobile data plan?
> > Whereas 1TB per month on a
> It doesn't seem sensible to put a cell-connection into each TV
> when they're all immobile. OTOH cars and pets go places.
>
> And is 20GB of data per day a "reasonable usage" on a mobile data plan?
> Whereas 1TB per month on a fixed line is quite normal.
These arguments seem stuck in the present
On Mon 03 May 2021 at 18:32:13 (+0200), to...@tuxteam.de wrote:
> On Mon, May 03, 2021 at 12:24:48PM -0400, Stefan Monnier wrote:
> > > There: now your smart-ass TV is a monitor again.
> >
> > At least until they start using a cell-connection for Internet access
> > (which would seem only natural
>> > There: now your smart-ass TV is a monitor again.
>> At least until they start using a cell-connection for Internet access
>> (which would seem only natural in the world of TVs, which historically
>> got their programs over the air) :-(
> Cars do that already. Why shouldn't TVs? Or pet collars?
On Mon, May 03, 2021 at 12:24:48PM -0400, Stefan Monnier wrote:
> > There: now your smart-ass TV is a monitor again.
>
> At least until they start using a cell-connection for Internet access
> (which would seem only natural in the world of TVs, which historically
> got their programs over the air)
> There: now your smart-ass TV is a monitor again.
At least until they start using a cell-connection for Internet access
(which would seem only natural in the world of TVs, which historically
got their programs over the air) :-(
Stefan
David Wright wrote:
> On Mon 03 May 2021 at 11:23:51 (+0300), Andrei POPESCU wrote:
> > On Sb, 01 mai 21, 08:31:04, Joe wrote:
> > > On Fri, 30 Apr 2021 17:25:20 -0400
> > > Stefan Monnier wrote:
> > >
> > > > > viewing material because it's about ten years old. But when we
> > > > > inevitably r
On Mon 03 May 2021 at 11:23:51 (+0300), Andrei POPESCU wrote:
> On Sb, 01 mai 21, 08:31:04, Joe wrote:
> > On Fri, 30 Apr 2021 17:25:20 -0400
> > Stefan Monnier wrote:
> >
> > > > viewing material because it's about ten years old. But when we
> > > > inevitably replace it and have no choice about
On Monday, 3 May 2021 at 11:23, Andrei POPESCU wrote:
> Get a computer monitor instead. In ten years most (if not all)
> traditional TV stations will likely have switched to streaming via the
> internet anyway ;)
When I went to order a 60" monitor for a meeting room at work, I found
that the eq
On Sb, 01 mai 21, 08:31:04, Joe wrote:
> On Fri, 30 Apr 2021 17:25:20 -0400
> Stefan Monnier wrote:
>
> > > viewing material because it's about ten years old. But when we
> > > inevitably replace it and have no choice about accepting a 'smart'
> > > TV,
> >
> > There are still normal TVs aroun
On Mon, May 03, 2021 at 01:46:26AM +0200, Ángel wrote:
> On 2021-05-01 at 09:28 +0200, deloptes wrote:
> > Some state their brainwaves are being influenced by whatever (video,
> > tv, wireless) It could be true, but there is no evidence and the
> > probability of this being true is very low.
>
> L
On 2021-05-01 at 09:28 +0200, deloptes wrote:
> Some state their brainwaves are being influenced by whatever (video,
> tv, wireless) It could be true, but there is no evidence and the
> probability of this being true is very low.
Looks like the goal of every advertisement to me.
On Sat, 01 May 2021 12:00:30 +0200
deloptes wrote:
> Joe wrote:
>
> > There is nothing 'religious' about assuming that many private
> > businesses will take every opportunity to make money from you in
> > ways that you would not permit if you were given the choice. What
> > is the purpose of 'fr
Joe wrote:
> There is nothing 'religious' about assuming that many private businesses
> will take every opportunity to make money from you in ways that you
> would not permit if you were given the choice. What is the purpose of
> 'free' social media, after all? What about the written guarantee car
On 01-05-2021 18:19, Joe wrote:
> On Sat, 01 May 2021 09:28:04 +0200
> deloptes wrote:
>
>> Joe wrote:
>>
>> > I know someone who started to be shown online adverts that could
>> > only have been based on a sound-wave conversation within the
>> > hearing of his smartphone. I don't know about othe
On Sat, May 01, 2021 at 10:04:17AM +0300, Andrei POPESCU wrote:
> On Jo, 29 apr 21, 14:21:22, to...@tuxteam.de wrote:
> >
> > BTW I'm not really a luddite [1]. I'd consider a smart phone if I
> > had a comparable control over its guts as I have of my laptop, take
> > or give. Those options are, al
On Sat, 01 May 2021 09:28:04 +0200
deloptes wrote:
> Joe wrote:
>
> > I know someone who started to be shown online adverts that could
> > only have been based on a sound-wave conversation within the
> > hearing of his smartphone. I don't know about other similar claims,
> > but I trust his.
> >
On Sat, May 01, 2021 at 08:31:04AM +0100, Joe wrote:
> On Fri, 30 Apr 2021 17:25:20 -0400
> Stefan Monnier wrote:
>
> > > viewing material because it's about ten years old. But when we
> > > inevitably replace it and have no choice about accepting a 'smart'
> > > TV,
> >
> > There are still no
On Fri, 30 Apr 2021 17:25:20 -0400
Stefan Monnier wrote:
> > viewing material because it's about ten years old. But when we
> > inevitably replace it and have no choice about accepting a 'smart'
> > TV,
>
> There are still normal TVs around.
>
Yes, but not many. We would want another 32" TV,
Joe wrote:
> I know someone who started to be shown online adverts that could only
> have been based on a sound-wave conversation within the hearing of his
> smartphone. I don't know about other similar claims, but I trust his.
>
> Are you saying that you don't believe anyone could be that naught
On Jo, 29 apr 21, 14:21:22, to...@tuxteam.de wrote:
>
> BTW I'm not really a luddite [1]. I'd consider a smart phone if I
> had a comparable control over its guts as I have of my laptop, take
> or give. Those options are, alas, a tad to pricey for my current
> income.
The PinePhone is interesting
> viewing material because it's about ten years old. But when we
> inevitably replace it and have no choice about accepting a 'smart' TV,
There are still normal TVs around.
Stefan
On Fri, 30 Apr 2021 20:48:07 +0100
Brian wrote:
> On Fri 30 Apr 2021 at 09:04:03 +0100, Joe wrote:
>
> [...]
>
> > We are aware that smartphones and the hypothetical 'smart' TV will
> > listen to conversations occurring in their vicinities, so we go
> > somewhere else for any private conversati
to...@tuxteam.de wrote:
>> No insult tomas - it's reality. One small tree can not stand the
>> avalanche.
>
> It is -- you said "nobody is doing anything". But there are folks
> doing something. Declaring them non-existent is perhaps the worst
> insult possible.
>
> Whether they succeed (or rath
On Fri 30 Apr 2021 at 09:04:03 +0100, Joe wrote:
[...]
> We are aware that smartphones and the hypothetical 'smart' TV will
> listen to conversations occurring in their vicinities, so we go
> somewhere else for any private conversation.
Basing one's behaviour on the hypothetical, imagined or pre
g the token available on linux so you could
>> use it in another program that requied a password, for example
>> fetchmail or getmail.
>>
>> I've tried to find it but I'm turning up nothing. I'm pretty sure I
>> didn't imagine it! Does anyone recal
On Fri, Apr 30, 2021 at 03:24:52PM +0200, deloptes wrote:
> to...@tuxteam.de wrote:
>
> > 1. it is an insult towards those actually doing something Like
> > (random example) this electronic music composer [1] and professor
> > (chosen at random among my acquaintances) who makes a point
> > of usin
an API key - password #1 is
> for gnus on laptop 1, password #2 is for Fetchmail on laptop 1, password
> #3 is for gnus on laptop 2 and so on. Each instance of an application
> gets its own long password.
>
> It's ostensibly more secure than storing the user's password in tha
1 - 100 of 2549 matches
Mail list logo
