"Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)"
They've actually been warning users since Catalina (if not longer) when the following are run:
python
irb
php --version
tclsh
For PHP, it also shows up in Apache's server string:
Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname
Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.
While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now:
% /usr/bin/python
WARNING: Python 2.7 is not recommended.
This version is included in macOS for compatibility with legacy software.
Future versions of macOS will not include Python 2.7.
Instead, it is recommended that you transition to using 'python3' from within Terminal.
Python 2.7.16 (default, Mar 25 2021, 03:11:28)
[GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
% /usr/bin/python3
Python 3.8.2 (default, Dec 21 2020, 15:06:04)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
% /usr/bin/python3
xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.
Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all.
I don't like how Apple handles this. If you have the developer tools installed, it's not especially obvious what is part of those tools and what is actually bundled with the OS. And so it's not surprising that some scripts I've come across will silently break in semi-odd ways without the dev tools.
Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?
> Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all.
There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage).
OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about.
> Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?
Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not).
The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.
> but where does a third party package manager put stuff?
/opt
> The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.
Yes, that's where I would suggest putting it, but the reason projects don't is either because they aren't aware of it, feel it's a bit more convoluted to make sure you update where PATH is set, or that /opt is generally used for singular applications, not an extended hierarchy such as /opt/local (which is actually a truly weird name, /opt/macports/ with /opt/macports/bin, /opt/macports/lib, etc would make more sense). It makes sense to use /opt from an "application" point of view, but I think the problem is many of these package managers see themselves as more than that, and as pseudo-system components, which clouds their reasoning.
The LFS spec you linked to is actually ancient at version 0.65, the latest is 3.0 and available here[1]. It's a bit "do what you want", but it really expects the "local" part of /opt/local that MacPorts uses to be some sort of identifier for MacPorts.
That said, it's the Linux Filesystem Hierarchy, so it only applies to Apple stuff inasmuch as it's common practices for UNIXes in general. And it's not like the major Linux distros follow it fully either. They're happy to break from it where it preserves some historical layout their OS has had that they think is easier for their users/admins.
python3 is a developer tool because it is the extension language for the lldb debugger. For example, I have python3 scripts for formatting my custom C++ data types, and that formatting also works in Xcode's visual debugger (which is presumably using the lldb API).
Previously, lldb's extension language was python2. This changed a release or two of Xcode ago. At that time, to use lldb scripts with that new release of Xcode you either had to run on Catalina (which added python3 to the existing python2) or install your own python3 and point lldb at that. This actually was what pushed me into moving to Catalina on my development system, because the Unicode handling would be much easier in python3.
As I understand it, Monterey and the Xcode that is released for it move the necessary python3 installation from the operating system itself to Xcode. I'm fine with that.
(I would not be fine with Apple telling me I have to go waste my time figuring out how to install a suitable python myself, when I never had to before. And indeed, many of their own developers may be like me and know a little Python but are in trepidation of the env thing.)
The way it was before meant that if they wanted to update python they had to release a new version of the operating system. This is clearly an imposition on the vast bulk of macOS users, who are not developers.
The reason for zsh is simple enough: Terminal is a standard Mac app, and there are some system maintenance things an ordinary user might do which require the command line.
So there needs to be a shell, and that's zsh now.
Apple switched to zsh because they're allergic to later GNU licenses and the version of bash they were shipping was absurdly out of date.
Yes, that's the practical reason. But what's missing is a conceptual reason, something that makes it easy to remember what is and is not a developer tool.
Possible approaches that would be less confusing than what we have today:
1. Ship Python 3 with macOS.
2. Ship all of the command-line developer tools with macOS, including clang et al.
3. Bring back the Snow-Leopard-era /Developer folder, and put developer tools there.
4. Put developer tools in /usr/developer, or /usr/local/developer, or /usr/local/Apple, to balance both UNIXness and clarity.
5. Don't ship Python at all. The Python foundation already distributes a .pkg installer for Mac. If xCode needs Python, follow your own Human Interface Guidelines and put it in the Application bundle.
All of these approaches have downsides, but I still think they'd be clear improvements over the current situation. Which is to say, I want Apple to figure this out!
At the time the GPLv3 was written, the GPLv3 was deliberately crafted to put commercial companies into a conflict situation.
(A) Give up selling audio with DRM (DRM did go away)
(A) Give up selling video with DRM
(A) Give up using HDMI as an output port
(A) Give up using digital signatures to secure the integrity of software
-OR-
(B) Give up using GPL v3 software, GCC, Bash
Pretty sure most customers actually want many of the things in (A) and a minority actually care about (B). The items in (B) can be post-installed by those that really want it. Sure those in (B) have a loud voice, but, HN, are they really representative (democratically a majority)?
How would you make the choice between (A) or (B)?
I would bet that if a subeoena for FSF/GNU email was issued there would be a lot of messages related to manipulation and coercion for licensing and re-licensing. The sort of stuff, when associated with companies turns into scandal, lawsuits and monopoly investigations. (GCC almost got to be what could be considered a monopoly compiler)
I do believe that open software has a place and is a really good choice. My opinion is that the GPLv3 is completely toxic, spawned from negativity and is ultimately anti-open source. I will never release any software under the GPLv3.
> Give up selling audio with DRM (DRM did go away) (A) Give up selling video with DRM (A) Give up using HDMI as an output port (A) Give up using digital signatures to secure the integrity of software.
Does GPLv3 really prevent an OS from doing those things? I think it would just prevent it in the same executable as GPLv3 software?
I don’t actually understand Apple’s “allergy”. On the iPhone I’m sure they object to the Tivoization clause (which coincidentally is why I like to use GPLv3), but I’m pretty darn sure macOS doesn’t fall afoul of anything...
Python 3 is required for the ability to install coremltools which makes it a developer tool.
Python 2.7 might be there because old software is there for compatibility reasons for software possibly for mathematical software that never really gets updated. Removing it in future versions makes sense because of the fact that if you haven't updated it won't work on ARM Macs.
The best way to make someone upgrade is to deprecate and then remove access. At minimum the worst case scenario is they roll their own and install Python 2.7.
How exactly is the above supposed to work when /usr/bin/python doesn't exist. If Apple chose to break the #! contract by doing something else, how would you feel about that?
This answer is both a great answer, but also a terrible one.
This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.
What about Python2 v.s. Python3?
This isn't true and cannot ever be. This happens for other scripting and interpreted languages.
This approach means that the burden of choice and setup is transferred 100% to the person running the script. If you have 2 scripts that require different dependencies, then you will encounter this problem. I think it is this that encourages folks to include hard coded paths to enumerate explicit dependencies.
Lots of the "package" managers for these scripting languages also don't deal with this very well. They advocate a "do it my way" or "do it yourself". Different languages do it different ways.
Ultimately, the person wanting to run the script, just wants to make it run -- they will follow the instructions to make it work and along the way will make "global" changes -- which will impact what will happen for any other script in the future. This will likely be diverged from anyone else who has a "base install".
The above is mostly about my observations with using Ruby, not Python. However, few attempts in using pre-packaged complex python "recipes" has always resulted in similar conflicts.
> This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.
Practically speaking, how does using env versus the absolute path make this any better or worse? You as the script author don't know what version of Python/Ruby/Bash/etc lives in /usr/bin. Maybe you could do some kind of automagic detection based on the user's OS, but any such assumptions are likely to go stale over time.
All env does is give users a choice about where to put their binaries. The versioning situation is a real problem, but I don't think using env makes it better or worse.
I don't think powershell is even the powershell of windows. You get some of the better sysadmins using it, but working in the c#/windows world I see developers rarely touching powershell, certainly nowhere near as often as you'll see Linux develops writing a shell script. I wouldn't be surprised if C# was more used for "scripting" purposes than powershell, it usually ends up shorter and more readable anyway.
I find the MacPorts approach to be very developer friendly and I wouldn’t really want to use a “naked” macOS install as my work machine. MacPorts makes it look like a very credible BSD workstation.
I really have no issue with Apple trimming down the surface of the OS to a minimum.
Totally agree. I think anyone developing with these tools would too. It's not as annoying as say, RedHat, but out of date "system" versions are just obnoxious.
I don't know if any "native" apps have leveraged them, though. That would be the real risk of disruption.
Also, as someone who never uses PHP, I'd really rather not have it on my machine. Scripting languages are a pretty big attack surface, even if it's just to pivot after initial compromise. I'd rather not have one there that's not being used.
I'll also make the inflammatory statement that people should just use sed and awk in shell scripts and leave Perl for when they really want to write Perl.
It is weird to me the number of times 90's Linux Distros used Perl for things that are easy in awk, awk for things that are easy with cut, and other commands for things that are easy with POSIX shell baked-in facilities. I guess I'm just a shell snob.
cut usually doesn't do what you want it to do. Most of the time you want to split on sequences of whitespace (which may or may not be tabs, it's not easy to tell from the output of the program). cut doesn't let you do this, which is a shame, as it would've been a sensible default. It also does weird things like print out the whole row if there's no instance of the separator on the line.
So because you can't trust cut to do what you want, you'll probably reach for something like awk '{print $3}' instead.
Yeah, after I remembered that `cut` exists shortly before needing to grab some fields of an input, I thought "oh, I'll use `cut` instead of `awk`". And lo and behold, `cut` couldn't do the thing I wanted. Why learn two tools when one will do? The only reason I can think of is the principle of least privilege, but if you can convince me it applies, I'll convince you should write a single tool that adheres to it instead of using countless tools for any given transform/privilege pair.
I tend to start writing in bash/sed and going on to regret it as the script gets more involved and needs a refactor in perl.
Most of the time the script doesn't get more complicated and it's fine with cut/sed/wc etc, but at some point it tips the balance and I grumble to myself.
> since it's as much as Unix system utility like awk or sed as a programming language.
Even those tools suffer from Apple's lack of fucks given. I often have to replace included system commands with the homebrew equivalent because Apple's is missing some common functionality.
I wish Apple would just adopt homebrew as a firstparty package manager.
Homebrew should first come up with basic functionality... like you know not assuming the OS will only have one user account ever. I was quite shocked when I found this out about the oh so amazing package manager.
Before someone shares some bizarre workaround: no thanks.
The last time I bothered with it, it complained about my use of `sudo` but wouldn't run unless I was logged in as admin - not a temporary bump, just logged in as an admin. Sudo isn't alright but running as admin is…? I really can't work that one out.
It also broke so I uninstalled it. When I need to I go straight to their formulas and install by hand, as a non-admin user.
The issue (in my experience) is that neither Homebrew nor Macports provide a "full fat" package management experience like pacman or even apt. Not only are they missing packages, they're missing features and are loaded with outdated builds. If Apple made a first-party package manager that didn't suck, I'd probably have a Mac on my desk today.
Homebrew is a piece of crap. There's no away to install specific versions of software (unless you dig through the git repo and install using a commit hash). It has a scorched earth policy of wiping out dependencies willy nilly. One time I installed Python 3.8 and it wiped out the version of openssl used with Python 3.7 I used for a client project.
You can actually `brew search python@` to see the available versions (major/minor only, not patch) and then `brew install python@3.7` to install an older version. Caveat is that this depends on someone having made a separate formula, under the correct versioned naming scheme, and uploaded it to homebrew. There doesn't seem to be a python2 formula, for example.
I think it's a difference in philosophy? Brew does a "good enough" job for the most common use case, supplementing Apple's janky *nix environment with commonly-needed tools, without a built-in package manager. It doesn't try to do complex simultaneous versions... in my (admittedly limited) experience, if you need to do that, you either do that in something like a project-based setup (npm/composer) or in a VM/container with its own packages.
In your situation, when you have multiple pythons running in the same environment, how does anyone given script know which one to call? What's a better way of doing this?
Regarding Perl, rather than removing it Apple actually upgraded it – from 5.28 to 5.30 – in Big Sur 11.3. I wasn't the only one briefly surprised and bitten by it:
Perl is requires for apple to maintain their unix(tm) certification. And while they likely dont see it as core to what they want macos to become it would be an news story in the more sensationalist part of the IT press if they were to drop it. and big sur is still listed as certified
https://www.opengroup.org/openbrand/register/.
Powerful command-line environments are offered everywhere (wsl, Linux container on Chrome, Linux on Linux). MacOS is actually quite lacking in comparison (being limited wrt licenses and lacking a package manager). So it’s just a GUI question, and I’m not sure there is a definite lead these days.
Integration with their other hardware devices is the more important moat right now, as is hardware.
There are plenty of third-party package managers for macOS that work fine. I would prefer it if Apple picked one to officially support, but installing Homebrew takes me ten minutes and then I never have to think about it again.
I had unpleasant issues with homebrew upgrades back when I used it. It’s not exactly state of the art. (Nix works the same everywhere, though — but there are some hoops you need to jump through on macs)
It’s definitely not the best. I have my issues with it. But I’ve been using it since I got a Mac in 2014 and it has improved a lot since then, it rarely blows up on me anymore. In fact I can’t remember when last it did.
I’ve always wanted to use Nix and have tried to get started a few times. It has always ended up seeming more trouble than it’s worth.
I've used it as my primary package manager on macOS for six months, but ended up dropping it.
My main reasons -
* Nix doesn't have support for GUI apps like homebrew cask does - which meant I couldn't drop homebrew anyway.
* The nix ecosystem forums suggest using nix-shell for managing packages for other languages, eg. python, java - but it's been really difficult to convince team members to use nix instead of pyenv, conda, gradle etc
What possible issue could you have with a package manager that just installs a program? It's the least problematic thing I work with every single day. PEBKAC
It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete.
Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.
> It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete.
There's a whole lot more to Unix and open source than GNU. macOS has current versions of many open source tools, such as zsh, awk, sqlite, tar, git, and xz.
If one is being pedantic, GNU is not even "open source" but rather is "free software," and macOS certainly is not free software.
None of that really matters when GNU is the predominant standard, though. You could tell your boss all about how great the MacOS coreutils are, but if your program doesn't compile, you're gonna be in trouble.
This new world is way better. Before we were dependent on Apple's release cadence to keep our OSS up to date. Apple officials dropping support doesn't mean they don't want these tools to be on their platform, it just means the community does a better job of managing Unix/OSS tools separate from Apple's release schedule.
That's still pretty appawling though. If Linux distros can have big release candidates and still push out package updates between releases then why can't one of the most profitable companies in the world manage it?
I'm not saying it's an easy problem to solve. Just that Apple aren't dropping support out of respect to their customers. They're doing it because it's cheaper.
Linux distros have massively different expectations of their users. And users have very different requirements from how they get and update their OSS, hence he variety of distros and package managers. Its less that Apple is unable to do this and more that Apple is in the one size fits all business, and that model simply doesn't work for solving the OSS distribution problem.
We're not talking about forking macOS for every theme change or offering alternative init daemons. We're just talking about providing a package manager for common user land tools. In fact Apple already do this: it's called "App Store". But you have to pay to have your app on there so most OSS don't bother. And here lies the problem: why would Apple run another package manager for free? For them, this is 100% a financial decision.
I'm thinking that the less value that Apple delivers to the customers, the better it is for their bottom line, don't forget, adding value costs money, plus its not like Apple fans are going to suddenly quit buying their products right?
Apple seems to be really good at maintaining their profit margin.
In a nutshell, this is the correct answer. Going all the way back to when Apple's Java was deprecated and eventually removed from the shipping OS. In the moment, it's annoying, but I would rather not have to fight with preinstalled software when trying to get a newer version of (say) zsh installed.
Here, they not only realized it had become popular, but GNU licensing gave them an excuse to switch the default without much thrashing about.
The fact that I can `chsh -s /usr/local/bin/zsh` and macOS doesn't freak out is quite nice.
There's still an even better solution: Apple could start treating their operating system like a first-class programming platform, and everyone would win. But it looks like they're still dragging their feet on that one.
They're rolling in billions with nowhere to spend it. They could just hire some more unix devs to update their tooling. Nobody wants to champion that because it'll never be a keynote bullet point.
That's a hugely subjective comment and there are plenty of instances throughout history of a powerful CLI and sophisticated GUI being included as part of the same OS (Xerox Alto, BeOS, NeXT, Plan 9). Linux and *BSD's have plenty of popular WM / DEs too: personally I'd rate KDE above anything commercial I've used but that's my subjective preference. Heck these days even Windows can be argued as having a "powerful CLI" with both WSL and Powershell existing, and the Windows UI has it's fair share of fans (regardless of what our own personal preferences might be).
This is very subjective. I, for one, much prefer kde plasma. And there's a substantial breed of developers who would prefer a tiling window manager with good keyboard navigation, such as i3.
It was impressive back when OSX debuted, but now it feels like Apple is lacking in both regards. Their shell utilities are all horribly outdated/mismatched, and their UI design took a nosedive with Big Sur. Modern MacOS reminds me of what Ubuntu felt like 10 years ago: it's a confused and scared operating system that doesn't quite know where to go from here. I mean, look at what Monterrey introduced; basically better Facetime and some new wallpapers. I'm getting the feeling that Apple has painted themselves into a corner here. They spent the past 2 decades focusing on vertical growth, only to discover that the next 50 years are going to be ruled by better interop and protocols.
Best GUI? Finder is atrocious, and overall experience is far worse than even cancelled Unity. YMMV, of course, but I hate every second spent with this 'best GUI'. The only reason I ever use macOS is because I occasionally run Sketch.
not in 2021, but apple made sort of an big deal about it when they started to market OSX 20 years ago.
And while you can still find an traditional unix(tm) box here and there in the dusty forgotten corners of enterprise serverooms(i am personally responsible for maintaining a few hpux boxen), unix(tm) certification haven't really mattered since Linux became serious business which happened around the same time OSX was launched.
What used to matter was that you could run the same CLI tooling in an macos desktop as on an Linux server but i don't think this is an use case apple see's as particularly important for the future success of Apple.
That’s the only reason my employer hands out MacBooks. If it stopped being something that used the same CLI tooling as our infrastructure, it would be Dells all around.
IMO, Apple still sees it as very important that macOS is fairly attractive for developers. Of course they’re selling lots of MacBook Airs to college students, but outside of that…
It’s not as if they want their CLI interaction to be 1-for-1 with Linux, but relatively close seems to still be a priority.
Do you have more info on that? Fairly attractive for macOS and iOS developers sure, but for me it was a happy accident that Macs also became popular for web development and Linux server admin, that it was never part of the strategy of Apple.
Companies see Mac products as more attractive for their workforce than Linux-based workstations. Having printers, wifi, other products seemlessly work, since Apple devotes time and money ensuring that, improves productivity, generally, and lowers costs in (in terms of Helpdesk staff and time spent diagnosing and fixing systems integration). So, developers and admins make use of what's offered, as it is a middle-ground between stability and functionality.
While it may have been a happy accident, it's a pretty big market.
Precovid, on any conference I went to, professional or academic, the amount of Apple laptops was insane. I'm sure they're running things locally or on Linux servers, but the fact that they work pretty well between them is important.
For anecdata, I've worked at two companies in a row now that have used exclusively Macs because it's simultaneously an acceptable platform for serious dev work and still user-friendly to tech illiterate interns.
I can't consciously buy a Mac if Apple is going to treat Linux like competition. One is free software, provided by volunteers for free, and the other is a desktop OS ran by the largest company in the world. It costs Apple nothing to respect the predominant standards, so why can't they do it?
> It costs Apple nothing to respect the predominant standards
Actually, it would cost them a lot, due to the GPL. Sure, they could try and pull a Google re: Java/Oracle feud, but I doubt they will and for good reason.
I agree, Macs aren't for me. But if Apple wants to increase their market share (hint: they're one of the most-traded shares of all time), they should start listening to their detractors. Especially for their desktops, where MacOS barely constitutes 7% of the desktop market share. Apple has been selling computers for nearly 5 decades, and their market share is still pitiful. Hell, if Google is selling more computers than you, something is seriously wrong with your computer.
Again, Apple is not interested in catering to you. Clearly. I think they're pretty happy with where they are, and catering to the demands of the "make it like Linux" crew are laughably irrelevant. I have no idea why "most-traded shares" is pertinent -- yeah, they're a super, ridiculously profitable company. Your commentary on their "pitiful" computer sales are not cogent.
The Google bit is particularly goofy. No, "Google" doesn't even appear on the charts (you know -- the charts which Apple usually is within the top 2, often leading). Chromebooks do, sold by a wide variety of sellers, as a schoolhouse special. Their great for what they do.
I just don't see them making any decision that does not make the MacOS CLI less useful with each and every release since at least the big cat series, and the user pattern is changing with those changes.
IT's an trip the classic macos took before it and i think there is an signficance in apple returning to the MAcOS branding thats subly hinting that the days when OSX was an relatively open unix is ending.
The few, government workstations that aren't running Windows are probably using RHEL. Microsoft and Red Hat/IBM have much more experience than Apple at speaking "enterprise."
Yes, but Perl still has a warning banner when you run it (at least in Big Sur and Monterey):
% perl -de1
WARNING: This version of perl is included in macOS for compatibility with legacy software.
In future versions of macOS the perl runtime will not be available by
default, and may require you to install an additional package.
Almost all exercises are minimal in nature. They will touch only small areas and (unless the book is based around advanced ideas) will not touch tricky / changing functionality. So I'm not surprised exercises still work.
For me, I had been too lazy to use Homebrew or Perlbrew since I don't develop locally per se, but I wanted `Perl::LanguageServer` for use with VS Code – which I'd installed via `local::lib` into `~/perl5/`.
Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.
Right, that's a risk you take doing local::lib against system perl.
I will often use the system perl to bootstrap https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx for managing per project environments if I need that
The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install.
> Python, Ruby, and Perl
The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves:
file -b /{usr/,}{s,}bin/* |cut -d\ -f1,2|sort|uniq -c|sort -n|tail
13 setuid Mach-O
23 a /usr/sbin/dtrace
50 a /usr/bin/perl5.28
53 a /usr/bin/perl5.18
81 POSIX shell
116 Perl script
954 Mach-O 64-bit
That is actually truly unfortunate, I think. While I understand the issues with lagging versions of system-installed languages, I think there is a comfort and educational value in having them available as part of the system for anyone to access without having to go fetch it.
It "lowers the friction of curiosity".
(And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).
I'm inclined to agree with you. When teaching someone programming, there's something comforting about telling them they can just open up a command prompt and type "python" (or irb, perl, etc) and start programming.
I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc.
(There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)
Bummer about Perl, because a stint with a slower machine taught me just how slow Python is. My Lua scripts were often done faster than Python starts up—even though the scripts were doing file i/o. So, for anything like personal productivity scripting, Python is bad. However Lua requires managing the runtime and modules—and I was thinking about dusting off Perl, since it's pretty fast and is just always around like Sh while not being garbage at data structures and code organization.
Hear me out, everyone here is talking about web developers and people who write the language. That’s the least import demographic and most unaffected segment of the user base.
Dropping PHP is irritating because PHP is actually a really good shell scripting language and it’s universal availability on macOS made distributing simple CLI tools for Mac written in PHP as a simple script or a bundled PHAR easy as pie.
I have a decent number of macOS specific tools I distribute as PHP, many 10+ years old, and I can guarantee almost none of my users have any idea what PHP is let alone how to install it.
Counter argument: removing languages from OSX is good, because built in languages are the source of a lot of friction in development. The installed version necessarily lags behind what most developers want, and having a tool chain completely separate from whatever manager you’ve installed really sucks.
For end users, the interpreter can be bundled with the application, that is much more stable for everyone.
That's 100% my take on this. If Apple leaves it in the build, then Apple ends up having to support it to some degree.
As long as it's trivial to install after purchase, the removal of this sort of thing is in no way concerning to me. When I've written things natively on my Mac, I've almost ALWAYS had to go get an updated version of perl / python / ruby / whatever to get current.
Especially considering that open-source projects provide this service for free. It blows my mind that Apple, The World's Most Valuable And Affluent Company, refuses to invest in a couple package maintainers for their "world class" operating system. If Apple ships it, they have an obligation to keep it up to date, especially since utilities like this pose serious security risks when left untouched.
Python developers I know get their interpreter installed. This is vs people in college I know that are dabbling in Python or people starting with it on a professional setting.
I currently have over 5 different python versions installed to be able to test against them. The different software I work gets deployed to different environments and I have all those versions installed locally to test.
For end users, it doesn't matter as long as it works. The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.
The interpreter can be bundled with the application, of course. But now you have n different interpreters with their own php.ini files and their own set of things to change. Upgrading the application means overwriting those files and causing more pain when they have to figure out why something stopped working.
> A bundled interpreter in the OS gives a stable platform to develop.
But it wouldn't be stable. Or it would be, but it would be hopelessly out of date.
Apple can either keep the bundled interpreters on the same version forever, or they can update it with the OS. Do the former, and it becomes hopelessly out of date. Do the latter, and software updates randomly break stuff.
Either the language developers need to actually keep their languages stable, or everyone else just needs to get used to keeping multiple versions around.
>Or it would be, but it would be hopelessly out of date
I think you need to define "out of date".
Out of date for me means not receiving security updates and stale. I think you mean not the latest version and stable for me is better in a production environment.
$ /usr/bin/python
WARNING: Python 2.7 is not recommended.
This version is included in macOS for compatibility with legacy software.
Future versions of macOS will not include Python 2.7.
Instead, it is recommended that you transition to using 'python3' from within Terminal.
Python 2.7.16 (default, Dec 21 2020, 23:00:36)
[GCC Apple LLVM 12.0.0 (clang-1200.0.30.4) [+internal-os, ptrauth-isa=sign+stri on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
but wait, also,
$ /usr/bin/python3
Python 3.8.2 (default, Apr 8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
I think we should take the lines,
> This version is included in macOS for compatibility with legacy software.
> Future versions of macOS will not include Python 2.7.
> Instead, it is recommended that you transition to using 'python3' from within Terminal.
For exactly what it says. It's included for compatibility with legacy software and should be transitioned from it to another version... the other version that's bundled with it.
> For end users, it doesn't matter as long as it works.The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.
I can understand what you wish for. But what you wish for is very far from what we’ve had so far. Time to accept reality.
It's pretty practical. I'm a developer. I deploy to multiple targets so I have them all. I test against them. Simple enough.
To talk to the point of the link here, what I distribute to MacOS I only have to worry about 1 interpreter because it's the one embedded on the OS (and at work, I can guarantee the version). The problem for me is Linux and whatever is bundled on the version of the distro that's currently running.
> This is a luxury and consequence of infinite compute resources.
It's a consequence of what I deploy to. If I only had 1 target and could guarantee it, I'd only need one.
Newer programmers have accepted this as "normal". It only started becoming this much ridiculous cumulative upkeep in the past decade or so. It's lazy. Lazy on behalf of the Python maintainers. And you keep accepting it instead of pushing back. You could have only one version, but you've been brainwashed to think having 5 versions of python on your machine is normal.
I'm not dissing version releases, just the adoption and deprecation. I wrote DirectX drivers for years, and going from DX3 to 5 to 7 meant backwards compatibility, and it was a PITA, but releases came out every two years and were deprecated shortly after so we didn't have vast quantities of exponential regressions. OpenGL was rock solid by comparison. The former was trial-and-error by MSoft, the latter was well thought out by consortium.
> Newer programmers have accepted this as "normal". It only started becoming this much ridiculous cumulative upkeep in the past decade or so.
Tell that to users of OpenSSL for the past two decades. Have fun when your dependencies use a different version. And yes, 0.9.7e is not compatible with 0.9.7g because semantic versioning be damned.
From the cost of testing, absolutely. By definition 5 version is 5x more testing. But since most python code is just crap thrown onto githubs and stackoverflow, who cares if it is regressed. But for devs trying to write solid, long-lived code, their cost of testing skyrockets. Python's LTS plan is not strict enough, and releases too frequent. As exhibit A, I give you their attempt at deprecating python2.
Regarding deprecating and moving away from Python 2, this has been discussed ad nauseam and the issues have been recognized around it. By the way, this wasn't a language issue, but an issue managing it.
Having said that, do you have any opinions or anything to discuss around the current plans?
It's a reality of pragmatism when different projects target different versions of the interpreter and there's no guarantee that different versions are not breaking some behaviour.
Better solution: Apple stops treating MacOS like a toy and gives it a proper package manager. I'm tired of hearing people float workarounds for a problem that can be solved by just holding Apple accountable for once.
Do you have a package being built from source instead of bottle?
Brew upgrade takes less than ten minutes or so for me. Things that influence this will be the amount and size of your installed packages and whether they have prebuilt binaries ("bottles") or if you need to build them from source. The latter is on your package maintainers.
Oh, Apple has a package manager - it's called the App Store. Opensource developers are just stingy and refusing to pay Apple $99 every year that Apple desperately needs to support it. /s
Is it really sarcasm? I have often seen workstations pre-installed with an OS and some specific software sold as « bundle ». ie in medical domain, cnc, video…
/usr/bin/php --version
WARNING: PHP is not recommended
PHP is included in macOS for compatibility with legacy software.
Future versions of macOS will not include PHP.
PHP 7.3.24-(to be removed in future macOS) (cli) (built: Dec 21 2020 21:33:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
I also remember having a lot of installation headaches when starting out as a developer because the preinstalled version conflicted with the version I was trying to install.
This seems like a net positive change to me and I hope they can keep dropping these built in languages.
Was this an issue with things preinstalled and trying to install your own or with trying to use your own after installing your own?
Wondering if it was really an issue with 2 interpreters or more of an issue with how the system works. More specifically PATH variables, shebangs and prioritizing your custom one over the system one.
Or... Apple upgrades the scripting languages regularly? I mean, they make updates that that gigabytes without changing anything, and then it's a problem to update PHP that is a couple of Mb? I don't think so...
PHP as a scripting language has to be the least relevant reason for retaining it. How is PHP remotely comparable to Python, Perl or Ruby for scripting. Not saying you can't do it but there are better options.
> More readable and writeable, and probably more popular in the past fifteen years.
You're confusing PHP's general popularity for web development with it's popularity as a command-line scripting language. There's no way PHP is more popular than Perl for non-web scripting. Unlike Perl, PHP was never designed as a general purpose language.
Try writing a PHP script which has to parse command line options. It ain't pretty. Python, Ruby and Perl were designed for this. PHP was not.
PHP is extremely fast for scripts written in raw, procedural PHP but its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.
> Try writing a PHP script which has to parse command line options. It ain't pretty. Python, Ruby and Perl were designed for this. PHP was not.
Worked just fine at the job where we had a ton of serverside daemons. You're saying like splitting a few strings and putting them in a dict is black magic, and as if Python, Ruby and Perl don't use some libs for that, which (hopefully) evolved over some time.
> its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.
A wild arbitrary goalpost appears! Even if Python is in any way comparable to PHP in ongoing execution (which I would like a lot but can't believe due to having some experience with that), we were talking about scripting, for which startup time with slim code matters, not ongoing performance with big frameworks. Cold startup time of Python is bad.
Checked now for good measure: turns out PHP 7 from MacOS isn't much faster than Python either from the system or from Brew, on a “Hello world”. However on a machine with a slow CPU PHP takes the lead; and especially PHP 8 is more than three times faster than Python. This vaguely contradicts my past experience on Linux, where I was never able to make Python as fast—maybe something iffy is going on specifically on Mac.
(However Perl does beat PHP by a lot, and even beats Lua on the slow machine—seems my latent hopes of using it for scripting were right, and I'll mourn its disappearance even more.)
You really have to know how it works to know what you're actually benchmarking, and if the numbers are even remotely related to what they would be on Linux. Unless the plan is to actually use in on Windows/Mac, ofc.
Option-parsing libs in Python, Ruby and Perl exist for a reason. There's more to it than "splitting a few strings and putting them in a dict" but if you don't know what you don't know stick with PHP.
> PHP is extremely fast for scripts written in raw, procedural PHP but its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.
That's not a flaw of PHP, it's the only correct design for a largely stateless and request-based thing like a web page. The flaw is the second-system effect of people thinking they needed a "framework" instead of a library, and producing something that can't have reasonable performance.
I benchmarked Laravel, Django and Symfony a year ago in a rather minimal setup on all three. From what I can remember, Laravel was a good amount faster than Django, and Symfony a bit faster than Laravel.
Take this and a basically every other benchmark with a huge grain of salt as the frameworks have quite different functionality enabled/installed out of the box.
Faster? LOL! Need speed? Use a compiled language. I rarely see a tool written in, say, python slow for what it was written for. From a user point 5ms vs 9ms in irrelevant.
With PHP the speed should not be CPU related, but instead IO. PHP IO is HORRIBLE, and a default setup using framework <insert here> usually peaks around 300-600 req/sec which is almost laughable in 2021.
Not that it really matters, but for CPU stuff numpy is multitudes faster than a PHP counterpart. Pypy also usually is lots faster than PHP for a given task.
300-600 req/sec with a default setup? That seems a bit low, unless it's a very slow framework or machine. Most frameworks are slow, but not that slow. I think ~2K+ rps was what I got when I did a comparison last year.
But, PHP IO is slow? What do you mean by that? A lot of things in PHP is basically just a wrapper for C, and it's really fast.
I'm really interested in why you think IO is slow.
The way PHP is built (start and die) on each execution. Compared to anything else, thats "running" PHP needs to do more work on each startup. This is also why its impossible to build a websocket server in PHP (without hacks like reachphp).
this is one of the main reasons PHP IO (read req/res) is slow. You can search for benchmarks if you so choose, and a basic setup for PHP is usually in the 300-600 req/sec range.
PHP long had decent performance, since version 4 iirc when it borrowed the bytecode approach from Perl and afterwards afaik was pretty much on par with it. Remember that even with FastCGI the vastly prevailing model of execution for PHP is to start the script just from the bytecode cache every time and destroy everything when it ends. Long-living async apps like with ReactPHP never became any kind of popular, and still PHP is likely the most popular serverside environment on the web (if only because of Wordpress).
Perl and PHP are both likely way better for personal productivity scripting than Python or Ruby, in terms of not waiting for them to get going already. Personally I would like it very much if Lua became as popular, though the absence of proper `null` is bothersome for data exchange.
If you're going to compare Perl with Ruby make it Perl + Moose then redo your benchmarks. Otherwise it's an apples to oranges comparison as Ruby has built-in OOP. Ruby was built on top of the best bits of Perl and with its blocks and metaprogramming it is arguably the most advanced scripting language. Python fails to match Perl and Ruby due to its half-assed lambdas.
PHP consists of an environment that can change the behavior of the program catastrophically just based on one configuration value (e.g. magic quotes). No one should be writing shell scripts using this language, especially if running on an uncontrolled machine.
As indicated by “e.g.”, that was given as an example. There are countless other parameters that change the behavior of the language. If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.
> There are countless other parameters that change the behavior of the language.
I call bologna.
If you stick to built-in methods and avoid extensions, really the most breaking thing someone is going to do is turn off `allow_url_fopen` off, and you can either work around that or just complain to the user that you need it and `exit(1)`.
> If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.
This is the most frustrating comment in this thread, imho. The _ideal_ is all code being distributed as readable source. Binaries are at best a sad compromise in the name of performance.
Why would you _desire_ the code you run to be an impenitible black box? I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.
> the most breaking thing someone is going to do is turn `allow_url_fopen` off
See [1]. "If PHP was compiled with --disable-url-fopen-wrapper, it won’t work." ... "But it will be printed if scream.enabled is set in php.ini." ... "exactly where it goes depends on display_errors, again in php.ini." There's so much variability in what an arbitrary PHP interpreter might or might not have support for, especially from 10 years ago.
> I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.
Then why not ship the source, along with an interpreter binary to run it in isolation? This is one of Lua's main use cases.
> Binaries are at best a sad compromise in the name of performance.
I disagree with this at a fundamental level because of the fact that binaries are what can be used by a computer. Anything that runs, is ultimately a binary, even if parts of that binary are generated dynamically. By adding a dependency of the environment (system PHP), it adds a layer of magic and unknowns.
> If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.
Why? It's more complicated, you need to compile different version for different operating systems and different architectures, if you have to update something you have to recompile it and typically to recompile it you have to install a development environment, versus opening the script and editing it.
Fair enough, good points. Really what I should have said is that if you're running on an untrusted system, it should be in an isolated environment (sandbox, container, etc.) which would preclude using a shared system binary. Statically linking your own executable would be another way to satisfy that constraint.
PHP is a pretty insane language though. I've started using Deno / Typescript for my scripting purposes and it is just a way way better experience than anything else I've used (and I have been searching for ages).
Pretty much every other option falls down in some way:
* Dart, Rust, Node etc. don't let you use just a single file like Python does.
* Python is very slow and it's type annotation system is better than nothing but is still the worst I have used.
* Everything except maybe Go requires you to list dependencies in a separate file, which rules out single-file scripts.
Deno is easily worth the installation effort, especially since it's so easy to install. You'd be really mad to stick with PHP.
Apple sells a couple hundred thousand computers that simply have to run a browser and show Facebook, for every one that has to have current PHP installed.
If you're developing anything and don't know how to configure your tools, I'm not sure what to say.
Do you understand the setup and configuration of every language of every tool you use? That seems impractical.
I use scripts written in Ruby reasonably often without _any_ understanding of how the Ruby ecosystem works. I just want to run the tool, and the tool happens to be written in Ruby.
There is zero arguments for having PHP bundled as default with the OS. It always ends up being an old PHP version, crippled with bugs, and now apple has one more thing to worry about in the update release cycle.
If someone really wants to still keep on using PHP its just a brew install away.
Suggesting "just" brew install php as in original post is silly to me.
You have to install homebrew first, which is a non-trivial task requiring root access.
It should be trivial to anyone needing it, and by extension anyone needing tools you usually install with homebrew. Unless this is the case you should not need PHP in the first place.
I totally believe you that PHP is a great general purpose scripting language to deploy mac CLI tools with, but this definitely feels like a https://xkcd.com/1172/ moment.
That's not a big deal. I imagine that the average OS user doesn't need Apache and PHP. People who do web development use Docker, because for any serious development you'd want your environment to match live one. And there's still an option to use brew or MacPorts to easily install all those programs.
I believe most macOS PHP developers use Homebrew. Some in combination with Laravel Valet for easy version switching and local domain management.
Docker is horribly slow on macOS. I'd wish that on no developer. We had to use docker for one project, but quickly decided to just run the tests in Docker and let the developers figure their environments out by themselves.
If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine.
That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts".
"Context" is anything in your working directory, more or less.
Another common slow down is bind mounts. Each file system operation is an RPC request between Docker for Mac and the Linux VM.
I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900
This is also true for Windows. WSL2 made containers faster, but FS is painfully slow. Sounds like the best thing (apart from switching) is running Linux in a VM (Hyper-V does OK) and having IDE, Docker and all the data in there.
> WSL2 made containers faster, but FS is painfully slow.
If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.
What I really had an issue with was the timespan between modifying a file in an editor (running in Windows) and the change being actually present in the container. I had to restart tests way too often because the old code was executing, which was really annonying, as sometimes you can't really tell if it failed because of the old code, or because the implementation was wrong.
The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine.
FreeBSD once had Docker working through the Linux compatibility layer. No virtualisation. I always thought would have been really cool to see that ported to macOS.
That depends a lot on weather the freeBSD compatiblity layer is kernel or user space as MacOS contrary to common space does not use an freeBSD derived kernel but one derived from the CMU mach64 project, and yes i know jobs said otherwise but he was never a trustworthy source for anything.
I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.
This continues to baffle me. I have an Apple laptop, I run macOS on my laptop, but I do all my development on a cloud VM.
I'm surprised to learn that there are developers out there, that have the cash for Apple hardware, but don't have the cash or connectivity to not run more than an IDE locally, with everything else happening remotely.
My devices (laptops, tablets) are all glorified thin clients as far as development work goes. The meat never happens locally.
Am I a rare case? Is there reasons why this isn't palatable to most people that I'm missing besides cost + connectivity? Are most people genuinely still not got the option of decent connectivity (either fixed or wireless or a combination of the two)?
> don't have the cash or connectivity to not run more than an IDE locally
It's not about lack of money. I prefer developing everything locally because it feels snappier to me, even with a good internet connection, or even a local server. It might not make a difference to you but that's what I prefer.
Thanks for the responses, it's why I'm asking, as I genuinely don't get it.
I think my view stems from the days of having to re-install my windows workstation every 6-12 months in order to regain decent performance, so moving as much as I can to be on a 'different host' (usually a local linux server) to minimise the pain of backups/restores when rebuilding the workstation.
You definitely do not have to re-install Windows every 6-12 months for decent performance. Just don't install every doodad and hopefully don't have corporate IT pushing 10 management applications running in the background.
Developing in a cloud VM is painful in other regards, specifically with regards to IDEs. Basically your options become to use a local IDE, with slow access to your files (not fun when PHPStorm needs to re-index your vendor directory), or to use a cloud IDE (none of which I know of are particularly good for PHP, nor as snappy as running your IDE locally).
Of course, you can just use a text editor instead of an IDE, but once you get used to being able to jump to definitions, get method signature autocompletion, refactoring, syntax checks etc, it's kind of hard to go back to just a text editor.
I’ve found the best middle ground is to use a Mac and then mostly develop in a local VM. Snapshots/etc are wonderful, and they can be transferred from machine to machine, so “setting up my development environment” is as simple as “install Parallels.”
> I prefer developing everything locally because it feels snappier to me, even with a good internet connection…
oarsinsync’s IDE is sending each keystroke from his local computer to a cloud machine, where the source code lives. That source code compiles, executes, is tested in the cloud. Is this the setup you’re comparing with?
The theory behind this is sound: “When the size of the program is smaller than the data, move the program to the data.” In this particular instance, the code edit keystrokes are smaller than the total amount of source code. If the complete source code, packaged or compiled program has to be moved to the cloud anyway, it saves a lot of data transfer to just move the edits.
This assumes you’re running your application in the cloud, and the trade-off is that you need a reliable network connection, otherwise you might find yourself unable to edit when the network is down.
I believe when latency is a concern then the calculous skews much more in the direction of providing feedback locally based on the data. For instance a reasonable strategy could be to make updates to the file locally in the ide in order to provide immediate feedback as the user types, but then send those updates to the server where other higher latency features such as code completion or diagnostics are run. Sadly I have yet to see such a setup.
I use "cloud" as a catch-all that covers local and remote VMs, that are all built using standard templates. My local VMs are LAN-local, not host-local. My remote VMs are all <10ms away.
My particular workflow involves running my IDE locally, and having files hosted remotely. My IDE is plenty snappy, running my code is plenty snappy, but I'm slowed down by a need to commit + push changes to a repository.
I have it on my stack to do something like syncthing to keep a local + remote cache without needing to explicitly go through version control, but I suspect that'll just shift the latency out of my workflow, and trip me up in different ways.
I do my dev locally. It's so much faster and I have a dynamic IP so the work of setting up a private VPN or resetting the firewall every day would drive me mad. I've been thinking about setting something up so I can do dev work outside during the nice weather on a highly portable but underpowered laptop, but so far my un willingness to go through the effort of setting it up exceeds my desire to have it set up. (In the past I've handled this quite fine with a powerful laptop. But right now my powerful laptop has zero nanoseconds battery power and the idea of discarding an otherwise working laptop bothers me on environmental grounds. It's approaching it's fourth year of life, but I can't find anything that obviously exceeds its specs.)
It also means I just don't have to worry about things when the internet goes down. Back in the olden days of working in an office (at a company where most people took the work at home option), I can remember how often the other staff would ask me "is the internet down" and my answer would be "I don't know, let me check". My home internet connection only seems to go down for the moment the the IP changes, but office internet connections seem to be subject to IT staff that need to constant change something, upgrades, who knows what the excuse is today.
However, I do my "local" work on a virtual machine or a docker container. I use GNU/Linux as the dev OS and as the test/production OS, but that's because I'm using what I'm comfortable with - there's no technical reason I should do it. My co workers have been quite productive using MacOS and Windows. This probably depends on your language environment: if you're using a JetBrains ide for your inspections, I think it's not hard to be OS agnostic. But when I've used LSP servers, they've typically expected to run locally, and similarity helps.
I don't know why doing development in Linux is a unpopular opinion.
I've been using Linux on my workstation and laptop for the past 20 odd years and I very much prefer it to the MacOS environment on the company issued Macbook.
Doing development in Linux is not an unpopular opinion.
People who do develop in Linux telling everyone else to develop in Linux because not developing in Linux is Wrong and Bad, however, tends to be unpopular.
The fact that Docker runs in Hyperkit/virtualization is not really the culprit for the slowness. That makes it a bit slower than native docker but virtualization is pretty good these days. The real problem is filesystem access. If you keep your volumes inside docker, it's pretty fast. Alternatively, you can try using NFS:
Use :delegated in the volume mount to speed stuff up.
Alternatively, if you are running Docker Compose, you can use two mounts and a volume. I'm assuming your application is a standard Symfony/Composer application, checked out in $HOME/Projects/foo:
1) $HOME/Project:/var/www
2) some-volume:/var/www/vendor
Then, once the containers are created, run composer install inside the container, and then either run it again on the host or copy the files over using docker cp so that your IDE picks up the dependencies.
For more complex stuff such as Drupal where you also have to account for web/modules/contrib, web/themes/contrib and the likes, you'll need to do the volume trick once again for each Composer-installed folder.
The result will be that the tens of thousands of files that Composer installs and each request requires will be inside the Linux VM without any performance impact, whereas the dynamic files you are using for development will be instantly available in the VM.
Long term I'd really wish if Docker for Mac/Windows could use inotify, on-demand synchronization plus a boatload of caching to get the performance issues under control. Oh, and while we're at it, it really really sucks that "host.docker.internal" is only available on Macs - you need that one to get xdebug to connect back to the "host", so you need two separate Docker Compose files, one for Mac developers and one for Linux developers.
> for any serious development you'd want your environment to match live one
Not sure what you mean by "serious", but I get paid for doing webdev (Rails) on an ARM Mac and we deploy to x86 Linux boxes and our only environment is Gemfile.lock, yarn.lock and roughly the same DB version. I don't remember ever having problems with that.
I got paid for years doing webdev before I achieved anything that I would think of now as "serious development". I'm sure I'll look back in another 5 years and think the same about my current self.
I'm not meaning to say that you yourself are not a serious developer, nor that webdev is not "serious development", but if you do this long enough you will encounter a problem that happens in production that can't be reproduced in your dev environment.
Yes, it's a good idea to have your development environment mimic production as closely as is practical, even if it's not something that you currently practice.
My objection to that is that in the long run it will make the source code less portable and thus limit my options and also may increase the risk when doing future upgrades.
I prefer if my team develops on different operating systems or Linux distributions and point realeses, not only for early catching of weird behavior but also usually this will in the long run eliminate any environment assumptions in the source code and thus create a cleaner code base.
If it is necessary to replicate an exact production behavior I have staging for that.
>I got paid for years doing webdev before I achieved anything that I would think of now as "serious development". I'm sure I'll look back in another 5 years and think the same about my current self.
Maybe your definition of "serious development" is whatever is around your current level instead of something objective?
I'm not sure that there's such a thing as an objective definition of "serious development", and my response clearly puts a spotlight on the subjectivity of the term, does it not?
Package-manager solutions tend to have a similar effect.
The "non-serious" sort of development mentioned was more where you'd be dealing with a large number of tools without any builder-tool to ensure uniform versioning.
There are many reasons to avoid using Docker, besides the fact that it is a dumpster fire managed by a failing company.
The new M1 macbooks couldn't even run Docker, which was enough to get the last holdouts of my dev team to switch to just properly managing their local environments.
Docker can be useful, but more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.
Docker has worked on M1 Macs since... mid-December of last year. Less than a month after they were released? Why was anyone on your "dev team" using M1 Macs within weeks of launch? At that point, even installing things with Homebrew required compiling everything from scratch. Not a very great use of developer time.
> more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.
This is like saying that an electric starter is a crutch, and Real Drivers relish the opportunity to spend 20 minutes using a crank starter to "properly" start their car's engine every time they need to go somewhere. No thanks. Like using a crank starter, managing a bespoke local environment is not some incredible skillset, even though you seem to be giving yourself a nice pat on the back for it. It's simply a questionable use of developer time, and doubly so if all of your production environments aren't identical.
Why is "dev team" in quotes? Seems like an odd thing to get pedantic about.
We have a BYOD policy, and several members of my team opted to get the new M1. They were junior devs who didn't know better not be early adopters. I agree that it was a huge waste of time, and Docker was a major contributor to that.
Your analogy about starters doesn't really make sense. We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety. Managing a local environment is a skill set, and frankly it is a skill set that many developers lack.
You can keep using docker if you want, I don't really give a shit. Its dead end tech that will be replaced in a few years by some new startup, while the *NIX systems using it will still be there and the developers reliant on docker will have to learn a new ephemeral skill set.
Why are you assuming devs who use Docker don't know how to manage a pretty simple LAMP setup?
It's easy, docker is a bit easier if you have multiple environments to deal with. If docker is gone in the next few years (lol) then we'll use the next one if it's easier too.
> We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety.
I do agree with this though, which is why I once built a server from scratch (as in physical parts) and put a website on it to find what I was lacking in "full stack"* -> installed the OS -> install and configure nginx, php, mysql, mail, sftp, bit of Zabbix to monitor the whole thing -> built a website to go on it -> made it live. Just for a laugh. At the time the only trouble I had was CSS :)
But aye, no skillset if docker dies haha
* Which later turns out doesn't include any of the build/install/OS/monitoring apparently. Full stack my arse.
WSL 1 uses picoprocesses, an idea taken from Drawbridge project [0][1], so not quite the original POSIX personality from NT, whereas WSL 2 just runs Linux on Hyper-V as guest, with some additional drivers for interoperability with Windows.
One great thing about Gentoo is that you can have multiple versions of packages like PHP, so you can run legacy and the newest, at the same time, on the same system, without having to deal with docker.
How? Is it because you compile it yourself so it's easy to specify an alternative prefix? How easy is it to use the version you want? (e.g. working on two projects simultaneously - say fixing a bug on production while otherwise working on compatibility with the new version).
The compiled binaries have a suffix, and you are able to select which binary you want for the default. So, `php` is set to say, `php74` or `php8`.
The suffix also applies to the config files and init scripts.
As far as running two versions on the same webserver, you just have to set up the config for each version to be on different ports or sockets.
Also, to clarify a bit, this is all using the Gentoo package manager, so you do not have to manually compile the packages, or manually create the symlinks.
In fact, thanks to consulting across .NET, Java and C++, targeting mobile, desktop and Web, I have plenty of tools installed and configured for each project.
You're an endangered species. I find it pretty funny how so many developers jump through so many hoops to avoid developing on the OS that's actually running the application in production. Apparently wasting many gigabytes of RAM on unnecessary virtualization, suffering from extremely slow IO, and constantly bashing your head against file permissions/network configuration/whatever else is so much more productive.
(Please don't waste your time replying with "I can't use X because of Y". The world does not need any more of these anecdotes. We've heard it all. If you don't want to be a part of the change, downvote and move on.)
With the right tooling and a good understanding of your tooling you can easily get away without docker or the like. Don't get me wrong, personally I avoid installing as much as possible and prefer containers, but it's not necessary if you have the knowledge, and the tooling. Especially with a scripted language like PHP that has most plugins bundled in most distributions.
> jump through so many hoops to avoid developing on the OS that's actually running the application in production.
lolwut? Most of us have been using homebrew longer than docker has been popular, often codebases older than that, too. If anything, it takes far more hoop jumping for the average user to run a full 1:1 VM on OSX.
Yeah I do use PHP but I'd rather put things on myself than have a bunch of preinstalled stuff potentially needing security updates
Also considering Mac's still on like bash v0.0.4 or something I'd rather be able to install the latest version of stuff as and when I need it (or use docker anyway making the whole thing moot as you say)
off topic: WHY does mac's `rm` not support the -rf flag being at the end of the command dammit. I don't trust myself putting it up front haha
But then if you are doing serious development, you should also be comfortable with Homebrew. Being a Ruby developer myself, I never used the bundled interpreter! This news is not that relevant. Obviously these runtimes are included because some packages or libraries need them, but I'd not depend on them for development.
This kind of HN elitism bothers me. PHP built its reputation on quick 'n dirty hacks which were easy to deploy on cheap hosting not by aping the infrastructure of some tech giant with fleets of servers, which is what Docker was originally designed for. The average PHP dev relying on the version which comes with the OS is most certainly not using Docker. Most home broadband upload speeds make Docker a non-starter.
If you don't have the energy to substantiate your counter, please don't use the little energy you have to post this kind of comments : snarkyness creates shallow and uninteresting conversations.
Yep, macOS is not an all-batteries-included Linux distribution. It doesn't need to ship with any programming language runtime that isn't strictly necessary for the OS itself to work.
Windows doesn't come with PHP, Python, or Ruby preinstalled, either.
Yep. And for that matter, why does a Linux distribution need them, either?
In the age of CD-ROMs shipped with magazines, sure including a 'blessed' version of most programming languages made sense. Saved the average Linux geek from needing to hunt down a separate (physical!) package for PHP or whatever.
Now, the same reasoning applies to Linux as to MacOS. Unless the OS itself relies on them (Perl?), including some random version of various PLs makes as much sense as including a bunch of shareware games.
Most Linux distros don't come preinstalled with PHP, Ruby, or node, either. You have to install it using the package manager, and you can use the exact same package manager to pull down different versions from different repos.
Honestly I wouldn't mind if some distros ditched the "blessed" version altogether for non-system languages. I can't remember the last time I used the default PHP in CentOS, it's always grossly outdated. But distros like Debian have a policy of packaging any open-source program they can get their hands on and keeping them up to date, at least when it comes to security fixes. It's their choice if they want to provide that service to their users, and many users like it.
I regularly set up servers using the stable PHP packages. If you sell a setup to a client then you want to provide an "expiry date" for the setup when the OS goes EOL. Stable packages kept up to date with nothing but security patches makes sure whatever you set up will run for X years without you having to worry about features being deprecated.
There's no need to have those versions pre-instaled though. As long as they can be installed with apt/yum then those who need them can install them.
Including programming languages makes it easier for kids and other beginners to get started programming.
Removing general-purpose languages from operating systems makes a certain kind of sense, but it also pushes further in the direction of computers being devices for consumption, not creation.
In fact windows made a big effort to remove all the unnecessary components (IIS, etc) to reduce the average attack surface, and offer them as additional features instead.
MacOS shipping with ruby/python etc allowed rich development tools like TextMate which became the template for modern text editors going forward to exist.
But I guess MacOS is more of a frontend for Electron apps now so it's less important when the logic is to just bundle everything needed in 1GB+ executables.
I was with you until that last sentence "Reduce footprint of OS" ... if you've seen the updates from macOS recently then a small footprint is not on their table (at all).
Probably even more reason they wanted to remove it along with the other scripting languages. All of which are better suited to be installed by the user to get the correct version they need.
Tragically this means the photo of my elePHPant plush will no longer be installed on all new Macs, nor be prevented from being uninstalled by System Integrity Protection.
(I'm not joking. PHP contains some very small PNG logos displayed in phpinfo(), one of which is an Easter egg that only appears on certain dates.)
EDIT: Ah, the Easter egg logo was changed with PHP 8. Well, some other elePHPant gets to be sad instead. :p
$ php --version
WARNING: PHP is not recommended
PHP is included in macOS for compatibility with legacy software.
Future versions of macOS will not include PHP.
PHP 7.3.24-(to be removed in future macOS) (cli) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
Looks like the same is said for Python, Ruby, Perl and all other scripting languages on MacOS too.
Apparently Apple prefers compiled binary for everything.
Am not complaining. The included Apache/MySQL servers were too old and I had to install those anew. But that always collided with the stock installed one.
It's good that Apple getting rid of those. Install what you need afresh.
>Apparently Apple prefers compiled binary for everything
If you're an Apple exec it's hard to ignore that iOS succeeded fine with just bundling everything into self contained apps. They definitely see this is as the future and the old model as the past.
There's a different comment here in this discussion from someone else that quotes the relevant text. Check that. Running the commands won't. But said elsewhere.
PHP 7.3.24 was released just two weeks before macOS 11's general availability.
If their policy is to freeze whatever version they could get their hands on at release time and ignore security fixes afterward, I would say good riddance. Third-party repos would do a much better job.
PHP is not recommended... wait, what? I can somehow understand the lowercase version / command, as in - we're phasing it out. Get it somewhere else. But giving the thumbs down to one of the most popular web dev languages out there is - I'm at a loss for words really.
But it is in such case a strong confirmation about how people are losing conscience of language (not a good thing to sacrifice, in terms of priority - it is very related to thought pollution), and awareness in general, and awareness, attention and quality as values. A progress towards "shallow as a new normal".
I am teaching a web-development course with PHP at university. Since PHP was preinstalled on MacOS in a ancient version, it was extremly hard for freshmen to get their mac prepared for the exercices. Windows users had a very simple start, basically just downloading and extracting a zip file from php.net... This seems to be good news for me, however most students have older macs so this will propably take some time to take effect...
That also requires installation of Homebrew. Not like it's the end of the world or anything but it's still another step to go through for someone that's just starting out in webdev. Back in the day I remember all-in-one LAMP stack apps for Windows that made it very, very simple to get going (and if I recall didn't require admin permissions either).
It sure does, and that's certainly a drawback versus a solution that's preinstalled — but if someone is going to become a webdev on a Mac, they will be unable to depend on preinstalled scripting languages and so any manner of instruction that requires a working go/node/python/ruby/perl installation will be forced to either use Homebrew or to handcraft replacements for Homebrew.
I would consider teaching students the skeletal basics of Homebrew to be a valuable pillar of their ability to perform webdev workplace duties using a Mac.
I would consider teaching students the deep details of trying to build their own python and ruby on Mac to not be a valuable pillar of their ability to perform webdev workplace duties using a Mac.
So I don't see how there's any alternative to Homebrew, not if they want to prepare their students for today's reality. "Use what's preinstalled with a Mac" is no longer a viable solution, and in my best judgement Homebrew is the minimum work necessary to get them from zero to ready. If there are alternatives that are as simple as Homebrew to have students deploy and maintain as a teacher, we'd all love to learn more about them.
In my experience, Homebrew is usually the simplest route and should be the first choice for people just starting out. It's one simple "extra" step at the beginning that saves you from multiple, more complex steps later on.
If Apple doesn't want to be in the business of keeping Python up to date, I can't possibly imagine them wanting to be in the business of keeping one thousand Pythons up to date.
On MacOS most of the files that makeup the system are now write protected (not just the file permissions, but something called "System Integrity Protection" or SIP). So you can't overwrite them. You can add a new install, but then you have to know how to change your $PATH to view that location first. That is just one more thing you have to know.
Apple did start to have a binary in the default location that was really a chooser that would respect per-user settings and re-direct you (exec) to the "right" install, but they seemed to have backed off on that.
Why are universities still teaching PHP? Is this a “programming” class or a specifically a PHP class that they offer for people who want to learn that particular language?
Please don’t frame your personal opinions as assumption-laden questions. If you think PHP isn’t worth it, then say that directly and openly. Framing your belief as a loaded question is not conducive to good discussion.
As a self taught, PHP was much more friendly to start with than anything else. Ruby and Python are close and would be better except that underestimates the learning hurdle with OOP and learning about libraries, etc.
I don't even understand why they included PHP in macOS to begin with. Perl? Python? I can understand, they are used by millions of projects and tools. But PHP? I've never seen a single CLI tool written in PHP, except the Phoronix Test Suite.
This makes it sound like it's personal against PHP, but really apple removing these baked in languages is a great thing. I've run into so many problems with the builtin python install, especially with SIP. Not so much fixing my machine (I always use a venv), but other peoples. This is just fixing a bad mistake.
I guess this is a more niche version of tabs vs
spaces, vi vs emacs, etc, but I’m surprised that HN (maybe the dev community in general?) mentions and seems to favor homebrew so much over Macports.
I’ve always used the latter, seldom had any problem with it, and found the community great when I did. I prefer it because it installs everything related to it in its own directory totally separate from the default OS, in one place. I find that more organized. There’s been times where there was no homebrew equivalent for a macports package. Also I remember hearing (if I’m not mistaken) that macports was used more internally at Apple(?)
In any case I’m surprised it’s not more 50/50. It seems more like 95% of macos package manager mentions are homebrew.
> I’m surprised that HN (maybe the dev community in general?) mentions and seems to favor homebrew so much over Macports.
I'm surprised that you're surprised. I use Macports but almost everything I encounter gives Homebrew install instructions up front (Macports is rarely mentioned, even if there is a port available).
Additionally, I find that while the docs for advanced Homebrew use are poor, they do at least have the basic everyday usage well-documented up-front. Macports approach of providing long, detailed & comprehensive contributor-oriented API docs and almost nothing simple & accessible for daily users makes it really intimidating for new users trialling it.
I looked on MacPorts for some of the software I use, but none of it is not available there. Does it only have packages for open-source, command line applications? If so, it's not going to compete with Homebrew.
Won't homebrew be need to be re-written in a compiled language now and embed a ruby interpreter after Apple removes scripting languages (except Perl) ?
Then people can go back to Fink, which existed before Homebrew (and MacPorts) and actually worked better. Literally the only reason people moved to Homebrew is that a bunch of Ruby on Rails developers bought Macs and Homebrew was written in Ruby while Fink was Perl scripts over dpkg.
I always liked that macOS gave you a version of these scripting runtimes. Not a great one, not the latest one, but one. Being able to run a quick Python script without installing things on someone else's computer was always convenient. It'll be sad to see these all go.
I use Python scripts every day, dozens of times a day, on Mac OS. I’d still prefer not to have Python integrated. Having multiple random versions floating around on the system (v2 plus a random v3 if you have Xcode installed) has been way more of a headache than it’s be worth.
I would much rather just have Mac OS come without Python and set up pyenv myself.
See, this is kind of the opposite situation, because you can bother to install a good Python that suits your needs. I’d just like a Python for the times I am at my mom’s computer and need to write a quick script, and I don’t want to install anything just for that. For conflicts: I wish Apple let you uninstall the “system” versions. But I still would like to keep them.
As someone who works with PHP on Mac OS, the installed version was nothing more than annoyance you have to deal with if you're using the actual runtime. Otherwise, used Docker and ignored it.
It's strange that this comment chain is trying to teach agys about how to use SimpleHTTPServer when their comment says they tried it and it didn't work for them.
Both Python (v2 and v3) servers work more or less but they have an issue: the first page load takes about 30 seconds on my machine, usually. I never figured out why exactly and that’s why I started using the PHP server.
As a full stack developer who works on tons of PHP and Laravel projects…I don’t care. It’s the 3rd thing I install on every new machine: Firefox, Homebrew, then latest version of PHP. This will have an effect on developers who create tools that rely on PHP but I’m not sure how big of a market that I’m really is so ok.
I never really understood why Apple included php, ruby, and python (and others?) on Macs. Mac was never advertised as a "batteries included dev environment" nor were any core applications relying on those languages (minus python, at least from what I understood). So why include it instead of asking the developer or engineers to bundle/install it?
I know Linux often relies on python and perl scripts, so it makes sense to include them in the base system. But there's no reason to include them in the base system if they're not used.
You pretty much don’t want third-party apis/tools/apps bundled with an OS.
It may seem convenient at first, but:
- updates are subject to the release schedule and priorities of the OS — which are unlikely to match yours are all your apps.
- when you end up going your own way anyway, you have to fight the OS over how to manage tools that it’s also trying to manage.
Whether it’s PHP, Vulkan, or whatever, you do not want it strictly tied to the OS.
Can we remove all of the BSD subsystem and replace it with busybox please? Way less surface area for vulnerabilities and it’s more likely to be up-to-date if there’s only one binary which needs updating.
GPL has a lot of other considerations when mixed with proprietary code however which makes it a very unpragmatic choice for commercial software companies who may be bound by multiple licenses.
That’s excellent news. The included scripting languages in macOS have always been a nuisance to deal with.
I agree that they keep something like python2 around for scripting, but that’s about it. Having to get around the included languages is a bitch every time I’m trying to set up a development environment.
Echoing others here, I honestly prefer this than dealing with outdated defaults built into the OS. More often than not they just get in the way.
The real bummer is for newcomers. It's going to make getting started much more of a headache since they first need to learn how to setup a local environment.
this, to me, is a non-issue. I certainly don't need my desktop system to ship a php binary when the language itself is a fast moving target these days.
You know what I'd rather Apple do? Ship proper control group and namespace support within XNU so it can be containerized. People have been asking for this for a while:
I’m a little surprised to see the resistance against this. I remember wishing it wasn’t bundled with the OS a decade ago. I used the languages, but never the version that came with the OS.
I found that the learning curve is pretty much same. I struggled the most with setting up the wsgi file.
But online documentation is really good because many people are using it.
I wonder if they'll remove wish. I always thought it was really cool that you could just sit down at any mac and hack out a quick app prototype in vim/wish without installing anything.
Thanks for sharing.I found a lot of interesting information here. A really good post, very thankful and hopeful that you will write many more posts like this one. https://www.tellthebell.app/
It sounds like they continue to boil the frog slowly.
If you look back 10 years and compare the Mac OS then and now, would you have accepted the change in one version? Probably not.
This will continue until Mac OS and iOS are unified and to develop for this new OS you need a hardware dev kit.
MS will probably try the same but will not succeed since they don't control the hardware.
The only thing that's happened over the last 10 years is Apple execs saying they're not going to do that, not doing it, and then people saying they're going to do it next year and not apologizing when it still is not true.
PHP was included with macOS? Wasn't that a huge security risk?
Normally you try to keep a system as small as possible, especially regarding scripting languages, so an attacker has as little tools as possible available.
I doubt any attacker is going to think "oh no, no PHP here, going to have to use Python!". If your security relies on not having an interpreter installed, something is badly wrong.
It was often a not up-to-date version and not updatable without a macOS update, but it wasn't used much, or even at all: I don't know any system script that would use it, and any web developer would use another setup anyway.
So since it's not used (in a webserver for example), it's not as much more a risk than shell scripts I guess.
"Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)"
Found via https://mjtsai.com/blog/2019/06/04/scripting-languages-to-be...
python
irb
php --version
tclsh
For PHP, it also shows up in Apache's server string:
Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname
Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.
I don't like how Apple handles this. If you have the developer tools installed, it's not especially obvious what is part of those tools and what is actually bundled with the OS. And so it's not surprising that some scripts I've come across will silently break in semi-odd ways without the dev tools.
Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?
There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage).
OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about.
> Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?
Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not).
The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.
/opt
> The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.
* https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/opt.htm...
MacPorts uses /opt/local for example.
The LFS spec you linked to is actually ancient at version 0.65, the latest is 3.0 and available here[1]. It's a bit "do what you want", but it really expects the "local" part of /opt/local that MacPorts uses to be some sort of identifier for MacPorts.
That said, it's the Linux Filesystem Hierarchy, so it only applies to Apple stuff inasmuch as it's common practices for UNIXes in general. And it's not like the major Linux distros follow it fully either. They're happy to break from it where it preserves some historical layout their OS has had that they think is easier for their users/admins.
1: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
Previously, lldb's extension language was python2. This changed a release or two of Xcode ago. At that time, to use lldb scripts with that new release of Xcode you either had to run on Catalina (which added python3 to the existing python2) or install your own python3 and point lldb at that. This actually was what pushed me into moving to Catalina on my development system, because the Unicode handling would be much easier in python3.
As I understand it, Monterey and the Xcode that is released for it move the necessary python3 installation from the operating system itself to Xcode. I'm fine with that.
(I would not be fine with Apple telling me I have to go waste my time figuring out how to install a suitable python myself, when I never had to before. And indeed, many of their own developers may be like me and know a little Python but are in trepidation of the env thing.)
The way it was before meant that if they wanted to update python they had to release a new version of the operating system. This is clearly an imposition on the vast bulk of macOS users, who are not developers.
So there needs to be a shell, and that's zsh now.
Apple switched to zsh because they're allergic to later GNU licenses and the version of bash they were shipping was absurdly out of date.
Possible approaches that would be less confusing than what we have today:
1. Ship Python 3 with macOS.
2. Ship all of the command-line developer tools with macOS, including clang et al.
3. Bring back the Snow-Leopard-era /Developer folder, and put developer tools there.
4. Put developer tools in /usr/developer, or /usr/local/developer, or /usr/local/Apple, to balance both UNIXness and clarity.
5. Don't ship Python at all. The Python foundation already distributes a .pkg installer for Mac. If xCode needs Python, follow your own Human Interface Guidelines and put it in the Application bundle.
All of these approaches have downsides, but I still think they'd be clear improvements over the current situation. Which is to say, I want Apple to figure this out!
At the time the GPLv3 was written, the GPLv3 was deliberately crafted to put commercial companies into a conflict situation.
(A) Give up selling audio with DRM (DRM did go away) (A) Give up selling video with DRM (A) Give up using HDMI as an output port (A) Give up using digital signatures to secure the integrity of software
-OR-
(B) Give up using GPL v3 software, GCC, Bash
Pretty sure most customers actually want many of the things in (A) and a minority actually care about (B). The items in (B) can be post-installed by those that really want it. Sure those in (B) have a loud voice, but, HN, are they really representative (democratically a majority)?
How would you make the choice between (A) or (B)?
I would bet that if a subeoena for FSF/GNU email was issued there would be a lot of messages related to manipulation and coercion for licensing and re-licensing. The sort of stuff, when associated with companies turns into scandal, lawsuits and monopoly investigations. (GCC almost got to be what could be considered a monopoly compiler)
I do believe that open software has a place and is a really good choice. My opinion is that the GPLv3 is completely toxic, spawned from negativity and is ultimately anti-open source. I will never release any software under the GPLv3.
Does GPLv3 really prevent an OS from doing those things? I think it would just prevent it in the same executable as GPLv3 software?
I don’t actually understand Apple’s “allergy”. On the iPhone I’m sure they object to the Tivoization clause (which coincidentally is why I like to use GPLv3), but I’m pretty darn sure macOS doesn’t fall afoul of anything...
Python 2.7 might be there because old software is there for compatibility reasons for software possibly for mathematical software that never really gets updated. Removing it in future versions makes sense because of the fact that if you haven't updated it won't work on ARM Macs.
The best way to make someone upgrade is to deprecate and then remove access. At minimum the worst case scenario is they roll their own and install Python 2.7.
How exactly is the above supposed to work when /usr/bin/python doesn't exist. If Apple chose to break the #! contract by doing something else, how would you feel about that?
This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.
What about Python2 v.s. Python3?
This isn't true and cannot ever be. This happens for other scripting and interpreted languages.
This approach means that the burden of choice and setup is transferred 100% to the person running the script. If you have 2 scripts that require different dependencies, then you will encounter this problem. I think it is this that encourages folks to include hard coded paths to enumerate explicit dependencies.
Lots of the "package" managers for these scripting languages also don't deal with this very well. They advocate a "do it my way" or "do it yourself". Different languages do it different ways.
Ultimately, the person wanting to run the script, just wants to make it run -- they will follow the instructions to make it work and along the way will make "global" changes -- which will impact what will happen for any other script in the future. This will likely be diverged from anyone else who has a "base install".
The above is mostly about my observations with using Ruby, not Python. However, few attempts in using pre-packaged complex python "recipes" has always resulted in similar conflicts.
Practically speaking, how does using env versus the absolute path make this any better or worse? You as the script author don't know what version of Python/Ruby/Bash/etc lives in /usr/bin. Maybe you could do some kind of automagic detection based on the user's OS, but any such assumptions are likely to go stale over time.
All env does is give users a choice about where to put their binaries. The versioning situation is a real problem, but I don't think using env makes it better or worse.
there is a TON more you can do with powershell than you can with bash. Plus object pipelines are superior to text pipelines
You can also install Powershell on Linux. So I would say Powershell is the Powershell of Linux
I really have no issue with Apple trimming down the surface of the OS to a minimum.
I don't know if any "native" apps have leveraged them, though. That would be the real risk of disruption.
Also, as someone who never uses PHP, I'd really rather not have it on my machine. Scripting languages are a pretty big attack surface, even if it's just to pivot after initial compromise. I'd rather not have one there that's not being used.
It is weird to me the number of times 90's Linux Distros used Perl for things that are easy in awk, awk for things that are easy with cut, and other commands for things that are easy with POSIX shell baked-in facilities. I guess I'm just a shell snob.
So because you can't trust cut to do what you want, you'll probably reach for something like awk '{print $3}' instead.
Most of the time the script doesn't get more complicated and it's fine with cut/sed/wc etc, but at some point it tips the balance and I grumble to myself.
Even those tools suffer from Apple's lack of fucks given. I often have to replace included system commands with the homebrew equivalent because Apple's is missing some common functionality.
I wish Apple would just adopt homebrew as a firstparty package manager.
Before someone shares some bizarre workaround: no thanks.
It also broke so I uninstalled it. When I need to I go straight to their formulas and install by hand, as a non-admin user.
I think it's a difference in philosophy? Brew does a "good enough" job for the most common use case, supplementing Apple's janky *nix environment with commonly-needed tools, without a built-in package manager. It doesn't try to do complex simultaneous versions... in my (admittedly limited) experience, if you need to do that, you either do that in something like a project-based setup (npm/composer) or in a VM/container with its own packages.
In your situation, when you have multiple pythons running in the same environment, how does anyone given script know which one to call? What's a better way of doing this?
From the horse's mouth
You can also install it on Linux if you wish.
• https://github.com/Homebrew/brew/issues/10127#issuecomment-8...
• https://github.com/Homebrew/brew/issues/11275
Usually it's one or the other.
Integration with their other hardware devices is the more important moat right now, as is hardware.
I’ve always wanted to use Nix and have tried to get started a few times. It has always ended up seeming more trouble than it’s worth.
* Nix doesn't have support for GUI apps like homebrew cask does - which meant I couldn't drop homebrew anyway. * The nix ecosystem forums suggest using nix-shell for managing packages for other languages, eg. python, java - but it's been really difficult to convince team members to use nix instead of pyenv, conda, gradle etc
Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.
There's a whole lot more to Unix and open source than GNU. macOS has current versions of many open source tools, such as zsh, awk, sqlite, tar, git, and xz.
If one is being pedantic, GNU is not even "open source" but rather is "free software," and macOS certainly is not free software.
On Linux, sure, but not on other Unix OSes (like *BSD)
I'm not saying it's an easy problem to solve. Just that Apple aren't dropping support out of respect to their customers. They're doing it because it's cheaper.
Apple seems to be really good at maintaining their profit margin.
Here, they not only realized it had become popular, but GNU licensing gave them an excuse to switch the default without much thrashing about.
The fact that I can `chsh -s /usr/local/bin/zsh` and macOS doesn't freak out is quite nice.
https://www.opengroup.org/openbrand/register/brand3668.htm
This is very subjective. I, for one, much prefer kde plasma. And there's a substantial breed of developers who would prefer a tiling window manager with good keyboard navigation, such as i3.
https://www.opengroup.org/openbrand/register/brand3668.htm
Windows Subsystem for Linus sure has been a game changer!
And while you can still find an traditional unix(tm) box here and there in the dusty forgotten corners of enterprise serverooms(i am personally responsible for maintaining a few hpux boxen), unix(tm) certification haven't really mattered since Linux became serious business which happened around the same time OSX was launched.
What used to matter was that you could run the same CLI tooling in an macos desktop as on an Linux server but i don't think this is an use case apple see's as particularly important for the future success of Apple.
It’s not as if they want their CLI interaction to be 1-for-1 with Linux, but relatively close seems to still be a priority.
Precovid, on any conference I went to, professional or academic, the amount of Apple laptops was insane. I'm sure they're running things locally or on Linux servers, but the fact that they work pretty well between them is important.
Actually, it would cost them a lot, due to the GPL. Sure, they could try and pull a Google re: Java/Oracle feud, but I doubt they will and for good reason.
They aren't for you. Move on.
The Google bit is particularly goofy. No, "Google" doesn't even appear on the charts (you know -- the charts which Apple usually is within the top 2, often leading). Chromebooks do, sold by a wide variety of sellers, as a schoolhouse special. Their great for what they do.
IT's an trip the classic macos took before it and i think there is an signficance in apple returning to the MAcOS branding thats subly hinting that the days when OSX was an relatively open unix is ending.
But it might help Apple to win government contracts.
% perl -de1
WARNING: This version of perl is included in macOS for compatibility with legacy software. In future versions of macOS the perl runtime will not be available by default, and may require you to install an additional package.
However, how come things break when Perl is upgraded? From what I've heard, Perl should be extremely backwards compatible. What am I missing?
https://perldoc.perl.org/perl#History
Those aren't an "incompatible changes seection".
perldelta covers bugfixes, feature additions etc.
Hint, use LWP.
Dude, there is literally a link with references.
Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.
I will often use the system perl to bootstrap https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx for managing per project environments if I need that
The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install.
> Python, Ruby, and Perl
The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves:
Conclusion: Apple is a Perl shop.And of course compile their scripts into executables or something.
It "lowers the friction of curiosity".
(And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).
I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc.
(There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)
Or default python2 breaking stuff that assume you have a recent install
Dropping PHP is irritating because PHP is actually a really good shell scripting language and it’s universal availability on macOS made distributing simple CLI tools for Mac written in PHP as a simple script or a bundled PHAR easy as pie.
I have a decent number of macOS specific tools I distribute as PHP, many 10+ years old, and I can guarantee almost none of my users have any idea what PHP is let alone how to install it.
For end users, the interpreter can be bundled with the application, that is much more stable for everyone.
As long as it's trivial to install after purchase, the removal of this sort of thing is in no way concerning to me. When I've written things natively on my Mac, I've almost ALWAYS had to go get an updated version of perl / python / ruby / whatever to get current.
I currently have over 5 different python versions installed to be able to test against them. The different software I work gets deployed to different environments and I have all those versions installed locally to test.
For end users, it doesn't matter as long as it works. The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.
The interpreter can be bundled with the application, of course. But now you have n different interpreters with their own php.ini files and their own set of things to change. Upgrading the application means overwriting those files and causing more pain when they have to figure out why something stopped working.
But it wouldn't be stable. Or it would be, but it would be hopelessly out of date.
Apple can either keep the bundled interpreters on the same version forever, or they can update it with the OS. Do the former, and it becomes hopelessly out of date. Do the latter, and software updates randomly break stuff.
Either the language developers need to actually keep their languages stable, or everyone else just needs to get used to keeping multiple versions around.
I think you need to define "out of date".
Out of date for me means not receiving security updates and stale. I think you mean not the latest version and stable for me is better in a production environment.
Google example, look at Debian stable.
Well, look at this way—the latest consumer version of macOS still comes with Python 2.
How do you stop the latter from becoming the former? When do you make the switch?
And remember, `/usr/bin/python3` wouldn't exist on your system (as more than a stub) if you hadn't installed the developer tools.
I can understand what you wish for. But what you wish for is very far from what we’ve had so far. Time to accept reality.
That's absurd. Five versions of the same language. Each with their own package folders. That's at least 15 GB.
This is a luxury and consequence of infinite compute resources.
How come?
It's pretty practical. I'm a developer. I deploy to multiple targets so I have them all. I test against them. Simple enough.
To talk to the point of the link here, what I distribute to MacOS I only have to worry about 1 interpreter because it's the one embedded on the OS (and at work, I can guarantee the version). The problem for me is Linux and whatever is bundled on the version of the distro that's currently running.
> This is a luxury and consequence of infinite compute resources.
It's a consequence of what I deploy to. If I only had 1 target and could guarantee it, I'd only need one.
I'm not dissing version releases, just the adoption and deprecation. I wrote DirectX drivers for years, and going from DX3 to 5 to 7 meant backwards compatibility, and it was a PITA, but releases came out every two years and were deprecated shortly after so we didn't have vast quantities of exponential regressions. OpenGL was rock solid by comparison. The former was trial-and-error by MSoft, the latter was well thought out by consortium.
Tell that to users of OpenSSL for the past two decades. Have fun when your dependencies use a different version. And yes, 0.9.7e is not compatible with 0.9.7g because semantic versioning be damned.
And how many versions of .Net Express are there installed on computers?
.
I'm a developer, not a user.
I develop for multiple platforms and targets. Not just one OS and implementation. That's why I, as a developer, need many. A user doesn't.
I'm okay with API's breaking and think that it's good and that's why things get versioned out.
Is the strict requirement of a single Python version really that much better?
Regarding deprecating and moving away from Python 2, this has been discussed ad nauseam and the issues have been recognized around it. By the way, this wasn't a language issue, but an issue managing it.
Having said that, do you have any opinions or anything to discuss around the current plans?
good luck with that
I use brew primarily only for packages that are only available on brew. I’m moving to nixpkgs for my packaging needs as soon as the M1 support drops.
Brew upgrade takes less than ten minutes or so for me. Things that influence this will be the amount and size of your installed packages and whether they have prebuilt binaries ("bottles") or if you need to build them from source. The latter is on your package maintainers.
I'm still using 7.x due to limitations.
This seems like a net positive change to me and I hope they can keep dropping these built in languages.
Wondering if it was really an issue with 2 interpreters or more of an issue with how the system works. More specifically PATH variables, shebangs and prioritizing your custom one over the system one.
Faster.
> Perl
More readable and writeable, and probably more popular in the past fifteen years.
> Ruby
Again faster.
You're confusing PHP's general popularity for web development with it's popularity as a command-line scripting language. There's no way PHP is more popular than Perl for non-web scripting. Unlike Perl, PHP was never designed as a general purpose language.
Try writing a PHP script which has to parse command line options. It ain't pretty. Python, Ruby and Perl were designed for this. PHP was not.
PHP is extremely fast for scripts written in raw, procedural PHP but its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.
Worked just fine at the job where we had a ton of serverside daemons. You're saying like splitting a few strings and putting them in a dict is black magic, and as if Python, Ruby and Perl don't use some libs for that, which (hopefully) evolved over some time.
> its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.
A wild arbitrary goalpost appears! Even if Python is in any way comparable to PHP in ongoing execution (which I would like a lot but can't believe due to having some experience with that), we were talking about scripting, for which startup time with slim code matters, not ongoing performance with big frameworks. Cold startup time of Python is bad.
Checked now for good measure: turns out PHP 7 from MacOS isn't much faster than Python either from the system or from Brew, on a “Hello world”. However on a machine with a slow CPU PHP takes the lead; and especially PHP 8 is more than three times faster than Python. This vaguely contradicts my past experience on Linux, where I was never able to make Python as fast—maybe something iffy is going on specifically on Mac.
(However Perl does beat PHP by a lot, and even beats Lua on the slow machine—seems my latent hopes of using it for scripting were right, and I'll mourn its disappearance even more.)
You really have to know how it works to know what you're actually benchmarking, and if the numbers are even remotely related to what they would be on Linux. Unless the plan is to actually use in on Windows/Mac, ofc.
That's not a flaw of PHP, it's the only correct design for a largely stateless and request-based thing like a web page. The flaw is the second-system effect of people thinking they needed a "framework" instead of a library, and producing something that can't have reasonable performance.
Take this and a basically every other benchmark with a huge grain of salt as the frameworks have quite different functionality enabled/installed out of the box.
With PHP the speed should not be CPU related, but instead IO. PHP IO is HORRIBLE, and a default setup using framework <insert here> usually peaks around 300-600 req/sec which is almost laughable in 2021.
Not that it really matters, but for CPU stuff numpy is multitudes faster than a PHP counterpart. Pypy also usually is lots faster than PHP for a given task.
But, PHP IO is slow? What do you mean by that? A lot of things in PHP is basically just a wrapper for C, and it's really fast.
I'm really interested in why you think IO is slow.
this is one of the main reasons PHP IO (read req/res) is slow. You can search for benchmarks if you so choose, and a basic setup for PHP is usually in the 300-600 req/sec range.
Perl and PHP are both likely way better for personal productivity scripting than Python or Ruby, in terms of not waiting for them to get going already. Personally I would like it very much if Lua became as popular, though the absence of proper `null` is bothersome for data exchange.
It’s just as valid a language for shell scripts as any other.
I call bologna.
If you stick to built-in methods and avoid extensions, really the most breaking thing someone is going to do is turn off `allow_url_fopen` off, and you can either work around that or just complain to the user that you need it and `exit(1)`.
> If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.
This is the most frustrating comment in this thread, imho. The _ideal_ is all code being distributed as readable source. Binaries are at best a sad compromise in the name of performance.
Why would you _desire_ the code you run to be an impenitible black box? I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.
See [1]. "If PHP was compiled with --disable-url-fopen-wrapper, it won’t work." ... "But it will be printed if scream.enabled is set in php.ini." ... "exactly where it goes depends on display_errors, again in php.ini." There's so much variability in what an arbitrary PHP interpreter might or might not have support for, especially from 10 years ago.
> I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.
Then why not ship the source, along with an interpreter binary to run it in isolation? This is one of Lua's main use cases.
> Binaries are at best a sad compromise in the name of performance.
I disagree with this at a fundamental level because of the fact that binaries are what can be used by a computer. Anything that runs, is ultimately a binary, even if parts of that binary are generated dynamically. By adding a dependency of the environment (system PHP), it adds a layer of magic and unknowns.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Why? It's more complicated, you need to compile different version for different operating systems and different architectures, if you have to update something you have to recompile it and typically to recompile it you have to install a development environment, versus opening the script and editing it.
Pretty much every other option falls down in some way:
* Dart, Rust, Node etc. don't let you use just a single file like Python does.
* Python is very slow and it's type annotation system is better than nothing but is still the worst I have used.
* Everything except maybe Go requires you to list dependencies in a separate file, which rules out single-file scripts.
Deno is easily worth the installation effort, especially since it's so easy to install. You'd be really mad to stick with PHP.
If you're developing anything and don't know how to configure your tools, I'm not sure what to say.
I use scripts written in Ruby reasonably often without _any_ understanding of how the Ruby ecosystem works. I just want to run the tool, and the tool happens to be written in Ruby.
If someone really wants to still keep on using PHP its just a brew install away.
I get it, it sucks that PHP has been getting badmouthed every time it's mentioned but let's not overcorrect.
In PHP you really need to know what version you are working with, otherwise weird stuff happens.
Docker is horribly slow on macOS. I'd wish that on no developer. We had to use docker for one project, but quickly decided to just run the tests in Docker and let the developers figure their environments out by themselves.
That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts".
"Context" is anything in your working directory, more or less.
I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900
If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.
The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine.
I may give it another chance, though. Thank you.
I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.
True of Windows too.
The overhead should be incredibly minimal.
It is a waste of time though. Just use Linux.
At least not as professional developers that don't want to fight the hardware, the OS <<and>> their development project.
I'm surprised to learn that there are developers out there, that have the cash for Apple hardware, but don't have the cash or connectivity to not run more than an IDE locally, with everything else happening remotely.
My devices (laptops, tablets) are all glorified thin clients as far as development work goes. The meat never happens locally.
Am I a rare case? Is there reasons why this isn't palatable to most people that I'm missing besides cost + connectivity? Are most people genuinely still not got the option of decent connectivity (either fixed or wireless or a combination of the two)?
It's not about lack of money. I prefer developing everything locally because it feels snappier to me, even with a good internet connection, or even a local server. It might not make a difference to you but that's what I prefer.
I think my view stems from the days of having to re-install my windows workstation every 6-12 months in order to regain decent performance, so moving as much as I can to be on a 'different host' (usually a local linux server) to minimise the pain of backups/restores when rebuilding the workstation.
Cheers!
Of course, you can just use a text editor instead of an IDE, but once you get used to being able to jump to definitions, get method signature autocompletion, refactoring, syntax checks etc, it's kind of hard to go back to just a text editor.
oarsinsync’s IDE is sending each keystroke from his local computer to a cloud machine, where the source code lives. That source code compiles, executes, is tested in the cloud. Is this the setup you’re comparing with?
The theory behind this is sound: “When the size of the program is smaller than the data, move the program to the data.” In this particular instance, the code edit keystrokes are smaller than the total amount of source code. If the complete source code, packaged or compiled program has to be moved to the cloud anyway, it saves a lot of data transfer to just move the edits.
This assumes you’re running your application in the cloud, and the trade-off is that you need a reliable network connection, otherwise you might find yourself unable to edit when the network is down.
My particular workflow involves running my IDE locally, and having files hosted remotely. My IDE is plenty snappy, running my code is plenty snappy, but I'm slowed down by a need to commit + push changes to a repository.
I have it on my stack to do something like syncthing to keep a local + remote cache without needing to explicitly go through version control, but I suspect that'll just shift the latency out of my workflow, and trip me up in different ways.
It also means I just don't have to worry about things when the internet goes down. Back in the olden days of working in an office (at a company where most people took the work at home option), I can remember how often the other staff would ask me "is the internet down" and my answer would be "I don't know, let me check". My home internet connection only seems to go down for the moment the the IP changes, but office internet connections seem to be subject to IT staff that need to constant change something, upgrades, who knows what the excuse is today.
However, I do my "local" work on a virtual machine or a docker container. I use GNU/Linux as the dev OS and as the test/production OS, but that's because I'm using what I'm comfortable with - there's no technical reason I should do it. My co workers have been quite productive using MacOS and Windows. This probably depends on your language environment: if you're using a JetBrains ide for your inspections, I think it's not hard to be OS agnostic. But when I've used LSP servers, they've typically expected to run locally, and similarity helps.
I've been using Linux on my workstation and laptop for the past 20 odd years and I very much prefer it to the MacOS environment on the company issued Macbook.
People who do develop in Linux telling everyone else to develop in Linux because not developing in Linux is Wrong and Bad, however, tends to be unpopular.
It's not.
https://www.jeffgeerling.com/blog/2020/revisiting-docker-mac...
Alternatively, if you are running Docker Compose, you can use two mounts and a volume. I'm assuming your application is a standard Symfony/Composer application, checked out in $HOME/Projects/foo:
1) $HOME/Project:/var/www
2) some-volume:/var/www/vendor
Then, once the containers are created, run composer install inside the container, and then either run it again on the host or copy the files over using docker cp so that your IDE picks up the dependencies.
For more complex stuff such as Drupal where you also have to account for web/modules/contrib, web/themes/contrib and the likes, you'll need to do the volume trick once again for each Composer-installed folder.
The result will be that the tens of thousands of files that Composer installs and each request requires will be inside the Linux VM without any performance impact, whereas the dynamic files you are using for development will be instantly available in the VM.
Long term I'd really wish if Docker for Mac/Windows could use inotify, on-demand synchronization plus a boatload of caching to get the performance issues under control. Oh, and while we're at it, it really really sucks that "host.docker.internal" is only available on Macs - you need that one to get xdebug to connect back to the "host", so you need two separate Docker Compose files, one for Mac developers and one for Linux developers.
Sigh.
It is certainly no longer a problem for my dev work since a certain docker version upgrade.
Not sure what you mean by "serious", but I get paid for doing webdev (Rails) on an ARM Mac and we deploy to x86 Linux boxes and our only environment is Gemfile.lock, yarn.lock and roughly the same DB version. I don't remember ever having problems with that.
I'm not meaning to say that you yourself are not a serious developer, nor that webdev is not "serious development", but if you do this long enough you will encounter a problem that happens in production that can't be reproduced in your dev environment.
Yes, it's a good idea to have your development environment mimic production as closely as is practical, even if it's not something that you currently practice.
I prefer if my team develops on different operating systems or Linux distributions and point realeses, not only for early catching of weird behavior but also usually this will in the long run eliminate any environment assumptions in the source code and thus create a cleaner code base.
If it is necessary to replicate an exact production behavior I have staging for that.
Maybe your definition of "serious development" is whatever is around your current level instead of something objective?
The "non-serious" sort of development mentioned was more where you'd be dealing with a large number of tools without any builder-tool to ensure uniform versioning.
A patently false generalization.
There are many reasons to avoid using Docker, besides the fact that it is a dumpster fire managed by a failing company.
The new M1 macbooks couldn't even run Docker, which was enough to get the last holdouts of my dev team to switch to just properly managing their local environments.
Docker can be useful, but more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.
Docker has worked on M1 Macs since... mid-December of last year. Less than a month after they were released? Why was anyone on your "dev team" using M1 Macs within weeks of launch? At that point, even installing things with Homebrew required compiling everything from scratch. Not a very great use of developer time.
> more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.
This is like saying that an electric starter is a crutch, and Real Drivers relish the opportunity to spend 20 minutes using a crank starter to "properly" start their car's engine every time they need to go somewhere. No thanks. Like using a crank starter, managing a bespoke local environment is not some incredible skillset, even though you seem to be giving yourself a nice pat on the back for it. It's simply a questionable use of developer time, and doubly so if all of your production environments aren't identical.
We have a BYOD policy, and several members of my team opted to get the new M1. They were junior devs who didn't know better not be early adopters. I agree that it was a huge waste of time, and Docker was a major contributor to that.
Your analogy about starters doesn't really make sense. We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety. Managing a local environment is a skill set, and frankly it is a skill set that many developers lack.
You can keep using docker if you want, I don't really give a shit. Its dead end tech that will be replaced in a few years by some new startup, while the *NIX systems using it will still be there and the developers reliant on docker will have to learn a new ephemeral skill set.
It's easy, docker is a bit easier if you have multiple environments to deal with. If docker is gone in the next few years (lol) then we'll use the next one if it's easier too.
> We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety.
I do agree with this though, which is why I once built a server from scratch (as in physical parts) and put a website on it to find what I was lacking in "full stack"* -> installed the OS -> install and configure nginx, php, mysql, mail, sftp, bit of Zabbix to monitor the whole thing -> built a website to go on it -> made it live. Just for a laugh. At the time the only trouble I had was CSS :)
But aye, no skillset if docker dies haha
* Which later turns out doesn't include any of the build/install/OS/monitoring apparently. Full stack my arse.
I also maintain a WSL Ubuntu setup to provide support for our windows developers. I suppose WSL is a VM.
[0] - httpss://channel9.msdn.com/Blogs/Seth-Juarez/Windows-Subsystem-for-Linux-Architectural-Overview
[1] - https://www.microsoft.com/en-us/research/project/drawbridge/
One great thing about Gentoo is that you can have multiple versions of packages like PHP, so you can run legacy and the newest, at the same time, on the same system, without having to deal with docker.
The suffix also applies to the config files and init scripts.
As far as running two versions on the same webserver, you just have to set up the config for each version to be on different ports or sockets.
Also, to clarify a bit, this is all using the Gentoo package manager, so you do not have to manually compile the packages, or manually create the symlinks.
I think this might be why there's a split, I use docker but I don't work on just the one site
In fact, thanks to consulting across .NET, Java and C++, targeting mobile, desktop and Web, I have plenty of tools installed and configured for each project.
How painful is that when you get a new computer?
One day downtime at most, thanks to IT images.
No need for super beefy hardware just to keep Docker happy.
(Please don't waste your time replying with "I can't use X because of Y". The world does not need any more of these anecdotes. We've heard it all. If you don't want to be a part of the change, downvote and move on.)
Docker is about 5 years time to become irrelevant, replaced by the next big thing(TM) in cloud deployments.
lolwut? Most of us have been using homebrew longer than docker has been popular, often codebases older than that, too. If anything, it takes far more hoop jumping for the average user to run a full 1:1 VM on OSX.
Also considering Mac's still on like bash v0.0.4 or something I'd rather be able to install the latest version of stuff as and when I need it (or use docker anyway making the whole thing moot as you say)
off topic: WHY does mac's `rm` not support the -rf flag being at the end of the command dammit. I don't trust myself putting it up front haha
Using Docker during development is not required and in fact not always ideal.
This kind of HN elitism bothers me. PHP built its reputation on quick 'n dirty hacks which were easy to deploy on cheap hosting not by aping the infrastructure of some tech giant with fleets of servers, which is what Docker was originally designed for. The average PHP dev relying on the version which comes with the OS is most certainly not using Docker. Most home broadband upload speeds make Docker a non-starter.
This is wrong in so many levels I don't even have the energy to start explaining why.
Windows doesn't come with PHP, Python, or Ruby preinstalled, either.
In the age of CD-ROMs shipped with magazines, sure including a 'blessed' version of most programming languages made sense. Saved the average Linux geek from needing to hunt down a separate (physical!) package for PHP or whatever.
Now, the same reasoning applies to Linux as to MacOS. Unless the OS itself relies on them (Perl?), including some random version of various PLs makes as much sense as including a bunch of shareware games.
But even for the non-critical software, packaged WP needs PHP, packaged Vagrant needs Ruby etc.
As for enterprise Linux, many customers relies on this packages, because they get reviewed and gets security patches on system updates.
Honestly I wouldn't mind if some distros ditched the "blessed" version altogether for non-system languages. I can't remember the last time I used the default PHP in CentOS, it's always grossly outdated. But distros like Debian have a policy of packaging any open-source program they can get their hands on and keeping them up to date, at least when it comes to security fixes. It's their choice if they want to provide that service to their users, and many users like it.
There's no need to have those versions pre-instaled though. As long as they can be installed with apt/yum then those who need them can install them.
Removing general-purpose languages from operating systems makes a certain kind of sense, but it also pushes further in the direction of computers being devices for consumption, not creation.
But I guess MacOS is more of a frontend for Electron apps now so it's less important when the logic is to just bundle everything needed in 1GB+ executables.
(I'm not joking. PHP contains some very small PNG logos displayed in phpinfo(), one of which is an Easter egg that only appears on certain dates.)
EDIT: Ah, the Easter egg logo was changed with PHP 8. Well, some other elePHPant gets to be sad instead. :p
Apparently Apple prefers compiled binary for everything.
Am not complaining. The included Apache/MySQL servers were too old and I had to install those anew. But that always collided with the stock installed one.
It's good that Apple getting rid of those. Install what you need afresh.
If you're an Apple exec it's hard to ignore that iOS succeeded fine with just bundling everything into self contained apps. They definitely see this is as the future and the old model as the past.
I just ran a version check on Python (2 and 3), Ruby, and Perl, and none of them said anything to the tune of "will be removed soon". (MacOS 11)
haha, I know it is a generic warning, but that is pure gold :D
People are weird.
If their policy is to freeze whatever version they could get their hands on at release time and ignore security fixes afterward, I would say good riddance. Third-party repos would do a much better job.
I would consider teaching students the skeletal basics of Homebrew to be a valuable pillar of their ability to perform webdev workplace duties using a Mac.
I would consider teaching students the deep details of trying to build their own python and ruby on Mac to not be a valuable pillar of their ability to perform webdev workplace duties using a Mac.
So I don't see how there's any alternative to Homebrew, not if they want to prepare their students for today's reality. "Use what's preinstalled with a Mac" is no longer a viable solution, and in my best judgement Homebrew is the minimum work necessary to get them from zero to ready. If there are alternatives that are as simple as Homebrew to have students deploy and maintain as a teacher, we'd all love to learn more about them.
Apple did start to have a binary in the default location that was really a chooser that would respect per-user settings and re-direct you (exec) to the "right" install, but they seemed to have backed off on that.
Please don’t frame your personal opinions as assumption-laden questions. If you think PHP isn’t worth it, then say that directly and openly. Framing your belief as a loaded question is not conducive to good discussion.
Simple answer: https://w3techs.com/technologies/overview/programming_langua...
What language would you pick for that?
I mean, it was far better than on Windows where you need to install some bundled package from a third party to just get hello-world running.
Not a big miss.
Brew install php
I’ve always used the latter, seldom had any problem with it, and found the community great when I did. I prefer it because it installs everything related to it in its own directory totally separate from the default OS, in one place. I find that more organized. There’s been times where there was no homebrew equivalent for a macports package. Also I remember hearing (if I’m not mistaken) that macports was used more internally at Apple(?)
In any case I’m surprised it’s not more 50/50. It seems more like 95% of macos package manager mentions are homebrew.
I'm surprised that you're surprised. I use Macports but almost everything I encounter gives Homebrew install instructions up front (Macports is rarely mentioned, even if there is a port available).
Additionally, I find that while the docs for advanced Homebrew use are poor, they do at least have the basic everyday usage well-documented up-front. Macports approach of providing long, detailed & comprehensive contributor-oriented API docs and almost nothing simple & accessible for daily users makes it really intimidating for new users trialling it.
I would much rather just have Mac OS come without Python and set up pyenv myself.
What was it used for? CUPS? something else?
Useful when coding small demos:
python3 -m http.server 8000
Both Python (v2 and v3) servers work more or less but they have an issue: the first page load takes about 30 seconds on my machine, usually. I never figured out why exactly and that’s why I started using the PHP server.
I would recommend installing PHP via brew https://github.com/shivammathur/homebrew-php
I know Linux often relies on python and perl scripts, so it makes sense to include them in the base system. But there's no reason to include them in the base system if they're not used.
It may seem convenient at first, but:
- updates are subject to the release schedule and priorities of the OS — which are unlikely to match yours are all your apps. - when you end up going your own way anyway, you have to fight the OS over how to manage tools that it’s also trying to manage.
Whether it’s PHP, Vulkan, or whatever, you do not want it strictly tied to the OS.
GPL has a lot of other considerations when mixed with proprietary code however which makes it a very unpragmatic choice for commercial software companies who may be bound by multiple licenses.
Guess it’s time to re-implement busybox in Rust with a non-viral license!
I agree that they keep something like python2 around for scripting, but that’s about it. Having to get around the included languages is a bitch every time I’m trying to set up a development environment.
The real bummer is for newcomers. It's going to make getting started much more of a headache since they first need to learn how to setup a local environment.
this, to me, is a non-issue. I certainly don't need my desktop system to ship a php binary when the language itself is a fast moving target these days.
You know what I'd rather Apple do? Ship proper control group and namespace support within XNU so it can be containerized. People have been asking for this for a while:
https://unix.stackexchange.com/questions/113471/cgroups-anal...
https://news.ycombinator.com/item?id=25447490
Do they still use CUPS for printing ???.
I never use the OSX standard version of PHP or Python
source?
Normally you try to keep a system as small as possible, especially regarding scripting languages, so an attacker has as little tools as possible available.
So since it's not used (in a webserver for example), it's not as much more a risk than shell scripts I guess.