Could you imagine if the Linux Developer Center went down? It'd be nearly impossible to write Linux software, or download Linux development tools, or generate a Linux binary that a device was allowed to run. It'd be awful.
Real businesses are affected by this. Please keep your trolling elsewhere. I came to the comments looking for what people are doing, not for snarky and ill-informed comments.
> It'd be nearly impossible to write Linux software, or download Linux development tools, or generate a Linux binary that a device was allowed to run. It'd be awful.
You clearly don't understand how the Apple Dev center works.
I managed to snag the iOS 7b3 SDK before it went down but not the documentation, unfortunately. Those downloads have been broken the whole time, so a download of Xcode is only as good as the documentation you still have.
No, you can download a .deb file from somewhere else and install it manually, or even just a .tar.gz with the binaries, or (if the software is open source) even get the source! Alternatively, as I posted above, there are a load of mirrors (over 400 iirc) of the ubuntu software repository.
Nice attempt at snark, but something being fault-proof in this regard doesn't magically make it worthy in others.
Like desktop use, for one. People will not adopt Linux for their desktop/laptop even when offered for free. Where by people I mean more than 1% of them.
That is not totally true. The reason most people stay with Windows is because the hardware ships with it. In my experience Linux usage has about 50% retention rate among those I installed the OS for.
If you'd install OSX or Windows on a non techie who grew up using just Linux, I'd think the retention rates would be much lower.
>That is not totally true. The reason most people stay with Windows is because the hardware ships with it.
Only every attempt to sell hardware that ships with Linux (by several companies) failed.
And the "switch to something different" didn't seem to bother those going to OS X.
OS X, in less time than what Desktop Linux was promoted (1998-2013 for Dektop Linux, 2001-2013 for OS X), and with more expessive hardware, went from 2% to around 12% in the US (and even more for laptop share).
>In my experience Linux usage has about 50% retention rate among those I installed the OS for.
No, that is actually stunningly good, considering the alleged state of the Linux desktop and considering the audience that the Linux desktop has traditionally been targeting. It is so good, that I suspect he has a strong selection bias (he is probably only installing Linux for users he thinks may be able to use it fulltime. This selection is probably unconscious.)
(And because it always seems to be necessary to add this disclaimer: I've been using Linux fulltime for over a decade; I'm not a critic, just a realist.)
Yeah well its not like computers ship without OS so your point does not really make sense. And its not like Linux has marketing unlike all other OSes out there. When you want to compare stuff you got to have similar factors in place otherwise it does not make sense.
Haha, great troll, dudebro! Well, gonna go back to making money from iOS apps and running Linux on a backend server since I can still write software, download development tools, and generate binaries.
Could you imagine if people could make the kind of money developing things for Linux that they do developing things for iOS? It would make comments like yours kind of funny and relevant.
> Could you imagine if people could make the kind of money developing things for Linux that they do developing things for iOS? It would make comments like yours kind of funny and relevant.
Yeah, one has to admit that Mac users are a more receptive audience for the high-brow humor of sophisticated fart apps.
And consumer software is the only one that matters because..? In any case if your mom uses the interwebz, she has probably used Linux software, both free and money-making.
Why should companies care about selling software for $9.99 when there are free alternatives, while instead they can focus on other things where they really add value ?
There is money to be made making software for Linux. Mostly in engineering / Scientific software. Making money of utility software ? Not so much. If you are a company like PGI you are probably making a ton of money selling fortran compilers to people running Linux on their clusters.
Sadly the PGI compilers are (at least in my experience with codes I use) buggy, slow, and difficult to use. Why pay when I can get comparable performance using GNU compilers?
People using FORTRAN have this weird tendency of not changing much with the times. Their code bases go back decades, and PGI compilers are something they continue using.
My experience with PGI is that the engineers liked them because they had a FORTRAN to CUDA compiler, so they didn't have to rewrite their code. They were pretty good about answering bug reports, with the number of times I had to install new compilers on the compute systems.
I would wager more money is made via Linux than iOS by a fairly large margin.
As an aggregate measure, spread across several million people? Perhaps. Resolving that is just a matter of looking up the data.
But that's not the question that matters for an actual developer. What actually matters is: How much money are you making on one platform, and how much could you make on the other? That question has a lot more to do with whether or not a developer makes his or her rent next month than the aggregate measure above.
I'm not saying it's useless to look at the long-term picture. I'm just trying to show that it's a big mistake to focus on that to the exclusion of more pressing things first.
I'm not sure I completely follow you.
I would calculate on the basis of developers building software that runs on top of Linux, so that would include a large proportion of all web applications as well as various embedded applications. You could probably include android in there also.
Now it's true that this isn't quite apples to apples since Linux is more fungible than iOS in most regards, mostly thanks to it's open source nature. For example moving your web application from Linux to FreeBSD is likely to make less of a revenue difference than say moving from iOS to Windows Phone 8.
The biggest point is probably that the existence of an Open Source/Free operating system has probably enabled more profitable businesses to exist than iOS.
The biggest point is probably that the existence of an Open Source/Free operating system has probably enabled more profitable businesses to exist than iOS.
Maybe.
On the one hand, I know exactly how great it is to have development tools that are a free download away (I remember shelling out hundreds on a C++ compiler in the mid-90s). Open source definitely rocks in this respect.
On the other hand, I know that without the iPhone, iOS, and all of the associated things that came with it (including the industry's massive pivot to compete in its wake), things might look very different for an app developer today. (Or at the very least they'd be slower in getting to this point.) I think it's important to realize that there were no independent app developers in 2007 - writing, buying and using software for the Palm handhelds or Windows CE was radically different on nearly every level.
It's quite difficult to retroactively unpick cause and effect though it could certainly be argued that the existence of Linux (and free UNIX in general) contributed greatly to the rise of the web.
I would still wager that more paid developer hours go towards stuff that ends up being executed on top of Linux than iOS though.
Why would you include Web Applications as part of that? Web applications are almost completely OS-agnostic. I can run my PHP application on Linux, on OSX, or on Windows. It shouldn't count for any of the three operating systems because it wasn't built for any of them. It was built to run on a software stack which runs on all three.
But people do in fact choose to run them on Linux which is unlikely to be a purely arbitrary choice though by nature open source stacks will be more portable, but it seems perverse to use that as a negative argument.
Sure, but people also choose to run them on Windows, and OSX. If it was Linux-only, then I could see why you'd include it as being "written for Linux" but web applications are, for the most part, OS-agnostic. People can choose to run it on a variety of platforms. Just because one is used more than the others does not mean it is the exclusive platform for web applications as a whole.
You're not writing a PHP application for Linux, you're just writing a PHP application, which can run on one of Linux, Windows, OSX, etc. Just because you choose to run in on Linux does not mean you wrote it specifically to be run on Linux, nor should it be included in the metric for Linux apps.
Some web applications are more platform specific than others.
Since Linux is the most popular OS for running web applications it seems reasonable to assume it was chosen for a reason and therefor web developers would be worse off if it were not available.
> Some web applications are more platform specific than others.
Rarely.
As I said before, you're not developing for Linux when you make a web application. You're developing for Rails/PHP/whathaveyou. These are all OS-agnostic and can be run on any OS. I can run my PHP app on my Macbook, my Linux server, or my friend's Windows desktop. They all work. Because it's not meant to be built for a particular OS.
I don't understand how you can be this stubborn about it. If the language can be run on any number of platforms, then, by definition, it's not an application for one specific platform.
I mean that a very large share of these applications are in practise deployed to Linux. If you total the $ revenue of these applications you would no doubt come to a very large figure.
So? That's not the discussion at stake here. We're talking about apps being written for Linux vs OSX. By definition, a web app is not written for a particular platform (with certain exceptions like ASP.net). If anything, it'd fall into its own category.
By that definition you can only count applications that rely on proprietary OS features, which you generally don't have with an open source OS (that's sort of the point).
I don't think it's invalid to describe a web app deployed to Linux or an embedded system running Linux as a "Linux app" but I guess that is really semantics.
Theoretically, you're correct. In practice, you look at a company like Amazon (where I work) and our software, while mostly it is written in Java and other high level languages, there are many bits and pieces written in C and C++, and even the high-level bits are likely to fail spectacularly if you try to run them on anything other than a close relative of the Linux distribution they were built for. This is just a fact of software development. Write-once run-everywhere is a virtual myth.
Unless of course you're talking about building a single Linux virtual machine image and deploying it to thousands of servers. That actually works phenomenally. Doesn't work as well with Apple's software. Or Microsoft's for that matter (though this is largely a question of licensing cost.)
> I would wager more money is made via Linux than iOS by a fairly large margin.
Without a doubt. IBM, Google, Amazon, and many, many others are deep in the Linux eco-system. Pretty much all supercomputing is done on Linux, and all the boring cloud/infrastructure/scientific stuff is done on Linux.
More people drive Toyota than BMW. More people eat at McDonalds than Five Guys. More people stay at a Holiday Inn than The Ritz Carlton. The statement is worthless as it conveys no meaning, other than a factoid, as do my statements.
How is that smugness working out for you ? Windows users are fewer than iOS users. Would you now compare Windows phones to Ferraris by using the same analogy ?
True. But the reality is far more complicated than that. In order to compare the two objectively (this is from the perspective of a developer, but many of the same factors also apply for end users), you also have to take into account things like the number of users that buy apps, app store fragmentation, how your software will fare in each store, and a whole host of other technical and market factors that are frequently discussed here.
I realize this might not be what you're saying, so I'll slay a misinterpretation for those that might hold it: going only by the sheer number of users on a platform alone does not mean that it is going to be a good idea for you to develop for it.
Most notable point is that iOS users spend more than 3x on apps than android users. Also, the same exact app on the iTunes Store tends to make more then 3x in sales than the same app on Google Play.
But iOS users surpass Android users in web usage and other smartphone features. Android is essentially the default choice on cheap feature phones. It's often what one gets when there is no choice.
Can you imagine writing desktop software for Linux? Inconsistent APIs, API breakage, ABI breakage, sizable variances between distributions, multiple desktops UI implementations, and you may as well just forget about mobile.
I'm not justifying Apple's ever increasing shift towards enacting strict constraints on their platform developers, but the comparison with Linux is pointless.
The company I work for develops high-end desktop software for Linux, Mac and Windows, and Linux generally causes us the least trouble and OS X (thanks mostly to atrocious graphics drivers and OpenGL support in addition to really bad memory allocation/paging issues that have only just been fixed in Mountain Lion) the most trouble. And this is on limited numbers of hardware and software variations for OS X.
We "officially support" RHEL 5.4 and RHEL 6.0 (and thus corresponding CentOSes).
But we've got customers running everything from RHEL 4.5 to the latest and greatest Ubuntus, Mints and Arch.
All with the same binary installers.
The only linux-related weirdness I can recall in the last two years distro-wise was Scientific Linux, which seemed to have some weird XOrg config issues.
So you integrate with the user's desktop environment, using standard local widgets, theming, integration with UX guidelines, local library dependencies, etc?
Or are you shipping a Qt app with your own dependencies included? If so, Qt is pretty notoriously buggy on OS X (and rightfully disliked by most users as it stands outside all platform conventions), perhaps explaining some of your complaints.
Local widgets & theming yes, although generally we ship with our own themes by default as we make VFX apps, and the last thing artists want is bright UI to distract them.
I don't believe there are general UX guidelines for Linuxes, but for things like notification popups, system tray stuff, yeah, we do all that natively to the distro through Qt (DBus handles all that transparently within Qt very nicely).
We ship Qt as shared libs with the binaries and all dependencies we need system-wise statically - i.e. zlib, libpng, libjpeg are statically linked. For things like embedded Python, we have to do the same on OS X anyway, due to different python and zlib versions per OS X version.
As for Qt and OS X regarding nativeness - I keep hearing this, but I never see any good examples. I agree it's possible to create Qt Apps on OS X that looks crap, but it's also possible to make them look native as far as I'm concerned. The only thing I can remember not being able to easily do in Qt regarding OS X widgets is the horizontal grouping of side-by-side buttons in radio-button fashion. But it's easy enough to knock up a QWidget subclass which replicates this. But admittedly I don't think I've tried to replicate every possible OS X control/widget...
I think what might be the most difficult part of making a Qt app on OS X look native is the layout and spacing stuff, which generally does seem to be a bit crap within Qt on OS X.
I can have the same code to do a side-panel with edit values in a panel, and it looks great on Linux and Windows:
http://imgur.com/kUI90ry
and the spacing and padding is all over the place - so I have to add a manual style-sheet to get the padding and spacing right, which is crap (image above is without extra stylesheet). So I'm not saying it's perfect or easy, but I think it is possible.
The dialog you've shown for OS X does not look native at all. Not just the spacing, but especially the second selector ('render') is quite odd. Also the font usage for the labels, the light-gray borders around the input fields and the tab focus is strange.
Does QT basically render a bitmap, or does it use the native controls and just has some odd default styling? If it's the first, then I would probably do the UI in native Objective C/Cocoa and keep a nice cross platform base for the VFX core of the app. Not sure if that's feasible for your application of course.
I concede the borders are slightly different, but I personally wouldn't have noticed or minded.
The render button is a custom button - the only difference from the native one is the right-hand menu triangle which isn't native.
Qt has styles, and draws controls itself via vector drawing. And you can customise this yourself: So you've got all the power in the world to do what you want, but at the expense of loads of complexity that no-one's really going to go to the trouble of doing. So basically, it tries to emulate the controls on all platforms, and does a pretty poor job on OS X.
Thank you, very interesting. Am I correct that the button 'Visible to: All' is basically an action button where you can use the arrow on the side to change the action within? Those are not really common on OS X. Guess that's why it looks a bit out of place.
I would side with the reader below, I think that going for a completely different look works better than 'almost' native. Ableton Live is a good example I think that has (almost) the same UI on Mac as on Windows which doesn't look bad on either OS.
Not quite: it's a highly-custom multiple selection mask button (with intelligent title based on the selection options) - doesn't really have any native equivalent on any platform as far as I'm aware:
The OS X version looks ancient and not like a modern OS X app at all. Is that due to limitations in Qt? I had considered Qt for cross platform development, but after seeing that comparison it seems like it would be better to maintain separate front-ends for different platforms.
I am thinking of Pixelmator, or Apple's Final Cut Pro and Motion for comparison to your screenshot. Even modern versions of Photoshop manage to look much nicer than that.
It's got a custom overall stylesheet for the tab widgets as I don't like the OS X tab style or colour, so they're completely different.
Qt "emulates" native control appearances by drawing them itself. This means it doesn't get it 100% correct (in OS X's case). You can apply stylesheets to configure all aspects of spacing and appearance, so in theory it's possible to write a stylesheet to completely emulate OS X's controls (or at least the majority of them), but that'd be a lot of work which you probably wouldn't want to do.
I could make it any colour I wanted with stylesheets in Qt - this was a personal app, and I'm not too concerned with what it looks like.
Mostly things that smelled like memory leaks (pull a matte, leave it for a while, come back and tweak it => long coffee break). Also, restoring from idle seemed to be the hardest on Snow Leopard.
Which keyer? Primatte's had a few issues in 6.3 and previous.
on 10.6 (and 10.7), memory allocation/paging is pretty atrocious if you haven't got much free mem left.
Basically, OS X prioritises paging to disk over freeing up Inactive memory (which isn't actually being used for anything at present), which is pretty crap. So it's very easy to make it page when it shouldn't when you allocate loads of memory, and the system will generally just grind to a halt.
Apple fixed this in 10.8, so now it will free up Inactive memory first, before it starts paging.
But neither of these explain any crashes within Nuke.
The kernel. Everything else from libc on up was rewritten, and under Google's control. The Play store is hardly in AOSP, much less their new IntelliJ-based development stack.
The Play Store along with all the other Google Experience apps like gMail and Maps is not in AOSP. Google has no obligation to open-source those, nor do they want to.
Just use Qt. Works brilliantly, great API and documentation, and gets you 95% of the way to Windows versions and 85% of the way on OS X too. On OS X you'll have issues with native painting within OpenGL drawing and maybe event throttling / reordering for mouse / pen tablet events that you have to install a manual event filter for to fix, as OS X doesn't always send input mouse/keyboard events in the correct order.
There's a massive amount of software that exists outside of note-taking apps where the customer will be more than happy to put up with different-looking buttons because the value the software provides is so high.
There are many software categories where visual-design decisions are not the only competition advantage.
Design is far more than just visual, and your dismissal of design as "different looking buttons" suggests that you don't really understand design very well.
I don't think anyone was, least of all me. In any case, I'll bite:
Different UI toolkits make doing certain things hard, certain things easy, and some things damn near impossible without large effort on the part of the developer.
So when the parent commenter says "Nobody on OS X wants a Qt app", I'd argue that yes, although you can make a "well designed QT app", it's much harder to make a "well designed OS X app" with QT.
Why will it be less likely to be a well designed OS X app? Because it will be different to a Cocoa app made with interface builder, in subtle and sometimes not so subtle ways. Sure you can code around these and make adjustments, but the level of effort and investment to get to the stage of if you'd just built it with a more suited tool for the job (Cocoa / Interface Builder on OS X) is quite high.
This is why there is some truth the the admittedly generalised statement made above that "Nobody on OS X wants a Qt app".
I think a more useful statement is that "Nobody on OSX wants a poorly designed app because the platform has a high standard for design". It is possible to design well designed apps without using Cocoa - see Sublime Text.
I have. It used to use X11, I saw even more complaints then.
There aren't any competitors, however, so people use Mathematica.
I use high-end expensive that are Qt-only too, but I would gladly switch if there were other options, because Qt is buggy, uses non-intuitive non-standard UI, exhibits poor performance due to impedance mismatches between the Mac and Qt event/threading models, and ultimately decreases overall utility of the UX.
Can you give me an example of the "non-intuitive non-standard UI"?
This may well be true, but it's quite possible it's just the developer was lazy and didn't do all the effort to make it look native.
Edit: in fact, I'll give an example: VirtualBox - it does look crap on OS X, but that's because the developers obviously didn't make any effort to make it look native. They've got icons in tabs pane buttons and huge toolbar buttons along the top (which isn't a unified toolbar btw - which would make it look more native), which goes completely against the way OS X apps tend to look.
VirtualBox, IDA Pro, Google Earth (in fact, everything from Google that uses Qt), EAGLE (PCB software), OpenSCAD, QGIS ...
I've literally never been fooled by a Qt app -- a Mac user can spot that hot mess from a mile away. It's not just a matter of visual layout and UX, although that matters and always falls somewhere between subtly or completely wrong.
The controls also tend to lag at weird times, behave slightly strangely, demonstrate unusual font metrics, etc. The apps tend to exhibit bugs related to menu bar event handling, window management, on and on, and crash more than any other apps I use daily.
This isn't a huge surprise given that Cocoa is designed to be the first and only gatekeeper between events, the OS, UI controls, and Cocoa's main event loop, and most of what makes Mac apps a Mac app has to do with the APIs and integration that you lose first-class access to once you deploy Qt -- that includes 'simple' things like UI layout metrics, which Qt has to re-implement.
I abandoned almost all those Qt apps on my list above. I even dropped EAGLE, despite being "native", in favor of Altera on Windows, which I paid a hefty premium for in no small part because it wasn't a pile of broken UX, Windows or not.
I still use IDA Pro, but the minute http://www.hopperapp.com/ can replace my IDA Pro usage, I'll switch in a heartbeat.
Although having looked at hopper, I must say I'm not convinced it seems any more native than a Qt app on OS X could look if work was concentrated with this goal in mind. So as I said in my VirtualBox comment, I think that while indeed it is a Qt deficiency that apps don't look native straight from the compiler, more work could be done by the developer to make it more native-like.
I've seen controls acting weirdly but only QPushButtons - that seems to be regarding the hit-test area - we've had to sub-class a lot of them on OS X to fix this by making the hit test area bigger which is annoying. There's also a pretty bad spacing/padding/layout issue as I alluded to in another comment.
I agree with the event stuff as well - definitely one of the biggest things which affects us is that sometimes mouse/keyboard events don't get sent to the app if the app isn't active or the mouse isn't over a particular window. Debugging through Qt, it seems that Qt never gets the event from the OS, so we have to install event filters for all windows and intercept them which is crap. We've also seen weird stuff like key release events being received before key down events - again debugging through Qt, it looks like an OS X issue in that that's the order they come in from the OS, but again, without a native version to compare to, it's difficult to tell or test.
Generally the crashing of our apps is due to graphics drivers or memory allocation issues (we deal with huge amounts of memory), and I'm not aware of Qt itself being the result of any crashes on OS X for our apps any more than other platforms, but I guess without a native version to compare to, it's difficult to say - but Qt is very rarely the cause of crashes in my experience and I generally develop for Linux and OS X.
Somewhat off topic, but does anyone know how Adobe does their cross platform interface? It doesn't feel like native Mac OS UI, though I think it works pretty well.
In fact they do: Phil Schiller himself on 10th June at the WWDC keynote mentioned that we've ported Mari to OS X, and he was extremely impressed with it and the fact that we've ported it.
It's heavily Qt-based, and doesn't really follow any Apple design guidelines. But it's the best 3D texture painting app in the world for high-end work.
