Re: Where to report print driver bug

[Marco Moock]

Am Fri, 23 Feb 2024 14:47:41 -0500
schrieb James Klaas :

> "Generic PCL 6/PCL XL Printer Foomatic/pxlcolor (recommended)"

Do you know the file that provides that?
If so, you apt-file search "file" to find the package that provides it.

Re: Journald's qualities

[Stefan Monnier]

 but what are the advantages of journald's representation compared
 to a naive one?
>>> 
>>> in short: querability without text parsing. That's about it.
>> 
>> They have to parse the binary format, so that's not in and of itself
>> an upside compared to parsing CSV.
>> 
>> I've made my share of bad design decisions that don't pan out. But
>> there's always an upside to my decision (even when it turns out it 
>> speeds up only those cases which can never occur, because of some
>> other aspect of the system).
>> 
>> AFAICT the format is *not* just a plain sequence of log entries, so 
>> there's some additional structure which is intended to speed up some
>> operations.
>> 
>> IOW, even if contrived, there should be *some* use case where it
>> does better than CSV, no?
>
> I can think of two possibilities, just offhand, in no particular order:
>
> * No need to parse the timestamps, et cetera, and take the risk that
> someone put in one that's in a format you don't expect; the times are
> stored internally in a consistent guaranteed format, so you can just use
> internal reader functions (paired with, and updated alongside, the
> internal writer functions) and be done with it.

Can't think of any reason why the same wouldn't apply to CSV: if someone
messes up the timestamps by hand, they're on their own.

> * No need to worry about handling log entries that *contain* commas, or
> whatever other element was chosen as the separator.

That's just a very minor convenience issue and it does not require
a structure any more complex than a plain sequence of log entries.

Same for FSS, it doesn't seem to require the more complex structure used
by journald.  There must have been some other use-case they had in mind
where they thought they could avoid the linear-time scan or something in
a way that they expected would be algorithmically beneficial.
I just can't see what it is they had in mind.


Stefan

Re: Journald's qualities

[Jeffrey Walton]

On Fri, Feb 23, 2024 at 10:17 PM The Wanderer  wrote:
>
> On 2024-02-23 at 15:35, Stefan Monnier wrote:
>
> >>> but what are the advantages of journald's representation compared
> >>> to a naive one?
> >>
> >> in short: querability without text parsing. That's about it.
> >
> > They have to parse the binary format, so that's not in and of itself
> > an upside compared to parsing CSV.
> >
> > I've made my share of bad design decisions that don't pan out. But
> > there's always an upside to my decision (even when it turns out it
> > speeds up only those cases which can never occur, because of some
> > other aspect of the system).
> >
> > AFAICT the format is *not* just a plain sequence of log entries, so
> > there's some additional structure which is intended to speed up some
> > operations.
> >
> > IOW, even if contrived, there should be *some* use case where it
> > does better than CSV, no?
>
> I can think of two possibilities, just offhand, in no particular order:
>
> * No need to parse the timestamps, et cetera, and take the risk that
> someone put in one that's in a format you don't expect; the times are
> stored internally in a consistent guaranteed format, so you can just use
> internal reader functions (paired with, and updated alongside, the
> internal writer functions) and be done with it.
>
> * No need to worry about handling log entries that *contain* commas, or
> whatever other element was chosen as the separator.

Systemd also provides tamper-resistant logs. The property is often
desirable in the enterprise. See Forward Secure Sealing,
.

Jeff

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hi,

On Sat, Feb 24, 2024 at 01:35:14PM +1100, Zenaan Harkness wrote:
> I wrote:
> > You seem by now to have ignored multiple messages where it was made
> > clear that the work was already done.
> 
> Assuming we care about the most rapid healing possible for those who
> are actually triggered by certain words in one or another language,
> there is a valid position to consider that is to increase, not
> decrease, exposure to and therefore the broader usage of, triggering
> words.
> 
> If we care about healing wounds, we ought not remove the catalysts to
> that healing.

I did wonder how long it would take for someone to go from, "it's
terrible that you activists are MAKING someone do this POINTLESS
non-technical work!" to "no one should use this thing someone did in
their own free time because it's bad, actually, for non-technical
reasons!"

Meanwhile I'd just appreciate hearing from actual users of it, since
I might be one, one day.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Zenaan Harkness]

>> Yeah like asking other people to do changes because they want to be
>> activists on internet but can't bother to put effort to do anything
>> that actually helps anyone.
>
> You seem by now to have ignored multiple messages where it was made
> clear that the work was already done.

Assuming we care about the most rapid healing possible for those who
are actually triggered by certain words in one or another language,
there is a valid position to consider that is to increase, not
decrease, exposure to and therefore the broader usage of, triggering
words.

If we care about healing wounds, we ought not remove the catalysts to
that healing.

Salt water stings, but helps clean the wound.

We fail in our duty of care to one another, when we reduce or
eliminate catalysts to healing.

Re: Journald's qualities

[The Wanderer]

On 2024-02-23 at 15:35, Stefan Monnier wrote:

>>> but what are the advantages of journald's representation compared
>>> to a naive one?
>> 
>> in short: querability without text parsing. That's about it.
> 
> They have to parse the binary format, so that's not in and of itself
> an upside compared to parsing CSV.
> 
> I've made my share of bad design decisions that don't pan out. But
> there's always an upside to my decision (even when it turns out it 
> speeds up only those cases which can never occur, because of some
> other aspect of the system).
> 
> AFAICT the format is *not* just a plain sequence of log entries, so 
> there's some additional structure which is intended to speed up some
> operations.
> 
> IOW, even if contrived, there should be *some* use case where it
> does better than CSV, no?

I can think of two possibilities, just offhand, in no particular order:

* No need to parse the timestamps, et cetera, and take the risk that
someone put in one that's in a format you don't expect; the times are
stored internally in a consistent guaranteed format, so you can just use
internal reader functions (paired with, and updated alongside, the
internal writer functions) and be done with it.

* No need to worry about handling log entries that *contain* commas, or
whatever other element was chosen as the separator.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Charles Curley]

On Fri, 23 Feb 2024 21:10:31 +0100
Ralph Aichinger  wrote:

> I just think this mailing 
> list probably is not the right place to argue this question. 

Hear, hear!

Those who wish to weigh in have done so. I doubt any further
argumentation will change anyone else's mind. Now kindly stop wasting
your time, my time, bandwidth, and hard drive space on this.

And grow some tolerance for other people's foibles, and perhaps others
will grow some tolerance for your foibles.

Thank you.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hi,

On Fri, Feb 23, 2024 at 09:26:09PM +0100, Ralph Aichinger wrote:
> in my /etc/interfaces there is now:
> 
> auto bond0
> iface bond0 inet static
> address 10.0.16.2/24
> bond-slaves en0 en1
> bond-mode 4
> bond-miimon 100
> bond-downdelay 200
> bond-updelay 200
> bond-lacp-rate 1
> bond-xmit-hash-policy layer3+4
> 
> which seems to work (I could not test throughput yet, because
> I am waiting for cables).
> 
> If I do this, does "ifupdown" use "ifenslave" or does it
> use "ip link set" as described here:

Last time I looked was in Debian 10 (buster) and there it does still
call ifenslave. ifupdown won't be able to bring up bond0 if
ifenslave isn't present on the system. You can verify it with "ifup
-v bond0" to see what commands it uses (assuming your networking was
down to start with, so that this would work).

> Also, above still(?) contains "bond-slaves en0 en1" so if this is
> a new implementation, is there still some terminology change to be
> expected? Or can I replace bond-slaves with something else in the
> current Debian bookworm?

What you describe is still the bonding driver, just without the use
of the "ifenslave" command. The very first reply to you in this
thread was from me pointing you at the teaming driver.

…which I have never used nor yet tried to use. But it *is* meant to
replace/succeed the bonding driver.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Journald's qualities (was: Selective rotation of journald logs)

[Nicholas Geovanis]

On Fri, Feb 23, 2024, 2:57 PM Dan Ritter  wrote:

> Stefan Monnier wrote:
> > Makes one wonder why they don't use naive append-only "plain text" logs
> > (tho with appropriate delimiters (maybe some kind of CSV) to make
> > searches more reliable than with old-style plain text logs)?
> >
> > What are the advantages of journald's representation?
> > I mean, to justify the slow search and large disk space usage, there is
> > presumably some upside for some use cases.  I can see some weak argument
> > against Sqlite based on the size of Sqlite, but what are the advantages
> > of journald's representation compared to a naive one?
>
>
> systemd's design philosophy, observed from the outside, goes
> like this:
>

bunch trimmed.

Exactly correct in my view. Systemd's use-case is the desktop, not the
server in the datacenter. They will be using log-aggregation software in
the datacenter anyway so no use for systemd logging. We don't install
desktop software on servers either, no X Windows, no gnome, etc. Network
connections are stable, no roaming :-)

Long-term logs are for servers, so systemd doesn't want them.
> systemd thinks logs are for finding out what just happened
> recently. If you wanted long-term logs, obviously you would
> configure a central repository on some other machine and ship
> them across the network.
>
>
> I have nothing but praise for the Debian maintainers of rsyslog,
> who have arranged it so that installing rsyslog immediately does
> appropriate things to pull data out of systemd.
>
> -dsr-
>
>

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Ralph Aichinger]

On Fri, 2024-02-23 at 20:10 +, Andy Smith wrote:
> One more time: a successor to the Ethernet bonding driver already
> exists and has for more than 10 years.

That is the other thing I wanted to ask here, I have configured a
LACP link aggregating interface more or less similar to what is
described in the wiki, in my /etc/interfaces there is now:

auto bond0
iface bond0 inet static
address 10.0.16.2/24
bond-slaves en0 en1
bond-mode 4
bond-miimon 100
bond-downdelay 200
bond-updelay 200
bond-lacp-rate 1
bond-xmit-hash-policy layer3+4

which seems to work (I could not test throughput yet, because
I am waiting for cables).

If I do this, does "ifupdown" use "ifenslave" or does it
use "ip link set" as described here:

https://www.uni-koeln.de/~pbogusze/posts/LACP_configuration_using_iproute2.html

behind the scenes? Is the wiki/documentation lagging the actual
implementation? Is there a way to find out (other than removing
ifenslave and seeing if it still works)?

Should documentation in the wiki be updated?

Also, above still(?) contains "bond-slaves en0 en1" so if this is
a new implementation, is there still some terminology change to be
expected? Or can I replace bond-slaves with something else in the
current Debian bookworm?

/ralph

Re: Journald's qualities

[Stefan Monnier]

> systemd's design philosophy, observed from the outside, goes
> like this:

Let's try and stick to the subject of the log representation in
`journald`, because we all know about the varied opinions about SystemD.

Being an "old-hand", I'm not in love of SystemD, but the thing does have
its upsides.  In the case of the format of `journald` logs, I don't
see them.


Stefan

Re: compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40

[Étienne Mollier]

Bonjour Basile,

Mon avis à deux sous d'internaute vaut ce qu'il vaut, et je ne
suis pas à l'abri de me prendre les pieds dans le tapis, donc
n'hésitez pas à prendre d'autres avis par ailleurs avant
d'engager des frais.  En particulier, je décline toute
responsabilité s'il devait y avoir un ou des pépins après achat.
;)

Basile Starynkevitch, on 2024-02-22:
> Est ce ia carte mère et le processeur susdits sont compatible Debian
> Testing? En particulier pour faire tourner un serveur Xorg et Gimp. Je
> m'interroge sur la compatibilité de la carte mère avec le coprocesseur
> graphique du AMD Ryzen  7 8700G.

Je ne vois pas d'objections : les nouvelles moutures de
l'installateur Debian devraient automatiquement ajouter les
microprogrammes nécessaires au bon fonctionnement du processeur
et de sa puce graphique embarquée.  Évidemment, le diable se
cache dans les détails, et on n'est pas à l'abri que certains
composants se trouvent être retors : cartes réseau, puces WiFi,
ce genre de choses.

En fait, ce pourrait être intéressant à la fin de l'installation
de la machine de rédiger un rapport via le système de suivi de
bogues, pour indiquer à l'équipe en charge de l'installateur ce
qui s'est bien passé et ce qui s'est moins bien passé :

$ reportbug installation-reports

Pour le moment, aucun des rapports d'installation[1] ne semblent
concerner les cartes mères à chipset B650, ce qui suggère que :
soit elles n'ont pas de problèmes, soit personne ne s'en sert.

[1] : https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports

> (l'usage principal étant le traitement d'images numériques, notamment avec
> Gimp et Inkscape; accessoirement la compilation par GCC)
> 
> Pour ceux qui connaissent materiel.net les composants qu'on souhaite
> assembler sont listés en https://materiel.net/s/5CKV6K et vos critiques
> constructives sont bienvenues (pour un usage professionnel pour un
> photographe professionnel)

Pour éviter de perdre du temps sur de la casse, surtout pour un
usage professionnel où le temps est littéralement de l'argent,
est-ce que ça ne vaudrait pas le coup de rajouter un disque pour
constituer une colonne Raid 1, et ainsi éviter de perdre une
journée de travail à jongler avec des sauvegardes lors de la
panne du disque ?  Attention, le Raid 1 ne remplace pas la mise
en place d'une stratégie de sauvegarde.

Autrement, compter uniquement sur une puce graphique embarquée
peut paraître un peu léger pour un usage professionnel, mais la
configuration a l'air suffisamment solide pour rajouter une
carte graphique dédiée après coup, si la puce intégrée devait
être insuffisante.

Bonne journée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: Journald's qualities

[Stefan Monnier]

>> Oh, that bug report is quite interesting, thanks.
>> Makes one wonder why they don't use naive append-only "plain text"
>> logs (tho with appropriate delimiters (maybe some kind of CSV) to make
>> searches more reliable than with old-style plain text logs)?
>> 
>> What are the advantages of journald's representation?
>> I mean, to justify the slow search and large disk space usage, there
>> is presumably some upside for some use cases.  
>
> The advantage of binary format is that you have separate fields for
> program, level etc and it is easier to filter by exactly what you want. 
> So "systemctl status servicename" just asks log subsystem for exactly
> what it needs.

That's why I said "with appropriate delimiters (maybe some kind of
CSV)".  Really plain text is what we had before, but it's not rocket
science to have a "plain text" format with a reliably delimited set
of fields, which is what I'd assume as the obvious naive choice.

>> argument against Sqlite based on the size of Sqlite, 
> I'd argue that's not really technically relevant

I did say "weak" 

>> but what are the advantages of journald's representation compared to
>> a naive one?
> in short: querability without text parsing. That's about it.

They have to parse the binary format, so that's not in and of itself an
upside compared to parsing CSV.

I've made my share of bad design decisions that don't pan out.
But there's always an upside to my decision (even when it turns out it
speeds up only those cases which can never occur, because of some other
aspect of the system).

AFAICT the format is *not* just a plain sequence of log entries, so
there's some additional structure which is intended to speed up
some operations.

IOW, even if contrived, there should be *some* use case where it does
better than CSV, no?

> It does have some features around FSS (signing logs) so for folks that
> need it there isn't many alternatives as it would be hard to make
> similar feature on database.

That should be just as easy to add to a CSV-style representation, tho.

> But on flipside inability to separate log into log rotation groups is
> *nasty*. You basically can't have verbose service in the system as that
> will rotate away any old logs of other services away. And looking for
> those logs is also the worst case:

It shouldn't be difficult to add a filtering step to the log rotation
(just extract all the log entries, filter out the unwanted ones, and
create a new log file with the result).
Beside the obvious usual issues of atomicity, the only real problem
I can imagine there is FSS for which you'd need to seal separately the
groups that share differently filtering rules.

> I guess another one being appendable log is that in case of crash it's
> easier to recover than embedded database...

AFAICT, CSV shares this property just as well.

> One-service-per-file approach is honestly good enough for most stuff.
> PITA to get chronological order though, every approach really have
> some drawbacks and benefits.

If you use a reasonable format with precise enough timestamps, you
should be able to "weave" entries from separate files back into
a coherent single chronology (assuming all those entries got their
timestamps from the same journald in the first place).


Stefan

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Ralph Aichinger]

On Fri, 2024-02-23 at 18:13 +0100, Mariusz Gronczewski wrote:
> "Do what I say, discussion is not allowed because I don't want to
> make a sensible arguments!" 


This certainly is not my position. I have no problem arguing this 
question, and I've got an opinion on it. I just think this mailing 
list probably is not the right place to argue this question. 

> "Damn those people using reason and questioning what I want, just do
> what I say!"
> 
For me it is more: "I know it is controversial, but I do not want to
flood the list with the controversial part, that contains lots of 
personal opinions, political positioning, subjective aspects, but want
to ask about the non-controversial, factual, part, that contains no
political aspects and can be answered without opinion, purely with
facts.

I just want to know the current situation, I don't want to convince
anybody here.


/ralph

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Ralph Aichinger]

On Fri, 2024-02-23 at 11:07 +0100, Marco Moock wrote:
> 
> Debian is mostly a collection of many packages that are packed in the
> repo.Such changes are normally done upstream.

I found e.g. this on upstream work on that topic:

https://lore.kernel.org/netdev/e515b840-c6f1-bc07-9369-c95e35257...@solarflare.com/T/

but I must confess I have not dug into upstream kernel sources to find
out if this has been accepted in the kernel, and if so from what
version.

> 
> I don't think that spending time on that is a valuable thing, there
> are more important tasks like testing or adding functionality.



I really don't want to argue any political arguments on the merits of 
removing master/slave, blacklist/whitelist, black hat/white hat here,
but I think "it is some effort" or "it concerns only few people" is not
the strongest argument. *If* one considers it the right thing to do,
then some minor effort in comparable with other minor changes is not
out of line. 

/ralph

Where to report print driver bug

[James Klaas]

I was going to submit a bug for this but I don't know what package I 
should report the bug against.


Debian bugreport says:
Please enter the name of the package in which you have found a problem, 
or type 'other' to report a more general problem. If you don't know what 
package the bug is in, please contact debian-user@lists.debian.org for 
assistance.


I have a Dell 2130cn, which is a PCL6 compatible printer. CUPS/Print 
manager says


"Generic PCL 6/PCL XL Printer Foomatic/pxlcolor (recommended)"

is the recommended driver and the only PCL6 driver that actually prints 
in color as far as I can tell. However, sometime in the past year or two 
(maybe between Bullseye and Bookworm), this driver no longer allows me 
to print in duplex.


I was able to print in duplex from Windows, so I decided to try a 
different driver. I tried both


"Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.3.4"

and

"Generic PCL 6/PCL XL Printer Foomatic/hpijs-pcl5c"

They both print in duplex, but do not print in color.

I would like to submit a bug report, but I do not know if I should only 
submit one for printer-driver-pxljr, which I think provides pxlcolor or 
something more generic.

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hello,

On Fri, Feb 23, 2024 at 06:14:02PM +0100, Mariusz Gronczewski wrote:
> Dnia 2024-02-23, o godz. 14:50:12
> fxkl4...@protonmail.com napisał(a):
> > too many people have nothing constuctive to do
> > so they spend there days stirring the pile
> > idle hands and all that
> 
> Yeah like asking other people to do changes because they want to be
> activists on internet but can't bother to put effort to do anything
> that actually helps anyone.

You seem by now to have ignored multiple messages where it was made
clear that the work was already done.

One more time: a successor to the Ethernet bonding driver already
exists and has for more than 10 years. In a time before some people
decided to get very worked up about inclusive language, it just
happens to avoid the terminology we're talking about.

Again, all I see are people getting very upset, accusing others of
being "woke" and "activists", but somehow they are the ones making
all the noise.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Kamil Jońca]

Dan Ritter  writes:

> Jeffrey Walton wrote: 
>> 
>> I don't want to bikeshed, though. Slavery ended in the US about 150
>> years ago. I don't know any slaves, and I don't own any slaves, so I
>> don't really have a dog in the fight.
>
>
> Point of fact: slavery is legal in the USA, as a legal punishment.
>
> Other point of fact: the effects of slavery in the USA continue
> to be felt in the present.
>
> At this point we have diverged completely from Debian topics.
>
> Let's bring it back around to actual action.
>
> The possible positions:
>
> 1. The terminology is bad, and I'm willing to work on fixing it.
>
> 2. The terminology is bad, but I can't work on it myself.
>
> 3. The terminology does not bother me, but I don't care if someone else wants 
> to fix it.
>
> 4. The terminology is good and we should not fix it.
>

x. I understand that terminology might be bad, but OTOH we have cost of
modyfying soft.
So I understand that for new piece of code we want to use new terminology
(some time ago github changes branch naming from "master" to "main" for
new projec, IIRC) but for old code we keep old until we have good
reasons to rewrite/refactor it.

KJ

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Jeffrey Walton]

On Fri, Feb 23, 2024 at 1:13 PM Gremlin  wrote:
>
> On 2/23/24 12:51, Dan Ritter wrote:
> > Jeffrey Walton wrote:
>
> [ >/dev/null ]
>
> >
> > Let's bring it back around to actual action.
> >
> > The possible positions:
> >
> > 1. The terminology is bad, and I'm willing to work on fixing it.
> >
> > 2. The terminology is bad, but I can't work on it myself.
> >
> > 3. The terminology does not bother me, but I don't care if someone else 
> > wants to fix it.
> >
> > 4. The terminology is good and we should not fix it.
> >
> > People taking positions one through three are people that I can
> > work with.
>
> 5. The terminology is good and we should fix it.

If you wish to see how this is going to play out, then visit
. That's the Ben Noordhuis
and Node.js pronoun scandal from 2014.

Jeff

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Jeffrey Walton]

On Thu, Feb 22, 2024 at 5:36 AM Ralph Aichinger  wrote:
>
> I know this is a loaded topic. I really don't want to discuss the
> political aspects of the "why", but just want to know the facts, i.e.
> how far this has been progressed in Debian.
>
> Is there anything planned to get "master/slave" terminology out of
> network bonding/LACP in Debian (or Linux kernel or whoever decides
> this terminology)? I know these things are slow to change, just
> wondering.
>
> https://wiki.debian.org/Bonding

This might be a question that is more appropriate for Debian's
Technical Committee, .

Jeff

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Marco Moock]

Am 23.02.2024 um 12:51:59 Uhr schrieb Dan Ritter:

> 1. The terminology is bad, and I'm willing to work on fixing it.
> 
> 2. The terminology is bad, but I can't work on it myself.
> 
> 3. The terminology does not bother me, but I don't care if someone
> else wants to fix it.
> 
> 4. The terminology is good and we should not fix it.

5. The terminology is completely different, because machines are
involved and not people.
Many languages have words that are used in many ways for completely
different things.

Just check what different meanings GIMP has.
Maybe some more people now feel uncomfortable with using it.
https://www.dict.cc/?s=gimp


-- 
Gruß
Marco

Spam und Werbung bitte an ichschickerekl...@cartoonies.org

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[tomas]

On Fri, Feb 23, 2024 at 11:24:39AM +0100, Marco Moock wrote:
> Am 23.02.2024 schrieb Alain D D Williams :
> 
> > It is "fixing" an issue for today's English speakers. Should we scour
> > our systems looking for similar issues in other languages ?

[...]

Fifty years ago it was "normal" to beat kids with a ruler
(I know from experience). Should we stop doing this now?

I'd say yes, but perhaps that's just me.

> > say, 20 years time when different words will then be considered
> > offensive, by some, do this all again ?
> 
> In Germany, some organizations do that as well - and most people are
> annoyed by that because it has no benefit.

While I do agree that reality is complex, and that it not always makes
sense, dismissing it right away because it doesn't matter to *you*
is also wrong.

> The most important thing is that the upstream projects would need to
> change that - including all the translators.
> 
> This is always a PITA - for no realistic benefit.

No benefit to *you* perhaps. See, I'm watching this space (free
software and friends) for quite a while now. I've watched it
since before the birth of Linux. Since then, the diversity of
people involved has increased quite a bit (it could be better,
mind you). So the array of things which matter has widened.

It isn't unplausible that the terminology "slave" is offensive
to someone outside your (or my) bubble. So it does make sense
to listen to others than just going by one's "gut feeling".

Here's [1] one ref on that. So yes, it might matter to some.

And to all those "I only take technical decisions". Folks:
tech is as much about physics and chemistry as it is about
anatomy and social science; after all, it is made by humans
for humans. And as to what happens when you have a strong
selection bias in technical design, [2] seems to be the
standard ref those days.

I just don't get it. If people isn't interested in the topic,
fine. Debian is huge, and no one can be interested in every
topic. Just keep out. But this kind of strong reactions...

 - "there is no good reason *why*"
 - "US political feel-good activism" [3]
 - "wastes people's time"

... as seen in this thread, to a simple question? Nah.

And now, I'm out of that thread myself (oh, another package:
git's default branch name "master" has become "main" these
days. No kittens were sacrified for that).

Cheers

[1] https://www.apa.org/ed/precollege/psn/2022/09/inclusive-language
[2] Carolina Criado Pérez "Invisible Women"
Exposing data bias in a world designed for men
Penguin Random House, 2019
[3] The OP was asking from Austria, and given their name, is
   Austrian, but hey, there you go. Perhaps there was some
   contagion via Schwarzenegger -- I hear he is (*horrors*)
   in California.

-- 
tomás


signature.asc
Description: PGP signature

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Gremlin]

On 2/23/24 12:51, Dan Ritter wrote:

Jeffrey Walton wrote:


[ >/dev/null ]



Let's bring it back around to actual action.

The possible positions:

1. The terminology is bad, and I'm willing to work on fixing it.

2. The terminology is bad, but I can't work on it myself.

3. The terminology does not bother me, but I don't care if someone else wants 
to fix it.

4. The terminology is good and we should not fix it.


People taking positions one through three are people that I can
work with.

-dsr-




5. The terminology is good and we should fix it.

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Dan Ritter]

Jeffrey Walton wrote: 
> 
> I don't want to bikeshed, though. Slavery ended in the US about 150
> years ago. I don't know any slaves, and I don't own any slaves, so I
> don't really have a dog in the fight.


Point of fact: slavery is legal in the USA, as a legal punishment.

Other point of fact: the effects of slavery in the USA continue
to be felt in the present.

At this point we have diverged completely from Debian topics.

Let's bring it back around to actual action.

The possible positions:

1. The terminology is bad, and I'm willing to work on fixing it.

2. The terminology is bad, but I can't work on it myself.

3. The terminology does not bother me, but I don't care if someone else wants 
to fix it.

4. The terminology is good and we should not fix it.


People taking positions one through three are people that I can
work with.

-dsr-

Re: Journald's qualities (was: Selective rotation of journald logs)

[Dan Ritter]

Stefan Monnier wrote: 
> Makes one wonder why they don't use naive append-only "plain text" logs
> (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
> 
> What are the advantages of journald's representation?
> I mean, to justify the slow search and large disk space usage, there is
> presumably some upside for some use cases.  I can see some weak argument
> against Sqlite based on the size of Sqlite, but what are the advantages
> of journald's representation compared to a naive one?


systemd's design philosophy, observed from the outside, goes
like this:

- assume that the machine is a laptop or mobile device that is
always changing: moves from network to network, plugs and
unplugs devices, goes to sleep and is woken up

- disk space is limited, but cpu time is free

- the network knows better than local config

- all services serve the local user's desktop, primarily

- the local user doesn't know anything but can call on a remote
  sysadmin

- systemd is the best at doing anything, so it should do
everything.

If all of these assumptions match up with your particular use
case, systemd is happy.


Long-term logs are for servers, so systemd doesn't want them.
systemd thinks logs are for finding out what just happened
recently. If you wanted long-term logs, obviously you would
configure a central repository on some other machine and ship
them across the network.


I have nothing but praise for the Debian maintainers of rsyslog,
who have arranged it so that installing rsyslog immediately does
appropriate things to pull data out of systemd.

-dsr-

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 14:50:12
fxkl4...@protonmail.com napisał(a):

> On Fri, 23 Feb 2024, Andy Smith wrote:
> 
> > Hi,
> >
> > On Thu, Feb 22, 2024 at 11:19:16AM +0100, Ralph Aichinger wrote:  
> >> I know this is a loaded topic. I really don't want to discuss the
> >> political aspects of the "why",  
> >
> > No surprise that there are a lot of people in this thread with very
> > strong feelings that they simply must tell us about, even though you
> > asked them not to, and very little to say on the actual technical
> > facts they claim to care about.   
> 
> too many people have nothing constuctive to do
> so they spend there days stirring the pile
> idle hands and all that
> 

Yeah like asking other people to do changes because they want to be
activists on internet but can't bother to put effort to do anything
that actually helps anyone.

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 14:44:03
Andy Smith  napisał(a):

> Hi,
> 
> On Thu, Feb 22, 2024 at 11:19:16AM +0100, Ralph Aichinger wrote:
> > I know this is a loaded topic. I really don't want to discuss the
> > political aspects of the "why",  
> 
> No surprise that there are a lot of people in this thread with very
> strong feelings that they simply must tell us about, even though you
> asked them not to, and very little to say on the actual technical
> facts they claim to care about. 

"Do what I say, discussion is not allowed because I don't want to make
a sensible arguments!" 

"Damn those people using reason and questioning what I want, just do
what I say!"

Yes, completely unsurprising as those kinds of demands always come from
those kinds of unreasonable people.

Fork a kernel, do your changes and see how many are interested.


-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Booten vanaf USB duurt steeds langer

[Geert Stappers]

On Thu, Feb 22, 2024 at 09:48:17AM +0100, Paul van der Vlis wrote:
> Op 20-02-2024 om 09:31 schreef Paul van der Vlis:
> > Hallo,
> > 
> > Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat
> > dit steeds trager wordt, op dezelfde machine:
> > 
> > Debian10:  18 seconden
> > Debian11:  60 seconden
> > Debian12:  ruim 120 seconden
> > 
> > Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan
> > reuze hard aan het knipperen. Het gaat verder allemaal wel goed.
> > 
> > Op een snellere machine is het wel wat sneller, maar het blijft
> > onacceptabel traag.
> > 
> > Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een
> > log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu
> > zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit.
> > 
> > Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian
> > installer of livestick, dat gaat wel goed. Maar als ik echt Debian
> > installeer op een USB device start het traag, dezelfde SSD aan SATA gaat
> > wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar
> > dat lijkt ook niet het probleem.
> > 
> > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?
> 
> Ik heb in elk geval een work-arround. Dit probleem blijkt niet te spelen in
> UEFI modus.

Dat is wel interesante informatie.  (aanname: nog steeds dezelfde
computer)  Eerder las ik het originele bericht als "Die is
doorvoersnelheid van de USB-controller aan het meten".  Met de nieuwe
informatie is mijn kijk: "De UEFI bootloader weet beter hoe data achter
de USB-controller naar binnen te halen" op de situatie.
 
> Groet,
> Paul


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Journald's qualities (was: Selective rotation of journald logs)

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 10:26:49
Stefan Monnier  napisał(a):

> > [13:37:48]cthulhu:/var/log/journal☠ journalctl |dd of=/dev/zero
> > bs=1M 0+15442 records in
> > 0+15442 records out
> > 63643115 bytes (64 MB, 61 MiB) copied, 5,47791 s, 11,6 MB/s
> > du -h /var/log/journal/
> > 337M/var/log/journal/44cf6f547971fc33309d1e9e02e7
> > 337M/var/log/journal/
> >
> > (I've raised a bug 8 years ago about it
> >  https://github.com/systemd/systemd/issues/2460 )  
> 
> Oh, that bug report is quite interesting, thanks.
> Makes one wonder why they don't use naive append-only "plain text"
> logs (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
> 
> What are the advantages of journald's representation?
> I mean, to justify the slow search and large disk space usage, there
> is presumably some upside for some use cases.  

The advantage of binary format is that you have separate fields for
program, level etc and it is easier to filter by exactly what you want. 
So "systemctl status servicename" just asks log subsystem for exactly
what it needs.

But journald logs aren't build for querying speed, there is for example
no index (in memory or on disk) that tells you where last log entries
from apps are so you get pathological cases like in ticket.

The problem is that you kinda do 2 types of querying on logs most often:

* get me all/most of what happened in last x lines/hours
* get me everything recent (or just everything period) that this
  particular service returned.

Which kinda exclude the "simple" tricks" like "just hash over service
name so at worst you have to search only 1/64th of files" as they would
make the "get me everything" case slower. But maybe not by all that
much.

The size issue... it's appendable binary format which means that any
metadata systemd adds can't be deduplicated by just having join on
table with service info, it needs to be repeated every single line and
I'm guessing that's where the bloat comes from.

I rambled about SQLite as it is kinda closest comparison for embedded
binary format that can be searched and I think that being able to run
SQL queries (sqlite now even have full text search) against your local
logs with no database daemons running would be killer feature on some of
the smaller devices.


> argument against Sqlite based on the size of Sqlite, 

I'd argue that's not really technically relevant as in most cases you'd
have other app in system using sqlite for *something* and will have
installed the library anyway. And space savings gets wasted just on how
verbose journald format is.

> but what are the
> advantages of journald's representation compared to a naive one?

in short: querability without text parsing. That's about it.

Which *is* a great feature, do not get me wrong, I use it all the time,
but the slowdown caused by its unfortunate implementation detail is
also showing up when I use it pretty often as the most common use case
is "something broke, log in on server that has been running on
automation for last 3 months and see what is happening"

It does have some features around FSS (signing logs) so for folks that
need it there isn't many alternatives as it would be hard to make
similar feature on database.

But on flipside inability to separate log into log rotation groups is
*nasty*. You basically can't have verbose service in the system as that
will rotate away any old logs of other services away. And looking for
those logs is also the worst case:

[17:57:56]cthulhu:~☠ echo 3 > /proc/sys/vm/drop_caches
[17:58:14]cthulhu:~☠ time systemctl status nginx |grep Notice
Notice: journal has been rotated since unit was started, output may be 
incomplete.

real0m1,645s
user0m0,000s
sys 0m0,094s
[17:58:19]cthulhu:~☠ echo 3 > /proc/sys/vm/drop_caches
[17:58:28]cthulhu:~☠ time sqlite /tmp/log_indexed.sqlite 'select * from log 
where source = "nginx";'  >/dev/null

real0m0,374s
user0m0,000s
sys 0m0,009s


I guess another one being appendable log is that in case of crash it's easier 
to recover than embedded database...

...or so would I say if I didn't saw journald throwing away binary logs with 
some errors after crash.


> 
> 
> Stefan
> 
> 
> PS: FWIW, the only time I thought about the design of a log format,
> I was thinking along the lines of reducing redundancy, i.e. keeping
> a kind of "suffix tree" of past messages so as to replace the many
> repeated chunks of text with references to past log entries.
> Then I realized that I could get the same result much more simply by
> gzipping the files, which would naturally be done as part of
> log rotation 
> 

One-service-per-file approach is honestly good enough for most stuff.
PITA to get chronological order thought, every approach really have
some drawbacks and benefits.

But honestly ? Send it to central logger and worry there if you have a
chance, especially if you do some parsing there can 

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Jeffrey Walton]

On Fri, Feb 23, 2024 at 5:08 AM Marco Moock  wrote:
> Am 22.02.2024 schrieb Ralph Aichinger :
> [...]
> > Is there anything planned to get "master/slave" terminology out of
> > network bonding/LACP in Debian (or Linux kernel or whoever decides
> > this terminology)? I know these things are slow to change, just
> > wondering.
> >
> > https://wiki.debian.org/Bonding
>
> I don't know why somebody should waste time for changing terms there.
> There is almost no technical benefit and the amount of people who
> operate Ethernet bonds is small, so the probability that somebody feels
> disturbed by those terms here is also small.
> [...]
> I don't think that spending time on that is a valuable thing, there are
> more important tasks like testing or adding functionality.

I align with most of this position. An engineer's time is better spent
on technical problems, not political ones. There is no technical
benefit, so don't spend time on it. And there are other venues for
political discourse.

> If you like to change that, feel free to create a fork of the upstream
> projects and use the terms you prefer.

I hope no one would object if OP created a politically correct
ifenslave-pc package.

I don't want to bikeshed, though. Slavery ended in the US about 150
years ago. I don't know any slaves, and I don't own any slaves, so I
don't really have a dog in the fight.

Jeff

Re: Selective rotation of journald logs

[Max Nikulin]

On 23/02/2024 17:15, Nicolas George wrote:


How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?


I am realizing that the following is not an answer to the asked 
question. The thread is no more than useless arguing anyway.


Some ideas that might be useful in close cases:
- a bunch of filtering options and --output=export as a part of log 
rotation to have selective copy of the journal in an alternative directory

- systemd-journald.service(8) § JOURNAL NAMESPACES for some services.


P.S.
When I read the question I decided that syslog for auth facility is a 
kind of solution.

Journald's qualities (was: Selective rotation of journald logs)

[Stefan Monnier]

> [13:37:48]cthulhu:/var/log/journal☠ journalctl |dd of=/dev/zero bs=1M
> 0+15442 records in
> 0+15442 records out
> 63643115 bytes (64 MB, 61 MiB) copied, 5,47791 s, 11,6 MB/s
> du -h /var/log/journal/
> 337M  /var/log/journal/44cf6f547971fc33309d1e9e02e7
> 337M  /var/log/journal/
>
> (I've raised a bug 8 years ago about it
>  https://github.com/systemd/systemd/issues/2460 )

Oh, that bug report is quite interesting, thanks.
Makes one wonder why they don't use naive append-only "plain text" logs
(tho with appropriate delimiters (maybe some kind of CSV) to make
searches more reliable than with old-style plain text logs)?

What are the advantages of journald's representation?
I mean, to justify the slow search and large disk space usage, there is
presumably some upside for some use cases.  I can see some weak argument
against Sqlite based on the size of Sqlite, but what are the advantages
of journald's representation compared to a naive one?


Stefan


PS: FWIW, the only time I thought about the design of a log format,
I was thinking along the lines of reducing redundancy, i.e. keeping
a kind of "suffix tree" of past messages so as to replace the many
repeated chunks of text with references to past log entries.
Then I realized that I could get the same result much more simply by
gzipping the files, which would naturally be done as part of
log rotation 

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[fxkl47BF]

On Fri, 23 Feb 2024, Andy Smith wrote:

> Hi,
>
> On Thu, Feb 22, 2024 at 11:19:16AM +0100, Ralph Aichinger wrote:
>> I know this is a loaded topic. I really don't want to discuss the
>> political aspects of the "why",
>
> No surprise that there are a lot of people in this thread with very
> strong feelings that they simply must tell us about, even though you
> asked them not to, and very little to say on the actual technical
> facts they claim to care about. 

too many people have nothing constuctive to do
so they spend there days stirring the pile
idle hands and all that

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hi,

On Thu, Feb 22, 2024 at 11:19:16AM +0100, Ralph Aichinger wrote:
> I know this is a loaded topic. I really don't want to discuss the
> political aspects of the "why",

No surprise that there are a lot of people in this thread with very
strong feelings that they simply must tell us about, even though you
asked them not to, and very little to say on the actual technical
facts they claim to care about. 

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hi,

On Fri, Feb 23, 2024 at 10:33:08AM +0100, Mariusz Gronczewski wrote:
> It would *literally* break every single script that checks the status
> of bonding config in system, as it is all just plain text.

Unless a different driver was made instead. Which is what actually
happened.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Andy Smith]

Hi,

On Fri, Feb 23, 2024 at 12:14:10PM +0100, Mariusz Gronczewski wrote:
> Dnia 2024-02-23, o godz. 11:25:25
> Roger Price  napisał(a):
> > On Fri, 23 Feb 2024, Marco Moock wrote:
> > > The only package I am aware of that changed some terms is sendmail.
> > >  
> > 
> > With the publication of RFC 9271 "UPS Management Protocol", the nut
> > packages (Network UPS Tools) did a vocabulary cleanup

[…]

> Did you looked up what actually changed and thought about implications
> vs changing kernel interfaces or did you just google for random tidbit
> of which project did waste time on that ?

Roger is responding to a statement of there being no other, with the
info that there is at least one other.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 14:23:07
Nicolas George  napisał(a):

> Mariusz Gronczewski (12024-02-23):
> > Like, really what kind of person gets angry when they get too much
> > details in instruction?  
> 
> What kind of person writes pages of angry mail when the details are
> not liked?
> 

That would be you, the thing like "conversation" and "having common
courtesy to answer questions instead of ignoring ones you don't like"
seems like foreign concept to you too. Now please just be quiet as this
is just spam at that point and the question has already been answered.

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Selective rotation of journald logs

[Nicolas George]

Mariusz Gronczewski (12024-02-23):
> Like, really what kind of person gets angry when they get too much
> details in instruction?

What kind of person writes pages of angry mail when the details are not
liked?

-- 
  Nicolas George

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 14:09:45
Nicolas George  napisał(a):

> Greg Wooledge (12024-02-23):
> > Have you even *read* this mailing list?  Most of the people who ask
> > for help here lack experience that you might consider "baby
> > sysadmin" level, and would greatly appreciate the explanations.  
> 
> It is usually quite easy to tell the difference by the phrasing and
> accuracy of the question.
> 

It does. It looked like person that can't comprehend the manual they
have been given nor use Google



-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 14:03:50
Nicolas George  napisał(a):

> Greg Wooledge (12024-02-23):
> > What was "blind" about his anaylsis?  It looked pretty well thought
> > out to me.  He showed actual examples of how space-inefficient it
> > is, and provided a theoretical example of how one misbehaved
> > service could flush out the important logs of well-behaved
> > services.  
> 
> The selective blindness here is to look only at the bad things. The
> drawbacks mentioned exist, but they are in part there for reasons, in
> order to fix the issues of the previous solutions.

I wrote about the stuff you explicitly asked, saving the logs on disk,
because you apparently can't stand a conversation about alternatives.

First you bitch I wrote about "the old stuff you know" now you bitch
about not going thru entire manpage of journalctl features. Decide

> 
> An analysis that mentions only the bad things and conclude to
> recommend using the previous solutions without even discussing their
> own drawbacks is not worth our time.
> 

The selective blindness is your problem, not "us". You decided "old
stuff" didn't work for you and got into shouting match when I described
you in excessive detail why what you want to do is impossible under
systemd.

And you got angry that someone described you why you can't do that.

> > If anything, the person who's blindly following a path is *you*.
> > You're looking to do something that multiple people have said is
> > not possible,  
> 
> Multiple?
> 
> > and when they offer you an alternative, your claws come out.  
> 
> When somebody spends one line answering the question and then pages
> “offering an alternative” by explaining things a baby sysadmin would
> already know, I deduce they are not much above the level of baby
> sysadmin themselves, and it cancels any trust I could have put in the
> one-line answer.
> 

I assumed that you are a beginner because if you read a manpage of
journald/ctl you would know what you are asking is not possible. And
the fact you haven't mentioned any other "traditional" way of doing it
made it look like that too, a newbie linux user that didn't knew it
existed.

So I wrote it with detail needed for beginner to do the job.

I would say I am sorry for mistaking your "skill" level but you already
proven abilty to read the documentation with understand is above you,
so I am not.

Like, really what kind of person gets angry when they get too much
details in instruction?


-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Selective rotation of journald logs

[Nicolas George]

Greg Wooledge (12024-02-23):
> Have you even *read* this mailing list?  Most of the people who ask
> for help here lack experience that you might consider "baby sysadmin"
> level, and would greatly appreciate the explanations.

It is usually quite easy to tell the difference by the phrasing and
accuracy of the question.

Regards,

-- 
  Nicolas George

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 13:48:35
Nicolas George  napisał(a):

> Mariusz Gronczewski (12024-02-23):
> > So to say it short: It is horrid.  
> 
> Generic bashing of systemd in favor of a blind cult of the good old
> ways are not what I am looking for either, and the unbalanced tone of
> your reply makes it look like precisely that.
> 

What was "blind" about it? I had now years of experience on few
hundreds systems dealing with it from basically since it was included
in Debian.

I assume you're one of those ignorants that assume any critique of 
product means that I somehow "hate" it  and everything around it without 
reason and that is frankly disgusting.

Systemd saved us thousands of lines of code thanks to its many useful
features and cut down whole swathes of bugs commonly made in "simple"
SysV systems and I'd recommend it on any alternative in a flash.

But journalctl is just not one of them and the way it
stores the data looks like an amateur really wanted towanted to write a
file format/database/querying system and failed at all of that, instead
of slapping SQLite (or any other existing established embedded
database) on it and calling it a day. Hell "a bunch of texfiles
prefixed with program name would've been an improvement. That's even
before we got into whole log duration management that I already
mentioned.

I *want* it to be good, system like that that is also efficient and
easy to query would be a dream for embedded system but it. is. just.
not. that. At the moment.

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Selective rotation of journald logs

[Greg Wooledge]

On Fri, Feb 23, 2024 at 02:03:50PM +0100, Nicolas George wrote:
> When somebody spends one line answering the question and then pages
> “offering an alternative” by explaining things a baby sysadmin would
> already know, I deduce they are not much above the level of baby
> sysadmin themselves, and it cancels any trust I could have put in the
> one-line answer.

Have you even *read* this mailing list?  Most of the people who ask
for help here lack experience that you might consider "baby sysadmin"
level, and would greatly appreciate the explanations.

Re: Selective rotation of journald logs

[Nicolas George]

Greg Wooledge (12024-02-23):
> What was "blind" about his anaylsis?  It looked pretty well thought out
> to me.  He showed actual examples of how space-inefficient it is, and
> provided a theoretical example of how one misbehaved service could
> flush out the important logs of well-behaved services.

The selective blindness here is to look only at the bad things. The
drawbacks mentioned exist, but they are in part there for reasons, in
order to fix the issues of the previous solutions.

An analysis that mentions only the bad things and conclude to recommend
using the previous solutions without even discussing their own drawbacks
is not worth our time.

> If anything, the person who's blindly following a path is *you*.  You're
> looking to do something that multiple people have said is not possible,

Multiple?

> and when they offer you an alternative, your claws come out.

When somebody spends one line answering the question and then pages
“offering an alternative” by explaining things a baby sysadmin would
already know, I deduce they are not much above the level of baby
sysadmin themselves, and it cancels any trust I could have put in the
one-line answer.

Regards,

-- 
  Nicolas George

Re: which package to file a bug report ?

[Frank Weißer]

First of all: I use german during installation; but I doubt that is 
relevant.


Marco Moock:

Am 22.02.2024 schrieb Frank Weißer :


I only choose ext2 for formatting the encrypted partition, because
nothing else is offered.


That is really strange. If I did install Debian 12, it offered me a
list of different file systems, including ext2/3/4.

It does on non-crypt partitions, but not if I choose 'physical volume 
for encryption' there; then afterwards I only have the choices to use it 
as ext2, swap or lvm or leave it unused for the encrypted partition.



Despite that the partition in fact is getting formatted ext4, so the
entry ext2 in /etc/fstab leads into emergency mode.


Does the installer format it as ext4, but shows ext2 and places that in
fstab?
Or do you format it manually?


The installer does format it as ext4, but shows ext2 and places that in
fstab, what ends up in emergency mode. That's why I'm here

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Stephen P. Molnar]

On 02/23/2024 07:33 AM, Mariusz Gronczewski wrote:

Dnia 2024-02-23, o godz. 12:40:19
Arno Lehmann  napisał(a):


On 23.02.24 at 10:33, Mariusz Gronczewski wrote:

On 22.02.2024 11:19, Ralph Aichinger wrote:

Hello!

I know this is a loaded topic...

...

There is no good reason *why*. It's entirely US political feel-good
activism

Statement one above proven.

...

All it does is wastes tens of thousands of people's time once the
have to fix

If there's a single person in the world who feels existing
terminology to hurt them, I consider my usage of such terms.

So you do nothing all day or ? Because there is always someone that
will find something a problem.


If it makes one person feel better, I think I did something good.

That's HORRID argument. You can do massive variety of unexcusably bad
things with that excuse. "But that person was happy for it"


If it makes others feel worse, I have to balance arguments. Arguments
such as "it was always thus" or "it's too much effort" are not strong
ones.


And that 0.001% that isn't even affected by term want it changed is
argument to you why ?


As it happens, I prefer being called "woke" above being rude.


How about "unable to discuss actual topic but throwing useless
generalizations in every sentence"? Is that woke or rude ?




Neither. it's a waste of bandwidth!

I'm guilty of that for posting this.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: Selective rotation of journald logs

[Greg Wooledge]

On Fri, Feb 23, 2024 at 01:48:35PM +0100, Nicolas George wrote:
> Mariusz Gronczewski (12024-02-23):
> > So to say it short: It is horrid.
> 
> Generic bashing of systemd in favor of a blind cult of the good old ways
> are not what I am looking for either, and the unbalanced tone of your
> reply makes it look like precisely that.

What was "blind" about his anaylsis?  It looked pretty well thought out
to me.  He showed actual examples of how space-inefficient it is, and
provided a theoretical example of how one misbehaved service could
flush out the important logs of well-behaved services.

If anything, the person who's blindly following a path is *you*.  You're
looking to do something that multiple people have said is not possible,
and when they offer you an alternative, your claws come out.

Re: Selective rotation of journald logs

[Nicolas George]

Mariusz Gronczewski (12024-02-23):
> So to say it short: It is horrid.

Generic bashing of systemd in favor of a blind cult of the good old ways
are not what I am looking for either, and the unbalanced tone of your
reply makes it look like precisely that.

-- 
  Nicolas George

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 13:02:00
Nicolas George  napisał(a):

> Mariusz Gronczewski (12024-02-23):
> > That is not a feature systemd's logging have.  
> 
> That is what it seems, but I would like second opinions.
> 
> > You'd have to make a
> > rsyslogd rule to put it in one directory  
> 
> Thanks, but my question was about systemd's infrastructure. Answers
> about the old systlog/logrotate infrastructure are a waste of time
> since I already know how they work and they are amply documented
> elsewhere.
> 

So to say it short: It is horrid. There is no any sensible indexing or
split between services or anything. Single spamming service can easily
make it rotate out more important but much more rare log entries and
there is nothing you can do about it.

It is also woefully inefficient, with each "line" of log taking few
times more than it does in text or even if thrown into SQLite database.

For example:

[13:37:01]cthulhu:/var/log/journal☠ ls -s -h /tmp/log.sqlite
79M /tmp/log.sqlite
[13:37:12]cthulhu:/var/log/journal☠ sqlite /tmp/log.sqlite 'select count(*) 
from log'
386351
journalctl |wc -l
381770
[13:37:48]cthulhu:/var/log/journal☠ journalctl |dd of=/dev/zero bs=1M
0+15442 records in
0+15442 records out
63643115 bytes (64 MB, 61 MiB) copied, 5,47791 s, 11,6 MB/s
du -h /var/log/journal/
337M/var/log/journal/44cf6f547971fc33309d1e9e02e7
337M/var/log/journal/

(I've raised a bug 8 years ago about it 
https://github.com/systemd/systemd/issues/2460 )

To summarize: the ~61MB of resulting text of logs takes around 337MB 
on disk when saved by journald, ~80MB in sqlite (~103MB when I added 
index for time and process). Use the old ways you know, it's a waste 
of time to try to wrangle journald to do what you want.


-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 12:40:19
Arno Lehmann  napisał(a):

> On 23.02.24 at 10:33, Mariusz Gronczewski wrote:
> > On 22.02.2024 11:19, Ralph Aichinger wrote:  
> >> Hello!
> >>
> >> I know this is a loaded topic...  
> ...
> > There is no good reason *why*. It's entirely US political feel-good 
> > activism  
> 
> Statement one above proven.
> 
> ...
> > All it does is wastes tens of thousands of people's time once the
> > have to fix  
> 
> If there's a single person in the world who feels existing
> terminology to hurt them, I consider my usage of such terms.

So you do nothing all day or ? Because there is always someone that
will find something a problem.

> If it makes one person feel better, I think I did something good.

That's HORRID argument. You can do massive variety of unexcusably bad
things with that excuse. "But that person was happy for it"

> If it makes others feel worse, I have to balance arguments. Arguments 
> such as "it was always thus" or "it's too much effort" are not strong
> ones.
> 

And that 0.001% that isn't even affected by term want it changed is
argument to you why ?

> As it happens, I prefer being called "woke" above being rude.
> 

How about "unable to discuss actual topic but throwing useless
generalizations in every sentence"? Is that woke or rude ?



-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: which package to file a bug report ?

[Marco Moock]

Am 22.02.2024 schrieb Frank Weißer :

> I only choose ext2 for formatting the encrypted partition, because 
> nothing else is offered.

That is really strange. If I did install Debian 12, it offered me a
list of different file systems, including ext2/3/4.

> Despite that the partition in fact is getting formatted ext4, so the
> entry ext2 in /etc/fstab leads into emergency mode.

Does the installer format it as ext4, but shows ext2 and places that in
fstab?
Or do you format it manually?

> I think the partitioning tool in installer should offer to format the 
> encrypted partition in ext4, as LUKS (?) does, instead of ext2 and
> must write ext4 to /etc/fstab, as this is, how it ends up.

LUKS is only a container and doesn't care about the file system inside.
After opening it, it is a file under /dev/mapper that can be formatted
like /dev/sdXY.

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Marco Moock]

Am 23.02.2024 schrieb Arno Lehmann :

> If there's a single person in the world who feels existing
> terminology to hurt them, I consider my usage of such terms.

Everytime there is somebody who doesn't like something.
I mostly care about technology and not the feelings a small amount of
users has.
It is free software - everybody can create a fork and change the stuff.

> If it makes one person feel better, I think I did something good.

I simply don't care about those feelings.

> If it makes others feel worse, I have to balance arguments. Arguments 
> such as "it was always thus" or "it's too much effort" are not strong
> ones.

The amount of work needed to change it is of course a really strong
argument because there need to be people who are willing to change it
and spend their time on it.
The technical gain of that is exactly zero, it doesn't solve any bug,
it doesn't add a feature, it doesn't make it easier to use, it simply
makes some tiny amount of users feel better.

> As it happens, I prefer being called "woke" above being rude.

Feel free to do so. I like the freedom in free software, so everybody
can create software without "problematic" terms.

> Oh, and tech and culture can not be separated, but that's probably
> also a loaded topic.

It cannot be completely separated because there is a language that is
being used and that language is part of a political discussion.

Although, it doesn't mean that a developers needs to change something.

Re: Selective rotation of journald logs

[Nicolas George]

Mariusz Gronczewski (12024-02-23):
> That is not a feature systemd's logging have.

That is what it seems, but I would like second opinions.

>   You'd have to make a
> rsyslogd rule to put it in one directory

Thanks, but my question was about systemd's infrastructure. Answers
about the old systlog/logrotate infrastructure are a waste of time since
I already know how they work and they are amply documented elsewhere.

-- 
  Nicolas George

Re: Meeting with the Development Team

[Steve McIntyre]

Sigh.

Please don't respond to spam, it just magnifies the noise.

I'm already updating our anti-spam rules regularly to try and keep
things as clean as possible.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Selective rotation of journald logs

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 11:15:29
Nicolas George  napisał(a):

> Hi.
> 
> It might be an obvious question, but I do not manage to find the
> obvious answer:
> 
> How do I tell systemd's logging system to keep authentication logs for
> one year and mail logs for one month?
> 
> Regards,
> 

That is not a feature systemd's logging have. You'd have to make a
rsyslogd rule to put it in one directory, another one for the other use
then tweak logrotate rules to rotate and keep each of them for
different length.

Most packages already log to separate files and have separate logrotate
rules so often it is just changing a single line, for example auth.log
is rotated with rest of the default logs:

/var/log/syslog
/var/log/mail.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/cron.log
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}

so if you wanted to change only auth.log you'd copy the section, and remove it 
from current one, like this:


/var/log/auth.log
{
rotate 53 # a year in weeks
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}


-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Arno Lehmann]

On 23.02.24 at 10:33, Mariusz Gronczewski wrote:

On 22.02.2024 11:19, Ralph Aichinger wrote:

Hello!

I know this is a loaded topic...

...
There is no good reason *why*. It's entirely US political feel-good 
activism


Statement one above proven.

...
All it does is wastes tens of thousands of people's time once the have 
to fix


If there's a single person in the world who feels existing terminology 
to hurt them, I consider my usage of such terms.


If it makes one person feel better, I think I did something good.

If it makes others feel worse, I have to balance arguments. Arguments 
such as "it was always thus" or "it's too much effort" are not strong ones.


As it happens, I prefer being called "woke" above being rude.

Oh, and tech and culture can not be separated, but that's probably also 
a loaded topic.


Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: utilisation de nis et nfs pour un réseau de 32 postes

[Basile Starynkevitch]

On 2/23/24 12:02, Erwann Le Bras wrote:


Bonjour

Peut-être faire des essais avec SSHFS? le $HOME des utilisateurs 
serait monté sur chaque client au boot.


Mais je ne sais pas si c'est plus efficace que NFS.



J'aurais tendance à imaginer que c'est moins efficace que NFS, qui est 
de toute façon lent (car Ethernet est beaucoup plus lent que par exemple 
une liaison SATA à un disque local, même rotatif).


NFS (à l'époque lointaine où je l'avais utilisé) ne crypte pas les 
données. SSHFS semble les crypter.


Autrefois (avant 2000) j'avais même utilisé des Sun4/110 dont le swap 
était une partition NFS distante.


Librement

--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See/voir:   https://github.com/RefPerSys/RefPerSys

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 10:54:09
 napisał(a):

> On Fri, Feb 23, 2024 at 10:33:08AM +0100, Mariusz Gronczewski wrote:
> > On 22.02.2024 11:19, Ralph Aichinger wrote:  
> > > Hello!
> > > 
> > > I know this is a loaded topic. I really don't want to discuss the
> > > political aspects of the "why", but just want to know the facts,
> > > i.e. how far this has been progressed in Debian.  
> > 
> > There is no good reason *why*. It's entirely US political feel-good
> > activism  
> [...]
> 
> Oh, goody. A culture warrior.
> 
> *plonk*
> 

Me? Exactly opposite, I'm against bringing culture into tech, it's the
OP that decided to.

It's a pair of words that worked well for decades for the purpose. Now
someone decided to do some feel good activism and just add work for no
gain. I'm against that.

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

Dnia 2024-02-23, o godz. 11:25:25
Roger Price  napisał(a):

> On Fri, 23 Feb 2024, Marco Moock wrote:
> 
> > The only package I am aware of that changed some terms is sendmail.
> >  
> 
> With the publication of RFC 9271 "UPS Management Protocol", the nut
> packages (Network UPS Tools) did a vocabulary cleanup at release
> 2.8.0 which included changing Master/Slave to Primary/Secondary.
> There have been no reports in the mailing list of this causing any
> problems.
> 
> Roger
> 

Because nut have backward-compatible name support. Can't do that if you
change literal text returned by kernel about device config. That is why
it "works" (for us too, we use it). Bringing unrelated project to the
discussion is, well, unrelated as problems are of entirely different
kind, making config backward-compatible is far easier than what it
returns (and nothing realistically would check for the word anyway in
case of UPS)

Did you looked up what actually changed and thought about implications
vs changing kernel interfaces or did you just google for random tidbit
of which project did waste time on that ?

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: utilisation de nis et nfs pour un réseau de 32 postes

[Erwann Le Bras]

Bonjour

Peut-être faire des essais avec SSHFS? le $HOME des utilisateurs serait 
monté sur chaque client au boot.


Mais je ne sais pas si c'est plus efficace que NFS.

Le 20/02/2024 à 12:26, Pierre Malard a écrit :

Ou ahh ! NIS, ça ne me rajeuni pas ça ;-)
Et pourquoi pas un LDAP pour l’authentification ?

Pour ce qui du montage direct du répertoire partagé sur la home dir ce 
n’est pas judicieux car ça va ramer dur si on fait une utilisation 
gourmande en entrée sortie.
Si je me souviens de ce qu’on avait fait ici c’est d’utiliser PAM et 
autofs pour gérer les accès sur les postes avec :


  * Création de la home dir à la volée si besoin depuis un squelette
qui contient un point de montage pour NFS
  * Montage du répertoire partagé de l’utilisateur dans $HOME/NFS


Comme ça l’utilisateur n’est pas ralenti dans ses compilations par 
exemple et peut accéder à ses données dans le répertoire ~/NFS



Le 20 févr. 2024 à 08:34, olivier  a 
écrit :


Bonjour,

J'ai un réseau totalement avec débian 11 (que je compte mettre à jour 
avec la version 12), constitué d'un serveur avec deux cartes réseau, 
l'une reliée à l’extérieur par la fibre (DHCP) et l'autre carte 
(Adresse IP fixe 192.168.200.0) reliée à un switch. Ce switch est 
relié à 32 postes (avec IP fixe de 192.168.200.10 à 192.168.200.50, 
adresse de la passerelle 192.168.200.0, masque de sous réseau 
255.255.255.0).


Les 32 postes sont utilisés par une classe d'élèves. J'ai 200 élèves 
à gérer, donc 200 profil différent.


Pour que chaque poste accède à internet, j'ai fais

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Est ce judicieux ?

J'ai essayé avec NIS avec debian 11, l'authentification à l'air de 
bien fonctionner. Pour l'authentification, NIS est il bien adapté 
pour ce genre de configuration ?


Par contre au niveau de l'export (NFS), cela rame un peu (je me rend 
compte que j'exporte l'ensemble du home serveur sur tous les clients 
et non celui uniquement de l'utilisateur). Comment faire pour 
exporter sur la machine cliente uniquement le profil de l'utilisateur 
et non tous les utilisateurs ?


Sur le serveur, j'ai mis à la fin dans le fichier /etc/exports

/home/NFS_Partage 192.168.200.1/24(rw,sync,no_subtree_check)
mais j'hésite avec

/home/NFS_Partage 
192.168.0.0/24(rw,all_squash,anonuid=1000,anongid=1000,sync,no_subtree_check)


Sur le client, j'ai mis à la fin dans le fichier fstab

DomaineNFS:/home/NFS_Partage /home nfs defaults    0 0

On m'a parlé de LDAP, mais je ne sais pas trop comment m'y prendre. 
Est il préférable d'utiliser LDAP ou NIS pour l'authentification ? 
Existe il un petit manuel simple pour créer 200 utilisateurs.


Mon réseau fonctionne, mais rame beaucoup au delà de 4 utilisateurs ? 
et je n'arrive pas à trouver une solution.


Un grand merci pour votre aide.

Olivier





--
Pierre Malard

  « /La façon de donner vaut mieux que ce que l'on donne /»
                   Pierre Corneille (1606-1684) - Le menteur
|\      _,,,---,,_
/,`.-'`'    -.  ;-;;,_
|,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--' `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) 
)-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'

- --> Ce message n’engage que son auteur <--

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Roger Price]

On Fri, 23 Feb 2024, Marco Moock wrote:


The only package I am aware of that changed some terms is sendmail.


With the publication of RFC 9271 "UPS Management Protocol", the nut packages 
(Network UPS Tools) did a vocabulary cleanup at release 2.8.0 which included 
changing Master/Slave to Primary/Secondary.  There have been no reports in the 
mailing list of this causing any problems.


Roger

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Marco Moock]

Am 23.02.2024 schrieb Alain D D Williams :

> It is "fixing" an issue for today's English speakers. Should we scour
> our systems looking for similar issues in other languages ? Then in,
> say, 20 years time when different words will then be considered
> offensive, by some, do this all again ?

In Germany, some organizations do that as well - and most people are
annoyed by that because it has no benefit.

The most important thing is that the upstream projects would need to
change that - including all the translators.

This is always a PITA - for no realistic benefit.

Selective rotation of journald logs

[Nicolas George]

Hi.

It might be an obvious question, but I do not manage to find the obvious
answer:

How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?

Regards,

-- 
  Nicolas George

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[tomas]

On Fri, Feb 23, 2024 at 11:00:39AM +0100, Marco Moock wrote:
> Am 23.02.2024 schrieb :

[...]

> > Oh, goody. A culture warrior.
> 
> I'm sure you have good reasons for changing the terms. Feel free to
> provide some real arguments that have a benefit for the users.

I'm not the one proposing changing the terms. But I do have
strong reasons to dislike people foaming at the mouth whenever
someone considers even discussing it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Marco Moock]

Am 22.02.2024 schrieb Ralph Aichinger :

> I know this is a loaded topic. I really don't want to discuss the
> political aspects of the "why", but just want to know the facts, i.e.
> how far this has been progressed in Debian.

Debian is mostly a collection of many packages that are packed in the
repo.
Such changes are normally done upstream.

> Is there anything planned to get "master/slave" terminology out of
> network bonding/LACP in Debian (or Linux kernel or whoever decides
> this terminology)? I know these things are slow to change, just
> wondering.
> 
> https://wiki.debian.org/Bonding

I don't know why somebody should waste time for changing terms there.
There is almost no technical benefit and the amount of people who
operate Ethernet bonds is small, so the probability that somebody feels
disturbed by those terms here is also small. Most people don't care
about master/slave either, they simply use that and don't let the wokes
spoil the party.

If you like to change that, feel free to create a fork of the upstream
projects and use the terms you prefer.

I don't think that spending time on that is a valuable thing, there are
more important tasks like testing or adding functionality.

The only package I am aware of that changed some terms is sendmail.

They decided to use blocklist_recipients instead of
backlist_recipients, but blacklist still works.

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Alain D D Williams]

On Fri, Feb 23, 2024 at 10:33:08AM +0100, Mariusz Gronczewski wrote:
> On 22.02.2024 11:19, Ralph Aichinger wrote:
> > Hello!
> > 
> > I know this is a loaded topic. I really don't want to discuss the
> > political aspects of the "why", but just want to know the facts, i.e.
> > how far this has been progressed in Debian.
> 
> There is no good reason *why*. It's entirely US political feel-good activism
> that doesn't change anything but wastes people's time. Do you actually think
> pressing on brake pedal oppresses anybody ? Because it also has master and 
> slave
> cylinder.
> 
> All it does is wastes tens of thousands of people's time once the have to fix
> every script, tool and doc piece related to  it, for absolutely no benefit
> aside from making some twitter activist happy "they did something".
> It would *literally* break every single script that checks the status
> of bonding config in system, as it is all just plain text.

+1

It is "fixing" an issue for today's English speakers. Should we scour our
systems looking for similar issues in other languages ? Then in, say, 20 years
time when different words will then be considered offensive, by some, do this
all again ?

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Marco Moock]

Am 23.02.2024 schrieb :

> On Fri, Feb 23, 2024 at 10:33:08AM +0100, Mariusz Gronczewski wrote:
> > On 22.02.2024 11:19, Ralph Aichinger wrote:  
> > > Hello!
> > > 
> > > I know this is a loaded topic. I really don't want to discuss the
> > > political aspects of the "why", but just want to know the facts,
> > > i.e. how far this has been progressed in Debian.  
> > 
> > There is no good reason *why*. It's entirely US political feel-good
> > activism  
> [...]
> 
> Oh, goody. A culture warrior.

I'm sure you have good reasons for changing the terms. Feel free to
provide some real arguments that have a benefit for the users.

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[tomas]

On Fri, Feb 23, 2024 at 10:33:08AM +0100, Mariusz Gronczewski wrote:
> On 22.02.2024 11:19, Ralph Aichinger wrote:
> > Hello!
> > 
> > I know this is a loaded topic. I really don't want to discuss the
> > political aspects of the "why", but just want to know the facts, i.e.
> > how far this has been progressed in Debian.
> 
> There is no good reason *why*. It's entirely US political feel-good activism
[...]

Oh, goody. A culture warrior.

*plonk*

-- 
t


signature.asc
Description: PGP signature

Re: Inclusive terminology (instead of master/slave) for network bonding/LACP

[Mariusz Gronczewski]

On 22.02.2024 11:19, Ralph Aichinger wrote:

Hello!

I know this is a loaded topic. I really don't want to discuss the
political aspects of the "why", but just want to know the facts, i.e.
how far this has been progressed in Debian.


There is no good reason *why*. It's entirely US political feel-good activism
that doesn't change anything but wastes people's time. Do you actually think
pressing on brake pedal oppresses anybody ? Because it also has master and slave
cylinder.

All it does is wastes tens of thousands of people's time once the have to fix
every script, tool and doc piece related to  it, for absolutely no benefit
aside from making some twitter activist happy "they did something".
It would *literally* break every single script that checks the status
of bonding config in system, as it is all just plain text.


--

Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64
https://devrandom.eu

Re: Booten vanaf USB steeds trager

[Paul van der Vlis]

Hoi Geert en anderen,

Op 21-02-2024 om 22:35 schreef Geert Stappers:

On Wed, Feb 21, 2024 at 04:02:59PM +0100, Paul van der Vlis wrote:

Op 20-02-2024 om 21:02 schreef Geert Stappers:

On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote:

Hallo,

Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit
steeds trager wordt, op dezelfde machine:

Debian10:  18 seconden
Debian11:  60 seconden
Debian12:  ruim 120 seconden


zestig gedeeld door achttien is dik drie
ruim honderdtwing gedeeld door zes is net geen twee



Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze
hard aan het knipperen. Het gaat verder allemaal wel goed.

Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel
traag.

Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log.
Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang
duurt. Dmesg geeft wel tijden, maar ik kom er niet uit.

Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian
installer of livestick, dat gaat wel goed. Maar als ik echt Debian
installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel
goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat
lijkt ook niet het probleem.

Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?


Ja, ik heb wel een idee.
En dat idee wil ik ruilen voor de output van `ls -l /boot`
op de getestde versies.


Dit is op Debian 10:
-- knip --
-rw-r--r-- 1 root root 52343097 jun  3  2021 initrd.img-4.19.0-16-amd64
-- knip --
-rw-r--r-- 1 root root  5287168 mrt 19  2021 vmlinuz-4.19.0-16-amd64
  
52 miljoen plus 5 miljoen is 57 miljoen.




Dit is op Debian 11:
-- knip --
-rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64
-- knip --
drwx-- 2 root root12288 19 feb 21:24 lost+found
-rw-r--r-- 1 root root  7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64


57m + 7m = 64m

64/57=1,12En 1,12 is echt geen factor drie.
  


Dit is op Debian 12:
-- knip --
-rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64
-- knip --
drwx-- 2 root root12288 19 feb 16:22 lost+found
-rw-r--r-- 1 root root  8140672  9 dec 16:48 vmlinuz-6.1.0-15-amd64


87m + 8m = 95m
95/64 is ongeveer anderhalf.
Die anderhalf komt wel in de buurt van factor twee.


Terug naar

Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?


Ja, ik heb wel een idee.



Het idee is de kernel en initrd kleiner maken.


Of de laad-snelheid groter. Het lijkt er haast op dat dit met een heel 
lage snelheid gebeurd.


Maar wat ook heel goed kan is dat er iets in de initramfs zit wat veel 
tijd kost. Maar blijkbaar alleen in legacy-mode van het bios, niet bij UEFI.



De bijvangst van de `ls -l /boot` is dat "de snelste" geen 'lost+found'
heeft. Over verschil in disk partities is nog geen informatie gegeven.


Er zijn inderdaad meer verschillen. De twee trage hebben LVM en 
encryptie en een aparte /boot. Ik had de tijd gemeten tot aan de 
paswoord prompt van de encryptie. Of bij de oudste tot de berichten van 
het opstarten van de services begonnen.



Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter inderdaad,
maar 87MB is niet zo heel groot, met USB3 is dat zo over toch?



Groet,
Paul


Groeten
Geert Stappers

Verzoek: Meer nieuwsgierigheid, minder mening en nog minder verwachtingen


Wellicht waren het wat frustraties...  Het ging om iets wat klaar moest, 
simpel leek, maar onverwachte problemen gaf.  En dan ook nog meerdere 
van dit soort dingen tegelijk.



Doe ons allemaal een plezier en ga voor meer nieuwsgierigheid.
Stel vragen als "Waar kijk ik tegen aan?", "Hoe het verder te onderzoeken?",
"Welk aspect van dichtbij bekijken?".


Ik had het beter kunnen formuleren. En ik was er graag dieper in 
gedoken, maar niet genoeg tijd.



Laat meningen op de achtergrond. Verwoord "steeds trager" als "duurt steeds 
langer".


Je bedoeld: een positievere insteek.


Mocht je wel een mening hebben, laat dan jouw ego dan aan jouw karma vragen
waar die mening "for the greater good" te ventileren.

Verwachtingen zijn helemaal van je zelf. Daar moet ik dan zelf ook
het meeste mee doen. Zo als geen verwachtingen hebben.


Tja, ik heb wel verwachtingen (want ook maar een mens).
En ben dan teleurgesteld als het anders gaat.

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/