[HN Gopher] PHP has been removed in macOS Monterey
___________________________________________________________________
PHP has been removed in macOS Monterey
Author : ingve
Score : 365 points
Date : 2021-06-17 07:33 UTC (15 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| eric4smith wrote:
| Yes back in the day whenever I used php it never had all the
| modules I wanted.
|
| Not a big miss.
|
| Brew install php
| user3939382 wrote:
| 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.
| saagarjha wrote:
| MacPorts got a lot of contributions from Apple people over
| the years, but I would be surprised if it was more popular
| even inside Apple these days.
| lenkite wrote:
| 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) ?
| astrange wrote:
| 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.
| lucideer wrote:
| > _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.
| vehemenz wrote:
| 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.
| akho wrote:
| I'm more surprised than you are. Nix is rarely mentioned at
| all, despite being better in most ways.
| j16sdiz wrote:
| This is the prompt I got running php in macOS11:
| $ 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
| dstick wrote:
| 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.
| detaro wrote:
| It's just a generic "this is deprecated and will be removed,
| don't rely on it" message, not a comment on the language...
| dstick wrote:
| I reference that in my post: lowercase "php" would refer to
| the command. Uppercase "PHP" to the language.
| mdp2020 wrote:
| 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".
| habibur wrote:
| 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.
| gregoriol wrote:
| Or they just don't want to maintain/update those components
| because there are much better and up-to-date ways to install
| them.
| maratc wrote:
| > Looks like the same is said for Python, Ruby, Perl and all
| other scripting languages on MacOS too.
|
| 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)
| habibur wrote:
| 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.
| whywhywhywhy wrote:
| >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.
| slver wrote:
| It's not the best way to phrase it.
| mfollert wrote:
| > WARNING: PHP is not recommended
|
| haha, I know it is a generic warning, but that is pure gold :D
| cies wrote:
| Like gold? This is where the rainbow leads to:
| https://www.reddit.com/r/lolphp
| kijin wrote:
| 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.
| saagarjha wrote:
| 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.
| D13Fd wrote:
| 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.
| robotron wrote:
| 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.
| saagarjha wrote:
| 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.
| donatj wrote:
| 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.
| [deleted]
| cutler wrote:
| 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.
| aasasd wrote:
| > _How is PHP remotely comparable to Python_
|
| Faster.
|
| > _Perl_
|
| More readable and writeable, and probably more popular in the
| past fifteen years.
|
| > _Ruby_
|
| Again faster.
| gizdan wrote:
| I never thought those reasons would ever be valid until PHP
| 7.
| aasasd wrote:
| 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.
| red_hare wrote:
| 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.
| smm11 wrote:
| 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.
| donatj wrote:
| 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.
| xyst wrote:
| Convert to go, distribute binaries instead :)
| ironmagma wrote:
| 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.
| jw1224 wrote:
| Magic quotes were removed from PHP entirely back in v5.4...
| and we're now on v8.
|
| It's just as valid a language for shell scripts as any other.
| ironmagma wrote:
| 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.
| donatj wrote:
| > 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.
| ironmagma wrote:
| > 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.
|
| [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
| design/
| alerighi wrote:
| > 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.
| ironmagma wrote:
| 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.
| ashtonkem wrote:
| 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.
| ubermonkey wrote:
| 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.
| smoldesu wrote:
| 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.
| vendiddy wrote:
| 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.
| alerighi wrote:
| 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...
| gizdan wrote:
| Sure, so what about those who are one or more versions
| behind?
| racl101 wrote:
| Yeah, I've used PHP for a decade and have always never used
| what comes with MacOS. Always installed a newer version.
| rovr138 wrote:
| /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
|
| so, 7.4 or 8?
|
| I'm still using 7.x due to limitations.
| smoldesu wrote:
| 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.
| vorpalhex wrote:
| 'brew' works really well, no need for them to reinvent the
| wheel.
| grzm wrote:
| If there were no need to reinvent the wheel, there would
| be no brew. macports (and fink) predate brew. The wheel
| is in the eye of the beholder.
|
| 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.
| gizdan wrote:
| Really well is an overstatement. You shouldn't have to
| wait several hours to do a brew upgrade.
| sigjuice wrote:
| Apple will do a package manager, once they work out how to
| bolt on an "app store" on it.
| smoldesu wrote:
| If those are the parameters, you can safely abandon hope
| now.
| znpy wrote:
| > problem that can be solved by just holding Apple
| accountable for once
|
| good luck with that
| mkr-hn wrote:
| Windows solves this for python by offering to install it from
| the app store the first time you use the command, and then
| keeps it updated.
| rovr138 wrote:
| 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.
| SavantIdiot wrote:
| > I currently have over 5 different python versions
| installed to be able to test against them
|
| 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.
| shadowgovt wrote:
| ... and if you're talking MacOS laptop and desktop
| ecosystem, it's a luxury you have and should take
| advantage of.
| heavyset_go wrote:
| I've got 3 different Python versions installed with pyenv
| and they only take up about 900MB.
| rovr138 wrote:
| I have no idea on where the 15GB either comes from. I
| also use pyenv and pyenv-virtualenv and my ~/.pyenv is
| not close to that.
| rovr138 wrote:
| > That's absurd.
|
| 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.
| SavantIdiot wrote:
| 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.
| jsjohnst wrote:
| > 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.
| Ensorceled wrote:
| Well, I'm one of the brainwashed zombies then, because
| I'm also running several versions of Python to comply
| with various dependencies of projects.
| Avamander wrote:
| > You could have only one version, but you've been
| brainwashed to think having 5 versions of python on your
| machine is normal.
|
| Is the strict requirement of a single Python version
| really that much better?
| SavantIdiot wrote:
| 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.
| rovr138 wrote:
| Sure, Microsoft...
|
| 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.
| dagmx wrote:
| 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.
| Wowfunhappy wrote:
| > 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.
| rovr138 wrote:
| >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.
|
| Google example, look at Debian stable.
| Wowfunhappy wrote:
| > I think you need to define "out of date".
|
| Well, look at this way--the latest consumer version of
| macOS still comes with Python 2.
| vbezhenar wrote:
| For end users the OS can be bundled with the application,
| that is much more stable for everyone.
| sidlls wrote:
| Sarcasm doesn't make a poor point better.
| suprfsat wrote:
| Electron is wildly successful, it's not a poor point at
| all.
| sidlls wrote:
| In the HN bubble, sure.
| suprfsat wrote:
| I bet I can find several users of Slack or Visual Studio
| Code who haven't even heard of HN.
| rovr138 wrote:
| Don't forget Spotify, WhatsApp desktop client, Skype,
| discord,
| rovr138 wrote:
| I think that's one place where it's divided and
| contended. People here are pretty vocal and critical of
| electron.
| 0x4a42 wrote:
| 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...
| lhball wrote:
| 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.
| swiley wrote:
| 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.
| euph0ria wrote:
| I love PHP but this makes good sense. Better to install it
| afterwards and get the package/version you want. Reduce footprint
| of OS.
| wila wrote:
| 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).
| chrisan wrote:
| 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.
| euph0ria wrote:
| Might be different departments working in different
| directions :)
| kijin wrote:
| 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.
| cm2187 wrote:
| 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.
| glenneroo wrote:
| Thankfully Candy Crush made the cut! /s
| [deleted]
| whywhywhywhy wrote:
| 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.
| piaste wrote:
| 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.
| kijin wrote:
| 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.
| fogihujy wrote:
| 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.
| strzibny wrote:
| One reason is that so many packages depend on them. Python
| and Perl is big in Fedora-based systems, for example.
|
| 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.
| ForHackernews wrote:
| 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.
| agys wrote:
| I used it as a quick html server as an alternative to the Python
| "simple" ones, which always had some issues for me.
|
| Useful when coding small demos: php -S
| localhost:8000
| [deleted]
| iriche wrote:
| python -m SimpleHTTPServer 8080
| nindalf wrote:
| That's Python 2. In Python 3 it's python -m
| http.server 8000
| speedgoose wrote:
| On MacOS, it seems that python 2 is still the default so
| the right command is :
|
| python3 -m http.server 8000
| astrange wrote:
| 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.
| agys wrote:
| Thanks :)
|
| 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.
| lukifer wrote:
| Big list of http static server one-liners:
| https://gist.github.com/willurd/5720255
| dlsa wrote:
| Wow! Today I discovered PHP was lurking in MacOS the whole time.
|
| What was it used for? CUPS? something else?
| pjmlp wrote:
| It was used for Web Sharing, actually disabled since Mountain
| Lion edition, https://www.cnet.com/how-to/how-to-enable-web-
| sharing-in-os-...
| zapzupnz wrote:
| Built in web sharing
| truncate wrote:
| And httpd.
| zerof1l wrote:
| 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.
| corobo wrote:
| 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
| strzibny wrote:
| > People who do web development use Docker, because for any
| serious development you'd want your environment to match live
| one.
|
| This is wrong in so many levels I don't even have the energy to
| start explaining why.
| Majestic121 wrote:
| 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.
| mattmanser wrote:
| The GP comment was similarly low effort.
| Toutouxc wrote:
| > 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.
| trey-jones wrote:
| 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.
| Dudeman112 wrote:
| >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?
| trey-jones wrote:
| 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?
| tored wrote:
| 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.
| mjburgess wrote:
| 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.
| sgt wrote:
| Not true at all. You can do serious development using a virtual
| environment in Python.
|
| Using Docker during development is not required and in fact not
| always ideal.
| pantulis wrote:
| 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.
| sgt wrote:
| Correct, Homebrew should be a breeze to a serious
| developer.
| pjmlp wrote:
| I do web development without docker, and yes it matches the
| live one.
| 5e92cb50239222b wrote:
| 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.)
| ljm wrote:
| Is this sarcasm? That sounds more like an indictment of
| Docker or Vagrant than anything else.
| gizdan wrote:
| 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.
| pjmlp wrote:
| Nah, just an old dog that has seen the pendulum swing too
| many times, and has more to sell to employers and customers
| than CV driven development.
|
| Docker is about 5 years time to become irrelevant, replaced
| by the next big thing(TM) in cloud deployments.
| hparadiz wrote:
| Same. Homebrew on my Mac and self compiled on Gentoo.
|
| I also maintain a WSL Ubuntu setup to provide support for our
| windows developers. I suppose WSL is a VM.
| pjmlp wrote:
| 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.
|
| [0] - httpss://channel9.msdn.com/Blogs/Seth-Juarez/Windows-
| Subsystem-for-Linux-Architectural-Overview
|
| [1] - https://www.microsoft.com/en-
| us/research/project/drawbridge/
| timw4mail wrote:
| Wow, another Gentoo user!
|
| 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.
| squiggleblaz wrote:
| 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).
| timw4mail wrote:
| 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.
| corobo wrote:
| > The live _one_
|
| I think this might be why there's a split, I use docker but I
| don't work on just the one site
| pjmlp wrote:
| I also don't work just in 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.
| corobo wrote:
| Fair, failed hypothesis there then.
|
| How painful is that when you get a new computer?
| pjmlp wrote:
| Go through the respective installers, done.
|
| One day downtime at most, thanks to IT images.
|
| No need for super beefy hardware just to keep Docker
| happy.
| iruoy wrote:
| 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.
| admissionsguy wrote:
| It used to be very slow, but I think they fixed it for the
| most part some months ago.
|
| It is certainly no longer a problem for my dev work since a
| certain docker version upgrade.
| efficax wrote:
| 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:
|
| https://www.jeffgeerling.com/blog/2020/revisiting-docker-
| mac...
| mschuster91 wrote:
| 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.
|
| Sigh.
| toxik wrote:
| 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.
| lugged wrote:
| This is trivially worked around with volume mounts and
| properly configuring VM / container resources.
|
| The overhead should be incredibly minimal.
|
| It is a waste of time though. Just use Linux.
| oblio wrote:
| I don't think they can really use Linux on Apple
| hardware.
|
| At least not as professional developers that don't want
| to fight the hardware, the OS <<and>> their development
| project.
| oarsinsync wrote:
| 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)?
| ratww wrote:
| _> 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.
| mgkimsal wrote:
| Agreed. I also like being able to know I can do some work
| even if disconnected, or traveling, or... just _not_
| needing to manage more external services.
| oarsinsync wrote:
| 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.
|
| Cheers!
| rewgs wrote:
| 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."
| oblio wrote:
| 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.
| drrotmos wrote:
| 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.
| jt2190 wrote:
| > 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.
| KptMarchewa wrote:
| You can just rsync local code to remote machine. All the
| benefits from local machine snappiness, without local
| compile hassles.
| oarsinsync wrote:
| 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.
| squiggleblaz wrote:
| 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.
| vehemenz wrote:
| Since you didn't list anything specifically, what do you
| find beneficial about developing on a cloud VM? And what
| is your setup?
| lugged wrote:
| So get a ThinkPad? Or a surface pro, or a Dell, or a
| Chromebook, or a system76?
| oblio wrote:
| I guess you missed the latest news about those devices
| with 20 hour battery life and the performance of a Intel
| device weighing twice as much :-)
| contriban wrote:
| I doubt anyone would need to work anywhere near 20 hours
| without being connected at all. The vast majority of
| people work on desks with plugs.
| daemoon wrote:
| Probably not, but if your are doing some heavy work the
| battery will last significantly longer.
| toxik wrote:
| Hey, where are you going with that goalpost? Put that
| down again.
| starfallg wrote:
| 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.
| ratww wrote:
| _> I don 't know why doing development in Linux is a
| unpopular opinion._
|
| It's not.
| bovermyer wrote:
| 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.
| udp wrote:
| 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.
| Stranger43 wrote:
| 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.
| sa46 wrote:
| 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
| fart32 wrote:
| 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.
| nickjj wrote:
| > 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.
| fart32 wrote:
| 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.
|
| I may give it another chance, though. Thank you.
| nly wrote:
| > If you wonder why that is, it's because Docker for Mac
| actually runs the Docker engine inside a Linux virtual
| machine.
|
| True of Windows too.
| pantulis wrote:
| Doesnt more recent Docker versions use HyperKit?
| toxik wrote:
| Correct but it's still a virtual machine.
| hibbelig wrote:
| Another problem is that bind mounts are slow; we put data
| into volumes if it's accessed often.
| diveanon wrote:
| "People who do web development use Docker"
|
| 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.
| coder543 wrote:
| > The new M1 macbooks couldn't even run Docker
|
| 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.
| diveanon wrote:
| 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.
| [deleted]
| corobo wrote:
| 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.
| [deleted]
| dmz73 wrote:
| 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.
| overgard wrote:
| 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.
| joelbluminator wrote:
| Did it correctly identify PHP as a virus?
| qalmakka wrote:
| 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.
| mtnGoat wrote:
| i use PHP CLI tools all the time, they exist. composer as an
| example.
| TazeTSchnitzel wrote:
| Well, don't forget macOS also used to include Apache.
| my123 wrote:
| It still does. % httpd -v Server
| version: Apache/2.4.46 (Unix) Server built: May 22
| 2021 02:05:58
|
| on macOS 12 beta.
| mekster wrote:
| On MacOS (when it was still capitalized), "I can program for
| the web from day 1 on Mac, cool!" probably made sense 20 years
| ago.
|
| 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.
| snshn wrote:
| It was there this whole time?! Thank dog it's gone.
| JoeCianflone wrote:
| 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.
| obayesshelton wrote:
| Most professional engineers are using some sort of virtualisation
| (docker or vagrant) with the language inside it.
|
| I never use the OSX standard version of PHP or Python
| hu3 wrote:
| > Most professional engineers are using some sort of
| virtualisation
|
| source?
| tibbydudeza wrote:
| Apple dropped Samba and wrote their own SMB client due to their
| fear of GPL v3.
|
| Do they still use CUPS for printing ???.
| sitharus wrote:
| Given that Apple have owned CUPS for close to 15 years, yes
| they still use CUPS. The author left Apple in 2019 and now
| maintains a fork.
| TazeTSchnitzel wrote:
| 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
| riffic wrote:
| if you need it, you can install it.
|
| 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...
| jsemrau wrote:
| I used PHP for many years and products. But currently I hold the
| opinion that Python-Flask is more powerful for server-side
| operations.
| vehemenz wrote:
| How easy is it to transition to Python/Flask from PHP for
| someone with limited experience in Python?
| WalterGR wrote:
| Xcode 11 Release Notes
| (https://developer.apple.com/documentation/xcode-release-note...)
|
| "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...
| darrenf wrote:
| 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:
|
| *
| https://github.com/Homebrew/brew/issues/10127#issuecomment-8...
|
| * https://github.com/Homebrew/brew/issues/11275
| Stranger43 wrote:
| 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/.
| xeeeeeeeeeeenu wrote:
| Perl isn't required by or even mentioned in the Single UNIX
| Specification.
| tpush wrote:
| Genuine question: is there anyone (corporate or not) that
| cares that macOS is a certified Unix?
| smoldesu wrote:
| I mean, I do. I'm sure plenty of businesses love having a
| standardized spec across their devices, too.
| mekster wrote:
| It's still impressive that powerful command line
| environment and the best GUI are offered in a same OS.
|
| Usually it's one or the other.
| Andrew_nenakhov wrote:
| 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.
| pornel wrote:
| 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.
| massysett wrote:
| > 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.
| smoldesu wrote:
| 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.
| jsjohnst wrote:
| > GNU is the predominant standard
|
| On Linux, sure, but not on other Unix OSes (like *BSD)
| max_hammer wrote:
| `awk` is part of GNU. And Unix(tm) is a proprietary
| product of AT&T.
| blacktriangle wrote:
| 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.
| hnlmorg wrote:
| 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.
| mousepilot wrote:
| 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.
| smoldesu wrote:
| Apple is fantastic at creating artificial scarcity out of
| zero-marginal-utility.
| blacktriangle wrote:
| 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.
| hnlmorg wrote:
| 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.
| smoldesu wrote:
| 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.
| chrisfinazzo wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| azangru wrote:
| > and the best GUI
|
| 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.
| JeremyBanks wrote:
| Indeed.
|
| Windows Subsystem for Linus sure has been a game changer!
| smoldesu wrote:
| 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.
| splistud wrote:
| and in this case it's neither
| akho wrote:
| 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.
| JiNCMG wrote:
| If you want to throw in WSL then include Docker on any OS
| akho wrote:
| Any OSes where Docker runs that I have not covered?
| mirthflat83 wrote:
| The joke went over your head
| jolux wrote:
| 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.
| akho wrote:
| 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)
| devilduck wrote:
| 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
| jolux wrote:
| 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.
| vanpythonista wrote:
| 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
| smoldesu wrote:
| Neither Macport or Homebrew work "fine", but please
| continue.
| geerlingguy wrote:
| WSL includes a package manager now?
| akho wrote:
| The distro you run in wsl certainly does.
| hnlmorg wrote:
| 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).
| cpach wrote:
| End-users? Probably ~0.
|
| But it might help Apple to win government contracts.
| rbanffy wrote:
| And who'd imagine, in 2000, that 20-ish years later, one
| of the most popular lines of computers would be RISC-
| based UNIX workstations...
| curt15 wrote:
| 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."
| Stranger43 wrote:
| 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.
| coredog64 wrote:
| 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.
| seabrookmx wrote:
| Ironically, Dell ships it's XPS "developer editions" with
| Ubuntu, which is likely much closer to your infra.
| mrehler wrote:
| 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.
| tarsinge wrote:
| 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.
| rovr138 wrote:
| 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.
| crooked-v wrote:
| 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.
| ILMostro7 wrote:
| 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.
| Stranger43 wrote:
| 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.
| smoldesu wrote:
| 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?
| defaultname wrote:
| Maybe they don't care about you as a customer? Apple has
| never pretended to cater to everyone.
|
| They aren't for you. Move on.
| smoldesu wrote:
| 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.
| defaultname wrote:
| 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.
| jsjohnst wrote:
| > 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.
| tgragnato wrote:
| Many care that macOS is Unix-like, I doubt anyone cares
| about the certification.
| chrisseaton wrote:
| I believe it's a compliance thing for government
| contracts.
| mrpippy wrote:
| 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.
| kqr wrote:
| I doubt they'll be able to get rid of Perl any time soon.
|
| However, how come things break when Perl is upgraded? From
| what I've heard, Perl should be extremely backwards
| compatible. What am I missing?
| darrenf wrote:
| 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.
| mst wrote:
| 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
| pjmlp wrote:
| Enjoy the incompatible changes section from all Perl
| history,
|
| https://perldoc.perl.org/perl#History
| anthk wrote:
| That's bullshit. I've run exercises from the Orelly CD
| bookshelf more than a decade old and they just run as is.
| viraptor wrote:
| 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.
| Ensorceled wrote:
| > That's bullshit.
|
| Dude, there is literally a link with references.
| pjmlp wrote:
| That just proves the point you got lucky with what
| language features were used on the exercises.
| mst wrote:
| That's a link to complete changelogs.
|
| Those aren't an "incompatible changes seection".
|
| perldelta covers bugfixes, feature additions etc.
| pjmlp wrote:
| foreach entry in "https://perldoc.perl.org/perl#History"
| do open entry on browser search for
| "Incompatible Changes" section read section
| contents
|
| Writing a script in Perl to do the above is left as
| exercise to the reader.
|
| Hint, use LWP.
| rurban wrote:
| They had to recompile their perl XS bindings, where esp.
| subversion is horrible to update.
| unethical_ban wrote:
| 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).
| Rebelgecko wrote:
| 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)
| aasasd wrote:
| 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.
| h1fra wrote:
| That's good, too many package assume you have python installed
| in macos and go looking into the wrong folder.
|
| Or default python2 breaking stuff that assume you have a recent
| install
| enriquto wrote:
| > for compatibility with legacy software.
|
| 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
|
| Conclusion: Apple is a Perl shop.
| Cthulhu_ wrote:
| What they could do is use an internal, non-user-usable
| runtime for their own perl scripts and allow the user to
| install their own one.
|
| And of course compile their scripts into executables or
| something.
| jcfields wrote:
| 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.
| mrsuprawsm wrote:
| 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.
| >>>
| [deleted]
| _wldu wrote:
| Python is to Unix/Linux/Mac what PowerShell is to Windows.
| It's here to stay.
| jbverschoor wrote:
| No it's not. And it won't
| cortesoft wrote:
| I am pretty sure bash is the powershell of Unix/Linux/Mac
| syshum wrote:
| bash is more akin to cmd/batch then Powershell.
|
| 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
| mishac wrote:
| you can install bash on windows too.
| suprfsat wrote:
| That's because it's not part of the base OS:
| % /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.
| Wowfunhappy wrote:
| 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?
| samatman wrote:
| 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.
| Wowfunhappy wrote:
| 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!
| [deleted]
| zitterbewegung wrote:
| 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.
| kbenson wrote:
| > 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.
| throw0101a wrote:
| > _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._
|
| * https://tldp.org/LDP/Linux-Filesystem-
| Hierarchy/html/opt.htm...
|
| MacPorts uses /opt/local for example.
| unknown_error wrote:
| > 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.
| Wowfunhappy wrote:
| MacPorts _did_ receive official resources from Apple for a
| long time. Then they stopped.
| Hamuko wrote:
| Apple did toss some ARM machines (DTKs I believe) to the
| Homebrew project.
| brigandish wrote:
| I'd plump for Macports or pkgsrc long before Homebrew.
| smoldesu wrote:
| 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.
| zodiakzz wrote:
| 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.
| brigandish wrote:
| 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.
| donarb wrote:
| 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.
| sixothree wrote:
| You could use homebrew to install powershell.
| mthoms wrote:
| I can't tell if you're joking or this is actually
| possible. Is it?
| benbristow wrote:
| https://docs.microsoft.com/en-
| us/powershell/scripting/instal...
|
| From the horse's mouth
|
| You can also install it on Linux if you wish.
| rbanffy wrote:
| 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.
| salmo wrote:
| 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.
| salmo wrote:
| 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.
| cutler wrote:
| Perl was invented to replace the shortcomings of hacking
| together sed + awk + shell, eg. multi-dimensional arrays.
| iso1631 wrote:
| 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.
| efaref wrote:
| 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.
| squiggleblaz wrote:
| 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.
| walshemj wrote:
| Only if the said script is less than a dozen lines
| imNotTheProb wrote:
| I wonder why Apple/Tesla/Jeep users apologize for
| Apple/Tesla/Jeep, where Google/MS/Ford get hated on for new
| features.
| joshenders wrote:
| 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.
| my123 wrote:
| busybox is not an option because of the GPLv3.
| http://landley.net/toybox/about.html might be one.
| swiley wrote:
| Man what a drag, it's a real bummer a multi billion dollar
| cooperation can't just rip off open source projects.
| dagmx wrote:
| They do contribute quite a bit to OSS.
|
| 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.
| tacker2000 wrote:
| Should be fine since the MacOS preloaded versions are not what
| you want anyway, most of the time.
|
| In PHP you really need to know what version you are working with,
| otherwise weird stuff happens.
| jonwinstanley wrote:
| Totally agree, almost everyone using PHP for their work will
| have installed their own or be using docker or homebrew
| la_fayette wrote:
| 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...
| floatingatoll wrote:
| 'brew install php' works across most ages of Macs and provides
| consistent paths for config files across deploymentd, in case
| that's useful.
| la_fayette wrote:
| This causes so many issues if you have installed php
| already... Stackoverflow is full of problems...
| floatingatoll wrote:
| Good thing it's being removed in three months, then :)
| afavour wrote:
| 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).
| calibas wrote:
| 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.
| floatingatoll wrote:
| 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.
| lukifer wrote:
| The real tragedy is that Apple hasn't taken over and bundled
| brew with the OS (or come up with their own blessed CLI
| package manager).
| floatingatoll wrote:
| 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.
| dagmx wrote:
| Why couldn't they just install a newer version of PHP though?
| ben174 wrote:
| 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?
| floatingatoll wrote:
| Why do you believe that PHP isn't worth learning?
|
| 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.
| la_fayette wrote:
| Why are there still trolls on the internet?
|
| Simple answer: https://w3techs.com/technologies/overview/prog
| ramming_langua...
| conductr wrote:
| 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.
| Dudeman112 wrote:
| PHP was the back-end language for my 'web development'
| classes.
|
| What language would you pick for that?
| gizdan wrote:
| 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.
| andix wrote:
| 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.
| astrange wrote:
| Script execution is blocked by default unless you turn off
| Gatekeeper.
| gregoriol wrote:
| 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.
| slver wrote:
| Security risk no. But it's a maintenance mess to have bunch of
| runtimes sitting around for no great reason.
| detaro wrote:
| 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.
| kUdtiHaEX wrote:
| I think that this is fine because if you need it you can easily
| install it with brew.
| pknerd wrote:
| Didn't know about it. I either used Laravel or MAMP.
| trey-jones wrote:
| I consider this a decent workaround: alias
| php='docker run --rm -ti php:pick-your-version'
|
| I write a fair amount of PHP on Linux and I haven't had php
| actually installed for years.
| oknoorap wrote:
| It's not a big deal at all. We can use docker.
| [deleted]
| cooper45 wrote:
| 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/
| marlynm wrote:
| No one should use system PHP anyway on macOS, It is an old and
| insecure version.
|
| I would recommend installing PHP via brew
| https://github.com/shivammathur/homebrew-php
| saagarjha wrote:
| What does this version have over
| https://github.com/Homebrew/homebrew-
| core/blob/master/Formul...?
| marlynm wrote:
| Exactly same as core tap for currently supported PHP versions
| i.e. 7.3 to 8.0. Builds with security patches backported for
| PHP 5.6 to 7.2.
| steve_adams_86 wrote:
| 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.
| robotron wrote:
| Good. The installed version just gets in the way if you're a PHP
| developer.
| JackPoach wrote:
| This is big. No, this is HUGE.
| jmull wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-17 23:02 UTC)