On Wednesday, 8 November 2017 at 09:34:39 UTC, Joakim wrote:
> ...

Companies (along with their technologies and profits) are like waves in the ocean..they come..and they go..

But BSD Unix.. like the energy which binds our molecules...will always be with us... it seems..

So I re-iterate. If we all just used FreeBSD, then we'd all be sitting around a fire singing kumbaya (during our break from writing stuff in D), instead of debating the merits of Microsoft, Apple and Google.

..And btw..we could immediately start writing 64bit code, with only a tiny 16MB download (dmd for freebsd).

What operating system can compete with that?

On Wednesday, November 08, 2017 10:35:17 codephantom via Digitalmars-d wrote:
> On Wednesday, 8 November 2017 at 09:34:39 UTC, Joakim wrote:
> > ...
>
> Companies (along with their technologies and profits) are like waves in the ocean..they come..and they go..
>
> But BSD Unix.. like the energy which binds our molecules...will always be with us... it seems..
>
> So I re-iterate. If we all just used FreeBSD, then we'd all be sitting around a fire singing kumbaya (during our break from writing stuff in D), instead of debating the merits of Microsoft, Apple and Google.
>
> ..And btw..we could immediately start writing 64bit code, with only a tiny 16MB download (dmd for freebsd).
>
> What operating system can compete with that?

Linux.

Oh, I'm all for using FreeBSD, but most of the arguments for using FreeBSD over Windows apply to Linux. And if you can't get someone to switch from Windows to Linux, you're not going to get them to switch to FreeBSD. FreeBSD and Linux are definitely different, but the differences are small when compared with Windows.

Personally, I think that the best course of action in general as a developer is to try and make your software as cross-platform as reasonably possible and let folks run whatever they want to run. A lot of the OS-related problems we have stem from the fact that too often, software is written for a specific OS (and not just Windows software is guilty of that). Unfortunately, it's not always reasonable or possible to write cross-platform software, but IMHO, that should at least be the goal, even if you're primarily targeting a single platform for release.

All of the software at one of my previous employers is written for Windows and uses lots of Windows-specific stuff even when the code really has no need to be Windows-specific. They've talked about wanting to run some of their software on Linux, but they can't do it without some major rewrites (to the point that it might actually be better to do it from scratch), and they're far from alone in being that boat. And it's not like there's something special about Windows that causes the problem. You could just as easily write your software to be Linux or FreeBSD-specific and then want to use it in a Windows application and be screwed. Writing your software to be platform-agnostic really needs to be a goal from the start, and IMHO, it's really not all that hard in most cases. It's just that too often, folks assume that they're only ever going to target a single platform.

But if you write your software to be as platform-agnostic as you reasonably can, then the platform that you're actually using matters a lot less. It also means that you can take advantage of development tools from multiple platforms.

- Jonathan M Davis

On Wednesday, 8 November 2017 at 11:47:32 UTC, Jonathan M Davis wrote:
> Personally, I think that the best course of action in general as a developer is to try and make your software as cross-platform as reasonably possible and let folks run whatever they want to run. A lot of the OS-related problems we have stem from the fact that too often, software is written for a specific OS (and not just Windows software is guilty of that).

Well.. that was the role that POSIX was meant to play. Even Windows was on board, sort of, for a short time. What a joke that all turned out to be.

"Perfect application portability across UNIX-based OSes is clearly beyond the realm of possibility." (from the 2016 paper below)
-
http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine.pdf

(conclusion: "We believe that a new revision of the POSIX standard is due, and we urge the research community to investigate what that standard should be."

btw. I wonder if anyone has got the linux version of DMD x64 to run on the Windows Subsystem for Linux (available in Windows 10 I believe).

On Wednesday, November 08, 2017 12:35:19 codephantom via Digitalmars-d wrote:
> On Wednesday, 8 November 2017 at 11:47:32 UTC, Jonathan M Davis
>
> wrote:
> > Personally, I think that the best course of action in general as a developer is to try and make your software as cross-platform as reasonably possible and let folks run whatever they want to run. A lot of the OS-related problems we have stem from the fact that too often, software is written for a specific OS (and not just Windows software is guilty of that).
>
> Well.. that was the role that POSIX was meant to play. Even Windows was on board, sort of, for a short time. What a joke that all turned out to be.
>
> "Perfect application portability across UNIX-based OSes is
> clearly beyond the realm of possibility." (from the 2016 paper
> below)
> -
> http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine.pdf
>
> (conclusion: "We believe that a new revision of the POSIX standard is due, and we urge the research community to investigate what that standard should be."
>
> btw. I wonder if anyone has got the linux version of DMD x64 to run on the Windows Subsystem for Linux (available in Windows 10 I believe).

POSIX certainly helps, but each OS that implements it adds more stuff on top of it (like extra flags or similar but different system calls that improve on the POSIX ones), and there's plenty of stuff that's simply not part of POSIX but is all over the place in slightly different forms, since it's not part of a standard. Heck, even when something is part of POSIX, that doesn't mean that it's properly and fully supported on a system that supports POSIX - e.g. the stuff that's in librt (like clock_getttime) isn't implemented on Mac OS X even though it's part of POSIX, so the stuff for getting the time in core.time and std.datetime has to be different for Mac OS X. Granted, the Mac OS X calls are actually better, but you're still stuck implementing the code differently for different OSes in spite of a standard.

And while historically, Windows implemented some POSIX stuff, they went and slapped an underscore on the front of all of the names, totally breaking compatibility. The new Windows Subsystem for Linux should be a huge step forward in some regards, but if I understand correctly, it's basically an emulation layer for running linux programs and not something you'd use as part of a Windows program. So, it only works if you're just looking to run Linux programs under Windows, not if you want to write a program that runs as part of Windows and can take advantage of the Windows stuff where it needs to. So, how useful it is depends on what you're trying to do.

Improvements to standards to allow for more stuff to be written in a cross-platform manner without versioning stuff it off for specific OSes is definitely desirable, but the reality of the matter is that even OSes that are very similar end up with differences that occasionally require versioning code - sometimes even when the API being used is part of a standard. And much as things could be improved, I don't see that ever changing. It sure doesn't help though when each OS goes off and implements something drastically different for core stuff (like opengl vs directx). Some competition is good, but when a major API is platform-specific, it makes it a _lot_ harder to write cross-platform code.

Ultimately though, even when dealing with different BSDs, you end up with portability problems if you're not careful.

- Jonathan M Davis

On Wednesday, 8 November 2017 at 12:35:19 UTC, codephantom wrote:
>
> btw. I wonder if anyone has got the linux version of DMD x64 to run on the Windows Subsystem for Linux (available in Windows 10 I believe).

I'm not that familiar with the Windows Subsystem for Linux, but it looks like it could be very useful. I'll set it up and try to install DMD tonight if I have time.

On Wednesday, 8 November 2017 at 09:34:39 UTC, Joakim wrote:
> On Wednesday, 8 November 2017 at 00:09:51 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 7 November 2017 at 19:46:04 UTC, Joakim wrote:
>>> Not at all, it makes things easier certainly, but there's a reason why mobile devs always test on the actual devices, because there are real differences.
>>
>> Mostly with low level stuff in my experience.
>
> And what experience would that be?  I've admitted I've never developed for Apple platforms, but my understanding is that even leaving aside the completely different touch-first UI, there are significant differences.  I wonder what Mac apps you simply ported the UI over to iPhone and they just worked.

Writing code from scratch for both. No, of course you cannot port it without a little bit of work as the base UI class is slightly different. However it is overall the same Objective-C framework design.

Quoting apple:

«If you've developed an iOS app, many of the frameworks available in OS X should already seem familiar to you. The basic technology stack in iOS and OSX are identical in many respects. But, despite the similarities, not all of the frameworks in OS X are exactly the same as their iOS counterparts»

https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/OSX_Technology_Overview/MigratingFromCocoaTouch/MigratingFromCocoaTouch.html

> I just said they're not going to dump it, so I don't know why you're going on about that.  If you mean their current lessened investment is not a good idea, it's because the old desktop OS doesn't matter as much, which is the whole point of this thread.

That would be an overall mistake as they would loose mindshare among programmers, but nevertheless the desktop is a much more mature environment.

>>> You are thinking too much short term here IMHO. The mobile
>> sector is rather volatile.
>
> I have no idea what this refers to: you have a bad habit of adding asides without any explation or non sequiturs, so that we're left stumped as to what you're talking about.

Over-quoting is spammy. So I don't, but here you go: The mobile sector is more volatile than the desktop/laptop sector, hence it would be a risky move to dump it. I think that was quite clear from what I wrote though…

> I see, so your claim is that MS, Nokia, HP, Sony, all much larger companies than Apple or google at the time, could not have countered them even on a lucky day.  I wonder why this is, as they certainly had more money, you don't believe they're that bright? :)

No, it is because they didn't have the resources internally. Money alone does not build teams or knowledge. Apple had worked on similar technology for decades and could recycle the frameworks for their desktop OS.

> Yet the businesses that did build Android, ie google, HTC, and so on, were much smaller than the corporate behemoths like HP or Sony that you claimed above couldn't do it.  Your claims about who could or couldn't do it make absolutely no sense.

Of course it does. They were not into operating systems and frameworks. Sony a little bit by having the Playstation, but that was very narrow and for a very narrow low level segment of programmers.


> Their problem was likely that they got in too early and got discouraged, not that they were "getting in late."

Apple was also in too early and got discouraged, but they reentered when the touch screen tech got better.

On Wednesday, 8 November 2017 at 14:36:11 UTC, jmh530 wrote:
> On Wednesday, 8 November 2017 at 12:35:19 UTC, codephantom wrote:
>>
>> btw. I wonder if anyone has got the linux version of DMD x64 to run on the Windows Subsystem for Linux (available in Windows 10 I believe).
>
> I'm not that familiar with the Windows Subsystem for Linux, but it looks like it could be very useful. I'll set it up and try to install DMD tonight if I have time.

The linux build of dmd has already been used on WSL to compile ldc without a problem:

https://wiki.dlang.org/Build_LDC_for_Android#Notes_for_Bash_on_Ubuntu_on_Windows

On Wednesday, 8 November 2017 at 14:40:11 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 November 2017 at 09:34:39 UTC, Joakim wrote:
>> On Wednesday, 8 November 2017 at 00:09:51 UTC, Ola Fosheim Grøstad wrote:
>>> On Tuesday, 7 November 2017 at 19:46:04 UTC, Joakim wrote:
>>>> Not at all, it makes things easier certainly, but there's a reason why mobile devs always test on the actual devices, because there are real differences.
>>>
>>> Mostly with low level stuff in my experience.
>>
>> And what experience would that be?  I've admitted I've never developed for Apple platforms, but my understanding is that even leaving aside the completely different touch-first UI, there are significant differences.  I wonder what Mac apps you simply ported the UI over to iPhone and they just worked.
>
> Writing code from scratch for both. No, of course you cannot port it without a little bit of work as the base UI class is slightly different. However it is overall the same Objective-C framework design.
>
> Quoting apple:
>
> «If you've developed an iOS app, many of the frameworks available in OS X should already seem familiar to you. The basic technology stack in iOS and OSX are identical in many respects. But, despite the similarities, not all of the frameworks in OS X are exactly the same as their iOS counterparts»
>
> https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/OSX_Technology_Overview/MigratingFromCocoaTouch/MigratingFromCocoaTouch.html

This link also notes many other significant differences, such as mobile hardware being much more constrained and "iOS users have no direct access to the file system," as I mentioned.

>>>> You are thinking too much short term here IMHO. The mobile
>>> sector is rather volatile.
>>
>> I have no idea what this refers to: you have a bad habit of adding asides without any explation or non sequiturs, so that we're left stumped as to what you're talking about.
>
> Over-quoting is spammy. So I don't, but here you go: The mobile sector is more volatile than the desktop/laptop sector, hence it would be a risky move to dump it. I think that was quite clear from what I wrote though…

It was not clear because it is divorced from reality, which of these two markets would you rather be in?

https://mobile.twitter.com/lukew/status/842397687420923904

In fact, Apple alone will likely sell more mobile iPhones and iPads this year than every PC vendor combined (see third chart):

http://www.asymco.com/2016/11/02/wherefore-art-thou-macintosh/

They have already cut investment in Macs and are not bothering to upgrade the existing Mac line for longer and longer, on the way to axing that line altogether. The notion that their iOS line, which now brings in the vast majority of their profits and revenue, is riskier is a joke.

>> I see, so your claim is that MS, Nokia, HP, Sony, all much larger companies than Apple or google at the time, could not have countered them even on a lucky day.  I wonder why this is, as they certainly had more money, you don't believe they're that bright? :)
>
> No, it is because they didn't have the resources internally. Money alone does not build teams or knowledge. Apple had worked on similar technology for decades and could recycle the frameworks for their desktop OS.
>
>> Yet the businesses that did build Android, ie google, HTC, and so on, were much smaller than the corporate behemoths like HP or Sony that you claimed above couldn't do it.  Your claims about who could or couldn't do it make absolutely no sense.
>
> Of course it does. They were not into operating systems and frameworks. Sony a little bit by having the Playstation, but that was very narrow and for a very narrow low level segment of programmers.

I see, so MS, Nokia, HP, Sony, and all the rest didn't have "resources internally" or knowledge of "operating systems and frameworks," but the much smaller search startup google did?  When google bought Android in 2005, they had yearly revenues of $6 billion, a pittance compared to the PC and mobile giants you are excusing:

https://www.informationweek.com/google-revenue-up-93--in-2005/d/d-id/1040162

I don't know if you're trying to make me laugh with these excuses or what.

>> Their problem was likely that they got in too early and got discouraged, not that they were "getting in late."
>
> Apple was also in too early and got discouraged, but they reentered when the touch screen tech got better.

Which MS could have done also, but didn't.  Any way you slice it, Apple grabbed an opportunity that plenty of other people could have- and according to you had the knowledge to, since you say many knew mobile was next- yet almost none of them did.  That speaks to what I was trying to show with that chart of the mobile tidal wave, that everyone, including Apple to some extent, didn't see _that_ coming.

On Wednesday, 8 November 2017 at 17:51:45 UTC, Joakim wrote:
>
> The linux build of dmd has already been used on WSL to compile ldc without a problem:
>
> https://wiki.dlang.org/Build_LDC_for_Android#Notes_for_Bash_on_Ubuntu_on_Windows
>

Thanks. I'll make use of that. I'll be happy if I can get blas/lapack working.

On Wednesday, 8 November 2017 at 17:51:45 UTC, Joakim wrote:
> way to axing that line altogether. The notion that their iOS line, which now brings in the vast majority of their profits and revenue, is riskier is a joke.

That really depends on what you mean by risk. There is no general correlation between high profits and low risk.

> I don't know if you're trying to make me laugh with these excuses or what.

So you don't understand that the foundation that Apple had for building iOS takes time, not only resources. Money does not solve all problems, but you think otherwise. Ok. I strongly disagree.

I assume it is a goodhearted laughter you are enjoying…

On Wednesday, 8 November 2017 at 21:02:26 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 November 2017 at 17:51:45 UTC, Joakim wrote:
>> way to axing that line altogether. The notion that their iOS line, which now brings in the vast majority of their profits and revenue, is riskier is a joke.
>
> That really depends on what you mean by risk. There is no general correlation between high profits and low risk.

I'm not saying mobile isn't risky.  It's a cutting-edge tech business, of course it's risky.  Just look at HTC, LG, and all the other mobile vendors doing badly.  However, I'd rather be in a booming risky business rather than a declining risky business, which is what the desktop market is and therefore riskier.

>> I don't know if you're trying to make me laugh with these excuses or what.
>
> So you don't understand that the foundation that Apple had for building iOS takes time, not only resources. Money does not solve all problems, but you think otherwise. Ok. I strongly disagree.
>
> I assume it is a goodhearted laughter you are enjoying…

I don't know why you go back to Apple, when you clearly cut out the part of the above excuses quote where I pointed out that _google had none of the advantages_ you think were necessary to win mobile, yet created the OS that now ships on the most mobile devices.

Of course it's not just a matter of money, but you were the one who mentioned how internal resources are needed, which is belied by the fact that google had much less.  You talk about OS expertise, all while HP has long had their own OS's, HP-UX and later Tru64, same with Sony and the various in-house OS's they've worked on.

You don't want to own up to the fact that google succeeded with a lot less resources and OS expertise than the companies you claim couldn't do it, which suggests those factors you think were so important likely weren't.  More likely, it is what I said: the incumbents like MS or Sony just didn't foresee mobile growing so large so fast, at least that was one of the main reasons.