Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.advocacy > #680043 > unrolled thread

MacOS Sequoia vs. Linux Mint

Back to article view | Back to comp.os.linux.advocacy

Contents

  MacOS Sequoia vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-13 15:40 +0000
    Re: MacOS Sequoia vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-13 21:56 +0000
      Re: MacOS Sequoia vs. Linux Mint -hh <recscuba_google@huntzinger.com> - 2024-12-14 10:31 -0500
        Re: MacOS Sequoia vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-15 01:01 +0000
    Re: MacOS Sequoia vs. Linux Mint DFS <guhnoo-basher@linux.advocaca> - 2024-12-13 22:07 -0500
      Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 05:39 +0000
        Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-14 08:10 -0500
          Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-14 16:09 +0000
          Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:18 +0000
            Re: MacOS Sequoia vs. Linux Mint Stéphane CARPENTIER <sc@fiat-linux.fr> - 2024-12-14 22:37 +0000
            Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:53 -0500
              Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-15 22:28 +0000
                Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 20:04 -0500
                  Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 06:42 +0000
                    Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-16 10:38 -0500
                      Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 22:28 +0000
                        Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 18:21 -0500
                          Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-19 07:14 +0000
                            Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 08:52 -0500
            Re: MacOS Sequoia vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-15 11:21 -0500
              Re: MacOS Sequoia vs. Linux Mint -hh <recscuba_google@huntzinger.com> - 2024-12-15 15:36 -0500
                Re: MacOS Sequoia vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-15 21:02 +0000
                Re: MacOS Sequoia vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-16 07:21 -0500
                  Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-16 11:10 -0500
                    Re: MacOS Sequoia vs. Linux Mint chrisv <chrisv@nospam.invalid> - 2024-12-17 22:09 -0600
        Re: MacOS Sequoia vs. Linux Mint DFS <guhnoo-basher@linux.advocaca> - 2024-12-14 10:31 -0500
          Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:22 +0000
            Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:58 -0500
        Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-14 15:59 +0000
        Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-14 19:53 +0000
          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:40 -0500
      Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-14 05:43 +0000
        Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-14 08:15 -0500
          Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-14 16:14 +0000
            Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-14 19:57 +0000
              Re: MacOS Sequoia vs. Linux Mint Joel <joelcrump@gmail.com> - 2024-12-14 15:06 -0500
                Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-15 00:06 +0000
                  Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-15 07:45 +0000
                Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:48 -0500
              Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-15 07:29 +0000
                Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-15 08:43 +0000
                  Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-16 10:30 +0000
            Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:13 -0500
              Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-16 10:33 +0000
                Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-16 20:18 +0000
                  Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-17 08:26 +0000
              Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 22:29 +0000
                Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 18:21 -0500
                Re: MacOS Sequoia vs. Linux Mint Joel <joelcrump@gmail.com> - 2024-12-17 19:22 -0500
                  Re: MacOS Sequoia vs. Linux Mint DFS <guhnoo-basher@linux.advocaca> - 2024-12-17 19:37 -0500
                    Re: MacOS Sequoia vs. Linux Mint Joel <joelcrump@gmail.com> - 2024-12-17 20:23 -0500
                      Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 20:36 -0500
                        Re: MacOS Sequoia vs. Linux Mint pothead <pothead@snakebite.com> - 2024-12-18 01:54 +0000
                          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 21:22 -0500
                    Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 20:34 -0500
                    Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-18 03:24 +0000
                      Re: MacOS Sequoia vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-18 08:24 -0500
                        Re: MacOS Sequoia vs. Linux Mint chrisv <chrisv@nospam.invalid> - 2024-12-19 18:37 -0600
                          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 20:12 -0500
                            Re: MacOS Sequoia vs. Linux Mint pothead <pothead@snakebite.com> - 2024-12-20 01:26 +0000
                            Re: MacOS Sequoia vs. Linux Mint DFS <guhnoo-basher@linux.advocaca> - 2024-12-20 09:25 -0500
                              Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-20 10:23 -0500
                    Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-19 07:14 +0000
                      Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 08:52 -0500
                  Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-17 20:32 -0500
                    Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-19 04:43 +0000
                      Re: MacOS Sequoia vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-19 07:58 -0500
                        Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 09:04 -0500
                        Re: MacOS Sequoia vs. Linux Mint DFS <guhnoo-basher@linux.advocaca> - 2024-12-19 11:25 -0500
                          Re: MacOS Sequoia vs. Linux Mint Joel <joelcrump@gmail.com> - 2024-12-19 11:50 -0500
                            Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 12:26 -0500
                            Re: MacOS Sequoia vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-19 13:39 -0500
                          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 12:21 -0500
                            Re: MacOS Sequoia vs. Linux Mint chrisv <chrisv@nospam.invalid> - 2024-12-19 13:53 -0600
                              Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 17:14 -0500
                      Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-19 08:48 -0500
      Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-14 08:01 -0500
        Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-14 16:21 +0000
          Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-14 16:54 +0000
          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:15 -0500
            Re: MacOS Sequoia vs. Linux Mint Stéphane CARPENTIER <sc@fiat-linux.fr> - 2024-12-15 13:47 +0000
              Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 10:27 -0500
            Re: MacOS Sequoia vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 05:46 +0000
            Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-16 10:37 +0000
              Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-16 11:04 -0500
                Re: MacOS Sequoia vs. Linux Mint RonB <ronb02NOSPAM@gmail.com> - 2024-12-17 08:22 +0000
        Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-14 20:01 +0000
          Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 08:43 -0500
            Re: MacOS Sequoia vs. Linux Mint Stéphane CARPENTIER <sc@fiat-linux.fr> - 2024-12-15 14:05 +0000
            Re: MacOS Sequoia vs. Linux Mint rbowman <bowman@montana.com> - 2024-12-15 18:23 +0000
              Re: MacOS Sequoia vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-15 14:56 -0500

Page 1 of 5  [1] 2 3 4 5  Next page →

#680043 — MacOS Sequoia vs. Linux Mint

So upgraded the Mac Studio to Sequoia:

$ uname -a
Darwin Mac 24.2.0 Darwin Kernel Version 24.2.0: 
Fri Dec  6 18:56:34 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6020 arm64

After the initial upgrade from Sonoma, it still had updates
to apply.  This took a while, and included the need for
another reboot -- all to update some xcode crap.

It's a lot easier to update Linux than Windows or MacOS.  Why
it would be such a pain for MacOS to do a simple update, I can
only guess at.

(I suspect it may be that MacOS doesn't have a facility
with the simplicity of Linux's ldconfig(8) for updating
shared libraries.)

Also:

_[/Users/scott/path_max]_(scott@Mac)🍏_
$ make use_pathconf
cc -g -O2 -std=c90 -Wall -Werror -pedantic    use_pathconf.c   -o use_pathconf
_[/Users/scott/path_max]_(scott@Mac)🍏_
$ ./use_pathconf
1024

It's still 1/4 that of Linux.

Although, I did run a find(1) on my fileserver for long pathnames, and
found that the longest was 359 characters...so MacOS would be fine with
that.  Windows?  Not so sure.

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.4 Release: Mint 21.3 Mem: 258G
   "Friends come and go, enemies accumulate."

[toc] | [next] | [standalone]

#680096

On 13 Dec 2024 15:40:28 GMT, vallor <vallor@cultnix.org> wrote in
<ls32rcFprp3U1@mid.individual.net>:

> So upgraded the Mac Studio to Sequoia:
> 
> $ uname -a
> Darwin Mac 24.2.0 Darwin Kernel Version 24.2.0: 
> Fri Dec  6 18:56:34 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6020 arm64
> 
> After the initial upgrade from Sonoma, it still had updates
> to apply.  This took a while, and included the need for
> another reboot -- all to update some xcode crap.
> 
> It's a lot easier to update Linux than Windows or MacOS.  Why
> it would be such a pain for MacOS to do a simple update, I can
> only guess at.
> 
> (I suspect it may be that MacOS doesn't have a facility
> with the simplicity of Linux's ldconfig(8) for updating
> shared libraries.)
> 
> Also:
> 
> _[/Users/scott/path_max]_(scott@Mac)🍏_
> $ make use_pathconf
> cc -g -O2 -std=c90 -Wall -Werror -pedantic    use_pathconf.c   -o use_pathconf
> _[/Users/scott/path_max]_(scott@Mac)🍏_
> $ ./use_pathconf
> 1024
> 
> It's still 1/4 that of Linux.
> 
> Although, I did run a find(1) on my fileserver for long pathnames, and
> found that the longest was 359 characters...so MacOS would be fine with
> that.  Windows?  Not so sure.

Went to add a static route to another segment of my network, and
couldn't find a way to do it while keeping the dhcp setup.  In order
to add a persistent route, I had to drop to the command line and
run networksetup(8) with the proper incantation.  Now I can ping
my file server.

Next, I tried to add a time machine backup destination, but there's
no way to add one by IP address from the gui.  Was going to try
to set one up with tmutil(8), but realized I should instead set
up an MDNS reflector on the router.  After that, the Mac Studio saw
the file server in the time machine tool, and everything followed from
that.

The file server runs Linux:

Linux DT 3.10.108 #42962 SMP Mon Aug 19 15:14:28 CST 2024
armv7l GNU/Linux synology_alpine_ds2015xs

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.4 Release: Mint 21.3 Mem: 258G
   "If there's one thing I can't stand, it's intolerance."

[toc] | [prev] | [next] | [standalone]

#680179

On 12/13/24 4:56 PM, vallor wrote:
> On 13 Dec 2024 15:40:28 GMT, vallor <vallor@cultnix.org> wrote in
> <ls32rcFprp3U1@mid.individual.net>:
> 
>> So upgraded the Mac Studio to Sequoia:
>>
>> $ uname -a
>> Darwin Mac 24.2.0 Darwin Kernel Version 24.2.0:
>> Fri Dec  6 18:56:34 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6020 arm64
>>
>> After the initial upgrade from Sonoma, it still had updates
>> to apply.  This took a while, and included the need for
>> another reboot -- all to update some xcode crap.
>>
>> It's a lot easier to update Linux than Windows or MacOS.  Why
>> it would be such a pain for MacOS to do a simple update, I can
>> only guess at.

Perhaps because you're DIYing it from the command line instead of using 
the GUI?

For the latter, system can auto-update, whereupon you just get a 
notification of "do it tonight, or install now?" whereupon the click 
will take you to a license agreement to click and off it goes.

Of course, one will need to remember to not have open/unsaved files 
which will automatically prevent data loss by pausing any reboots 
if/when merited.

>> (I suspect it may be that MacOS doesn't have a facility
>> with the simplicity of Linux's ldconfig(8) for updating
>> shared libraries.)

Of course, when stuff gets updated in the background overnight, why 
should it bother one if an update takes an extra 15 minutes?

>> Also:
>>
>> _[/Users/scott/path_max]_(scott@Mac)🍏_
>> $ make use_pathconf
>> cc -g -O2 -std=c90 -Wall -Werror -pedantic    use_pathconf.c   -o use_pathconf
>> _[/Users/scott/path_max]_(scott@Mac)🍏_
>> $ ./use_pathconf
>> 1024
>>
>> It's still 1/4 that of Linux.
>>
>> Although, I did run a find(1) on my fileserver for long pathnames, and
>> found that the longest was 359 characters...so MacOS would be fine with
>> that.  Windows?  Not so sure.
> 
> Went to add a static route to another segment of my network, and
> couldn't find a way to do it while keeping the dhcp setup.  In order
> to add a persistent route, I had to drop to the command line and
> run networksetup(8) with the proper incantation.  Now I can ping
> my file server.

Sounds odd; I can assign static IPs on my router to individual devices 
as I want.  Of course, that's different from what comes next:

> Next, I tried to add a time machine backup destination, but there's
> no way to add one by IP address from the gui.  

Sure, because the GUI is the mainstream solution, and it leverages a 20 
year old zeroconf technology (eg. Bonjour).  That facilitates using DHCP 
instead of needing to plug in Static IP assignments.  Of course, you're 
free to do things the old fashioned & harder way if you so desire.


> Was going to try
> to set one up with tmutil(8), but realized I should instead set
> up an MDNS reflector on the router.  After that, the Mac Studio saw
> the file server in the time machine tool, and everything followed from
> that.

Sounds like some subdomain/VPN isolations were doing what they were 
supposed to do, so adding the MDNS reflector was to circumvent?


> The file server runs Linux:
> 
> Linux DT 3.10.108 #42962 SMP Mon Aug 19 15:14:28 CST 2024
> armv7l GNU/Linux synology_alpine_ds2015xs

IIRC, same.


-hh

[toc] | [prev] | [next] | [standalone]

#680266

On Sat, 14 Dec 2024 10:31:16 -0500, -hh <recscuba_google@huntzinger.com>
wrote in <vjk8c4$6us$3@dont-email.me>:

> On 12/13/24 4:56 PM, vallor wrote:
>> On 13 Dec 2024 15:40:28 GMT, vallor <vallor@cultnix.org> wrote in
>> <ls32rcFprp3U1@mid.individual.net>:
>> 
>>> So upgraded the Mac Studio to Sequoia:
>>>
>>> $ uname -a
>>> Darwin Mac 24.2.0 Darwin Kernel Version 24.2.0:
>>> Fri Dec  6 18:56:34 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6020 arm64
>>>
>>> After the initial upgrade from Sonoma, it still had updates
>>> to apply.  This took a while, and included the need for
>>> another reboot -- all to update some xcode crap.
>>>
>>> It's a lot easier to update Linux than Windows or MacOS.  Why
>>> it would be such a pain for MacOS to do a simple update, I can
>>> only guess at.
> 
> Perhaps because you're DIYing it from the command line instead of using 
> the GUI?

Nope, did that all from the gui.

> 
> For the latter, system can auto-update, whereupon you just get a 
> notification of "do it tonight, or install now?" whereupon the click 
> will take you to a license agreement to click and off it goes.
> 
> Of course, one will need to remember to not have open/unsaved files 
> which will automatically prevent data loss by pausing any reboots 
> if/when merited.

What I'd like is for it to download the updates and have them ready
for such an action.  But it _still_ took an inordinate amount of time
to update.  (I didn't complain about the update from Sonoma to Sequoia
because I would expect that to take a while -- it's the extra update
afterwards that I was complaining about.)

> 
>>> (I suspect it may be that MacOS doesn't have a facility
>>> with the simplicity of Linux's ldconfig(8) for updating
>>> shared libraries.)
> 
> Of course, when stuff gets updated in the background overnight, why 
> should it bother one if an update takes an extra 15 minutes?
> 
>>> Also:
>>>
>>> _[/Users/scott/path_max]_(scott@Mac)🍏_
>>> $ make use_pathconf
>>> cc -g -O2 -std=c90 -Wall -Werror -pedantic    use_pathconf.c   -o use_pathconf
>>> _[/Users/scott/path_max]_(scott@Mac)🍏_
>>> $ ./use_pathconf
>>> 1024
>>>
>>> It's still 1/4 that of Linux.
>>>
>>> Although, I did run a find(1) on my fileserver for long pathnames, and
>>> found that the longest was 359 characters...so MacOS would be fine with
>>> that.  Windows?  Not so sure.
>> 
>> Went to add a static route to another segment of my network, and
>> couldn't find a way to do it while keeping the dhcp setup.  In order
>> to add a persistent route, I had to drop to the command line and
>> run networksetup(8) with the proper incantation.  Now I can ping
>> my file server.
> 
> Sounds odd; I can assign static IPs on my router to individual devices 
> as I want.

Not related.  The SAN segment is a 10G wired network behind my Linux
workstation -- different /24 network.  The most straightforward way
to tell the Mac Studio about how to get to that network is a static
route.  If the dhcp server were more configurable, there is a dhcp
option to add a route -- but I'm not that lucky to have a smarter
dhcp server.


>  Of course, that's different from what comes next:
> 
>> Next, I tried to add a time machine backup destination, but there's
>> no way to add one by IP address from the gui.  
> 
> Sure, because the GUI is the mainstream solution, and it leverages a 20 
> year old zeroconf technology (eg. Bonjour).  That facilitates using DHCP 
> instead of needing to plug in Static IP assignments.  Of course, you're 
> free to do things the old fashioned & harder way if you so desire.

The reflector is tying together both broadcast domains.  That _is_ the
easy way to do it -- the "hard" way would be to try to set up the destination
with tmutil(8) from the command line.  On the Linux workstation, all I had
to do is modify avahi-daemon.conf with "enable-reflector=yes" and restart
the service -- after that, the Studio could see the Time Machine broacast[*].

> 
> 
>> Was going to try
>> to set one up with tmutil(8), but realized I should instead set
>> up an MDNS reflector on the router.  After that, the Mac Studio saw
>> the file server in the time machine tool, and everything followed from
>> that.
> 
> Sounds like some subdomain/VPN isolations were doing what they were 
> supposed to do, so adding the MDNS reflector was to circumvent?

Two different broadcast[*] domains, so the Mac Studio side wasn't seeing
the Time Machine broadcasts until I enabled the reflection.

[*] Actually, it's multicast, but same idea.

>> The file server runs Linux:
>> 
>> Linux DT 3.10.108 #42962 SMP Mon Aug 19 15:14:28 CST 2024
>> armv7l GNU/Linux synology_alpine_ds2015xs
> 
> IIRC, same.

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.4 Release: Mint 21.3 Mem: 258G
   "Put on your seatbelt. I'm gonna try something new."

[toc] | [prev] | [next] | [standalone]

#680124

On 12/13/2024 10:40 AM, vallor wrote:

> It's a lot easier to update Linux than Windows or MacOS.


Maybe, maybe not.

The massive update to Win11 24H2 was a few mouse clicks.  Absolutely no 
other user input was required.

[toc] | [prev] | [next] | [standalone]

#680130

On Fri, 13 Dec 2024 22:07:11 -0500, DFS wrote:

> The massive update to Win11 24H2 was a few mouse clicks.

Over how many hours?

[toc] | [prev] | [next] | [standalone]

#680153

Le 2024-12-14 à 00:39, Lawrence D'Oliveiro a écrit :
> On Fri, 13 Dec 2024 22:07:11 -0500, DFS wrote:
> 
>> The massive update to Win11 24H2 was a few mouse clicks.
> 
> Over how many hours?

It was probably much longer, but here is a fact you can't deny: when 
Microsoft or Apple offer a large update like 24H2, they essentially 
reinstall the operating system, make sure that existing software and 
settings are properly transferred over and clean up whatever garbage the 
previous installation had to provide a decent out-of-the-box experience. 
When Linux does a big update, like an update after two weeks of not 
using your computer, it basically just overwrites whatever is there and 
hopes for the best. It might check a few things along the way to make 
sure that it all works alright, but you often end up with broken 
dependencies or configurations which require you to fix the system in 
one way or another. Taking this into consideration, any smart human 
being that's used both operating systems would rather the cleanup of 
either Microsoft or Apple than the potential breakdown of Linux.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680198

On 2024-12-14, CrudeSausage <crude@sausa.ge> wrote:
> Le 2024-12-14 à 00:39, Lawrence D'Oliveiro a écrit :
>> On Fri, 13 Dec 2024 22:07:11 -0500, DFS wrote:
>> 
>>> The massive update to Win11 24H2 was a few mouse clicks.
>> 
>> Over how many hours?
>
> It was probably much longer, but here is a fact you can't deny: when 
> Microsoft or Apple offer a large update like 24H2, they essentially 
> reinstall the operating system, make sure that existing software and 
> settings are properly transferred over and clean up whatever garbage the 
> previous installation had to provide a decent out-of-the-box experience. 
> When Linux does a big update, like an update after two weeks of not 
> using your computer, it basically just overwrites whatever is there and 
> hopes for the best. It might check a few things along the way to make 
> sure that it all works alright, but you often end up with broken 
> dependencies or configurations which require you to fix the system in 
> one way or another. Taking this into consideration, any smart human 
> being that's used both operating systems would rather the cleanup of 
> either Microsoft or Apple than the potential breakdown of Linux.

The biggest difference between  Linux and Windows' updates is that the 
Linux updates work but there's always a chance that the Windows' update will 
cause a BSOD. I've used Linux for about 18 years. Never once has an update 
caused a system failure — and I've had old computers that I didn't update 
for over a year.

To me the huge update (instead of a number of small ones, like Linux uses) 
is just asking for trouble. And after two weeks, Linux doesn't have "huge" 
updates. As mentioned above, I've gone much longer than two weeks and 
updates still take less than a couple minutes. Linux is definitely superior 
in how it updates. Not even close for Windows. This is one of the main 
reasons I like Linux.

-- 
“Evil is not able to create anything new, it can only distort and destroy 
what has been invented or made by the forces of good.”  —J.R.R. Tolkien

[toc] | [prev] | [next] | [standalone]

#680241

On Sat, 14 Dec 2024 08:10:54 -0500, CrudeSausage wrote:

> When Linux does a big update, like an update after two weeks of not
> using your computer, it basically just overwrites whatever is there and
> hopes for the best.

Remember that Linux distros like Debian have integrated package 
management. That means there is no “hope for the best” -- it knows exactly 
what is currently there, what needs to be removed, what needs to be 
updated, and what needs to be added.

This is why you don’t even need to do a reboot if it is sufficient to 
simply stop and start the affected services.

[toc] | [prev] | [next] | [standalone]

#680248

Le 14-12-2024, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
>
> Remember that Linux distros like Debian have integrated package 
> management. That means there is no “hope for the best” -- it knows exactly 
> what is currently there, what needs to be removed, what needs to be 
> updated, and what needs to be added.

Tell that to LP/FR/NV/whatever who can't update a simple tool like
Midnight Commander without breaking it.

> This is why you don’t even need to do a reboot if it is sufficient to 
> simply stop and start the affected services.

It's not that right. I don't reboot after most of my updates, but when
the kernel is updated, without a reboot, some things, like plugging an
usb device, don't work. Maybe I would be able to fix it without a reboot,
but the reboot is faster than any time I would need to investigate. So
for me, the best way is to refuse updates, if they include the kernel
updates, before shutting down my computer.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#680317

Le 2024-12-14 à 17:18, Lawrence D'Oliveiro a écrit :
> On Sat, 14 Dec 2024 08:10:54 -0500, CrudeSausage wrote:
> 
>> When Linux does a big update, like an update after two weeks of not
>> using your computer, it basically just overwrites whatever is there and
>> hopes for the best.
> 
> Remember that Linux distros like Debian have integrated package
> management. That means there is no “hope for the best” -- it knows exactly
> what is currently there, what needs to be removed, what needs to be
> updated, and what needs to be added.
> 
> This is why you don’t even need to do a reboot if it is sufficient to
> simply stop and start the affected services.

And yet people complain about broken Debian installs all the time anyway:

<https://www.ninjaone.com/blog/how-to-fix-broken-debian-packages/> or 
<https://www.howtogeek.com/how-to-fix-broken-packages-on-linux/>

Go lie to someone else.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680428

On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:

> And yet people complain about broken Debian installs all the time
> anyway:

I speak from personal experience from successfully doing lots of Debian 
installs, for myself and for paying customers.

[toc] | [prev] | [next] | [standalone]

#680446

Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
> 
>> And yet people complain about broken Debian installs all the time
>> anyway:
> 
> I speak from personal experience from successfully doing lots of Debian
> installs, for myself and for paying customers.

Meanwhile, I still don't believe you for many good reasons.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680467

On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:

> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>
>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>> 
>>> And yet people complain about broken Debian installs all the time
>>> anyway:
>> 
>> I speak from personal experience from successfully doing lots of Debian
>> installs, for myself and for paying customers.
> 
> Meanwhile, I still don't believe you for many good reasons.

Windows does that to you, doesn’t it: degrades your ability to distinguish 
truth from fiction. Comes from believing too much Microsoft propaganda.

[toc] | [prev] | [next] | [standalone]

#680483

Le 2024-12-16 à 01:42, Lawrence D'Oliveiro a écrit :
> On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:
> 
>> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>>
>>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>>>
>>>> And yet people complain about broken Debian installs all the time
>>>> anyway:
>>>
>>> I speak from personal experience from successfully doing lots of Debian
>>> installs, for myself and for paying customers.
>>
>> Meanwhile, I still don't believe you for many good reasons.
> 
> Windows does that to you, doesn’t it: degrades your ability to distinguish
> truth from fiction. Comes from believing too much Microsoft propaganda.

I've purposefully disregarded your previous post because I figured you 
would write something like this here. I'll just say this much about your 
statement about truth and Linux, especially when relating NVIDIA GPUs:

Let me know when Linux can reliably wake a machine equipped with an 
NVIDIA GPU from sleep.

I'm looking forward to your barrage of lies.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680645

On Mon, 16 Dec 2024 10:38:19 -0500, CrudeSausage wrote:

> Le 2024-12-16 à 01:42, Lawrence D'Oliveiro a écrit :
>
>> On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:
>> 
>>> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>>>
>>>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>>>>
>>>>> And yet people complain about broken Debian installs all the time
>>>>> anyway:
>>>>
>>>> I speak from personal experience from successfully doing lots of
>>>> Debian installs, for myself and for paying customers.
>>>
>>> Meanwhile, I still don't believe you for many good reasons.
>> 
>> Windows does that to you, doesn’t it: degrades your ability to
>> distinguish truth from fiction. Comes from believing too much Microsoft
>> propaganda.
> 
> ... especially when relating NVIDIA GPUs ...

Which you neglected to mention when claiming I was somehow not credible 
about doing successful Debian installs.

[toc] | [prev] | [next] | [standalone]

#680658

Le 2024-12-17 à 17:28, Lawrence D'Oliveiro a écrit :
> On Mon, 16 Dec 2024 10:38:19 -0500, CrudeSausage wrote:
> 
>> Le 2024-12-16 à 01:42, Lawrence D'Oliveiro a écrit :
>>
>>> On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:
>>>
>>>> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>>>>
>>>>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>>>>>
>>>>>> And yet people complain about broken Debian installs all the time
>>>>>> anyway:
>>>>>
>>>>> I speak from personal experience from successfully doing lots of
>>>>> Debian installs, for myself and for paying customers.
>>>>
>>>> Meanwhile, I still don't believe you for many good reasons.
>>>
>>> Windows does that to you, doesn’t it: degrades your ability to
>>> distinguish truth from fiction. Comes from believing too much Microsoft
>>> propaganda.
>>
>> ... especially when relating NVIDIA GPUs ...
> 
> Which you neglected to mention when claiming I was somehow not credible
> about doing successful Debian installs.

We were talking about updating, not installing. It's hard to imagine 
someone getting a routine install of Debian wrong but easy to imagine 
that same install breaking from a routine update.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680761

On Tue, 17 Dec 2024 18:21:05 -0500, CrudeSausage wrote:

> Le 2024-12-17 à 17:28, Lawrence D'Oliveiro a écrit :
>> On Mon, 16 Dec 2024 10:38:19 -0500, CrudeSausage wrote:
>> 
>>> Le 2024-12-16 à 01:42, Lawrence D'Oliveiro a écrit :
>>>
>>>> On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:
>>>>
>>>>> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>>>>>
>>>>>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>>>>>>
>>>>>>> And yet people complain about broken Debian installs all the time
>>>>>>> anyway:
>>>>>>
>>>>>> I speak from personal experience from successfully doing lots of
>>>>>> Debian installs, for myself and for paying customers.
>>>>>
>>>>> Meanwhile, I still don't believe you for many good reasons.
>>>>
>>>> Windows does that to you, doesn’t it: degrades your ability to
>>>> distinguish truth from fiction. Comes from believing too much
>>>> Microsoft propaganda.
>>>
>>> ... especially when relating NVIDIA GPUs ...
>> 
>> Which you neglected to mention when claiming I was somehow not credible
>> about doing successful Debian installs.
> 
> We were talking about updating, not installing.

Really? You said “installs” above.

[toc] | [prev] | [next] | [standalone]

#680784

Le 2024-12-19 à 02:14, Lawrence D'Oliveiro a écrit :
> On Tue, 17 Dec 2024 18:21:05 -0500, CrudeSausage wrote:
> 
>> Le 2024-12-17 à 17:28, Lawrence D'Oliveiro a écrit :
>>> On Mon, 16 Dec 2024 10:38:19 -0500, CrudeSausage wrote:
>>>
>>>> Le 2024-12-16 à 01:42, Lawrence D'Oliveiro a écrit :
>>>>
>>>>> On Sun, 15 Dec 2024 20:04:58 -0500, CrudeSausage wrote:
>>>>>
>>>>>> Le 2024-12-15 à 17:28, Lawrence D'Oliveiro a écrit :
>>>>>>
>>>>>>> On Sun, 15 Dec 2024 08:53:32 -0500, CrudeSausage wrote:
>>>>>>>
>>>>>>>> And yet people complain about broken Debian installs all the time
>>>>>>>> anyway:
>>>>>>>
>>>>>>> I speak from personal experience from successfully doing lots of
>>>>>>> Debian installs, for myself and for paying customers.
>>>>>>
>>>>>> Meanwhile, I still don't believe you for many good reasons.
>>>>>
>>>>> Windows does that to you, doesn’t it: degrades your ability to
>>>>> distinguish truth from fiction. Comes from believing too much
>>>>> Microsoft propaganda.
>>>>
>>>> ... especially when relating NVIDIA GPUs ...
>>>
>>> Which you neglected to mention when claiming I was somehow not credible
>>> about doing successful Debian installs.
>>
>> We were talking about updating, not installing.
> 
> Really? You said “installs” above.

Yep, installs = installed operating systems. Their _installs_ stopped 
working correctly after routine updates.

-- 
CrudeSausage

[toc] | [prev] | [next] | [standalone]

#680346

Lawrence D'Oliveiro wrote this post while blinking in Morse code:

> On Sat, 14 Dec 2024 08:10:54 -0500, CrudeSausage wrote:
>
>> When Linux does a big update, like an update after two weeks of not
>> using your computer, it basically just overwrites whatever is there and
>> hopes for the best.
>
> Remember that Linux distros like Debian have integrated package 
> management. That means there is no “hope for the best” -- it knows exactly 
> what is currently there, what needs to be removed, what needs to be 
> updated, and what needs to be added.
>
> This is why you don’t even need to do a reboot if it is sufficient to 
> simply stop and start the affected services.

The aptiude front-end for apt might detect an issue with versions. You can then
examine the issue and see a list of one or more solutions; you can then pick
the solution you want.  And in a few days, that issue will likely be gone
anyway.

-- 
Support your right to arm bears!!

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.os.linux.advocacy

csiph-web