Hacker News Reader

Comment by naibafo | Hacker News Reader

There are different issues with OSX though, that colleagues of mine had, that never occur with Linux. E.g. the chore of somehow managing different software versions such as the outdated default one and a second one installed with homebrew. Almost all my colleagues struggled with setting up python 2 und 3 correctly at some point, whereas this just worked for me on Linux.

Some struggled with font rendering between a 1080p monitor and their Retina displays as well.

View on HN

>Almost all my colleagues struggled with setting up python 2 und 3 correctly at some point, whereas this just worked for me on Linux.

This is one area where I'd have to concede the Apple experience is objectively suboptimal.

However, the Python ecosystem isn't doing anyone any favors here.

Languages and platforms generally are best supported on linux. Clojure, haskell, python, anything except the platform provided by the Apple/Microsoft is easier to configure on linux.

C++ ecosystem sucks a lot when you have to build 5 libraries using 5 different building systems. Linux package managers do that for you.

Yet VC++ offers much better tooling, including pre-compiled headers, incremental compilation and linking, experimental support for modules, C++ friendly OS APIs, and a package manager actually written in C++.

And a project config system that will break everything at the slightest provocation! Seriously, setting up even moderately complicated multi-project solutions usually results in days lost to figuring out why x library isn't linking with y project. The editor is great, the build system is somehow worse than make/cmake.

Nowadays MSVC has a built-in cmake integration (a bit like vscode). You can open a folder with CMakeLists.txt and it will mostly work.

Yes, if you can justify using cmake on Windows. Most customers want an MSVC project though it seems.

And then you want to use that library that isn't a msvc project.

Or, God forbid, you want to use clang or gcc. Or intel's whatever.

Intel is compatible with MSVC++, using binary libraries is quite common on the PC world since MS-DOS days.

Plus there are DLLs and COM libraries as well.

> However, the Python ecosystem isn't doing anyone any favors here.

Apple isn't, either. They ship a version of Python by default that is woefully out of date and conflicts with any other Python that you install, and what's more, some of their tools (notably, LLDB) freak out if you have a newer Python on your $PATH.

Except you forgot Apple ships Python 2.7.15, which was released in 2018. It's actually quite up to date.

My Mac on Mojave ships with Python 2.7.10 which was released May 23, 2015.

maybe it is right now. But in my experience they usually don't keep them up to date very well

Sounds like RHEL 7...Unless you enable Software Collections.

RHEL 8 is moving to Python 3, though, with a Python 2 binary kept for system tools that still need it.

I have struggled occasionally with the various Linux package managers not being able to resolve Python library conflicts/dependency conflicts. Like, really, things where you wonder how possibly could there be a conflict, such as scipy not being able to update because matplotlib ver whatever being needed by some other lib that interoperates with scipy but itself is updatable something something something.

I'm still not sure I know the best way to install Python packages. It seems someone has something bad to say about any given method (pkg mgr, pip, venv, etc).

I just use nix on OS X, better package manager than most linux distros have. I have my own copies of py2/3 and the system one, not a huge deal to be honest (outside of the pain of linux side nixos updates breaking derivations for macOS, but thats generally not a fault of the os).

The issue I have with Nix, vs a combined MacPorts+Homebrew is that Nix is a pain to get working. The time investment required for Nix is too high.

Last time I tried Nix I eventually got the Nix environment working, but ran into MacOS-specific issues trying to install relatively common development-related packages like Ruby and PostgreSQL.

It's waaaay better than it used to be. A couple of years ago there were a lot of impurities which would cause everything to break whenever macOS was updated. But these days it just uses libSystem from macOS and the rest is managed by nixpkgs.

No argument there, I definitely agree, however its easily my favorite package manager. And lets me keep nixos config similarly.

This is at least as bad a problem on Linux — I would argue worse since I've seen people break the system tools written in Python — and it's mostly due to Python being old enough to be both widespread and to have accumulated tons of easily-googled bad advice. The people who have problems with this almost always also have tons of similar problems with everything else because they've avoided learning enough system administration to work cleanly or troubleshoot problems effectively, and that's unfortunately cross-platform — they'll also do things like copy DLLs into Windows system folders, get annoyed that rpm/dpkg won't let them install the wrong version of an important library, etc.

I work in an rpm shop, and we've been exploring switching to python. Could you expand on or link to some of the rpm&pyhton issues you've run into?

The main thing is understanding that the system python installation should be left alone and you should install each app/project in a separate virtualenv / venv so their versions of Python & installed packages are isolated from the system and each other. This also tends to get rid of about 99% of the times where someone try "sudo <previous command>" before reading the error message.

These days I tend to recommend using https://pipenv.readthedocs.io/ or https://poetry.eustace.io/ which will automate creation of those virtual environments and provide a nice interface for managing versioned package installs (i.e. `pipenv install foobar` will record the exact version you installed, including SHA-256 hashes, for repeatable installs).

If you're in the Red Hat world, note also that they're making some big (and I think welcome) changes to isolate the Python they use from the version developers use, which will also allow tracking newer versions faster:

https://developers.redhat.com/blog/2018/11/27/what-no-python...

I was looking at venv, but I guess not fully looking through into deployment. Do you know if venv works with setup.py bdist_rpm or is there nothing standard linking the two concepts?

You should not mix bdist_rpm and venv; but you can build eggs or wheels with bdist_egg/bdist_whl and install these into venv.

To be blunt, Apple would be better served removing any and all of the outdated packages, not even bothering to include certain packages at all, and just telling people to use one of the several community supported package managers. The GNU packages especially come to mind since they are all out of date anyway.

If there’s no requirement from some OS feature to have a particular package preinstalled, I would rather not even have it in the base system if I’m just going to have to replace it with an updated (and updateable) version.

I might be unlucky but Linux had been a nightmare on the few laptops I've tried it on. It is not that I have not tried. I did. Some of the problems I had: Very slow UI, not recognizing my Wifi Card, Chrome stopping support for CentOS, Problems with the Graphic Card and multiple monitors, problems with most printers I try, problem with my Bluetooth mouse...

Linux and the multiple variants have been horrible. Also, you commented about Python 2-3, I agree I had issues with OS X. But you are ignoring the fact that installing software on Linux is still a mess of resolving all the dependencies and the package manager. Where in OS X, it is just a file move to App.

Nowadays, I run dev code on a Linux docker container. I do pretty much anything else on OS X.

Your experience running Linux on a laptop is highly dependent on how well it supports the hardware that happens to be in your device. If you're able to research the driver support ahead of time, you may find that Linux runs flawlessly on the laptop you bought. If you install Linux on a random laptop, then getting wifi, audio, etc working can be hit or miss, depending on the drivers.

As far as installing apps, I guess it depends on what you're trying to install. In my experience installing apps is easier on Linux than on any proprietary OS, so long as you're installing open source applications and working within the package manager and keeping your system up to date. If you want to run proprietary software on your open source OS, then yeah it's more difficult since Linux distributions aren't really designed for it.

> Your experience running Linux on a laptop is highly dependent on how well it supports the hardware that happens to be in your device.

My second mainline Linux install was a copy of RedHat on a laptop.

Mind you, this was RedHat 5.1 on an old 486 laptop with 8 meg of RAM, PCMCIA, etc. Sometime in 1995 or 96, I forget.

Several re-compiles later, I had that entire system working - all drivers for all the hardware, including the built-in modem (plus sound and PCMCIA ethernet).

I got lucky there.

This.

I had an Asus laptop that would only pickup wifi if I hibernated it first. I have a Dell touchscreen model that took a full day to get the touchpad to work at all as Ubuntu kept defaulting to the screen. Too afraid to do a fresh install of the current (or any other) distro because I can't remember how I fixed the touchpad issue.

It sounds like you were really unlucky. The last time I struggled with any of the issues mentioned by you is at least 4 or 5 years in the past.

> But you are ignoring the fact that installing software on Linux is still a mess of resolving all the dependencies and the package manager. Where in OS X, it is just a file move to App.

This is also highly dependent on specific experiences. I haven't had any issues with conflicting dependencies on Arch linux in the past few years. And personally I appreciate a system package manager for all software instead of having to download applications and doing drag and drop for installation

Sounds like you just got lucky with the versions you happened to need vs what the system versions were on your version/distro of Linux. It's not like Linux has a built-in solution to the problem, you can definitely still have issues with conflicting versions.

BTW, on either platform your best bet IMO is installing all your scripting languages within some kind of version manager. I like pyenv, rbenv, and nodenv since they work exactly the same way between the three languages.

I have a feeling that Apple doesn't want their users to install that kind of development environments, other runtimes, etc. to their MacOS installations. Time Machine also sometimes doesn't Backup these installations correctly.

Similarly, TeX installation is hard and it's forcefully shoehorned on the installation, and you can't do anything better in the current situation.

My solution is to run a Linux VM for these situations. For programming and server-like purposes, a headless minimal installation is fine. For TeX authoring, an XFCE installation is very handy and not impacting battery life in a visible way.

> Similarly, TeX installation is hard [...]

Installing MacTeX has always been one of the most straightforward things I can imagine.

It was. When I got my first Mac in 2008, it was very straightforward. When Apple started to tighten OSX security they stumbled a little IIRC (I cannot find the old warnings and notes on the page). Also, around the same time, OSX installer changed, and OS upgrades started to take longer since TeX installation had so many files.

When they were working on these problems, I was in the middle of my Ph.D., and I needed a stable TeX installation, fast. I installed a Linux VM, all my woes went away, and that method just stuck.

I just checked the MacTeX page now, and it looks like they solved the problems I mentioned above, but currently I'm too lazy and need that TeX installation keep working, so I'll not retry it now.

To be fair, that may be a python problem, as I've also had issues with 2 & 3 on a Linux machine as well. At this point, unless I can avoid it I just use a VM for any python 2 work.

I didn't mean just managing 2 and 3.

OSX comes with some software such as git and python2 preinstalled. However they do not usually keep that software up to date and there is no way for you to change that, which means that community package managers need to be used to install more up to date software versions in parallel to the system ones

This is a pain point. I use pyenv+pyenv-virtualenv+pyenv-implicit to keep me sane on MacOS (and everywhere else honestly, system python is for the system.)

https://github.com/pyenv/pyenv

This was my main complaint with OSX until I tried nix. When I ditched homebrew and reinstalled the same packages with nix, I don't think a single one had problems. The CLI has some stupid pitfalls though..

what works for me

1. brew install pyenv 2. pyenv install 2.7.x 3. pyenv install 3.x 4. cd work; pyenv local 3.7.x (by default, all projects under "work" will use 3.x) 5. cd work/legacy; pyenv local 2.7.x (but this one will be on 2.x)

then for each project, I'll create a separate virtual environment.

For various reasons, I have about 6 separate python versions and a dozen or so mini projects all working flawlessly as separate virtual environments created under separate versions managed by pyenv, and I always have the latest pyenv thanks to brew.

Reply on news.ycombinator.com