61–70 of 143 posts
It's really sad that the only way to get macOS running in a virtual machine is with hacks and tweaks. I'm working on a cross platform desktop app written in Qt and while it should theoretically work on macOS I haven't had a chance to actually try it, because I don't own any Apple computers. Apple is shooting themselves in the foot.
Earlier quoted context omitted.
Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. 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_LI…
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.) 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 mu…
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.
Earlier quoted context omitted.
> rolling release 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…
Debian Unstable isn't the only rolling release distro. Another popular one I can think of Arch Linux. 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 a…
Earlier quoted context omitted.
You get all the Unix goodness you would get from Linux combined with the commercial polish you're used to from Windows (even more so).
Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. 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_LI…
Earlier quoted context omitted.
Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. 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_LI…
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.) 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 mu…
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.
Earlier quoted context omitted.
Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. 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_LI…
I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
Earlier quoted context omitted.
That's the point. I don't want to have to ssh into it. However, since I can't legally virtualize MacOS on my laptop I'm forced to in order to make sure that my software works fine on MacOS. That's why I'm resentful toward Apple. They make it really difficult for people to develop cross platform applications that work on MacOS and the only response I tend to get is a smug, "Eh, just buy a Mac Book."
> only response I tend to get is a smug, "Eh, just buy a Mac Book." 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 bu…
Earlier quoted context omitted.
> Apple is shooting themselves in the foot. 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 fo…
Everything you said is very true. 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…
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.
https://github.com/AndrewDryga/vagrant-box-osx#downloads Can hosting these images get you sued?