Re: Upgrading systemd may silently break your Unstable/Sid system!

On 2024-07-28 20:01:35 -0400, Greg Wooledge wrote: > In the interests of posting something *useful*, here's a timeline. > As I understand it, here's what's happened so far: > > 2024-06-23: bug #1074156 filed against package procps > procps: Depend or Recommend linux-sysctl-defaults > Bug

Re: Upgrading systemd may silently break your Unstable/Sid system!

On Mon, Jul 29, 2024 at 01:13:10 +0200, Vincent Lefevre wrote: > On 2024-07-28 14:13:09 +, Michael Kjörling wrote: > > And posting on debian-user with a bombastic Subject line which implies > > that this is a widespread issue when it really only seems to exist in > > Unstable is, quite

Re: systemd may silently break your system!

ement under /etc, i.e. one entirely replaces the defaults by > > one's own settings. An include mechanism would allow a finer control > > of the settings. The sysctl.d configuration system does not allow one > > to include a file (to get the current defaults and possibly change >

Re: Upgrading systemd may silently break your Unstable/Sid system!

On 2024-07-28 14:13:09 +, Michael Kjörling wrote: > And posting on debian-user with a bombastic Subject line which implies > that this is a widespread issue when it really only seems to exist in > Unstable is, quite frankly, in my opinion at best dishonest. No, the breakage was done *on

Re: systemd may silently break your system!

own settings. An include mechanism would allow a finer control > of the settings. The sysctl.d configuration system does not allow one > to include a file (to get the current defaults and possibly change > some of them just after). I really don't understand what you're asking for here

Re: Upgrading systemd may silently break your Unstable/Sid system!

I've run Sid exclusively for years; the last time I broke it badly enough to justify a reinstall was in 2013 and that was for not paying attention during an upgrade :) My heartburn is I would have expected to see this change in a changelog and apt-listchanges didn't say a word about this. As

Re: systemd may silently break your system!

t; > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of > > > > > the systemd package. > > That symlink was suggested as legacy support for reading the conf file > over a decade ago. Bullseye's man 8 sysctl indicates it still reads > /etc/sysctl

Re: Upgrading systemd may silently break your Unstable/Sid system!

On 2024-07-28 at 10:13, Michael Kjörling wrote: > On 28 Jul 2024 15:08 +0200, from er...@rail.eu.org (Erwan David): >> Le 28/07/2024 à 14:28, allan a écrit : >>> I would agree with you *if* the change had been publicized. >> >> [...] But in my view it is a bug to remove something else than the

Re: Upgrading systemd may silently break your Unstable/Sid system!

On 28 Jul 2024 15:08 +0200, from er...@rail.eu.org (Erwan David): > Le 28/07/2024 à 14:28, allan a écrit : >> I would agree with you *if* the change had been publicized. > > [...] But in my view it is a bug to remove something else than > the symlink even with the same name At the risk of

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

Le 28/07/2024 à 14:28, allan a écrit : I would agree with you *if* the change had been publicized. I found the 99-sysctl.conf symlink accidentally. I removed the symlink and moved sysctl.conf to 99-sysctl.conf since the original config was not being read. This turned out to be a lousy idea

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

I would agree with you *if* the change had been publicized. I found the 99-sysctl.conf symlink accidentally. I removed the symlink and moved sysctl.conf to 99-sysctl.conf since the original config was not being read. This turned out to be a lousy idea since the symlink was removed with the next

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

On 28 Jul 2024 04:25 +0200, from vinc...@vinc17.net (Vincent Lefevre): >> A conffile is user-managed, so any changes you make to a conffile must >> be respected by the package. It can't just overwrite your changes, or >> restore a conffile if you've deleted it. > > This is rather poor design,

Re: systemd may silently break your system!

> > > > the systemd package. That symlink was suggested as legacy support for reading the conf file over a decade ago. Bullseye's man 8 sysctl indicates it still reads /etc/sysctl.conf with its --system option, but bookworm lacks that manpage, and instead its man 5 sysctl.d

Re: systemd may silently break your system!

for the heads-up, my /etc/sysctl.conf was no longer being read. Now moved to a file in /etc/sysctl.d/ tested with: sysctl --system now working again.

Re: systemd may silently break your system!

-- > > You're on unstable. In bookworm, it says this: > > > Kernel system variables configuration files > > Files found under the /etc/sysctl.d directory that end with .conf are > parsed within sysctl(8) at boot time. I

Re: systemd may silently break your system!

ls regarding the configuration files refer to > sysctl.d(5) or sysctl.conf(5) > You're on unstable. In bookworm, it says this: ---- Kernel system variables

Re: systemd may silently break your system!

On 2024-07-27 09:26:49 -0400, Greg Wooledge wrote: > > On 2024-07-26, Vincent Lefevre wrote: > > > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > > (currently in unstable) *without any announcement*, so that > > > the /etc/sysctl.conf file (which is still documented, BTW) > > >

Re: systemd may silently break your system!

On 2024-07-27 10:23:01 +0200, Michel Verdier wrote: > On 2024-07-26, Vincent Lefevre wrote: > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > (currently in unstable) *without any announcement*, so that > > the /etc/sysctl.conf file (which is still documented, BTW) > > is no

Re: systemd may silently break your system!

s concerned, I would have thought this was just part of the evolution from big-file-under-/etc/ to individual-snippets-under-/etc/foo.d/ that's been happening for years. And I can't find another instance on my system of a /etc/foo.d/NN-bar → /etc/bar.conf where the symlink has a sequence number. (IOW bar.conf doesn't "know" that it's part of an ordered collection of configurations.) Cheers, David.

Re: systemd may silently break your system!

> On 2024-07-26, Vincent Lefevre wrote: > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > (currently in unstable) *without any announcement*, so that > > the /etc/sysctl.conf file (which is still documented, BTW) > > is no longer read. > > > > So, be careful if you have

Re: systemd may silently break your system!

On 2024-07-26, Vincent Lefevre wrote: > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*, so that > the /etc/sysctl.conf file (which is still documented, BTW) > is no longer read. > > So, be careful if you have important settings there

Re: systemd may silently break your system!

e careful if you have important settings there (security...). I had to laugh when I saw the title: systemd may silently break your system! So what's new in the world according to Poettering? Jeff

Re: systemd may silently break your system!

I had already removed the symlink and migrated sysctl.conf to 99-sysctl.conf and it appears Debian deleted that file as well. On Fri, Jul 26, 2024 at 9:00 AM Vincent Lefevre wrote: > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*,

systemd may silently break your system!

The /etc/sysctl.d/99-sysctl.conf symlink has been removed (currently in unstable) *without any announcement*, so that the /etc/sysctl.conf file (which is still documented, BTW) is no longer read. So, be careful if you have important settings there (security...). -- Vincent Lefèvre - Web:

Re: update system periodically

tab. > > `apt update` (and `apt-get update`) will only update the package > database. That should be about as safe as you can get, because it will > have no impact on day-to-day use of the system. > > `apt upgrade`, `apt full-upgrade`, `apt-get dist-upgrade` and other > com

Re: update system periodically

On Sun 21 Jul 2024 at 22:01:58 (-0600), Charles Curley wrote: > On Sun, 21 Jul 2024 18:43:28 -0500 > David Wright wrote: > > > I run the following from root's crontab: > > > > apt-get -qq -o Acquire::http::Proxy="http://192.168.1.14:3142/; > > update && apt-get -qq -d -o > >

Re: update system periodically

at should be about as safe as you can get, because it will have no impact on day-to-day use of the system. `apt upgrade`, `apt full-upgrade`, `apt-get dist-upgrade` and other commands like those _can_ be risky, depending on circumstances. There might also be legitimate reasons why you don't _want_ t

Re: update system periodically

On Mon, 22 Jul 2024 05:47:58 +0800 cor...@free.fr wrote: > I have been running an old debian 11 for many days. > is it safe to run 'apt upgrade' and 'apt update' periodically? > for example put them into crontab. I suggest you do the next update manually. Then you can automate the process with

Re: update system periodically

On Sun, 21 Jul 2024 18:43:28 -0500 David Wright wrote: > I run the following from root's crontab: > > apt-get -qq -o Acquire::http::Proxy="http://192.168.1.14:3142/; > update && apt-get -qq -d -o > Acquire::http::Proxy="http://192.168.1.14:3142/; dist-upgrade && find >

Re: update system periodically

Hi, On Mon, Jul 22, 2024 at 05:47:58AM +0800, cor...@free.fr wrote: > is it safe to run 'apt upgrade' and 'apt update' periodically? > for example put them into crontab. I prefer to use apticron to download updates daily and tell me about them, and then for me to install them manually. The

Re: update system periodically

cacher-ng on one machine as a proxy, which you might not, in which case omit both occurrences of: -o Acquire::http::Proxy="http://192.168.1.14:3142/; > I ask this question because I am worried that some software updates > may conflict with each other after running in this way, resulting

Re: update system periodically

On Mon, Jul 22, 2024 at 07:34:29 +0800, Bret Busby wrote: > One thing to remember, regarding automated upgrades, is that, if an upgrade > involves a kernel upgrade, then you can have a need for immediate rebooting, > which may be problematic. It's also rare, but NOT unheard of, for a stable

Re: update system periodically

software updates may conflict with each other after running in this way, resulting in system unavailability. Thank you. The perception of safety is subjective, and depends on different aspects and perspectives of the circumstances applicable at any particular time. One thing to remember

Re: update system periodically

other after running in this way, resulting in system unavailability. Thank you. The perception of safety is subjective, and depends on different aspects and perspectives of the circumstances applicable at any particular time. One thing to remember, regarding automated upgrades

Re: update system periodically

On 7/21/24 17:47, cor...@free.fr wrote: Hi list, I have been running an old debian 11 for many days. is it safe to run 'apt upgrade' and 'apt update' periodically? for example put them into crontab. I wouldn't have the upgrade run automatically, because maybe there's a package you wouldn't

update system periodically

in system unavailability. Thank you. -- corey hickman

Listing packages installed on broken system, was systemd errors

r install working cleanly to remind > me of what was installed. You don't need to be able to run a system merely to list what's installed on it. Just mount the root filesystem somewhere, like /mnt, and type: $ dpkg-query --admindir=/mnt/var/lib/dpkg -W --showformat '${Package}_${Version}

Re: Great system

On 2024-07-08 10:05, George at Clug wrote: On Monday, 08-07-2024 at 11:19 Richard Bostrom wrote: Debian is such a great system. But now copying and rsync does not work Richard, Please elaborate on what you mean by "copying and rsync does not work"? I often use Thunar, cp, and rsy

Re: Great system

On Mon, Jul 08, 2024 at 01:19:14AM +, Richard Bostrom wrote: > Debian is such a great system. But now copying and rsync does not work and it > has to be done from a live-usb. The system is turning un-usable. Please less > releases and more stable releases. I am reverting to the vers

Re: Great system

On Monday, 08-07-2024 at 11:19 Richard Bostrom wrote: > Debian is such a great system. But now copying and rsync does not work Richard, Please elaborate on what you mean by "copying and rsync does not work"? I often use Thunar, cp, and rsync to copy files, and have not

Great system

Debian is such a great system. But now copying and rsync does not work and it has to be done from a live-usb. The system is turning un-usable. Please less releases and more stable releases. I am reverting to the version prior of bookworm. Although graphically not as good. Yours sincerely

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 28/06/2024 18:42, Keith Bainbridge wrote: On 28/6/24 16:13, John Crawley wrote: Except that midnight is also 0:00, so you still have the am/pm confusion. They should have kept 0:00 just for midnight really. That's the first time I've seen anything to justify calling midnight AM.

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 28/6/24 16:13, John Crawley wrote: Except that midnight is also 0:00, so you still have the am/pm confusion. They should have kept 0:00 just for midnight really. That's the first time I've seen anything to justify calling midnight AM. Thankyou But how can mid-day be after mid-day?

Re: System time/timezone, was Re: Maximum size .bash_aliases file

an you cite any      rule that would clarify this once and for all?  "A. Yes. Please see CMOS 9.38: “Except in the twenty-four-hour system      (see 9.39), numbers should never be used to express noon or      midnight (except, informally, in an expression like twelve o'clock      at night).

Re: System time/timezone, was Re: Maximum size .bash_aliases file

ng. Can you cite any rule that would clarify this once and for all? "A. Yes. Please see CMOS 9.38: “Except in the twenty-four-hour system (see 9.39), numbers should never be used to express noon or midnight (except, informally, in an expression like twelve o'clock at night). Altho

Re: System time/timezone, was Re: Maximum size .bash_aliases file

convince the copywriters that this is confusing. Can you cite any rule that would clarify this once and for all? "A. Yes. Please see CMOS 9.38: “Except in the twenty-four-hour system (see 9.39), numbers should never be used to express noon or midnight (except, informally, in

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Wed, Jun 26, 2024 at 11:25:38 -0500, John Hasler wrote: > I wrote: > > 12 Noon and 12 Midnight works. > > David Wright wrote: > > Except that The Wanderer's "strictly correct" version, M for noon, > > is out there in some pre-2008 documents. > > If you use M for noon you should use either AM

Re: System time/timezone, was Re: Maximum size .bash_aliases file

I wrote: > 12 Noon and 12 Midnight works. David Wright wrote: > Except that The Wanderer's "strictly correct" version, M for noon, > is out there in some pre-2008 documents. If you use M for noon you should use either AM or PM for midnight. -- John Hasler j...@sugarbit.com Elmwood, WI USA

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 6/25/24 20:36, Keith Bainbridge wrote: On 23/6/24 23:22, e...@gmx.us wrote: I started using 24 hour time in junior high school with digital watches.  I just thought it made more sense, especially for setting alarms.  Several decades later I've not seen any reason to change, though it

Re: System time/timezone, was Re: Maximum size .bash_aliases file

> That does expose one unfortunate weakness of this system: unless > > > you introduce an additional layer of complexity, e.g. using > > > "00:00 M", the notations for noon and midnight would be > > > identical.) > > > > 12 Noon and 12 Mid

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 25/6/24 07:53, The Wanderer wrote: Although I don't think anything or anyone actually does it this way, I think strictly speaking the correct 12-hour notation for that time would be "12:00 M" - followed by 12:00:01 PM, and preceded by 11:59:59 AM. Sorry to repeat you - well you did it

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 24/6/24 23:41, Erwan David wrote: AM/PM would not be so strange if between 11AM and 1 PM it was 12 AM ... Umm 12Meridian?? -- All the best Keith Bainbridge keithr...@gmail.com keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 24/6/24 00:53, Curt wrote: On 2024-06-23, Nicholas Geovanis wrote: I think we are losing sight of the fact that all of timekeeping is an abstraction and over-generalization. Time zones were created to help regularize railroad schedules over wide areas. Timezones are an abstraction that

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 23:22, e...@gmx.us wrote: On 6/23/24 02:30, gene heskett wrote: A attribute the FCC forced on broadcasters as they like to see transmitter logs kept in 24 hour time. I got so used to it that when I retired in 2002, I'd been on 24 hour time for 40 years and didn't convert back to

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 18:57, Brad Rogers wrote: On Sun, 23 Jun 2024 15:35:14 +1000 Keith Bainbridge wrote: Hello Keith, +14:00?? I've only ever heard of maxima of +/- 12:00. AFAIAC, it was political willy waving, nothing more; To be 'first' into the new millennium. As if that has any cachet

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 18:56, Brad Rogers wrote: On Sun, 23 Jun 2024 13:01:10 +1000 Keith Bainbridge wrote: Hello Keith, Not to mention some cultures change how words are spelt: colour, odour, metres to quote a few. Due, mainly, to the literacy of the people that moved, rather than any deliberate

Re: System time/timezone, was Re: Maximum size .bash_aliases file

Well, The International BIPM writes the time with a colon: https://www.bipm.org/en/ Best Heriberto On Tuesday, June 25, 2024, David Wright wrote: > On Mon 24 Jun 2024 at 23:34:45 (+0800), Bret Busby wrote: >> On 24/6/24 21:41, Erwan David wrote: >> > Le 24/06/2024 à 22:38, Curt a écrit : > >> >

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Mon 24 Jun 2024 at 23:34:45 (+0800), Bret Busby wrote: > On 24/6/24 21:41, Erwan David wrote: > > Le 24/06/2024 à 22:38, Curt a écrit : > > > When my mom came to visit one time in the nineties she requested I > > > change my alarm clock to AM PM time (it is now 15:25 here in the Gallic > > >

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Mon 24 Jun 2024 at 17:12:18 (-0500), John Hasler wrote: > The Wanderer writes: > > (Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM, > > where the standalone M would stand for "midnight". That does expose one > > unfortunate weakness of th

Re: System time/timezone, was Re: Maximum size .bash_aliases file

te that LC_TIME=en_US.utf8 uses a 12-hour clock by default now. This was not the case until recently. Before that, it used a 24-hour clock just like LC_TIME=C does. I've exported LC_TIME=C into my environment to get the previous behavior back. That's my choice. Perhaps your Slackware system is us

Re: System time/timezone, was Re: Maximum size .bash_aliases file

e only correct term for the > time that is exactly the midpoint would be "meridiem", and therefore, M. > > (Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM, > where the standalone M would stand for "midnight". That does expose one > unfortun

Re: System time/timezone, was Re: Maximum size .bash_aliases file

for "midnight". That does expose one > >> unfortunate weakness of this system: unless you introduce an additional > >> layer of complexity, e.g. using "00:00 M", the notations for noon and > >> midnight would be identical.) > > > > 12 Noon an

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 2024-06-24 at 18:12, John Hasler wrote: > The Wanderer writes: > >> (Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM, >> where the standalone M would stand for "midnight". That does expose one >> unfortunate weakness of this system:

Re: System time/timezone, was Re: Maximum size .bash_aliases file

The Wanderer writes: > (Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM, > where the standalone M would stand for "midnight". That does expose one > unfortunate weakness of this system: unless you introduce an additional > layer of complexit

Re: System time/timezone, was Re: Maximum size .bash_aliases file

(Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM, where the standalone M would stand for "midnight". That does expose one unfortunate weakness of this system: unless you introduce an additional layer of complexity, e.g. using "00:00 M", the notatio

Re: System time/timezone

Bret Busby composed on 2024-06-24 23:42 (UTC+0800): > The USA is a few hundred years behind the rest of the > world, and, cannot comprehend ISO standards - > the ISO standard for date, is > 2024-06-24 > -MM-DD > which is the most efficient way of expressing a date, using the > components

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 6/24/24 11:42, Bret Busby wrote: On 24/6/24 21:38, Curt wrote: You can become confused, though, when filling out US forms where the birth date is written M/D/Y instead of D/M/Y, and sometimes you have to be careful not commit the silly mistake that will entrain months of delay in intricate

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 24/6/24 21:38, Curt wrote: You can become confused, though, when filling out US forms where the birth date is written M/D/Y instead of D/M/Y, and sometimes you have to be careful not commit the silly mistake that will entrain months of delay in intricate *dédales* of the administration.

Re: System time/timezone, was Re: Maximum size .bash_aliases file

not include a colon between the hours and the minutes - 10:30pm is 2230 in the 24 hour clock format. Regarding the reference to degrees Celsius, as a person who remembers the switchover (in this region) from degrees Fahrenheit to the "metric" system, it is easy to remem

Re: System time/timezone, was Re: Maximum size .bash_aliases file

Le 24/06/2024 à 22:38, Curt a écrit : On 2024-06-23, gene heskett wrote: A attribute the FCC forced on broadcasters as they like to see transmitter logs kept in 24 hour time. I got so used to it that when I retired in 2002, I'd been on 24 hour time for 40 years and didn't convert back to two

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 2024-06-24, Curt wrote: > On 2024-06-23, gene heskett wrote: >>> >> A attribute the FCC forced on broadcasters as they like to see >> transmitter logs kept in 24 hour time. I got so used to it that when I >> retired in 2002, I'd been on 24 hour time for 40 years and didn't >> convert back

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 2024-06-23, gene heskett wrote: >> > A attribute the FCC forced on broadcasters as they like to see > transmitter logs kept in 24 hour time. I got so used to it that when I > retired in 2002, I'd been on 24 hour time for 40 years and didn't > convert back to two 12 hour periods a day. The

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sun 23 Jun 2024 at 08:41:51 (-0400), Greg Wooledge wrote: > On Sat, Jun 22, 2024 at 23:25:43 -0500, David Wright wrote: > > creation of Pacific/Kiritimati (+14:00), which became a press > > story at the start of the new millennium. > > > > $ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date

Re: System time/timezone, was Re: Maximum size .bash_aliases file

Brad Rogers writes: > Due, mainly, to the literacy of the people that moved, rather than any > deliberate choice. That is, spelling was often a 'best guess'. https://en.wikipedia.org/wiki/Webster's_Dictionary#Noah_Webster's_American_Dictionary_of_the_English_Language -- John Hasler

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 2024-06-23, Nicholas Geovanis wrote: > > I think we are losing sight of the fact that all of timekeeping is an > abstraction and over-generalization. Time zones were created to help > regularize railroad schedules over wide areas. Timezones are an abstraction > that permit us to _pretend_ that

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 6/23/24 09:23, e...@gmx.us wrote: On 6/23/24 02:30, gene heskett wrote: A attribute the FCC forced on broadcasters as they like to see transmitter logs kept in 24 hour time. I got so used to it that when I retired in 2002, I'd been on 24 hour time for 40 years and didn't convert back to

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 6/23/24 02:30, gene heskett wrote: A attribute the FCC forced on broadcasters as they like to see transmitter logs kept in 24 hour time. I got so used to it that when I retired in 2002, I'd been on 24 hour time for 40 years and didn't convert back to two 12 hour periods a day. I started

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sat, Jun 22, 2024 at 23:25:43 -0500, David Wright wrote: > creation of Pacific/Kiritimati (+14:00), which became a press > story at the start of the new millennium. > > $ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date > Sun Jun 23 04:24:54 Pacific 2024 > Sun Jun 23 13:09:54 +0845 2024 > $

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sun, 23 Jun 2024 15:35:14 +1000 Keith Bainbridge wrote: Hello Keith, >+14:00?? I've only ever heard of maxima of +/- 12:00. AFAIAC, it was political willy waving, nothing more; To be 'first' into the new millennium. As if that has any cachet whatsoever. -- Regards _ "Valid sig

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sun, 23 Jun 2024 13:01:10 +1000 Keith Bainbridge wrote: Hello Keith, >Not to mention some cultures change how words are spelt: colour, odour, >metres to quote a few. Due, mainly, to the literacy of the people that moved, rather than any deliberate choice. That is, spelling was often a

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 6/23/24 01:35, Keith Bainbridge wrote: On 23/6/24 14:25, David Wright wrote: On Sun 23 Jun 2024 at 12:52:55 (+1000), Keith Bainbridge wrote: Have you ever pondered why the 'international date line' is so convoluted? Only on the odd occasion when an area decides to cross it, for whatever

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Fri, Jun 21, 2024 at 12:18 AM David Wright wrote: > [...] > Well, that's a mouthful. And what am I to call the time that a system > issues using that system default time zone? The kernel clock counts ticks. The ticks are relative to Epoch, which is UTC. Ticks are what you see in t

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 14:25, David Wright wrote: On Sun 23 Jun 2024 at 12:52:55 (+1000), Keith Bainbridge wrote: Have you ever pondered why the 'international date line' is so convoluted? Only on the odd occasion when an area decides to cross it, for whatever reason. Like Samoa recently. And before

Re: System time/timezone, was Re: Maximum size .bash_aliases file

; Yes, they're set as desired. > > So you meant "the same time, but in different time zones". You should > have said that. That's how you and I see them, but a passenger from Bahrain, say, sees things differently. They just want to be directed to a system on Bahraini time, ju

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sun 23 Jun 2024 at 12:52:55 (+1000), Keith Bainbridge wrote: > Have you ever pondered why the 'international date line' is so convoluted? Only on the odd occasion when an area decides to cross it, for whatever reason. Like Samoa recently. And before that, the creation of Pacific/Kiritimati

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 00:53, David Wright wrote: Styles change: there's a tendency in English to evolve towards compound words, sometimes with hyphenation along the way. Not to mention some cultures change how words are spelt: colour, odour, metres to quote a few. But don't fret.Some people

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 12:08, Nicholas Geovanis wrote: On Sat, Jun 22, 2024, 11:02 AM Stefan Monnier > wrote: > Yes, I realise that. The times are being displayed by the gettys, > controlled by the /etc/issue format string.  Jobs are being run > by cron,

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On 23/6/24 01:16, to...@tuxteam.de wrote: Possible. I was happy to forget that I had anything to do with Windows  Especially delving into the registry -- All the best Keith Bainbridge keithr...@gmail.com keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sat, Jun 22, 2024, 11:02 AM Stefan Monnier wrote: > > Yes, I realise that. The times are being displayed by the gettys, > > controlled by the /etc/issue format string. Jobs are being run > > by cron, logs written by rsyslogd, and so on. And the term is … ? > > Maybe there simply isn't such a

Re: Current best practices for system configuration management?

llation. Would be grateful for some advice! I think the "best" answer depends upon the scale of your installation. I have a SOHO network with a dozen or so Debian, Windows, macOS, and iOS clients, a FreeBSD/ZFS CVS, SSH, and Samba server, and a FreeBSD/ZFS backup server. For s

Re: Current best practices for system configuration management?

Hi all, Sorry to resurrect an old-ish thread, but I am facing the exact same task, minus the know-how. Basically I am looking to pre-configure a number of Debian setups - let's say, "server", "laptop" and "PC" - that would contain sets of packages to install (or uninstall), configuration files

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sat, Jun 22, 2024 at 09:52:39 -0500, David Wright wrote: > On Fri 21 Jun 2024 at 07:15:32 (-0400), Greg Wooledge wrote: > > > If I boot up two computers > > > and they display different times, what term is appropriate in your > > > opinion to describe the time displayed? > > > > They're out of

Re: System time/timezone, was Re: Maximum size .bash_aliases file

> Yes, I realise that. The times are being displayed by the gettys, > controlled by the /etc/issue format string. Jobs are being run > by cron, logs written by rsyslogd, and so on. And the term is … ? Maybe there simply isn't such a term. The subject is sufficiently complex/delicate that there

Re: System time/timezone, was Re: Maximum size .bash_aliases file

. > > > > It's a log time ago, but we were a shop with a few pretty knowledgeable > > folks, > > so I guess we first tried something like that. > > There was a Registry Key: > > HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

Re: System time/timezone, was Re: Maximum size .bash_aliases file

one and hasn't specified one itself). > > > On 19/06/2024 11:37, to...@tuxteam.de wrote: > > > Especially that bit with the "system timezone". Reminds me of some > > > remote past, where a system actually had a timezone (and changed its > > > cl

Re: System time/timezone, was Re: Maximum size .bash_aliases file

> > On 20/06/2024 11:52, to...@tuxteam.de wrote: > > [...] > > > Well, that's a mouthful. And what am I to call the time that a system > > issues using that system default time zone? If I boot up two computers > > and they display different times, what term is appro

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Fri 21 Jun 2024 at 07:15:32 (-0400), Greg Wooledge wrote: > On Thu, Jun 20, 2024 at 23:17:42 -0500, David Wright wrote: > > And what am I to call the time that a system > > issues using that system default time zone? > > If you mean the current time translated into that t

Re: RTC, was Re: System time/timezone

On 20/6/24 11:51, Max Nikulin wrote: On 20/06/2024 02:16, Nicholas Geovanis wrote: Servers in data centers don't move around, they just sit there :-) So in my experience servers running anything non-windows have RTC set to local time. That's been on Red Hat/CentOS, Debian, Ubuntu. My

Re: System time/timezone, was Re: Maximum size .bash_aliases file

On Sat, Jun 22, 2024 at 10:22:53AM +0700, Max Nikulin wrote: [...] > I think, you are biased treating "system" as tightly built-in while most of > others assume "system-wide". Taking your bias out ("you are biased" -- "most of others") I'd tend

Re: System time/timezone, was Re: Maximum size .bash_aliases file

appropriate in your opinion do describe the setting stored as the /etc/localtime symlink? localtime(5) The default time zone (i.e. that one which is used when some process calls for one and hasn't specified one itself). So you just believe that "system" is confusing. However other co

  1   2   3   4   5   6   7   8   9   10   >