Hacker News new | past | comments | ask | show | jobs | submit login

Yay! Glad to see this rather than the Red Hat approach of continuing to support dead versions (yes, I know that enterprises value stability blah blah blah)



When I was at Apple, they discontinued bundling the command line version of emacs, and they sent a long internal email stating why. The stated reason was that any newer emacs would suffer from license incompatibility with macOS, and they didn't see the point of supporting a 10 year old version that the FSF doesn't even support when, if someone really wants emacs, it's just a `brew install emacs` away.

I can't say I disagree.


I find it kind of frustrating that Apple would use that as a rationale without taking efforts to support homebrew. If they didn’t like the way homebrew was engineered, they could have afforded to port dpkg or something similar. If they did like homebrew, they should have hired on the core developers.

It’s less true today than it used to be, but Mac was the best Unix developer box in the corporate world. A huge portion of their sales (especially high end sales where they make the most profit) relied on these community efforts.

I’ve moved over to using nix instead of homebrew and it’s so much better that it makes me wonder how it ever got this way. I think this is how.


The funny thing is that Apple uses Homebrew internally. We had custom taps and it was part of a lot of setup documentation in our Confluence.

I think the issue is that Apple isn't "one" thing. There are thousands of engineers, each with their own opinion, but also a thousand lawyers and corporate executives who are very concerned with how every action will make Apple "look" as a company. Sometimes their decisions made sense, sometimes they don't.


They hired the original lead developer of Homebrew, which seems to me like support. He chose not to continue working there and seems to now be selling NFTs of his old tweets and git commits, but it seems hard to pin that on Apple.

I'm assuming, of course, the idea was to let him spend at least some of his company time working on Homebrew.


They have supported both homebrew and macports throughout the years. What are you talking about?


What I don't get is why they bundled that version for so long. It would have made perfect sense to stop bundling it when emacs switched to GPL3. It just caused annoying issues where trying to use emacs in your terminal would bring up this ancient version that would potentially conflict with your .emacs.


I don't disagree either, but the whole GPLv3 situation is still not solved after all this years. Will they completely remove bash, rsync, eventually?


I seem to remember they just switch default shell to zsh, which is MIT [0]

[0] https://github.com/zsh-users/zsh/blob/master/LICENCE


And if you change your default back to bash, every new terminal you open complains that you should switch to zsh


  export BASH_SILENCE_DEPRECATION_WARNING=1


If someone does that, I hope they find a newer version of bash. The old (3.27?) GPL2 bash should give a warning like that.


Not if you install a modern bash, unless I’ve missed something all these years.


What I see when I open a terminal is this: The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050.

I believe I switched from the default zsh to the bash that also came with the operating system. I don't think I installed a new bash. I was just trying to add on to/respond to the question "Will they completely remove bash, rsync, eventually?" . My answer was too short and I didn't actually make it clear what I was saying. I think the answer to the question "Will they completely remove bash, rsync, eventually?" is yes, at least for bash, I think they will remove it. My evidence for thinking they'll remove it is if you switch from the default zsh to the bash that comes with the operating system, they'll kindly ask you to switch back to zsh every time you open the terminal. Yes, you can change the default from nagging you with BASH_SILENCE_DEPRECATION_WARNING, which is great to know.


Sure, but that doesn’t solve the issue of shipping ancient software forever. It’s not default but it’s there, like Python 2 was


I don't really see the problem with this though; people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something.


> people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something.

This is probably somewhat optimistic: there are a lot of people who are not developers who still use those tools — I've supported scientists, librarians, analysts, etc. who had a few scripts using tools like that but weren't really comfortable making changes. That doesn't mean it's _hard_ to install Homebrew but it's something which they'll need a little pointer and possibly institutional approval to do.


That's fair, I guess it has a potential to affect non-geek users at some level if they're using geek-supplied scripts.

I guess I just feel like the net good would be to de-bundle these non-compliant tools and get them to install upstream versions from Homebrew or MacPorts or something.

It's annoying, and I'm not one of those people that tends to be the "OMG JUST RTFM IT'S NOT THAT HARD!!", since if people are struggling with it then it is "that hard", but I feel like there isn't a solution that can satisfy all parties with this.

It seems that we either break the workflow, which makes a few of the aforementioned parties for a bit, keep bundling the old versions of these tools and leave potential security problems in there, or somehow forcing Apple to change their OS to be GPL3 compliant. For better or worse (probably worse), that last one isn't going to happen, so it feels like the lesser of the two evils is to stop bundling software that won't be getting future support.


I agree that plenty of people who are not developers use those tools but I also don’t think the lift of installing homebrew or macports is going to be too much for people who are already smart enough to run those scripts in the first place. Like you said, it just requires a little pointer, which hopefully people will be happy to provide.

The approval thing is valid, but I feel like that is likely going to be an issue that becomes more and more common as Apple moves to move more and more tools and utilities to the Xcode tools download anyway. Support/approval teams are just going to need to adjust to that reality, even if it’s an annoyance because I don’t see things shifting back, at least with Apple.

But issues of approval aside, I honestly think back of myself as a teenager, installing fink and Macports and figuring it all out as I went along and I wouldn’t have called myself a developer then. I was just a girl who wanted to tinker with stuff.

I think we (and I’m not talking about you specifically but the more general “we” as in the types of people that frequent HN) often underestimate the abilities of our non-dev brethren. We overestimate how much users know too, of course, but I do think we often slot people who have shown that they have the capabilities and desire to solve a problem into a “lesser” box just because they don’t carry the title of developer. And that affects those users too, who then assume they can’t do something when their own track record proves otherwise.


Definitely. I work a lot with librarians — that's a field which isn't considered “technical” but then you look and there are people writing shell scripts to process collections, writing tools in languages like Python to manipulate metadata or work with APIs, etc. and that distinction starts to look pretty arbitrary. (This is actually a big retention problem in the field: someone who learns that in college / on the job is going to look at the pay multiplier they can get by applying for a developer job)


It means I can’t go to help someone with their laptop and use emacs to look at their cruddy code :) but covid ended that sort of help anyways, now I have to watch them type in screen share and see if they know about tab completion and shell history thru the up arrow.


Well you should be using vi anyway so I consider this a win /s

That's a reasonable thing to be annoyed about, but I also think that progress dictates breaking workflows occasionally.


Part of the magic of macOS was a pretty UNIX that just works.

Sure, I can install and deal with the burden of a package manager, but I don’t want to and didn’t use to need to for basic tools. I want Apple to do this.

If you’re installing your own shell making sure it doesn’t conflict with anything else, you might as well run Linux.


I'm pretty sure they eventually will.

Personally, I'd like to know why Apple decided to ban GPLv3 software in macOS. It's not locked down enough to trip the TiVo clause[0]. My ongoing guess has been "just in case we need this in iOS", but these tools are all things that Apple would never ship in iOS anyway - the whole point of that OS is that you don't get access to any of those tools[1].

Alternatively, they might have just taken the Linus Torvalds tact of "this changes the deal", even if that change is minor. But that's not so much a license compatibility problem as much as it is a difference of opinion. Which is something that might never actually be resolved. Thanks to the v3 split, "GPL" now means two different licenses based on RMS's personal opinions on what restrictions best preserved software freedom at that time[2]. Even a hypothetical GPLv4 that dropped the TiVo clause for the sake of appeasing Linus and Apple would be changing the deal for people who wrote v3 programs expecting them to be a bulwark against locked-down devices.

In either case, it does not make sense for Apple to ship decades-old utilities that it refuses to update for legal or moral reasons. At best, they're dead weight - it is very much common practice for people developing on macOS to install the newer versions of those utilities themselves. At worst, they are an actual security hazard, as they aren't sandboxed in any way. Bugs in those utilities would be very much exploitable on macOS. So if we've decided "we're not going to update this ever", then we might as well get rid of it and replace it with something else.

[0] The TiVo clause in GPLv3 is actually not that strong, BTW. It requires that, if you ship the software as part of some hardware, that you provide a way for the owner of that hardware to modify the GPLv3 bits and have the hardware still work. The only thing that would remotely trip the clause on macOS would be SIP, and that's also owner-overridable.

You will lose iOS app support in the process on M1 Macs, but the TiVo clause doesn't cover that scenario - which is ironic because that's exactly how TiVo worked around similar language in GPLv2.

[1] Apps like iSH or a-shell do exist, but they run x86 or WASM binaries within the App Store sandbox. They also don't trip the GPLv3 TiVo clause.

[2] At one point, RMS was seriously open to the idea of just rolling the Affero clause directly into GPL, which probably spooked people way more


I wonder if it has something to do with the Busybox lawsuit. I think that it might be more to do with "we don't want to rock the boat with licensing...GPL2 has worked for us, and we don't want to be forced into a corner like Linksys was with Busybox".

This is entirely speculation on my end, IANAL and I didn't work in that part of Apple.


> Will they completely remove bash, rsync, eventually?

Removing bash is a pretty safe bet. They’ve been making move after move in recent years preparing for it.

https://scriptingosx.com/2019/06/moving-to-zsh/


I disagree. System utilities need to stick. I Apple shipped stone age Emacs for some reason, they should continue doing so.


In perpetuity? Why? In forty years they should be using a 55 year old version of Emacs and a 45 year old version of Python? I respectfully but firmly disagree.

Very few are using it, it's not getting updates, and is a potential security hole because of the lack of updates, it seems to me to be smart to get rid of it. Most people wouldn't want to use that ancient version of Emacs, and would install a newer one via Homebrew or GNU Emacs for OS X.


This assumes brew works on your machine. It doesn’t on older Macs.


As noted on the GNU emacs site[0], you can download prebuilt binaries here[1], if you really can’t be bothered with ‘make install’. Homebrew is hardly necessary (for most things.)

[0]: https://www.gnu.org/software/emacs/download.html

[1]: https://emacsformacosx.com/


At least for me, homebrew emacs isn’t that useful. It is terminal-only.


There are taps that build GUI Emacs via homebrew, that's what I use. In particular, I use this one: https://github.com/d12frosted/homebrew-emacs-plus


I think it was a "removing from future versions of macOS" situation, not removing from existing installs. If your mac is old enough to not have homebrew, it's probably too old to install Catalina due to the fact that they stopped supporting devices without Metal support.

Also, feel free to replace `brew install emacs` with the macports equivalent and the point still stands.


Well sure, there are alternatives. I was commenting on the casual assumption that everyone has brew. Brew has worse support for older Macs than a lot of other software.


And you can compile emacs from trunk or master or main or whatever from the GitHub mirror pretty easily.


Tigerbrew has a python2 formula available back to 10.4: https://github.com/mistydemeo/tigerbrew/blob/master/Library/...


MacPorts works on OS X 10.4 Tiger and above. :)


Are there any machines that support newer versions of the OS that don’t support Homebrew?


Surely you can cobble together a toolchain circa your old Mac and build from source?


RHEL and macOS are two very different products with two very different audiences and can hardly be compared like this.

That being said, Python 2 will last through the end of RHEL 7's lifespan through June 2024, and that includes the AppStream module in RHEL 8 which will similarly end support in June 2024. After that customers are recommended to upgrade to a supported version of Python or continue using Python 2.7 at their own self-supported risk, we will not support them in that endeavor.

RHEL 9 (due out in a few months) does not ship Python 2.7.

https://access.redhat.com/support/policy/updates/rhel8-app-s...


With Ubuntu, if you delete Python, it obliterates everything. Have fun re-installing your system. Learned that the hard way. You can bet I "use Arch btw" now.


I don't see how that's relevant here, unless you interpreted my statement to mean we will be removing Python 2.7 in RHEL 8. That isn't happening, the module will remain in the AppStream repositories but will not receive any support.

Removing the system Python is prevented on RHEL/Fedora (with an exception). The package manager, DNF and YUM, are marked as protected which prevent their removal. You'd need to remove the protection file from /etc/dnf/protected.d before you can do that. Removing the system python would remove the package manager which depends on it, therefore the transaction is stopped. Using the RPM utility directly also will not work unless you a) pass --nodeps or b) list out every single dependency at the same time manually. You can test this in the CentOS containers with the following:

quay.io/centos/centos:7:

  yum remove python
  rpm -ev python
quay.io/centos/centos:stream8

  dnf remove platform-python
  rpm -ev platform-python
quay.io/centos/centos:stream9

  dnf remove python3
  rpm -ev python3
Best practice policy: use yum/dnf, not rpm for any package management.


You're right, it's not relevant here. I somehow managed to replied to you instead of the comment I was thinking about responding to. Weird.


No worries, I make that mistake all the time; I should've considered that possibility.


It’s not just “value stability”, there’s a good chance that without them knowing some part of their billion dollar enterprise absolutely depends on an old python component that would break if 2.7 were removed.

They know that at some point, their RHEL version runs out of extended support. Two years before that they’ll experiment with the new RHEL version on their test environment and notice everything is totally broken. And then they’ll have two years to fix it which is just barely enough time, as “fixing it” requires buy in and planning and resources from dozens of divisions and hundreds of people.

To enterprises, having Red Hat support some ass backwards old version of whatever package is not just “valued”, it’s exactly why they pay millions to Red Hat instead of running some free Linux version.


The way I have always understood it - the Python that RedHat supplies is intended for it's scripts. If we install our own packages or remove any packages, then the risk destabilising the system. I have seen situations where people have removed python packages that resulted in yum no longer working, for e.g.

Hence, I have always (including from the RHEL 6.x days) provided my own local python version by compiling and packing as a custom rpm. I now use venv to do the same.


Actually RedHat no longer ships Python since RHEL 8, instead they have platform-python for internal use of the operating system and you need to explicitly install the Python version you want


This is a RHEL 8 only feature, RHEL 9 will have a global python3. Whether alternative version are offered as modules or as side-by-side installs like in Fedora, I do not know.

https://koji.fedoraproject.org/koji/search?terms=python%5B2-...


Why is it bad that red hat does that? That’s what their clients pay them for.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: