[HN Gopher] Rsync replaced with openrsync on macOS Sequoia
___________________________________________________________________
Rsync replaced with openrsync on macOS Sequoia
Author : zdw
Score : 67 points
Date : 2025-04-06 21:14 UTC (1 hours ago)
(HTM) web link (derflounder.wordpress.com)
(TXT) w3m dump (derflounder.wordpress.com)
| ndegruchy wrote:
| Huh, interesting. I hadn't noticed when I upgraded, but I don't
| use many of the features of `rsync` to begin with. I ended up
| installing the real `rsync` shortly thereafter.
| jethro_tell wrote:
| Why?
| wewewedxfgdf wrote:
| Good - MacOS had an old and crappy version of rsync
| dima55 wrote:
| MacOS sounds like it's not very good
| modeless wrote:
| It's really not. The hardware is so good that I put up with
| it, but it is a bad OS in so many ways. My dream laptop would
| be a MacBook with a normal keyboard layout and running a well
| supported version of Linux.
| mrlonglong wrote:
| They already do. Asahi Linux.
| goosedragons wrote:
| Still missing a bunch of features like USB-C displays.
| Isn't ready for newer CPUs yet either.
| jbverschoor wrote:
| cli? Just run orbstack..
| wenc wrote:
| macOS is a BSD.
|
| If you're used to Linux (I am) it feels there are lots of
| quality of life changes, but I realized it's because I'm
| used to Linux.
|
| The OS itself is fine.
| rbanffy wrote:
| It's adequate. You can use MacPorts to install a more modern
| Unix environment.
|
| Much better than Windows.
| ndegruchy wrote:
| Eh, I swap between the big three every day and they're all
| terrible in their own unique manners. macOS certainly has
| problems, and Apple's adversarial relationship with open
| source is not helping anything, but I wouldn't call macOS
| _bad_ , just not suited for everyone's needs.
| dghlsakjg wrote:
| Why?
|
| This is an included package from a 3rd party that was kept at
| a previous version for licensing reasons.
|
| If you want the latest version of rsync, you can just install
| it.
|
| Are you upset that MacOs doesn't include a copy of Libre
| Office, or every other bit of 3rd party software?
| duskwuff wrote:
| On one hand, it's a little annoying that openrsync doesn't
| support some features that rsync does.
|
| On the other hand, it's _great_ that there are multiple
| independent implementations of rsync now. It means that it 's
| actually being treated as a protocol, not just a piece of
| software.
| chungy wrote:
| The website says "We are still working on it... so please
| wait."
|
| rsync has a lot of features, surely this will take a good
| amount of time.
| varenc wrote:
| I'm exciting about this too. It becoming more like a protocol
| makes me optimistic we'll see binary diff API points based on
| the rsync algorithm.
|
| fun fact: Dropbox internally used rsync binary diff to quickly
| upload small changes to large file. I assume they still do. But
| their public API endpoints don't offer this and a small change
| to a large file means the whole file must be updated.
| andrewflnr wrote:
| > binary diff API points based on the rsync algorithm
|
| Now that's an idea I never considered. Nice.
| zmj wrote:
| I implemented rsync's binary diff/patch in .NET several years
| ago: https://github.com/zmj/rsync-delta
|
| It's a decent protocol, but it has shortcomings. I'd expect
| most future use cases for that kind of thing to reach for a
| content-defined chunking algorithm tuned towards their common
| file formats and sizes.
| candiddevmike wrote:
| How does this mean rsync is a protocol?
| bombela wrote:
| Think ssh, http etc
| jeroenhd wrote:
| So, anyone got a good resource on why Apple is so afraid of
| GPLv3? Surely this shouldn't be a problem as long as they
| statically compile the executables?
| banqjls wrote:
| The TiVo clause.
| rbanffy wrote:
| It wouldn't apply to the kernel. Also, a lot of the command
| line tools are not distributed as part of the OS.
| jhasse wrote:
| They want to damage the reputation of the GPLv3 to reduce
| the chances of it ever being used in anything were the
| clause would make a difference.
|
| They are evil basically.
| Arnt wrote:
| Apple doesn't say. IMO you should not trust other people's
| statements about Apple's reasoning.
| ndegruchy wrote:
| In all likelihood they just don't want to broach the idea of
| having to fight (and potentially lose) the GPL3 in court. Given
| the case history on the GPL2, it seems like more work than it's
| worth. They can just replace the parts that are "problematic"
| in their eyes and avoid a whole class of issues.
| Aurornis wrote:
| My perspective on GPL and related licenses changed a lot after
| working with lawyers on the topic. Some of the things I thought
| to be completely safe were not as definitive to the lawyers.
|
| I don't know Apple's reasoning, but I know that choosing non-
| GPL licenses when available was one of the guiding principals
| given to us by corporate lawyers at another company.
| cosmic_cheese wrote:
| A lot of it is indeed the legal murkiness.
|
| On the engineering level, other liceneses likely get selected
| because it's easy. You don't need to consult the legal
| department to know how to comply with licenses like MIT, BSD,
| etc, so you just pull the thing in, make any required
| attributions, and continue on with your day. It's a lot less
| friction, which is extremely attractive.
| KerrAvon wrote:
| Yes, although even for the more liberal licenses you
| actually still want legal review at a sufficiently large
| company to ensure that your engineering read of the license
| is accurate. What if someone changed the wording slightly
| in some way that turns out to be legally significant, etc.
| cosmic_cheese wrote:
| That might apply in a handful of cases, but the vast
| majority will check out when a quick diff against a
| reference license file shows that the only changes are
| party names.
| KerrAvon wrote:
| I think it's very unlikely to happen, in general. I'm
| just saying a large corporation will want to check every
| time because they cannot really afford to do otherwise.
| palata wrote:
| > but I know that choosing non-GPL licenses when available
| was one of the guiding principals
|
| Sure, but in this case Apple has chosen, for _20 years_ , to
| not go with GPLv3 when there was no alternative.
| giantrobot wrote:
| This was basically the justification I was told when I was at
| Apple. The GPLv3 is too viral for the liking of Apple's legal
| department. They do not want to be the test case for the
| license.
| quotemstr wrote:
| The funny thing is that the rest of the world has moved on
| and is no longer afraid of the GPLv3. The reality that
| people aren't, as Apple's legal people predicted, being
| legally obliterated hasn't changed Apple legal's stance.
| Doomsday cults actually get stronger when doomsday fails to
| drive.
| ninkendo wrote:
| GPL3 closes what was considered a loophole, where device makers
| would ship a product derived from GPL'd code, and release the
| source, but provide no ability for users to actually compile
| and run that source on the device (this was called "tivo-
| ization" at the time, because TiVo did it.)
|
| So for iOS, it's pretty obvious why they don't use gplv3...
| because it would violate the terms.
|
| For macOS they could certainly get away with shipping gplv3
| code, but they do a lot of code sharing between iOS and macOS
| (and watchOS/tvOS/visionOS/etc) and it doesn't make much sense
| to build on a gplv3 foundation for just one of these operating
| systems and not the others. So it's simpler to just not use it
| at all.
|
| It also means they're more free to lock down macOS from running
| your own code on it in the future, without worrying about
| having to rip out all the gpl3 code when it happens. Better to
| just not build on it in the first place.
| KerrAvon wrote:
| No, this doesn't quite scan, because there's no reason they
| couldn't ship a current of `bash` or any number of other GPL3
| things. Aurornis is probably closest to the mark: it is
| legally ambiguous, and Apple probably does not want to be a
| test case for GPL3 compliance.
| ninkendo wrote:
| If they shipped a gpl3 version of bash _on iOS_ , they
| would be in violation. This isn't really a question: gpl3
| requires you to not only provide the source if you use it
| in a product, but the ability to modify it and run your
| modified version. Which iOS doesn't let you do.
|
| Now, _macOS_ would be fine in shipping a gpl3 bash. But not
| iOS. (Yes, iOS has bash. Or ar least they used to, they may
| be all on zsh now, I'm not sure.)
|
| So, the question becomes to Apple, do we ship different
| bash versions for different devices, and treat macOS as
| being different, and have to worry about only using newer
| bash features on macOS? Or do we keep the same old version
| on all platforms, and just eschew the new bash everywhere?
| It's a pretty simple decision IMO, especially because users
| can just use brew on macOS and put their own bash on there
| if they want.
|
| Others are pointing out that gpl3 is less tested in court
| and that lawyers are just more uncertain/afraid of gpl3
| than gpl2, especially with respect to patents... but I
| don't think these are mutually exclusive. It's clear that
| they can't ship gpl3 on 4 out of their 5 operating systems.
| macOS is an outlier, and from an engineering standpoint
| it's a lot simpler to just keep them all the same than it
| is to ship different scripts/etc for different platforms.
| It can be both reasons.
| jitl wrote:
| > It also means they're more free to lock down macOS from
| running your own code on it in the future, without worrying
| about having to rip out all the gpl3 code when it happens.
| Better to just not build on it in the first place.
|
| how does locking down macOS have anything to do w/ GPL
| compliance? Apple is free to do whatever BS with the OS they
| ship in terms of terminal access, user permission level, etc
| regardless of GPL of any code on the device. I could ship a
| GPLv3 system tomorrow that disallows user root access and as
| long as I make the OS source freely available and
| redistributable, it's fine.
| ninkendo wrote:
| If you make a device which uses GPL'd code, and provide all
| the covered source code you used, but prevent users from
| putting any modified code on the device, you are in
| violation of GPLv3, but not GPLv2. That means this
| sentence:
|
| > I could ship a GPLv3 system tomorrow that disallows user
| root access and as long as I make the OS source freely
| available and redistributable, it's fine.
|
| Is not true for gpl3. It's called the "tivo-ization"
| loophole, and it's one of the principal reasons the GPL3
| was made in the first place. I think you're just wrong.
| duskwuff wrote:
| Current versions of macOS use a signed system volume [1],
| much like iOS - under a standard system configuration, the
| user can't replace system executables or other files, even as
| root. Unlike iOS, the user can disable SSV, but I'm not
| certain that's sufficient for GPLv3 - and I can't imagine
| Apple feels comfortable with that ambiguity.
|
| [1]: https://support.apple.com/guide/security/signed-system-
| volum...
| quotemstr wrote:
| Companies develop idiosyncratic cultures and either learn to
| live with them or die. Apple's learned to live with a legal
| culture deathly afraid of the GPLv3. Some influential director
| or someone made a decision 20 years ago and the GPLv3
| superstition became self perpetuating, reality be damned.
| Outside incentives never became strong enough to override it.
|
| Every company has its stupid superstitions.
| banqjls wrote:
| You don't have to embed a github gist to show 5 lines of console
| output that are not even highlighted. You can use the HTML <code>
| tag.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML
| chasil wrote:
| "...Apple decided that while it could comply with the terms of
| GPLv2 license with regards to rsync 2.x, it could not comply with
| the terms of GPLv3 license with regards to rsync 3.x."
|
| This is due to the software patent terms that appeared in GPLv3.
|
| https://news.ycombinator.com/item?id=21645618
|
| https://lobste.rs/s/8lbh1k
|
| https://archive.ph/AeMTz
| IAmLiterallyAB wrote:
| I think its actually the anti-Tivoization stuff that they take
| issue with
| brian_herman wrote:
| Can someone do an analysis of the packages of macOS Sequoia that
| are still GPL licenced?
| palata wrote:
| Am I the only one finding that "openrsync" sounds like "rsync" is
| not open source? I find it a bit confusing because rsync is GPL.
|
| Just like I would find it weird for a project to be called
| openlinux or librelinux...
|
| Still it's great to have multiple implementations, of course!
| ronsor wrote:
| It's called _openrsync_ because it 's developed for and by
| OpenBSD.
| palata wrote:
| I truly respect OpenBSD, but I hope they won't end up writing
| openopenssl :-)
|
| (I will admit: I had to check and openssh is actually "the
| OpenBSD Secure Shell" project, so I guess it makes sense :-)
| ).
| ronsor wrote:
| Sorry, OpenBSD already wrote libressl and libtls
| jitl wrote:
| "free" != open
|
| open != "free"
| palata wrote:
| Are you trying to imply that GPL is not open source?
| jitl wrote:
| one is software anarchism, the other is software communism
| firecall wrote:
| I feel compelled to comment just to note the vintage WordPress
| Theme being used!
|
| Worth a click just to see how we used to live!
| NelsonMinar wrote:
| Does openrsync work?
|
| The problem with Apple's ancient userspace is so many of the
| utilities are outdated and don't support things like files bigger
| than 4GB. So switching to a tool updated in the last 19 years may
| be an improvement. But then rsync is such a standard, is
| openrsync 100% compatible?
|
| The need to install and maintain Homebrew was a big part of why I
| switched from MacOS to Windows. WSL is a very good Unix
| environment, being just Ubuntu or Debian.
| alphabettsy wrote:
| How is maintaining two operating systems simpler?
| fmajid wrote:
| Just like they replaced bash with zsh. Most Big Tech firms are
| allergic to GPL3.
| 7e wrote:
| GPLv3 is a legal landmine. In fact, GPL itself is wildly
| unpopular compared to more open licenses. The FSF is getting
| what it deserve here. Open source predates the FSF and will
| remain long after the FSF is dead.
| wanderingmind wrote:
| Can you show examples of impactful open software that
| predates fsf and stallman?
| donnachangstein wrote:
| BSD predates the Stallman Utilities (kernel sold
| separately) by about a decade.
| donnachangstein wrote:
| The FSF and its acolytes are so delusional they would see
| this as a win.
| mcstafford wrote:
| Whose popularity do you champion, and what sorts of motive
| bring deservedness in to the discussion?
___________________________________________________________________
(page generated 2025-04-06 23:00 UTC)