2/3s of all PR activity on Github is on a Mac, for what it's worth. Certainly the platform punches above its weight relative to market share.
https://developer.apple.com/videos/play/wwdc2017/102/?time=2...
https://developer.apple.com/videos/play/wwdc2017/102/?time=2...
Maybe the developer in question would have been better using a manually created VM or WSL?
Not to mention, the windows environment is completely different to linux and OSX. Until x64, they had a different calling convention. On OSX and linux, also until recently, I could use the same compiler for both platforms and still be supported by the platform vendor.
All of these non-trivial differences make it a lot more resource-intensive to support a codebase on windows that already runs on Linux and OSX. Asides from my work VMs, I don't even have a windows device that I could use for development. So to me, it's no surprise that most open source projects don't build on Windows.
Also, mingw and cygwin also exist since late 90's.
OS X tools are kind of included on Apple's hardware price.
Apple hardware costs in many countries is similar to average PC + VS License costs.
As for mingq and cygwin, most regular people don't have it installed and configured. And cygwin and mingw are not _platforms_ which receive first party support, as unfortunate as that might be.
It was pure pain. Especially when the boss kept asking me what was taking so long (it's just a recompile right?).
500 € PC + Visual Studio vs 1000 € Mac.
All projects are ultimately created to scratch somebodies itch. If it doesn't work on windows out of the box that isn't their use case. What you are wondering is in effect is why people don't pay money to purchase a windows license which will ultimately fund a bad and evil company in order to enable the projects software to run on an inferior OS that the dev doesn't run or care about. If its not end user software for desktop users it doesn't even have the positive effect of enabling a substantially bigger group of potential users to benefit from the software. For anything server related they are either already running linux or can as easily run a linux vm as a windows one.
Further the users who would benefit will by and large buy a license if the software is non free but probably wont contribute anything but complaints phrased similarly to the support requests they would make for paid products that had failed to perform adequately.
I suspect that it was on the local tooling side that things fell apart for this Windows developer, if he was grabbing a project mostly built on Mac or Linux.
A lot of popular dev tooling built around web technologies (node, Ruby, PHP, etc) isn't as mature on Windows as it is on MacOS or Linux.
My source on this is me. I have a Mac and a Windows box at home, and I've had projects fail to set up and build on the Windows machine for these reasons.
It's very nice to give end users the option - when I joined, I asked for Linux and was given a brand-new Dell XPS with Ubuntu pre-installed, root access, and told, customise it to suit you. I keep that spirit with my users.
Throwing Windows into such a setup is a nightmare though - two users actually installed their company laptops with their own personal Windows 10 licenses without my knowledge or approval - I still hold a grudge because I had to actually read the MS EULA to make sure they weren't about to cause trouble! It means I can't manage them (I have no real tools to do so on Ubuntu), so they're on their own for that. Fortunately management has my back, declaring the company to be a *nix shop.
Our actual product is all containerised so it should run anywhere.
Ansible works pretty well for managing Windows machines but it requires a little bit more up-front setup on the Windows side and as always YMMV depending on what you're trying to do.
Not that many years ago that was the same reason IT departments would give for only giving people Windows machines.
This is part of the reason I basically refuse to customize anything on a new linux machine; my needs are already weird enough that I'd rather just adapt myself to the defaults for everything else.
Remap the sequence "jk" to escape, you don't even have to take your hand off the home row to exit a mode.
Ctrl to Escape
Escape to Caps
I mostly use Ctrl-[ for Escape. I have a lot or weird Ctrl bindings. Not an emacs level of Ctrl bindings, but enough that I use this particular rearrangement.
You have to love Emacs and Vim users.
Quite sure Apple's world doesn't revolve around the needs of such a small user base.
No issues.
To those who haven't: Give it a go. Put Escape on Caps lock. If you've got Control there and you're running Linux or Windows with a standard PC keyboard, you probably actually want to swap Control and Alt. If you haven't, you probably want to swap Control and Alt anyway. (This will give you bindings similar to the Mac's Command key. The thumb is a much stronger finger and far more suited to these combinations than the weak pinky.)
That feels like a fair solution.
This is a huge improvement over when I started developing and was forced to use Windows.
1) There is a lot of cargo-culting around the MacBook because hurr durr Windows is terribad (though, to be fair, Docker does work better natively with OS X than Windows, even under WSL), and
2) Most companies give their developers the choice of a MacBook or the shittiest Windows machines known to man (because of irresistable volume deals from Windows OEMs). I bet the spread would be more even if companies were willing to offer the Surface Book as an option. This laptop is nice.
https://www.consumerreports.org/laptop-computers/microsoft-s...
Archived at https://archive.fo/sBiUK
Most of issues people have with Windows can easily be explained by low quality hardware. If you need a decent laptop, you're looking at price tags above $1000. Depending on where you live, I wouldn't buy a Windows laptop below $1400, if you expect to be happy with it.
Honestly Microsoft should take steps to prevent the sale of Windows 10 on laptops without an SSD and at least 4GB of RAM. That would help the Windows brand tremendously.
Docker for Windows doesn't exist for Windows 7 (still used in a number of enterprise environments). You're stuck with Docker-Machine in that case.
Many companies don’t allow mac purchases, even for developers.
I think it would be cumbersome to say the least...
* Would you have to install through the app store gui?
* How would it manage dependency chains and conflicts (system ruby vs local ruby)?
* How about explicit paths or build parameters?
* How would it handle different shells?
And, with all that said, I have a quite a bit of negative sentiment towards Apple lately for their hardware and platform choices. So I would still say, it's not a developer-centric platform (the Mac)...
Possibly or not. Ubuntu gives me both a gui and a command line option for apt. Thinking about being able to type "app-store install openssh" gives me goosebumps.
> How would it manage dependency chains and conflicts (system ruby vs local ruby)?
First, that example is a problem for ruby, not for the package manager. Second, software can be in the store statically compiled. Third, apt handles dep management really well. Perhaps that's something apple can learn from?
> How about explicit paths or build parameters?
This is a solved problem in ubuntu.
> How would it handle different shells?
Again, this is a solved problem.
> So I would still say, it's not a developer-centric platform (the Mac)
The question I have is if we deploy on linux, why are we using a mac to develop software on?
The sad thing about linux is that as much as I love it and its ecosystem, i cant recommend it to anyone who wants things to "just work":
- X and wayland crash on me all the time on this laptop because of its HiDPI screen and my kinda-works-but-is-wonky fixes to work with multiple monitors.
- Hardware support is the best its ever been, but graphics cards, wifi, exotic devices, laptop power states and embedded devices can still be a pain because manufacturers simply dont care.
- desktop applications can still be a little glitchy, Web browsers work fine, as do first party DE apps, but the more you get away from things which arent in the big name gui toolkits and have custom controls and behaviour, the more problems you seem to run in.
But aside from all that im happy here in ubuntu. When your software library feels as easy as picking a book from a shelf and 90% of the system updates by the update manager and says "hey restart when you feel like it" Im quite comfortable.
If you look Apple ship a modern version of ZSH with their OS, I believe because it isn’t affected by the same potential licensing issues.
Everyone else will buy consumer oriented devices that are as open as the ipad.
It's not a bicycle for the mind its a train and if you dress appropriately and pay your fee you may set up a concession stand on the route.
With various linux package management systems you have multiple interfaces to the same same system thus you can at one moment use the gui to install foo and having closed that you can fire up your favorite terminal and run install bar.
* It'd clutter the app store and force developers to use the app store and whatever approval process they decide.
It also has a concept that neither Microsoft Apple nor Google has opted to pick up on because they desire control of their platform and to extract a substantial tax on all software sold on same via such control... sources also called repositories.
Linux package management systems draw from not a single centrally managed source but a user editable list of sources. Each source is free to run with their own set of requirements. There is nothing requiring a hypothetical dev tools source from being any more restrictive than whomever maintains the source used by homebrew.
Further packages can actually contain sources. It would be entirely trivial to package up a source of dev tools as a package and allow people to install that via the front end of their choice.
* How would it handle different shells?
Different shells is probably the simplest answer the arguments to a hypothetical install command would be simple text strings. If the argument command includes characters that the shell considers special characters they would have be escaped or wrapped in quotes like any other combo of shell and cli tool. Generally most package names just don't include characters like ([])$\~`'" in the name and most commands don't require any particular special attention to shell escapes.
* How would it manage dependency chains and conflicts (system ruby vs local ruby)?
* How about explicit paths or build parameters?
These are implementation details that don't go away by exiling developer tooling to officially unsupported channels. For example language specific package managers will probably remain a thing but it would be vastly easier if you could do officalmacpackage install developerrepo then officialmacpackage install cargo|node|whateverfloatsyourboat then use that to deal with whatever.
All your concerns are basically lack of experience with more reasonable systems there are zero good reasons not to do this. There are literally no downsides other than the work required for an official solution. However it seems vastly unlikely that we will ever see such a thing.
The logical endpoint of Apple's vision seems to be 2 classes of device. One with a very high introductory price and annual maintenance that allows you to create and run whatever you like so long as such software is distributed via blessed channels and you tithe the required 30% to apple and more reasonably priced but still expensive devices that only allow you to consume software.
The former will come with xcode and technology to deal with apple approved languages. You will be able to play with other tech on your local devices but it wont be able to be distributed to end users.
The latter will be as open as your ipad is now.
https://www.patreon.com/homebrew
(I do not participate in Homebrew other than as a user.)
“How dare they inject advertising into a critical command line tool that I use to get paid money!”
“It’s inexcusable to promote your own financial success when someone types brew upgrade”
“No doubt they’re blowing the money on burrito delivery in SOMA”
“I’ve been a $1 Patreon since they launched three months ago and they haven’t implemented my favorite wishlist feature!”
“If they can’t do it for free, they should give up and shut down and let someone fork it.”
From memory of speaking with an ex senior-Apple-dev-person, Apple doesn't support any 3rd party Open Source projects nor Communities. eg Homebrew, or even the software they bundle in their OS
Any license with a Patent clause or Tivoization clause will be verboden. As an example you will never get something that depends on Postgres in the Apple store.
Other types of developers were a kind of nice to have regarding sales, but no longer relevant.
If you do anything else than UI scripts, I would agree with the above and say you are better off with a linux box.
When you get into plumbing, I feel like there are better alternatives.