Re: Why do UID values of system users matter?
On Sat 17 Aug 2019 at 04:18:00 (+0200), Steffen Dettmer wrote:
>
> I see, multiboot with different /etc but shared /usr or /local could invite
> a lot of trouble if using different UIDs, indeed! Thanks for the quick
> explanation.
Sure. Most system files can be copied between different /etc
partitions on the same host because they're owned by root.root
or by one of the invariant system users.
But there are a few that can catch you out. For example, it's
obvious that you might want to copy your mail submission passwords
between two systems to save typing them all in again, but
/etc/exim4/passwd.client is owned by root.Debian-exim, and that
GID is >100, so potentially different:
$ ls -l /agogs/etc/exim4/passwd.client /etc/exim4/passwd.client
-rw-r- 1 root mlocate 663 May 30 2018 /agogs/etc/exim4/passwd.client
-rw-r- 1 root Debian-exim 663 May 30 2018 /etc/exim4/passwd.client
$ ls -n /agogs/etc/exim4/passwd.client /etc/exim4/passwd.client
-rw-r- 1 0 118 663 May 30 2018 /agogs/etc/exim4/passwd.client
-rw-r- 1 0 120 663 May 30 2018 /etc/exim4/passwd.client
$
> > (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 /
> > > Stretch).
> >
> > AFAICS, user "man" has had UID 6 since at least Debian 6/squeeze
> >
> Ohh, this is interesting, so I wonder why I had a different value then,
> maybe something else was wrong with my system then...
Difficult to say. My reaction would be to check the ownership of all
non-root-owned files. Because of the potential for trouble like the
above, I routinely keep a list on each system.
# find / -mount \( ! -group 0 -o ! -user 0 \) -ls | awk '{printf "%s%s
%s\n", $5, $6, $11}' | sort -k 3 > /root/non-root-owned-files
Cheers,
David.
Re: Why do UID values of system users matter?
On Fri 16 Aug 2019 at 23:27:27 (+0200), Steffen Dettmer wrote: > > just for my curiosity I wonder why the numeric UID values matter at all, > for example: > > update-passwd has found a difference between your system > accounts and the current Debian defaults. It is advisable to > allow update-passwd to change your system; without those > changes some packages might not work correctly. For more > documentation on the Debian account policies, please see > /usr/share/doc/base-passwd/README. > > The proposed change is: > > Change the UID of user "man" from 13 to 6 > > (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 / > Stretch). Very odd. The master lists are in /usr/share/base-passwd/*master and the jessie version (3.5.37) has man as 6 and 12. Going back to woody (Debian 3.0 from 2002), the UID is still 6, though the GID at that time was 100, the "users" group, shared by several system UIDs. > Normally I would assume that the numeric values would not be use > anywhere at all, only the symbolic names. OSes and filesystems use numbers rather than names for efficiency: even a modern 32-bit UID only uses the space of four ASCII characters, whereas some of the UID/GID names are long, eg systemd-bus-proxy and debian-security-support. > If the numeric value matters, why are their values no kept across releases? Because that presents too much administrative effort, which dynamic allocation is designed to avoid. You just have to exercise care if/when you copy files between different systems in "inappropriate" ways, eg using cp when you have two installations in the same PC. Cheers, David.
Re: Why do UID values of system users matter?
On Fri, Aug 16, 2019 at 10:18 PM Steffen Dettmer wrote: > Hi, > > thanks for your quick reply. > > I see, multiboot with different /etc but shared /usr or /local could > invite a lot of trouble if using different UIDs, indeed! Thanks for the > quick explanation. > > > (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 / >> > Stretch). >> >> AFAICS, user "man" has had UID 6 since at least Debian 6/squeeze >> > >From looking at an Ubuntu 16.04 System I administer, User "man" (uid 6) is, apparently the owner of /var/cache/man, which appears to be an area for translating man pages. Who creates this User? > > Ohh, this is interesting, so I wonder why I had a different value then, > maybe something else was wrong with my system then... > Could there be multiple Packages that might attempt to Create that User (man)? Best regards, Kenneth Parker
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
Super, il semble bien que j'ai oublié de passer les logs vers un fichier, pour m'en débarrasser. Je pense utiliser le bashrc, donc, pas besoin de créer un script complémentaire. Merci pour ce retour. Le 16/08/2019 à 22:23, Étienne Mollier a écrit : > G2PC, au 2019-08-16 : >> .bashrc >> alias mediawiki1='/usr/bin/php >> /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete' >> >> >> crontab -e >> 01 10 * * * bash -ic "mediawiki1 >> /var/log/cron-dropbox.log 2>&1" > Bonjour, > > D'après le manuel de bash(1), section ALIASES, les alias ne sont > pas évalués quand le shell n'est pas interactif, à moins > d'utiliser l'option "expand_aliases" en tête du script, via > "shopt". Je suppose que c'est ce qui vous a motivé à lancer le > script Bash avec l'option "-i". Sauf que le « pseudo terminal » > fourni par l'environnement de cron ne fournit aucune manière > d'interagir, d'où l'erreur : > >> bash: impossible de régler le groupe de processus du terminal (20286): >> Ioctl() inapproprié pour un périphérique >> bash: pas de contrôle de tâche dans ce shell > Je pense que vous vous en sortirez mieux simplement à coup de : > > 01 10 * * * /usr/bin/php > /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete >> > /var/log/cron-dropbox.log 2>&1 > > Ou alors, si comme moi vous n'aimez par les longues lignes, en > lançant un script exécutable /root/bin/mediawiki, par exemple : > > #!/bin/bash > exec /usr/bin/php \ > /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php \ > --delete >> /var/log/cron-dropbox.log 2>&1 > > Qui serait appelé comme ceci : > > 01 10 * * * /root/bin/mediawiki > > Ou bien alors comme cela si le fichier n'est pas exécutable : > > 01 10 * * * /bin/bash /root/bin/mediawiki > > Amicalement,
Confounding behaviour of Empathy.
The Contacts List in Empathy notifies in bold letters, "You haven't added any contacts yet". Meanwhile the "Add Contact" button is pale grey; disabled. It needs a file initialized? A dependancy? Thanks, ... Peter E. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: Why do UID values of system users matter?
Hi, thanks for your quick reply. I see, multiboot with different /etc but shared /usr or /local could invite a lot of trouble if using different UIDs, indeed! Thanks for the quick explanation. > (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 / > > Stretch). > > AFAICS, user "man" has had UID 6 since at least Debian 6/squeeze > Ohh, this is interesting, so I wonder why I had a different value then, maybe something else was wrong with my system then... Steffen
Re: Debian Wiki and LSB (https://wiki.debian.org/LSB)
Hi, ok, thank you for your quick reply! I hope it is OK to edit there. To avoid confusion I added a hint with a link to https://lwn.net/Articles/658809/ and updated the following WikiTopics: - https://wiki.debian.org/LSB - https://wiki.debian.org/DebianLsb - https://wiki.debian.org/LsbRuntimeCompliance - https://wiki.debian.org/LSBInitScripts - https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot It would be great if someone experienced could take a look. Especially the last two pages could need more updating, since AFAIK init.d scripts unfortunately are superseeded by systemd units. Steffen On Fri, Aug 16, 2019 at 11:19 PM Roberto C. Sánchez wrote: > On Fri, Aug 16, 2019 at 11:15:32PM +0200, Steffen Dettmer wrote: > >Hi, > >is the "Debian Wiki" at [1]https://wiki.debian.org/ "official"? If > so, I > >hope here is the right place to ask. The wiki at e.g. > >[2]https://wiki.debian.org/LSB tells "Currently all major > distributions > >comply with the LSB" and [3]https://wiki.debian.org/DebianLsb tells > >"Debian strives to follow and comply with the Linux Standard Base". > This > >are high ranked google hits for searching "debian lsb". > >I though Debian essentially dropped (almost all) LSB compliance. > >Is the Wiki just outdated or is LSB support back? > >Steffen > > The first page has not been updated in over 10 years and the second page > in over 9 years. They are definitely outdated. > > Regards, > > -Roberto > -- > Roberto C. Sánchez > >
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote: > On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote: > > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote: > > > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > > > > > > > Nowadays that system often relies on printer/print queue Bonjour > > > > broadcasts. > > > > > > And that is called "jumping to conclusions". > > > Printing itself haven't changed a bit for last 15 years - a print server > > > takes user's PS or PDF, mangles it to fit printer's representation (be > > > it PCL or something else), and feeds it to the printer. By utilizing > > > unicasts of course. > > > > I was going to let this go because it takes us beyond the server > > situation we are discussing and is a reasonable, succinct description > > of classic printing (which will become unsupported by CUPS in a few > > years time). > > > > However, modern printers will accept and print jobs (e.g. PDF and JPEG) > > without the mangling. These AirPrint-enabled, IPP printers completely > > do away with having to use non-free software or plugins also. What is > > there to dislike about that? > > Nothing. But it also means that one only needs something like ipptool > ([1]) on client-side, leaving CUPS (and a whole notion of a "print > server") out of the equation completely. ipptool depends on libcups2. > > > A user can discover a print server via mDNS multicasts (*not* > > > broadcasts). Or a user can be told a location of such print server. > > > > So - I give my VIP, Android-using customer a piece of paper with a URI > > to type into his phone rather than telling him which printer to use to > > print out the multimillion Euro contract he has just signed? > > Very last century. > > Multicasts are limited to a single L2 network segment by their very > definition. DNS-SD/Bonjour not scaling on typical multi-segment networks is a recognised issue by CUPS upstream. Developments at https://tools.ietf.org/wg/dnssd/ could produce a solution that CUPS could take advantage of. > Putting your printers (or print servers) within a guest network (WiFi > for Android customers) - that's a last century indeed. > > Besides, "multimillion Euro contract" can involve some pretty secretary > lady who's happy to print said contract. Just saying. I have no idea whether a secretary likes to be typecast, but is being pretty, male and amenable a prerequisite to obtaining the post? Anyway, the secretary has knocked off and I am left to instruct my VIP how to use his Android phone to type the printer location without a mistype: dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 So much for telling a user a location. While he is typing I could rivet him with describing the difference between a broadcast and a multicast. -- Brian.
Re: Why do UID values of system users matter?
Le 16/08/2019 à 23:27, Steffen Dettmer a écrit : (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 / Stretch). AFAICS, user "man" has had UID 6 since at least Debian 6/squeeze.
Re: Why do UID values of system users matter?
On Fri, Aug 16, 2019 at 2:28 PM Steffen Dettmer wrote: > Hi, > > just for my curiosity I wonder why the numeric UID values matter at all, > for example: > > > I believe file ownership is tracked by numeric UID rather than user name. So, for example, if you multi-boot, a file owned by user 500 in one system will be owned by user 500 on every other system, even if it does not correspond to the same user name. That's been my experience anyway, and an occasional issue. dan
Why do UID values of system users matter?
Hi, just for my curiosity I wonder why the numeric UID values matter at all, for example: update-passwd has found a difference between your system accounts and the current Debian defaults. It is advisable to allow update-passwd to change your system; without those changes some packages might not work correctly. For more documentation on the Debian account policies, please see /usr/share/doc/base-passwd/README. The proposed change is: Change the UID of user "man" from 13 to 6 (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 / Stretch). Normally I would assume that the numeric values would not be use anywhere at all, only the symbolic names. If the numeric value matters, why are their values no kept across releases? Steffen
Re: Debian Wiki and LSB (https://wiki.debian.org/LSB)
On Fri, Aug 16, 2019 at 11:15:32PM +0200, Steffen Dettmer wrote: >Hi, >is the "Debian Wiki" at [1]https://wiki.debian.org/ "official"? If so, I >hope here is the right place to ask. The wiki at e.g. >[2]https://wiki.debian.org/LSB tells "Currently all major distributions >comply with the LSB" and [3]https://wiki.debian.org/DebianLsb tells >"Debian strives to follow and comply with the Linux Standard Base". This >are high ranked google hits for searching "debian lsb". >I though Debian essentially dropped (almost all) LSB compliance. >Is the Wiki just outdated or is LSB support back? >Steffen The first page has not been updated in over 10 years and the second page in over 9 years. They are definitely outdated. Regards, -Roberto -- Roberto C. Sánchez
Debian Wiki and LSB (https://wiki.debian.org/LSB)
Hi, is the "Debian Wiki" at https://wiki.debian.org/ "official"? If so, I hope here is the right place to ask. The wiki at e.g. https://wiki.debian.org/LSB tells "Currently all major distributions comply with the LSB" and https://wiki.debian.org/DebianLsb tells "Debian strives to follow and comply with the Linux Standard Base". This are high ranked google hits for searching "debian lsb". I though Debian essentially dropped (almost all) LSB compliance. Is the Wiki just outdated or is LSB support back? Steffen
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
On 16/08/2019 22.23, Étienne Mollier wrote: > Qui serait appelé comme ceci : > > 01 10 * * * /root/bin/mediawiki > > Ou bien alors comme cela si le fichier n'est pas exécutable : > > 01 10 * * * /bin/bash /root/bin/mediawiki Hum, bien sûr remplacez root par l'utilisateur en charge dudit mediawiki... ;) 01 10 * * * /bin/bash "$HOME/bin/mediawiki" Amicalement, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: maximale Monitorgröße auslesen
Thomas writes: Hallo, wie kann ich die maximal anschließbare Monitorgröße auslesen? Der PC hat Stretch. Gruss Thomas Hallo, *** das hier ist die englischsprachige debian-user Liste, von daher sollten Fragen wohl besser auf Englisch gestellt werden? *** die maximale Auflösung ergibt sich aus der Kombination Grafikkarte+Treiber+gewählter/vorhandener Anschluss an der Grafikkarte bzw. bei integrierter Prozessorgrafik aus Grafikeinheit+Treiber+Mainboard+gewählter Anschluss. ich würde dafür zwei Quellen konsultieren: * Datenblätter der Grafikkarte bzw. von Mainboard+CPU. Bei hohen Auflösungen besonders auf die DisplayPort und HDMI Versionen achten. * xrandr auf der Konsole eingeben. Das zeigt, was der Treiber glaubt ausgeben zu können, bei mir bspw: $ xrandr Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 DP-0 connected primary 2560x1440+1920+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 59.95*+ 1920x1200 59.88 [...] DP-1 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm 1920x1080 60.00*+ 59.9450.00 1680x1050 59.95 [...] Das Problem bei der xrandr-Variante ist, dass es oft nur etwas anzeigt, wenn schon ein Monitor angeschlossen ist und dann wird (zumindest bei Flachbildschirmen) eigentlich als höchste Auflösung immer die native Auflösung des Monitors ausgegeben. Es kann mehr möglich sein, wenn man einen höher aufgelösten Monitor anschließt. Bzgl. der physischen Monitorgrößen (24", 27", ...) gibt es übrigens keine Einschränkungen: Ein 27" Full-HD Monitor ist aus Sicht des Rechners kein Unterschied zum 24" Monitor (außer im Hinblick auf die Pixeldichte, aber das ist erst bei sehr hohen Auflösungen auf kleinen Monitoren kritisch und verhindert nicht die Bildausgabe an sich). ~~~ Shortened english variant: Available maximum resolution depends on graphics card and driver and on mainboard and driver for integrated processor graphics. To find out about their capabilities, it is best to consult the respective datasheets (check the HDMI and DP versions for high resolutions). Alternatively, `xrandr` can give some basic insights about the resolution although it only displays the resolutions possible in the current setup by default (i.e. it is not well-suited to find out if a monitor of higher resolution could be attached problemlessly). Finally, physical screen size is mostly irrelevant for hardware compatibility unless small screen sizes and high resolutions come together (like UHD on 21" or such). HTH Linux-Fan pgp0ETyrFfqFH.pgp Description: PGP signature
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
G2PC, au 2019-08-16 : > .bashrc > alias mediawiki1='/usr/bin/php > /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete' > > > crontab -e > 01 10 * * * bash -ic "mediawiki1 >> /var/log/cron-dropbox.log 2>&1" Bonjour, D'après le manuel de bash(1), section ALIASES, les alias ne sont pas évalués quand le shell n'est pas interactif, à moins d'utiliser l'option "expand_aliases" en tête du script, via "shopt". Je suppose que c'est ce qui vous a motivé à lancer le script Bash avec l'option "-i". Sauf que le « pseudo terminal » fourni par l'environnement de cron ne fournit aucune manière d'interagir, d'où l'erreur : > bash: impossible de régler le groupe de processus du terminal (20286): > Ioctl() inapproprié pour un périphérique > bash: pas de contrôle de tâche dans ce shell Je pense que vous vous en sortirez mieux simplement à coup de : 01 10 * * * /usr/bin/php /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete >> /var/log/cron-dropbox.log 2>&1 Ou alors, si comme moi vous n'aimez par les longues lignes, en lançant un script exécutable /root/bin/mediawiki, par exemple : #!/bin/bash exec /usr/bin/php \ /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php \ --delete >> /var/log/cron-dropbox.log 2>&1 Qui serait appelé comme ceci : 01 10 * * * /root/bin/mediawiki Ou bien alors comme cela si le fichier n'est pas exécutable : 01 10 * * * /bin/bash /root/bin/mediawiki Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
.bashrc alias mediawiki1='/usr/bin/php /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete' crontab -e 01 10 * * * bash -ic "mediawiki1 >> /var/log/cron-dropbox.log 2>&1" J'obtiens dans les messages system, via mailx : bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique bash: pas de contrôle de tâche dans ce shell
Re: Compiling Linux with "bdver2" gcc optimization option
Franco Martelli, on 2019-08-16: > On 16/08/19 at 17:22, Étienne Mollier wrote: [...] > > Compilers may have good optimization routines to boost the speed > > of the code in several situations, but in other ones there are > > trade-offs to take between size and performance of the code. I > > personally prefer smaller sized executables (-Os): they fit in > > less pages, so uses less CPU cache, and leave more room for my > > programs to get more of their own data in cache (or I might > > simply have spent too much time on suckless.org. ;) > > Do you remember which kernel CONFIG switch lets to do this optimization? You can set these values as following if you want to optimize for size, or the other way around for performance: # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y Then "make oldconfig" to validate your changes. And same as before, do your own measures. ;) > > Activating CPU specific options is interesting on some > > particular use cases, but newer instruction often require > > setting up various bits in the CPU before use, which tends to > > inflate the resulting executable. This may be interesting for > > scientific applications, or programs dealing with big data > > arrays in general. In kernel mode however, the only case I can > > think of where CPU specific accelerators would be beneficial are > > disk ciphering and RAID arrays, for which I believe there is > > already some runtime detection of available instructions, even > > with the generic compiler options. > > I have four disks in a RAID 5 software array configuration on my system, > they are managed by mdadm this is my /proc/mdstat file: > > $ cat /proc/mdstat > Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] > md0 : active raid5 sda1[0] sdb1[1] sdd1[3](S) sdc1[2] > 1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] > [UUU] > > unused devices: If you have a look at "sudo dmesg" output, near the beginning, the kernel outputs a series of performance testing out of various RAID topologies, and keeps the best for runtime. I'm speaking from memory, as I have no RAID array at hand to check this. [...] > > Or just see how perform your usual programs, if there are > > visible improvements. > > > > Have fun, :) > > Yes I agree the optimization won't impact on performance in a way that > is perceptively by an human there are tweak more important in the kernel > such as CONFIG_HZ_1000=y > I always take measurement of the time employee by kernel compilation out > of curiosity. > Thanks again for the tips, best regards You're welcome, :) -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: TWAIN in Debian 10.
On Fri, 16 Aug 2019 07:58:58 -0700 pe...@easthope.ca wrote: > Hi again, > > I'm interested in moving an image from a JVC Digital Camera KY-F70 to > Debian 10. The camera is pre-USB; it has a 50 pin SCSII connector. > Probably what the Wikipedia SCSII connector article mentions as > HPCN50. The JVC manual mentions TWAIN software for image transfer and > claims their software works in Windows 95/98/NT 4.0. > > Has anyone used TWAIN in Debian? Is there any chance of Debian > receiving images using TWAIN directly? Try to make the Windows TWAIN > software provided by JVC work under wine? If wine is necessary, can > anyone recommend a Windows version from the three noted above? > I'm pretty sure that TWAIN was dropped by the time of Win 7, or the 64 bit version at the latest. -- Joe
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote: > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > > > > > Nowadays that system often relies on printer/print queue Bonjour > > > broadcasts. > > > > And that is called "jumping to conclusions". > > Printing itself haven't changed a bit for last 15 years - a print server > > takes user's PS or PDF, mangles it to fit printer's representation (be > > it PCL or something else), and feeds it to the printer. By utilizing > > unicasts of course. > > I was going to let this go because it takes us beyond the server > situation we are discussing and is a reasonable, succinct description > of classic printing (which will become unsupported by CUPS in a few > years time). > > However, modern printers will accept and print jobs (e.g. PDF and JPEG) > without the mangling. These AirPrint-enabled, IPP printers completely > do away with having to use non-free software or plugins also. What is > there to dislike about that? Nothing. But it also means that one only needs something like ipptool ([1]) on client-side, leaving CUPS (and a whole notion of a "print server") out of the equation completely. > > A user can discover a print server via mDNS multicasts (*not* > > broadcasts). Or a user can be told a location of such print server. > > So - I give my VIP, Android-using customer a piece of paper with a URI > to type into his phone rather than telling him which printer to use to > print out the multimillion Euro contract he has just signed? > Very last century. Multicasts are limited to a single L2 network segment by their very definition. Putting your printers (or print servers) within a guest network (WiFi for Android customers) - that's a last century indeed. Besides, "multimillion Euro contract" can involve some pretty secretary lady who's happy to print said contract. Just saying. Reco [1] https://github.com/istopwg/ippsample
Re: Permissions and delivery of LAN email by exim
On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: > AIUI exim should be able to deliver emails into a user's mbox, but > I'm confused about how exim is meant to do that, because it runs as > user Debian-exim, but mailbox permissions are normally group:mail. I don't know much about exim4, but: -rwsr-xr-x 1 root root 1241412 Jul 20 07:35 /usr/sbin/exim4 That setuid bit means it *can* become you in order to deliver a message to your inbox.
Re: Compiling Linux with "bdver2" gcc optimization option
On 16/08/19 at 17:22, Étienne Mollier wrote: > Bonjour, > > Woops, this sounds a bit like I might not have used a very clear > wording. If I were at your place, I would proceed so; but I > don't have a Piledriver CPU to do actual testing on my side. > I'm still stuck with an old K10, not to mention my laptop, which > comes with an old regular Atom. :) > > I did try to replace the k8 option by amdfam10 though. In the > half hundred thousand lines of logs issued by the build, I get > something like a dozen differences between k8 and k10. There > were a tremendous amount of warnings too, but some of the ones > you encountered did not appear: the thing with the missing jump > target for instance, nor the ANNOTATE_NOSPEC_ALTERNATIVE on the > retpoline thing. I am running Debian Sid, currently shipping > with Gcc 9, so this is a difference to take in account though. > Finally, building an upstream Linux 5.2 kernel instead of > Buster's 4.19 does not show most of the warnings I encountered, > as these are being fixed as they come, but probably not as well > in LTS kernels. > > Doing a third run with addition of the tuning options (-mtune) > made almost no difference at all, except on the build number and > the CRC hash. It seems to me that the architecture specific > (-march) option already applies the proper tuning, at least for > my architecture. > > My last manipulation consisted in building Linux upstream 5.2.9, > released lately, with -march=amdfam10, and this one is running > quite well so far: > > $ uname -rv > 5.2.9-k10 #1 SMP PREEMPT Fri Aug 16 16:13:08 CEST 2019 > > But again, no messages worth mentioning during the compilation. > > Do your warnings appear when your build targets k8? > Or when building a generic x86_64 kernel? Actually I run kernel built with "k8" option, it works fine, I got no warning during the compilation. Investigating deeper your tips about "amdfam10" I checked the gcc options web page: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html amdfam10 optimization was for Family 10 CPU but I have a Family 15h CPU I notice that it also exists a "bdver1" for my CPU family so I wanted give it a try and I compiled the kernel source with "bdver1" and surprise I got no warning, all worked fine, :-) the command line I use to compile is: ~/linux-source-4.19$ time make -s -j9 ; make -s -j9 modules > Compilers may have good optimization routines to boost the speed > of the code in several situations, but in other ones there are > trade-offs to take between size and performance of the code. I > personally prefer smaller sized executables (-Os): they fit in > less pages, so uses less CPU cache, and leave more room for my > programs to get more of their own data in cache (or I might > simply have spent too much time on suckless.org. ;) Do you remember which kernel CONFIG switch lets to do this optimization? > > Activating CPU specific options is interesting on some > particular use cases, but newer instruction often require > setting up various bits in the CPU before use, which tends to > inflate the resulting executable. This may be interesting for > scientific applications, or programs dealing with big data > arrays in general. In kernel mode however, the only case I can > think of where CPU specific accelerators would be beneficial are > disk ciphering and RAID arrays, for which I believe there is > already some runtime detection of available instructions, even > with the generic compiler options. I have four disks in a RAID 5 software array configuration on my system, they are managed by mdadm this is my /proc/mdstat file: $ cat /proc/mdstat Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md0 : active raid5 sda1[0] sdb1[1] sdd1[3](S) sdc1[2] 1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: > > To be honest, I don't believe the performance gain to get from > the compiler is tremendous here. Figures from the author of the > patch are there to tell us there is a gain indeed; but when you > investigate in detail the percentage of performance brought by > the tuning, it is only about 0.03% for the selected benchmark on > median values. See the "Data" section at the very end of the > README, and do your own calculations: > > https://github.com/graysky2/kernel_gcc_patch/blob/master/README.md > > The best you can do here is to do your own measures with your > own pattern of usage. If you are a developer, you can run timed > builds of Linux, and see the time it takes. If you are inclined > toward image rendering speeds, there are a few demo-scenes out > there where you might get a few figures such as the frame rate > (careful, glxgears may get capped to 60Hz when some accelerators > are in use, prefer fancier demos. ;) > > There is also this other thread dealing with kernel latency > measures; you may find a few useful tools listed in this > discussion: > >
maximale Monitorgröße auslesen
Hallo, wie kann ich die maximal anschließbare Monitorgröße auslesen? Der PC hat Stretch. Gruss Thomas
Permissions and delivery of LAN email by exim
AIUI exim should be able to deliver emails into a user's mbox, but I'm confused about how exim is meant to do that, because it runs as user Debian-exim, but mailbox permissions are normally group:mail. For example, with exim4 on hostR set up as … internet site; mail is sent and received directly using SMTP Domains to relay mail for: hostS;corp Keep number of DNS-queries minimal (Dial-on-Demand)? Yes dc_eximconfig_configtype='internet' dc_relay_domains='hostS;corp' dc_minimaldns='true' … hostS can send an email to foo@hostR without its being rejected. At the receiving end, with these lines in /etc/exim4/hubbed_hosts, … hostR.corp: 192.168.1.18 mail_spool hostR: 192.168.1.18 mail_spool … when exim tries to deliver this email directly, the exim log shows … 1hyefl-0001RE-Up <= f...@some-other.domain.tld H=(hostS.corp) [192.168.1.17] P=esmtp S=711 id=20190816160149.nckhtqfas3tge...@hosts.corp 1hyefl-0001RE-Up == f...@hostr.corp R=hubbed_hosts T=mail_spool defer (-6): mailbox /var/mail/foo has wrong uid (1003 != 111) … and the email remains stuck in /var/spool/exim. Background info: etc/passwd on hostR: mail:x:8:8:mail:/var/mail:/usr/sbin/nologin Debian-exim:x:111:120::/var/spool/exim4:/usr/sbin/nologin foo:x:1003:1003:Mr Chew,,,:/home/foo:/bin/bash ps -ef on hostR: 9659 1 111 ?Ss 0:00 /usr/sbin/exim4 -bd -q30m ls on hostR: drwxrwsr-x 2 rootmail 4096 Aug 16 13:24 /var/mail/ -rw-rw 1 foo mail 19284 Aug 16 12:00 /var/mail/foo -rw-rw 1 Debian-exim mail 670 Aug 16 13:24 /var/mail/root So what piece of the puzzle is missing that would allow exim to deliver such an email to foo's mbox? Exim has no difficulty, for example, delivering locally generated emails from cron … 1hyfaG-00027u-Mt <= r...@hostr.corp U=root P=local S=91975 1hyfaG-00027u-Mt => foo R=local_user T=mail_spool 1hyfaG-00027u-Mt Completed … nor in delivering remotely sent emails to root: 1hygu1-0002c1-A7 <= f...@some-other.domain.tld H=(hostS.corp) [192.168.1.17] P=esmtp S=734 id=20190816182441.gwbbcru46mt7c...@hosts.corp 1hygu1-0002c1-A7 => r...@hostr.corp R=hubbed_hosts T=mail_spool H=192.168.1.18 1hygu1-0002c1-A7 Completed Cheers, David.
Re: Migration des noms des interfaces réseau
Le 16/08/2019 à 01:31, Bernard Schoenacker a écrit : Peut-on sans risque modifier tous les fichiers de conf qui contiennent eth0 et eth1 pour leurs nouveaux noms ? J'ai un firewall géré avec fwbuilder : dois-je modifier à la main le script généré ? Si vous avez des URL sur cette migration, je suis preneur... Merci ! bonjour, voici un début de piste avec la doc de arch linux qui peut s'adapter à Debian : https://wiki.archlinux.org/index.php/Systemd-networkd attention, pour éviter que le système se mélange les pinceaux, il est conseillé de donner les adresses arp en dur dans le fichier de conf network de chaque carte réseau pour les règles iptables contenant le nom du device il est conseillé de le remplacer par la nouvelle désignation Bonjour, Merci pour le lien. Mais du tout, je suis un peu plus perdu ;-) Je ne vois aucune référence à /etc/network/interfaces... systemd-networkd remplace-t-il totalement ce système ? Et pour le nom des interfaces, je peux donc sans crainte remplacer chaque référence à eth0 par son nouveau nom ? Ça fait une bonne vingtaines de fichiers à modifier avec parfois plusieurs références dans chaque fichier... Cordialement, -- Migrec
Confounding behaviour of Empathy.
The Contacts List in Empathy notifies in bold letters, "You haven't added any contacts yet". Meanwhile the "Add Contact" button is pale grey; disabled. I guess others have encountered this connundrum. Anyone have a solution? Thanks, ... Peter E. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: Arrow annotation in GIMP.
On Fri, Aug 16, 2019 at 10:40:59AM -0700, pe...@easthope.ca wrote: > From: Dan Ritter > Date: Wed, 14 Aug 2019 08:26:18 -0400 > > Set the background to transparent. > [...] > Really I don't understand the representation used in GIMP. From what > I've read, there are three channels, R, G, B. OK. Plus an optional > 4th, alpha. What is it? There are four: RGBA -- [1] should address your other questions. The alpha channel is useful when you overlay images (like in your arrow case): you want the arrow be "on top" of your image, but you don't want the arrow's background obscuring the rest of your image. You could achieve that with a "mask" (an array of bits of your image's size with an 1 for each "relevant" pixel and a 0 for each "irrelevant" one). This is an alpha channel with one bit depth. A deeper alpha channel allows semi-transparency, where the foreground image could, for example, merge "softly" into the background. A neat effect would be to make your arrow semi-transparent: you would still see through, as if the arrow was smoked glass. Best you play with that under Gimp, then you'll "get" it quickly. Cheers [1] https://en.wikipedia.org/wiki/RGBA -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote: > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > > > Nowadays that system often relies on printer/print queue Bonjour > > broadcasts. > > And that is called "jumping to conclusions". > Printing itself haven't changed a bit for last 15 years - a print server > takes user's PS or PDF, mangles it to fit printer's representation (be > it PCL or something else), and feeds it to the printer. By utilizing > unicasts of course. I was going to let this go because it takes us beyond the server situation we are discussing and is a reasonable, succinct description of classic printing (which will become unsupported by CUPS in a few years time). However, modern printers will accept and print jobs (e.g. PDF and JPEG) without the mangling. These AirPrint-enabled, IPP printers completely do away with having to use non-free software or plugins also. What is there to dislike about that? > A user can discover a print server via mDNS multicasts (*not* > broadcasts). Or a user can be told a location of such print server. So - I give my VIP, Android-using customer a piece of paper with a URI to type into his phone rather than telling him which printer to use to print out the multimillion Euro contract he has just signed? Very last century. Anyone fancy carrier pigeons? -- Brian.
Re: Arrow annotation in GIMP.
From: Dan Ritter Date: Wed, 14 Aug 2019 08:26:18 -0400 > Set the background to transparent. Menus: Layer > Tranparency > Add Alpha Channel. The new viewer remains black. Might be transparent. Might not. (If all else fails, will see what happens when the arrow is dropped on the image layer. If the result has the appearance of the arrow layer, the arrow background is not transparent and my image is obscured.) Really I don't understand the representation used in GIMP. From what I've read, there are three channels, R, G, B. OK. Plus an optional 4th, alpha. What is it? What is the point of alpha? Transparent should be simply no marking. RGB = (0,0,0). What does alpha represent? Thanks, ... P. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: TWAIN in Debian 10.
From: Dan Ritter Date: Fri, 16 Aug 2019 12:15:24 -0400 > The problem with TWAIN, as I recall, is that it wasn't actually > a standard API between devices and OS so much as a standard way > for an application to call a manufacturer-supplied application > in order to control and receive images. > > That's why it was completely supplanted by SANE, which more or > less standardizes the device-OS interface as well as the > application-application interface. Thanks for the background. > You might manage to get the Windows TWAIN software to run in > WINE, or if you have a Windows 95/98 virtual machine, that would > probably work. Thanks. Will put some effort on those approaches. If there is a JVC diskette with DOS software that is probably the best place to start. Simpler is better in this case. Wine is installed. Haven't tried the JVC software yet. Might try the virtual system. I've used bochs and QEMU for Oberon. I guess Windows will require system installation media. > 1360x1024 at 7.5 frames/sec > > 640x200 at 30 frames/sec Only static images needed here. > ... the SCSI connection is designated for connection to a > storage drive or printer. We have the original manual. More than a page covers a PC connection via SCSII. > If you are specifically looking for a microscope mountable > camera, there are lots of relatively cheap C-mount cameras > and C-mount adapters, all with much better specs and much > easier to access. Advances in micro-electronics and software make beautiful old hardware obsolete. =8~| Thanks again, ... P. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: webmail and email from command line
anyone who needs that, needs a burner account. Those are lots less permanent and when your account is taken by someone else since you have no way to recover that account it's understood whatever you had in it was encrypted and is disposible. Google provides a higher level of management than you need for this kind of account. The aol "service" it turns out had these kind of accounts which once a screen name was taken over you lost the account that went with it. Search for public internet sites and check out what mail services those have to offer and I think you'll be happy. On Fri, 16 Aug 2019, loredana wrote: > Date: Fri, 16 Aug 2019 11:26:53 > From: loredana > To: Jude DaShiell > Cc: debian-user@lists.debian.org > Subject: Re: webmail and email from command line > Resent-Date: Fri, 16 Aug 2019 13:27:39 + (UTC) > Resent-From: debian-user@lists.debian.org > > On Fri, Aug 16, 2019 at 12:51 PM Jude DaShiell wrote: > > > Running using 2fa may be possible with non-browser apps if your security > > records indicate you ran with what google considers an untrusted app and > > google has it listed. You can generate an app-specific password for the > > non-browser app and will need to save it. Then you modify your > > non-browser app settings on local machine and key in that app-specific > > password in place of the other password you used earlier. This has been > > documented for mutt as being possible and may work for other non-browser > > apps too. You'll need to give google a mobile number for account > > recovery and the like too. > > Yes, that should work too (see the first mail in this thread). > > But ... what stopped me and made me think is: what if I prefer to have > access to "my" mail without giving up a mobile or not so mobile > telephone number? > > I am happier if this is made possible for everybody who prefer so via > a free application. Not sure gmailieer is going to work, not until I > try it. Bu it looks promising. > > Cheers, > Loredana > > --
Re: TWAIN in Debian 10.
On Fri, Aug 16, 2019 at 11:15 AM wrote: > Has anyone used TWAIN in Debian? TWAIN is my all time favorite acronym.
Re: TWAIN in Debian 10.
pe...@easthope.ca wrote: > Hi again, > > I'm interested in moving an image from a JVC Digital Camera KY-F70 to > Debian 10. The camera is pre-USB; it has a 50 pin SCSII connector. > Probably what the Wikipedia SCSII connector article mentions as > HPCN50. The JVC manual mentions TWAIN software for image transfer and > claims their software works in Windows 95/98/NT 4.0. > > Has anyone used TWAIN in Debian? Is there any chance of Debian > receiving images using TWAIN directly? Try to make the Windows TWAIN > software provided by JVC work under wine? If wine is necessary, can > anyone recommend a Windows version from the three noted above? > > Other ideas? The problem with TWAIN, as I recall, is that it wasn't actually a standard API between devices and OS so much as a standard way for an application to call a manufacturer-supplied application in order to control and receive images. That's why it was completely supplanted by SANE, which more or less standardizes the device-OS interface as well as the application-application interface. You might manage to get the Windows TWAIN software to run in WINE, or if you have a Windows 95/98 virtual machine, that would probably work. I would note, though, that this camera appears to have terrible specifications by current standards: 1360x1024 at 7.5 frames/sec 640x200 at 30 frames/sec and the SCSI connection is designated for connection to a storage drive or printer. If you are specifically looking for a microscope mountable camera, there are lots of relatively cheap C-mount cameras and C-mount adapters, all with much better specs and much easier to access. -dsr- -dsr-
Re: Debian latency test
Reco, on 2019-08-16: > On Fri, Aug 16, 2019 at 02:31:38PM +0200, danwe wrote: > > is there any program to test the intern latency of Debian? So > > I just need > > to know how much time the Linux Kernel needs to response to a > > request. [...] > bpftrace definitely can do it, but some learning is required. Yes, I confirm that is a great tool! The following page is a nice kick starter to begin to proceed to measures and various data acquisition, teaching by example: https://github.com/iovisor/bpftrace/blob/master/docs/tutorial_one_liners.md Just be careful with the injection of code at trace points or kprobes: the more you inject code for your measure, the more the targeted kernel operation will take time, thus slowing the machine et providing you with underestimated results. Have fun, :) -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Compiling Linux with "bdver2" gcc optimization option
Bonjour, Franco Martelli, on 2019-09-14: > On 13/08/19 at 19:35, Étienne Mollier wrote: [...] > > I would do a few tests with a virtual > > machine supporting bdver2 instructions before going live anyway, > > and backups stored far away from the machine once testing, and > > possibly without contact with that kernel. > > I didn't boot that kernel, I don't rely on it. Thanks if you can > investigate on what happens during compilation process. Woops, this sounds a bit like I might not have used a very clear wording. If I were at your place, I would proceed so; but I don't have a Piledriver CPU to do actual testing on my side. I'm still stuck with an old K10, not to mention my laptop, which comes with an old regular Atom. :) I did try to replace the k8 option by amdfam10 though. In the half hundred thousand lines of logs issued by the build, I get something like a dozen differences between k8 and k10. There were a tremendous amount of warnings too, but some of the ones you encountered did not appear: the thing with the missing jump target for instance, nor the ANNOTATE_NOSPEC_ALTERNATIVE on the retpoline thing. I am running Debian Sid, currently shipping with Gcc 9, so this is a difference to take in account though. Finally, building an upstream Linux 5.2 kernel instead of Buster's 4.19 does not show most of the warnings I encountered, as these are being fixed as they come, but probably not as well in LTS kernels. Doing a third run with addition of the tuning options (-mtune) made almost no difference at all, except on the build number and the CRC hash. It seems to me that the architecture specific (-march) option already applies the proper tuning, at least for my architecture. My last manipulation consisted in building Linux upstream 5.2.9, released lately, with -march=amdfam10, and this one is running quite well so far: $ uname -rv 5.2.9-k10 #1 SMP PREEMPT Fri Aug 16 16:13:08 CEST 2019 But again, no messages worth mentioning during the compilation. Do your warnings appear when your build targets k8? Or when building a generic x86_64 kernel? > > Note that someone from the Gentoo community has developed a set > > of patches to expand the possibilities of optimization for the > > kernel, depending on Linux and GCC versions. You may be > > interested in the following one for Buster: > > > > > > https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v8.1%2B_kernel_v4.13%2B.patch > > > > These mainly apply changes in various code sections to put the > > flags in place, and provide options through the .config file of > > the source code. I haven't tested it, but I don't believe this > > will solve your warnings, reading through the patch. Yet it > > does a bit more than just replacing the compiler flag: there is > > notably a component related to L1 cache shift which is modified > > too. That should bring an appreciable performance boost if it > > corrects cache line mismatch. > > Thanks, but I don't want to patch the kernel, that change to the > Makefile was enough simple in order to get the optimization that I > looking for. Fair enough, I reread the whole patch, and your modification seems sufficient, I believe. > > Please be aware that CPU optimizations in kernel, targeting Zen > > and Skylake in this case, seemed to be hardly detectable, or > > even counter productive, with various computer usage patterns, > > according to measures done by Phoronix earlier this year: > > > > https://www.phoronix.com/scan.php?page=article=linux-50-march=1 > > > > Of course this may not be the case for your own typical load, > > but I would recommend to do a few measures, to assess the actual > > performance gain on your machine with, and without, CPU specific > > compiler optimizations. > > I never experimented benchmark with and without bdver2 option, I assumed > that if it exists an option for k8 in the kernel then changing it to > bdver2 it would be good (I hope). Compilers may have good optimization routines to boost the speed of the code in several situations, but in other ones there are trade-offs to take between size and performance of the code. I personally prefer smaller sized executables (-Os): they fit in less pages, so uses less CPU cache, and leave more room for my programs to get more of their own data in cache (or I might simply have spent too much time on suckless.org. ;) Activating CPU specific options is interesting on some particular use cases, but newer instruction often require setting up various bits in the CPU before use, which tends to inflate the resulting executable. This may be interesting for scientific applications, or programs dealing with big data arrays in general. In kernel mode however, the only case I can think of where CPU specific accelerators would be beneficial are disk ciphering and RAID arrays, for which I believe there is already some runtime detection of available
TWAIN in Debian 10.
Hi again, I'm interested in moving an image from a JVC Digital Camera KY-F70 to Debian 10. The camera is pre-USB; it has a 50 pin SCSII connector. Probably what the Wikipedia SCSII connector article mentions as HPCN50. The JVC manual mentions TWAIN software for image transfer and claims their software works in Windows 95/98/NT 4.0. Has anyone used TWAIN in Debian? Is there any chance of Debian receiving images using TWAIN directly? Try to make the Windows TWAIN software provided by JVC work under wine? If wine is necessary, can anyone recommend a Windows version from the three noted above? Other ideas? Thanks,... Peter E. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 08:39:43 -0400, Greg Wooledge wrote: > On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote: > > On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > > > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > > > > > On Thu, 2019-08-15 at 19:41 +0100, Brian wrote: > > > > > The fact remains that dbus is not a DE only package. How did anyone > > > > > get the idea it was? > > > > > > > > Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia > > > > [1] > > > > > > > >D-Bus was developed as part of the freedesktop.org project [...] to > > > >standardize services provided by Linux desktop environments such as > > > >GNOME and KDE. > > > > > > > > It's seems quite reasonable to me for people to jump to the conclusion > > > > that it's not likely relevant for servers. > > > > > > > > [1] https://en.wikipedia.org/wiki/D-Bus > > > > > > Jumping to conclusions is the ideal way of neglecting facts and promoting > > > fallacious assertions. I have given two examples that challenge > > > > > > dbus "...is redundant for typical server software" > > > > The first one being "apt cache rdepends"? You can do better than this. > > > > The second one being CUPS? dbus is not required for printing itself. > > Also, most servers don't deal with ink-and-paper printing. At all. I don't quite follow that, but is it of great importance? Some do, and then dbus will be involved in advertising print queues to clients. > Brian asked how people would conclude things about D-Bus, and Tixy gave > a completely legitimate answer. It was an answer I had been considering > writing myself, but I was lazy. > > The name is *literally* an abbreviation for Desktop Bus, and you (Brian) > claim you don't understand why people think it's only for desktop systems? > Come on. I own up to reading solely the primary source at freedesktop. I can find no reference there to dbus being required only when (to quote John Doe) > a DE (Gnome,Mate, ...) is present. Whatever the genesis of the application's name and function, it has evidently moved on in the last 10+ years. firewalld (which looks like a good candidate for use on a server) also depends on dbus. -- Brian.
Re: webmail and email from command line
Hi Loredana, I agree with other debianers that setting a forward to another email provider for now should be the easiest option. I think it would be a good idea to find an email provider that allows smtp/imap clients, and as far as I know protonmail does it only in Pro version. I know there is posteo.de that does. Also, there should be some small local email providers in your area, the services are usually on fee (normally quite low) but you gain direct support with setups and all the rest. As for command line email clients, probably the most complete one is Mutt. There is a guide from a year ago on how to configure it with gmail here: https://gitlab.com/muttmua/mutt/wikis/UseCases/Gmail I know mutt allows different security features, but it surpass my experience with it, as gmail might be demanding and moody in allowing external clients. You can actually set mutt and emacs to work together as explained here: https://gitlab.com/muttmua/mutt/wikis/MuttFaq/Editor#how-do-i-configure-mutt-to-use-mail-mode-in-emacs or here https://www.emacswiki.org/emacs/MuttInEmacs If you decide for mutt and stumble across configuration problems, you can look for support in sdf.org community. It is a command-line based community (you login over ssh) with an important part of blind users, so surely they will be more knowledgeble than I am :smiley: I hope this helps, best regards, ~l.
Re: webmail and email from command line
On Fri, Aug 16, 2019 at 12:51 PM Jude DaShiell wrote: > Running using 2fa may be possible with non-browser apps if your security > records indicate you ran with what google considers an untrusted app and > google has it listed. You can generate an app-specific password for the > non-browser app and will need to save it. Then you modify your > non-browser app settings on local machine and key in that app-specific > password in place of the other password you used earlier. This has been > documented for mutt as being possible and may work for other non-browser > apps too. You'll need to give google a mobile number for account > recovery and the like too. Yes, that should work too (see the first mail in this thread). But ... what stopped me and made me think is: what if I prefer to have access to "my" mail without giving up a mobile or not so mobile telephone number? I am happier if this is made possible for everybody who prefer so via a free application. Not sure gmailieer is going to work, not until I try it. Bu it looks promising. Cheers, Loredana
Re: Debian latency test
I do have Xenomai 2 with RTnet and Xenomai 3 without RTnet. I have tested "latency" on both to see how fast the Kernel can react to a request. In that context I do not want to measure how fast e.g. real-time udp frames will be. I just need to know how fast the Kernel could be. Am Fr., 16. Aug. 2019 um 14:52 Uhr schrieb Henning Follmann < hfollm...@itcfollmann.com>: > On Fri, Aug 16, 2019 at 02:31:38PM +0200, danwe wrote: > > Hello, > > > > is there any program to test the intern latency of Debian? So I just need > > to know how much time the Linux Kernel needs to response to a request. > > > > Kind regards > > > > Daniel > > This measurements will be meaningless unless you have a > real time enabled kernel. The kernel does not provide > predictable responsetimes without rt. > > > -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
Re: Debian latency test
On Fri, Aug 16, 2019 at 02:31:38PM +0200, danwe wrote: > Hello, > > is there any program to test the intern latency of Debian? So I just need > to know how much time the Linux Kernel needs to response to a request. > > Kind regards > > Daniel This measurements will be meaningless unless you have a real time enabled kernel. The kernel does not provide predictable responsetimes without rt. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: webmail and email from command line
On Fri, 16 Aug 2019, loredana wrote: > Date: Fri, 16 Aug 2019 10:02:17 > From: loredana > To: Celejar > Cc: debian-user@lists.debian.org > Subject: Re: webmail and email from command line > Resent-Date: Fri, 16 Aug 2019 12:03:05 + (UTC) > Resent-From: debian-user@lists.debian.org > > First of all, I wish to thank all of you who shared their experience. > Be reassured I am taking any constructive suggestion into serious > account and exploring more. > > Then: > > On Fri, Aug 16, 2019 at 2:03 AM Celejar wrote: > > > > On Wed, 14 Aug 2019 16:24:49 +000 > > > loredana wrote: > > > secure applications, this is likely not to be a viable solution (it > > > seems that google is going to forbit less secure application access > > > starting November first of this year and it is already a pain to use > > > it now). > > > > What is your source for Google's plans, and how is it already a pain? > > I am following the google development on this issue, but I got the > date from the mu4e mailing list. I'l post the link, if I can find it > again (remember, I am almost blind and even replying to email is, at > the moment, really slow and difficult). > > > have been using getmail and sylpheed with several Google mail accounts > > for years, and it seemed pretty straightforward - just set the "allow > > less secure apps" option, and then configure POP3 / SMTP normally. > > In the email that started this thread, I tried to make clear that this > is something happening "now". I use the internet for crossing oceans > quickly since bitnet and I remember whet google was born as > google."org". I am myself a long term gmail user and this is why I > carefully look after main changes. The way email clients will > authenticate to gmail is drfinitely one of them and is going to affect > us for sure. > > I may be able to be more responsive once I find a good way of avoiding > webmail. > Meanwhile, here is the best I could find toward a possible solution > that may help avoid the OAUTH2 authorization issue by complying with > it. > > You need debian buster as a minimum, then look at the gmailieer > package. It seems to be oauth2 enabled and therefore be able to access > gmail and possibly other mail providers. I still have to test it. If > you try it, be careful because it requires notmuch and notmuch is in > the less secure apps list, so you have to allow less secure apps > first, I guess, and hopefully be able to set it off/on as you like > again (if you can, this will probably get a feeling about the pain > ...). > > gmailieer is GPLv3+ and in debian. IMHO this these are two good > things. The debian package page: > https://packages.debian.org/search?keywords=gmailieer > > It seems that mbsync (isink) is on itw long way to become OAUTH2 > enableb, too, as possibly other applications. It is a matter of timen > and the free software community will catch up, as usual. > > I don't think the authentication issue is going to affect webmail > users for a while. Running using 2fa may be possible with non-browser apps if your security records indicate you ran with what google considers an untrusted app and google has it listed. You can generate an app-specific password for the non-browser app and will need to save it. Then you modify your non-browser app settings on local machine and key in that app-specific password in place of the other password you used earlier. This has been documented for mutt as being possible and may work for other non-browser apps too. You'll need to give google a mobile number for account recovery and the like too. > > Loredana > > --
Re: Configure apt-get to work through corp internet proxy
On Thu, Aug 15, 2019 at 08:03:49PM +, Wilkinson, Matthew wrote: > Hello Debian users, > > I'm experimenting with Debian in an enterprise environment. We have a corp. > Internet proxy which downloads and scans files prior to passing the files > onto the client. > > With Debian this seems to be a problem for APT. I am able to run 'apt-get > update' and that seems to work OK, however when I try to actually run > 'apt-get upgrade' on Debian 10 it tries for a few seconds to download a patch > for: 'linux-image-4.19.0-5-amd64', which is 47.6MB. It tries and gives up > fairly quickly. > ># apt-get upgrade >Reading package lists... Done >Building dependency tree >Reading state information... Done >Calculating upgrade... Done >The following packages will be upgraded: > linux-image-4.19.0-5-amd64 >1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. >Need to get 47.6 MB of archives. >After this operation, 3,072 B disk space will be freed. >Do you want to continue? [Y/n] y >Get:1 http://cdn-fastly.deb.debian.org/debian-security > buster/updates/main amd64 linux-image-4.19.0-5-amd64 amd64 4.19.37-5+deb10u2 > [47.6 MB] >Err:1 http://cdn-fastly.deb.debian.org/debian-security > buster/updates/main amd64 linux-image-4.19.0-5-amd64 amd64 4.19.37-5+deb10u2 > Undetermined Error [IP: x.x.x.x] > E: Failed to fetch > http://cdn-fastly.deb.debian.org/debian-security/pool/updates/main/l/linux-signed-amd64/linux-image-4.19.0-5-amd64_4.19.37-5+deb10u2_amd64.deb > Undetermined Error [IP: x.x.x.x] >E: Unable to fetch some archives, maybe run apt-get update or try with > --fix-missing? > Have you considered that the proxy blocks this package? Does your company approve of this and did you talk to the administrator? ? -- Henning Follmann | hfollm...@itcfollmann.com
Re: Debian latency test
Hi. On Fri, Aug 16, 2019 at 02:31:38PM +0200, danwe wrote: > is there any program to test the intern latency of Debian? So I just need > to know how much time the Linux Kernel needs to response to a request. latencytop comes to mind first. strace can be used for this, assuming that you know which syscall you want to check. bpftrace definitely can do it, but some learning is required. Reco
Re: SOLVED: Re: buster: DNS server?
On Thu, Aug 15, 2019 at 01:01:42PM -0600, D. R. Evans wrote: > Thanks to those who replied to my original post, > <45c61e48-0393-a413-4f7a-d88be911a...@gmail.com>; the responses gave me enough > clues to find the source of the problem. > > The solution turned out to be obvious in retrospect (like so many things). > > For some reason, the buster installation had not installed bind9. As soon as I And the reason was? I guess the user not requesting the installation :) > installed that package manually, DNS started to work correctly for the other > machines on the LAN. > > Thanks again. > > Doc > -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: Trackman Marble under wayland in Buster
On Wed, Aug 07, 2019 at 11:29:48AM -0400, Henning Follmann wrote: > Hello, > I just updated to buster and with that comes wayland. > I am using a Trackman marble and I do have a custom > configuration for it to switch to scoll when I hold > button 8 (called "EmulateWheel"). > Is there a way to do this under wayland? > > here is my previous marblemouse.conf for X: > > Section "InputClass" > Identifier "Marble Mouse" > MatchProduct "Logitech USB Trackball" > MatchIsPointer "on" > MatchDevicePath "/dev/input/event*" > Driver "evdev" > Option "Buttons""9" > Option "ButtonMapping" "1 9 3 4 5 6 7 2 8" > Option "EmulateWheel" "true" > Option "EmulateWheelButton" "8" > Option "Emulate3Buttons" "true" > EndSection > # Replying to myself: You can get scrolling capabilities through gsettings: $> gsettings set org.gnome.desktop.peripherals.trackball \ scroll-wheel-emulation-button 8 You only have to do this once for the current user. BUT sometimes it is "off". Sporadically it does not work. But this might have to do with this laptop. The power management and the usb somehow interfere with each other. It is a hardware problem. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote: > On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > > > On Thu, 2019-08-15 at 19:41 +0100, Brian wrote: > > > > The fact remains that dbus is not a DE only package. How did anyone > > > > get the idea it was? > > > > > > Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia > > > [1] > > > > > >D-Bus was developed as part of the freedesktop.org project [...] to > > >standardize services provided by Linux desktop environments such as > > >GNOME and KDE. > > > > > > It's seems quite reasonable to me for people to jump to the conclusion > > > that it's not likely relevant for servers. > > > > > > [1] https://en.wikipedia.org/wiki/D-Bus > > > > Jumping to conclusions is the ideal way of neglecting facts and promoting > > fallacious assertions. I have given two examples that challenge > > > > dbus "...is redundant for typical server software" > > The first one being "apt cache rdepends"? You can do better than this. > > The second one being CUPS? dbus is not required for printing itself. Also, most servers don't deal with ink-and-paper printing. At all. Brian asked how people would conclude things about D-Bus, and Tixy gave a completely legitimate answer. It was an answer I had been considering writing myself, but I was lazy. The name is *literally* an abbreviation for Desktop Bus, and you (Brian) claim you don't understand why people think it's only for desktop systems? Come on.
Re: Debian latency test
On Fri, Aug 16, 2019 at 02:31:38PM +0200, danwe wrote: >Hello, >is there any program to test the intern latency of Debian? So I just need >to know how much time the Linux Kernel needs to response to a request. >Kind regards >Daniel You don't mention what sorts of requests, but two utilities that you may find useful are iostat (in the sysstat package) and perf (in the linux-perf package). Regards, -Roberto -- Roberto C. Sánchez
Debian latency test
Hello, is there any program to test the intern latency of Debian? So I just need to know how much time the Linux Kernel needs to response to a request. Kind regards Daniel
Re: webmail and email from command line
First of all, I wish to thank all of you who shared their experience. Be reassured I am taking any constructive suggestion into serious account and exploring more. Then: On Fri, Aug 16, 2019 at 2:03 AM Celejar wrote: > > On Wed, 14 Aug 2019 16:24:49 +000 > loredana wrote: > > secure applications, this is likely not to be a viable solution (it > > seems that google is going to forbit less secure application access > > starting November first of this year and it is already a pain to use > > it now). > > What is your source for Google's plans, and how is it already a pain? I am following the google development on this issue, but I got the date from the mu4e mailing list. I'l post the link, if I can find it again (remember, I am almost blind and even replying to email is, at the moment, really slow and difficult). > have been using getmail and sylpheed with several Google mail accounts > for years, and it seemed pretty straightforward - just set the "allow > less secure apps" option, and then configure POP3 / SMTP normally. In the email that started this thread, I tried to make clear that this is something happening "now". I use the internet for crossing oceans quickly since bitnet and I remember whet google was born as google."org". I am myself a long term gmail user and this is why I carefully look after main changes. The way email clients will authenticate to gmail is drfinitely one of them and is going to affect us for sure. I may be able to be more responsive once I find a good way of avoiding webmail. Meanwhile, here is the best I could find toward a possible solution that may help avoid the OAUTH2 authorization issue by complying with it. You need debian buster as a minimum, then look at the gmailieer package. It seems to be oauth2 enabled and therefore be able to access gmail and possibly other mail providers. I still have to test it. If you try it, be careful because it requires notmuch and notmuch is in the less secure apps list, so you have to allow less secure apps first, I guess, and hopefully be able to set it off/on as you like again (if you can, this will probably get a feeling about the pain ...). gmailieer is GPLv3+ and in debian. IMHO this these are two good things. The debian package page: https://packages.debian.org/search?keywords=gmailieer It seems that mbsync (isink) is on itw long way to become OAUTH2 enableb, too, as possibly other applications. It is a matter of timen and the free software community will catch up, as usual. I don't think the authentication issue is going to affect webmail users for a while. Loredana
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 12:46:17PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 13:21:11 +0200, to...@tuxteam.de wrote: > > I'm getting old, so this piqued somewhat my vanity. I double-checked: [...] > It's a fair cop! :-) Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 13:21:11 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote: > > On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: > > [...] > > > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > > > doesn't require avahi-daemon? > > > > I don't think so; not in this thread anyway. > > I'm getting old, so this piqued somewhat my vanity. I double-checked: > > In Message-ID: <15082019194357.c7ba6d840...@desktop.copernicus.org.uk> > > [me] > >> CUPS depends on avahi depends somehow on dbus. Try some day lprng, > >> works a charm :-) > > [you] > >> I forgot: the cups package does not depend on avahi-daemon; it is a > >> Recommends:. avahi-daemon does depend on dbus. It's a fair cop! -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: [...] > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > > doesn't require avahi-daemon? > > I don't think so; not in this thread anyway. I'm getting old, so this piqued somewhat my vanity. I double-checked: In Message-ID: <15082019194357.c7ba6d840...@desktop.copernicus.org.uk> [me] >> CUPS depends on avahi depends somehow on dbus. Try some day lprng, >> works a charm :-) [you] >> I forgot: the cups package does not depend on avahi-daemon; it is a >> Recommends:. avahi-daemon does depend on dbus. Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote: > > On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > > > > > On my print server with buster: > > > > > > root@futro:~# apt purge dbus > > > Reading package lists... Done > > > Building dependency tree > > > Reading state information... Done > > > The following packages will be REMOVED: > > > dbus* libpam-systemd* > > > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > > > After this operation, 1,057 kB disk space will be freed. > > > > Don't get the idea I am using lprng. avahi-daemon is not on the list > > because I choose not to advertise the print queues on this server. > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > doesn't require avahi-daemon? I don't think so; not in this thread anyway. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote: > On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > > > On my print server with buster: > > > > root@futro:~# apt purge dbus > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > The following packages will be REMOVED: > > dbus* libpam-systemd* > > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > > After this operation, 1,057 kB disk space will be freed. > > Don't get the idea I am using lprng. avahi-daemon is not on the list > because I choose not to advertise the print queues on this server. No, I didn't get that idea -- wasn't it you who reminded us that CUPS doesn't require avahi-daemon? Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:48:30AM +0100, Brian wrote: > On Fri 16 Aug 2019 at 12:24:14 +0200, to...@tuxteam.de wrote: > > > On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: > > > > [...] > > > > > https://www.freedesktop.org/wiki/Software/dbus/ > > ^^^ > > > > ;-) > > DE - Desktop *Environment*. A case of selective censorship? :) Censorship? I didn't get that pun (promised! :) [...] Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > On my print server with buster: > > root@futro:~# apt purge dbus > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages will be REMOVED: > dbus* libpam-systemd* > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > After this operation, 1,057 kB disk space will be freed. Don't get the idea I am using lprng. avahi-daemon is not on the list because I choose not to advertise the print queues on this server. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 12:24:14 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: > > [...] > > > https://www.freedesktop.org/wiki/Software/dbus/ > ^^^ > > ;-) DE - Desktop *Environment*. A case of selective censorship? :) > [...] > > > As Reco said: > > > > > If you don't need it - just uninstall it. > > > > What do you get for 'apt purge dbus'? > > Not the OP, but here's mine: > > tomas@trotzki:~$ sudo apt purge dbus > [sudo] password for tomas: > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package 'dbus' is not installed, so not removed > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. On my print server with buster: root@futro:~# apt purge dbus Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: dbus* libpam-systemd* 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. After this operation, 1,057 kB disk space will be freed. Mmm. I think Reco has led me to a state of enlightenment! -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: [...] > https://www.freedesktop.org/wiki/Software/dbus/ ^^^ ;-) [...] > As Reco said: > > > If you don't need it - just uninstall it. > > What do you get for 'apt purge dbus'? Not the OP, but here's mine: tomas@trotzki:~$ sudo apt purge dbus [sudo] password for tomas: Reading package lists... Done Building dependency tree Reading state information... Done Package 'dbus' is not installed, so not removed 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. And this is: tomas@trotzki:~$ uname -a Linux trotzki 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux tomas@trotzki:~$ cat /etc/debian_version 9.9 so it's Stretch, aka oldstable. And oh, of course with an X GUI. Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:06:43AM +0200, john doe wrote: [...] > Okay, as far as I understand it, depends means that it will be pulled as > an dependency but not that it is required for it to work properly. > What I'm starting to realise is that to much dependencies are pulled to > implement lots of feature that is not always necessery. That very much depends on the application: some (mis?) use dbus as a dynamic linking facility which could be as well served by shared objects. Kind of a Rube Goldberg way of doing dynamic linking -- but that's my opinion, you'll find others. Bluez is one example. Since it is the only bluetooth framework available under Linux, that means: no dbus -> no bluetooth. Others just complain that there's no dbus and carry on (X is one example. This from my Xorg.0.log (line wrap by me): [ 354.912] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) > Before posting to the list, a google search let me think that dbus is > only required when DE is wanted. > Do you have online documentation that would explain why dbus is required > when no DE is used? It is a desktop invention (it was introduced by Havoc Pennington, after much frustration trying to adopt Corba for the Gnome Desktop: compared to that, DBus was, indeed, progress. KDE had a similar frustration with its own distributed object monster -- uh -- model and followed suit). But since then it has expanded to non-desktop things. I've got quite a few beefs with DBus, which I won't expand here, but that's why I try to find out how far I can go without it. Turns out, for my use case, pretty far. Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote: > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > > On Thu 15 Aug 2019 at 21:05:10 +0200, to...@tuxteam.de wrote: > > > > > On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote: > > > > > > > I wouldn't try to dissuade anyone from using last century's > > > > technology > > > > if they have their heart set on it [...] > > > > > > C'mon. You /know/ you're talking nonsense. Old is old, and new is > > > new. > > > Beyond that... > > > > > > BTW I still use TeX, so... 1980s. Works a charm, too. > > > > The technology I am referring to (as I think you very well know) is > > the printing system. No more, no less. > > Which is last century by itself. > > > > Nowadays that system often relies on printer/print queue Bonjour > > broadcasts. > > And that is called "jumping to conclusions". > Printing itself haven't changed a bit for last 15 years - a print server > takes user's PS or PDF, mangles it to fit printer's representation (be > it PCL or something else), and feeds it to the printer. By utilizing > unicasts of course. > A user can discover a print server via mDNS multicasts (*not* > broadcasts). Or a user can be told a location of such print server. > > avahi is useful for discovery of CUPS, and that's about it. Printer discovery is an important aspect of a modern printing system. If a user or institution can get by without it, fine. If not, dbus is required. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 11:06:43 +0200, john doe wrote: > On 8/15/2019 6:52 PM, Brian wrote: > > On Wed 14 Aug 2019 at 07:36:21 +0200, john doe wrote: > > > >> Hi Rico, and thanks for your answer. > >> > >> On 8/13/2019 9:25 PM, Reco wrote: > >>> On Tue, Aug 13, 2019 at 08:07:49PM +0200, john doe wrote: > I have no plan to reboot that server, what are the pros and cons of not > doing that > >>> > >>> Pro: keeping uptime > >>> Con: keeping previous, possibly buggy, version for dbus running. > >>> > or how can I avoid rebooting altogether? > >>> > >>> dbus is not mandatory and is redundant for typical server software. > >>> If you don't need it - just uninstall it. Simple as that. > >>> > >> > >> okay, dbus is only required when a DE (Gnome,Mate, ...) is present. > >> If I'm correct, and given the fact that I don't use a DE, I could look > >> at safely remove it? > > > > You are not correct. 'apt rdepends dbus' is worth looking at. > >> > > Okay, as far as I understand it, depends means that it will be pulled as > an dependency but not that it is required for it to work properly. > What I'm starting to realise is that to much dependencies are pulled to > implement lots of feature that is not always necessery. > > > Before posting to the list, a google search let me think that dbus is > only required when DE is wanted. > Do you have online documentation that would explain why dbus is required > when no DE is used? As https://www.freedesktop.org/wiki/Software/dbus/ says: > D-Bus is a message bus system, a simple way for applications to > talk to one another. There is no mention of DEs on that page. dbus is for any application to talk to any other application. > P.S. > > The Debian bugreport provided in this thread seems to corroborate your > pointbut I can't find something tangible to back that up. As Reco said: > If you don't need it - just uninstall it. What do you get for 'apt purge dbus'? -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On 8/15/2019 6:52 PM, Brian wrote: > On Wed 14 Aug 2019 at 07:36:21 +0200, john doe wrote: > >> Hi Rico, and thanks for your answer. >> >> On 8/13/2019 9:25 PM, Reco wrote: >>> On Tue, Aug 13, 2019 at 08:07:49PM +0200, john doe wrote: I have no plan to reboot that server, what are the pros and cons of not doing that >>> >>> Pro: keeping uptime >>> Con: keeping previous, possibly buggy, version for dbus running. >>> or how can I avoid rebooting altogether? >>> >>> dbus is not mandatory and is redundant for typical server software. >>> If you don't need it - just uninstall it. Simple as that. >>> >> >> okay, dbus is only required when a DE (Gnome,Mate, ...) is present. >> If I'm correct, and given the fact that I don't use a DE, I could look >> at safely remove it? > > You are not correct. 'apt rdepends dbus' is worth looking at. >> Okay, as far as I understand it, depends means that it will be pulled as an dependency but not that it is required for it to work properly. What I'm starting to realise is that to much dependencies are pulled to implement lots of feature that is not always necessery. Before posting to the list, a google search let me think that dbus is only required when DE is wanted. Do you have online documentation that would explain why dbus is required when no DE is used? P.S. The Debian bugreport provided in this thread seems to corroborate your pointbut I can't find something tangible to back that up. -- John Doe
Re: webmail and email from command line
On Thu, Aug 15, 2019 at 10:02:57PM -0400, Celejar wrote: > On Wed, 14 Aug 2019 16:24:49 + > loredana wrote: > > ... > > > secure applications, this is likely not to be a viable solution (it > > seems that google is going to forbit less secure application access > > starting November first of this year and it is already a pain to use > > it now). > > What is your source for Google's plans, and how is it already a pain? I > have been using getmail and sylpheed with several Google mail accounts > for years, and it seemed pretty straightforward - just set the "allow > less secure apps" option, and then configure POP3 / SMTP normally. Google's evil comes through the backdoor, without making any noise, like Wormtongue. Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > On Thu, 2019-08-15 at 19:41 +0100, Brian wrote: > > > The fact remains that dbus is not a DE only package. How did anyone > > > get the idea it was? > > > > Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia > > [1] > > > >D-Bus was developed as part of the freedesktop.org project [...] to > >standardize services provided by Linux desktop environments such as > >GNOME and KDE. > > > > It's seems quite reasonable to me for people to jump to the conclusion > > that it's not likely relevant for servers. > > > > [1] https://en.wikipedia.org/wiki/D-Bus > > Jumping to conclusions is the ideal way of neglecting facts and promoting > fallacious assertions. I have given two examples that challenge > > dbus "...is redundant for typical server software" The first one being "apt cache rdepends"? You can do better than this. The second one being CUPS? dbus is not required for printing itself. Reco
Re: dbus-deamon avoiding reboot after upgrade
On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > On Thu 15 Aug 2019 at 21:05:10 +0200, to...@tuxteam.de wrote: > > > On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote: > > > > > I wouldn't try to dissuade anyone from using last century's > > > technology > > > if they have their heart set on it [...] > > > > C'mon. You /know/ you're talking nonsense. Old is old, and new is > > new. > > Beyond that... > > > > BTW I still use TeX, so... 1980s. Works a charm, too. > > The technology I am referring to (as I think you very well know) is > the printing system. No more, no less. Which is last century by itself. > Nowadays that system often relies on printer/print queue Bonjour > broadcasts. And that is called "jumping to conclusions". Printing itself haven't changed a bit for last 15 years - a print server takes user's PS or PDF, mangles it to fit printer's representation (be it PCL or something else), and feeds it to the printer. By utilizing unicasts of course. A user can discover a print server via mDNS multicasts (*not* broadcasts). Or a user can be told a location of such print server. avahi is useful for discovery of CUPS, and that's about it. > dbus "...is redundant for typical server software" appears to deserve > some explanation. > > > Use what works for you, whether old or new doesn't matter > > "old" doesn't work for modern printing systems. Of course it does. Reco
