How is that exactly? A huge majority of developers in your situation go out and buy a Mac; another hardware purchase in their pocket. This is part of their business strategy: developers are forced to participate, and by and large they do just that.
It hurts you far more than it does Apple by refusing to participate. If you believe you're "hurting Apple" by not developing for their platform, think again. Even if your software is free to download, it's not Apple that suffers - it's your (potential) users; and they will blame you, not Apple, for the lack of support.
Apple wins this battle every time. Welcome to the ecosystem. :)
I never sshed into them.
Apple isn't trying to make that way of working easier... they are trying to make life easier for macOS-specific devs. Apple is looking for well integrated applications, and as I'm sure you know, that's really hard to do well cross-platform as you often end up coding to the lowest-common interface.
Again, that's from the Apple point of view...
Which again is hardly different from UNIX culture, which doesn't matter what the hardware is capable of, as long as, it runs UNIX and given that the UNIX culture never cared for the desktop experience (Xlib and Motif really?!) that gives a clash of cultures.
You're right - they did have a Java-Cocoa bridge early in OS X, but deprecated it quickly when it was difficult to translate Obj-C semantics into Java. I remember trying it, but it wasn't really that easy to use. Even in this case though, the idea was to write Mac-specific applications, just in a different language. Most of the application's magic was still in the ObjC/Cocoa layers, which weren't cross-platform (or were they - I can't remember if there was a Windows port at sometime??).
While this would have made it easier to write cross-platform applications, realistically, that was never the goal. I think the goal of the Java-Cocoa bridge was to offer a backup plan in case too many devs didn't like Obj-C. At the time, Objective C was a novel language for many people. Once Obj-C got enough mindshare and it looked like it got enough of a buy-in from developers, Apple ditched Java quickly. I'm sure the licensing issues from Sun in the early 2000's didn't help matters here.
Also, it's only been fairly recently that Apple turned over the Mac Java port back over to Oracle. For the longest time, Java developers on Macs were always a version or two behind because they were on the OS X release schedule, rather than the Oracle/Sun release schedule.
They dropped it the moment they realized most of them were happy to use Objective-C and somehow they were the first company to turn back the tide from JIT to AOT compilation.
Yes, back in the NeXT days there was a Windows version of the whole Objective-C dev environment for Windows, and also an initial port of Cocoa to Windows when it was still called Rhapsody.
As for fairly recent, it was almost 10 years ago. :)
Of course.
Back in the day we had to buy Commodore 64, Spectrum, Spectrum +, Spectrum +2A, Spectrum +3, Atari ST, Atari Falcon, Amiga 500, Amiga 1200, PC, .... and Mac.
So those of us that enjoy a packaged experience of OS + Software + Dev Tools are more than used to it.
The culture of the hardware doesn't matter, just give me a CLI and a 2D frame buffer isn't the culture of the desktop computers.
That's not an "Of course" situation. It's a "bang your head against the wall in frustration" situation. The hardware is commodity hardware, so the software runs on the same hardware that everyone owns, but you're legally required to pretend that it doesn't.
Not in any of my pockets or devices at home, besides the laptop.
But, we digress. Tell me again how it's reasonable that hardware that will run OSes 1, 2, and 3 shouldn't be allowed to run OS 1, because the hardware doesn't have a fruit sticker on the side.
Old hardware was inherently incompatible software-wise, due to widely varying CPU and system architectures. ARM and MIPS hardware today somewhat mirrors that on a device-by-device level; every model has different interconnections between its components and often different mixes of components connected in. Luckily, we've got OSes that provide relatively robust hardware abstraction layers, so that the same software package from my 2010 device is highly likely to run on my 2016 device. I think that strengthens my argument: when even widely varied hardware isn't much of a barrier to software interoperability, why should we be satisfied with legal limitations?
And anyhow, the point was software development. Going into the definition of what is and isn't a PC is a bunch of BS semantics. Let's drill down to the devices that are pertinent to the discussion: The set of devices that are technically capable of native (as opposed to web) OSX and iOS development, and the set of devices that are legally capable of the same. Those are what the discussion is about.
You find a lot of tutorials on the web, how to install macOS. It is not much harder than to install Ubuntu.
Sure you can mitigate it by not doing updates, having a test machine to receive the updates and verify that it still works, yadda yadda.
I managed CI infrastructures for IOS/Android developers a few years ago and the hoops we had to jump through with xcode / EULA-breaking virtualization, etc was something I'd never experienced before. Hopefully it's different now, but we used to have to run farms of mac minis because we couldn't have jenkins/bamboo trigger more than one xcode test/build run at a time. So we'd have these $1500 mac minis sitting around doing ONE job at a time whilst the Android builds could easily do 1-10 things simultaneously.
Everything felt like Apple was fighting our developer experience. It was even worse for our business model as we developed 3rd party applications for other companies which brought it's own headaches with signing, testflight, getting demo/beta apps to clients before release to app store, etc.
As someone who is interested in OSX testing like this - ie, not arguing with you - would it be possible to have a mac mini use virtualbox with real OSX installations running in parallel?
From what i've heard in this thread, Virtualbox/etc support OSX just fine, on OSX machines. Hypothetically, you could parallel-ize on a single machine via virtualbox, no?
I understand Apple is still making it a PITA though. Not disagreeing, just learning why you were only running a single instance per box. :)
Our initial goal was to have one OSX system running multiple xcode builds/tests. I think at some point we may have gotten it working by having different targets set up but I don't recall the specifics.
Sorry I can't be of more help. We worked with 3-4 other app developers and it seemed like all of us were doing completely different work arounds to reach the same goal. I'd love to know how King or any of the other huge (number of apps) developers deal with these things. It doesn't seem like it's talked about much.
I think the only way it hurts Apple is that no one runs OSX Server anywhere. I'm willing to bet Apple doesn't have data centres filled with MacPros, but instead has proprietary internal hardware for servers running OSX.
OSX is terrible to run your services on compared to any other Linux/BSD variant out there with build-in package management. Apple is not tapping into that particular market, but considering how much they make off their consumer hardware I doubt it matters.
At this point in time OSX/MacOS/iOS and Android/ChromeOS is pretty much the same thing. A basically proprietary platform (yeah yeah, i know about AOSP. But good luck using most apps without having Google's services installed) living on top of a vestigial _nix.
At least Google's stuff generally works from a Linux desktop; Apple's just refuses (including iCloud: apparently I am required to use a Mac or Windows machine to view pictures my mom posts; Apple seem to think that Linux browsers are incapable of displaying pictures and text).
CI. You have to jump through inordinate hoops to have a CI system that tests on OS X. In the cloud there's Travis CI that supports OS X, or there's the GitLab runner that can drive Parallels or VirtualBox (incl. snapshot and rollback).
We're currently moving our Linux, BSD and Windows CI from VMs and bare metal to openstack. It would be great if openstack could (legally) run MacOS X on the Linux hosts, or if we could have it use the openstack API to interact with the VMs via vmware, so we can use ansible to maintain the VMs across the board.
Yes, that's true, but we can also start being sincere about the fact that the whole story is BS. I've been recently assigned a mac by my university (never used one before) and I have to say that the ecosystem is at least unhealthy.
Maybe mac users don't really care, but having to install a third party software for common tasks like reverse scrolling, keeping the system from going to sleep, writing to NTFS, are symptoms, in my opinion, of a too much strong top down interaction between the os and the user. Same goes for the whole "OSX only on Apple hardware" story.
So no, Apple isn't shooting temselves in the foot, but surely they are disrespecting the end user. You can excuse that by saying that it is business, but I would reply that it is still true and by avoiding to talk about it we are implicitly doing Apple a favor by hiding the issues with what would otherwise be a great piece of software. We should say more often that these practices are bad for the consumer.
Ever tried to write to HFS+ or to EXT3 from Windows ? Did it work without installing a third party tool ?
> reverse scrolling, keeping the system from going to sleep
You can change the way the scroll works from your Mac Settings, same goes for the power options.
It only works for a single device. So if you want to keep natural scrolling on the trackpad and use regular scrolling on a external mouse, you can't. For some reasons the two checkboxes for this (even under different panes) are linked.
By the way, there is an ecosystem of excellent small utilities developed open source for linux that are, in my opinions, superior to the ones on OSX, or at least, the one I work and am familiar with. Of course open source produces many useless tools, but I've also found unusable applets for mac, so...
Windows is of course out of the equation.
Living from donations isn't really a sustainable thing.
Going to sleep - it's under power options in Settings.
Also writing to NTFS is not a problem they care about. When's the last time you wrote to ext4 or HFS+ on Windows natively without extra tools?
It's exactly the same here - they support HFS, HFS+ and FAT32 and VFAT. Windows supports NTFS and FAT32 and VFAT. Do we get upset with Microsoft because they don't support HFS+?
Yes, but do you want to have different setting for your trackpad and mouse at the same time? You need a third party software. It's not as bad as I told the story
> Going to sleep - it's under power options in Settings
But I don't want to open the settings and change the behavior of the whole system if I right now need to have it awake for 10 minutes. Sure I could launch `caffeinate` on a terminal, but a clickable applet would be better. But of course it's either paid or buggy.
> writing to NTFS is not a problem they care about.
As to say, they don't care about something very basic that their users might need and don't need much implementation.
In fact I think you can simply `mount -t <ntfs_or_something>` your drive or add a line to `/etc/fstab`, but you won't have it in finder.
> When's the last time you wrote to ext4 or HFS+ on Windows natively without extra tools?
This just makes windows a worse OS. If you compare it to a real OS, like your favorite linux variant, you can.
> Do we get upset with Microsoft because they don't support HFS+?
Actually I do. This is exactly what I'm talking about: it's just a business practice to enforce their own standards, since the whole implementation wouldn't be so hard: they could just add a pop up upon installation that says "This software is not guaranteed to work, use at your own risk".
In the end, it is clear that a OS which support more FSes (especially the most widespread ones) is better than the same OS without that feature, and I say we should complain that we can't get it.
I think you are expecting the wrong thing from the OS. How do you keep Windows awake for 10 minutes only? Proper NTFS support on Linux is only recent (and I don't think it supports all the excellent features of NTFS).
If an OS vendor adds in support for something that is only partial or offers messages regarding "this isn't really supported", either a) nobody would use it, or b) people would use it and complain. It is safer to release something complete, or not at all. And since "typical" Mac users aren't trying to mount ext4, ReiserFS, XFS or NTFS on their machines I can see why they would not support it.
For comparison, when's the last time you used COM or DCOM on Linux or Mac? When's the last time you ran a Cocoa app on Linux? Does it sicken you that RedHat and SUSE won't pull their finger out and support these technologies? Why doesn't RedHat release a driver for SQL Server ODBC support independent of Microsoft? They must be attempting to force their own Linux-centric monopoly!
You can see how foolish this sounds. It is based on unrealistic expectations.
Yeah, not happening. I have some users who sometimes complain about something broken in iOS on Safari, I google, and it turns out to be a known Safari bug. I just tell them that it is their device which is broken, which they agree with because it works fine on their computers. And it works fine for other users with Android phones.
The people who this hurts, are the Apple end users. There are a few bugs they just have to deal with because it's impossible for me to test a fix. Tough luck for them.
This is however for a free product. Anyone is of course welcome to buy me Apple hardware, but I don't see that happening either.
If we had a properly functioning DoJ they'd crack down on this anti-competiive behavior. But we don't.
Haha, joke's on them - I simply won't test[1] my web apps against Safari!
1. But our QA does :(, so I guess they won. Fortunately Apple decided to create 1st-party webdriver support as of Safari 10, so they at least recognize that assisting developers test on Safari is important. Hopefully someday we'll get macOS disk images to test Safari à la modern.ie
Nowadays linux can certainly run on Apple hardware without any extra effort
Edit: macOS!
Technically OS X is a "UNIX clone"
> and there are toons of goodies on the OS X
You mean there is a Clippy for OSX?
Yes it is, but it doesn't share the UNIX culture, rather the GUI culture inherited from the Xerox PARC ideas that impregnated Apple and NeXT.
The UNIX compatibility was a requirement for NeXT to get a foot in the market targeted by Sun and Irix workstations.
Apple and NeXT never had a culture of pure CLI applications and daemons.
Also my Hotpoint dishwasher at home has a circuit board that I can only buy from Hotpoint. Does this mean they are abusing their position? Should I expect to be able to run something else on my dishwasher?
My car is a Volkswagen. I cannot take engine management software from a Chrysler and put it into my Volkswagen. Yet Volkswagen is a very large competitor in the "car" market. Does this mean that Volkswagen is abusing its position regarding the engine management software in my car?
If I am right, you are saying that Apple has a monopoly of power inside its own operating system. Yes, I think that's correct!
Where I work, my company has a monopoly on the features and timescale in the application software that we develop. I don't think anyone would ever call that a monopoly in the true sense of the word. Would you let me dictate what features go in your software?
Why would Apple let anyone else tell them what should go in their software?
Google it or search on Youtube. This works well for testing purposes
On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) Certain utilities like gdb will not run because System Integrity Protection disallows them. In theory, we can sign gdb through a somewhat circuitous series of steps, except that this doesn't work if we want to ssh into the box. This requires turning off SIP, modifying some files, and then turning SIP back on. Technically, it's all possible, but it's one series of aggravations after another. Developing on a platform should not be this difficult.
I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.).
Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake.
And then you have to deal with things such as VC's standard library not having getopt, etc.
For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.
Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS.
Also, Visual Studio has its own package manager with tons of libraries and tools.
Of course, much of changes now with Windows Subsystem for Linux.
Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches.
As a quick note, thank god for the Homebrew crew as that does make things much nicer.
As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.
Kind of annoying that Intel's Fortran compiler on Windows is the only commonly-used one that doesn't at least allow you to ask for gfortran-compatible mangling. Hopefully if the PGI LLVM Fortran front-end ever gets released it'll be another option (fingers crossed that it uses gfortran compatible mangling so life is simpler).
It is also possible to link gfortran compiled dll's with C and C++ in Visual Studio. A few years ago I even called a gfortran dll from C# using p-invoke with no particular problem.
Agree, this is why I've mentioned that you can use Fortran code compiled as a DLL with gfortran (open source) from Visual Studio in C, C++ and C# projects.
I'm sure they'd appreciate help.
A funny footnote to that article is now with Windows 10 and the ucrt, Windows is "a Microsoft Visual C/C++ Run-Time delivery channel" once again.
My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operating system and no changes ever how things look or work.
That pretty much limits you to Debian unstable... Or Windows, if forcibly upgrading counts as "rolling."
But wouldn't a rolling release be the exact opposite of what you'd want if you want no changes, ever? And if that's the case, just don't upgrade macOS until Xcode forces you to, that usually gives you a few years. I stayed on Snow Leopard for years until Apple put a gun to my head, but Mavericks and Yosemite gave me no problems; everything worked just like it did before. (I still miss Snow Leopard, though...)
Typically, changes in rolling releases are easier to deal with. At any time, the change is smaller, so you don't have to be overwhelmed by a large number of changes all over the place, as is sometimes the case with versioned releases; and the changes are fresher, so your inputs to the developers who made the change are easier to apply.
Hence my remark, the original workstation where twm was created is good enough.