Linux Support on Pro Edition

[Alexander Elagin 143]

Remember this hot topic re bringing Linux support to the Pro edition like any other platform already there? There is a famous RSP-17195 with a huge number of votes.

Well, as one could expect, this issue has been closed with a popular resolution: Won't Fix. So much for the popular demand...

[Fritzew 51]

Hey, they need to earn money somewhere? Do you work for nothing?

[Bill Meyer 337]

3 minutes ago, Fritzew said:

Hey, they need to earn money somewhere? Do you work for nothing?

Linux is free, not Delphi. If people want to pay for Delphi to build software for Linux, let 'em. So long as Delphi Pro is not free, I don't see that it is "work for nothing".

[Fritzew 51]

Hey, it is the decision from Embarcadero. And to be honest I can understand. I'm not "happy" about it, but.......
 

[Larry Hengen 39]

It makes no sense to me, I just reviewed the edition matrix found at https://www.embarcadero.com/products/delphi/product-editions.  The community edition has support for mobile platforms and MacOS, but not Linux. 

 

What makes MacOS different from Linux....oh yeah, the fact that it has desktop market share.  So you can develop a server process or a full GUI application for free for the Mac (albeit 32 bit right now), but you have to pay the big Buck$ to develop a server application for Linux, the one platform where developers tend to employ FOSS rather than commercial development tools.  If EMBT trusts that their community edition license works, why not include the Linux compiler in that edition?  At least then, developers who want to target linux can see how well the tool works and buy it when their project gets off the ground.  The community edition is meant to bring developers into the Delphi ecosystem.  Without GUI support, a limited number of Windows developers are going to target Linux, and without an entry level edition, no Linux developers are going to try it.

 

EMBT's Linux investment is probably minimal compared to other targets, like Mobile, yet the only way to try it out is with a trial edition.  If trial's worked so well then why did EMBT publish the community edition?

 

Delphi needs to provide a fully cross platform desktop solution or it will lose further market share to the likes of C# and it's community edition.

[Andrea Raimondi 13]

I both agree and disagree at once 🙂

I know, I do this often! 🙂 But let me explain.

 

I AGREE:

Linux should be available for Pro and Community edition

 

I DISAGREE:

At the moment, Emba does not have anything "Enterprise-y" for Linux in Enterprise besides Linux itself.

Is this going to change? I don't know. I have already pointed this out to them as well, so who knows 🙂 

 

And there is another thing as well: objectively, there are going to be far fewer people who will want a Linux edition of their servers given that a lot of Windows developers already have business arrangements with hosters for Windows machines and many just manage these in-house. Plus, honestly, how many developers used to FOSS will actually pay for Delphi? They will still probably settle for Lazarus and FPC because, hey, free! 

It's a difficult act to balance methinks which is why I can see both sides of the issue. But I fundamentally agree: it should be available. 

[Markus Kinzler 174]

[partly OT]Microsofts plans to include a full linux kernel with Windows 10 later this year. [/partly OT]

[Arnaud Bouchez 407]

We use FPC for Linux server-side development, cross-compiling via Lazarus from Windows via https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases

Then we use https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux to run the executable as console with no VM, and validate the regression tests quickly and efficiently.

Even if FPC/Lazarus is Open Source, its compiler is very good.

 

IIRC the Delphi for Linux compiler uses ARC, which could become a real PITA to debug for memory leaks for a server application.
At least, FPC has a single memory model on all targets.
See http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html for this platform limitations/requirements.

Edited May 8, 2019 by Arnaud Bouchez

[Markus Kinzler 174]

4 minutes ago, Arnaud Bouchez said:

IIRC the Delphi for Linux compiler uses ARC,

No. Anymore. Only on mobile ARC is used (will also change in the future).

[Arnaud Bouchez 407]

@Markus Kinzler You are right: I forgot about http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

So many back & forth! 😞
I prefer very much the FPC stability, and attempt to never break existing code - some Delphi people consider(ed) it conservative, but I find it refreshing.

 

For instance, I would miss shortstring support for sure (are they available in Delphi for Linux?), as IMHO they are a good way to avoid heap allocation and an hidden try...finally block, e.g. for efficient logging or text/JSON/XML generation, if you just append some ASCII characters, and don't mess with encoding. A local shortstring is much more efficient than string in some cases.

[Alexander Elagin 143]

33 minutes ago, Arnaud Bouchez said:

I prefer very much the FPC stability, and attempt to never break existing code - some Delphi people consider(ed) it conservative, but I find it refreshing.

I just spent two days debugging an innocently looking piece of code which works correctly when compliled with Delphi Win32, Delphi Win64, FPC Win64, FPC Linux64... but not with Delphi Linux64. The reason was that the Delphi Linux64 compiler for some obscure reason has SizeOf(LongWord)=8... Well, I had to look at the Delphi 10.3.1 help file, which has the following sentence: "Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64." Damn. Then I scrolled the help ten lines up and... "The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord". Confusing, isn't it? The FPC at least is consistent.

Edited May 8, 2019 by Alexander Elagin

[David Heffernan 2345]

26 minutes ago, Alexander Elagin said:

I just spent two days debugging an innocently looking piece of code which works correctly when compliled with Delphi Win32, Delphi Win64, FPC Win64, FPC Linux64... but not with Delphi Linux64. The reason was that the Delphi Linux64 compiler for some obscure reason has SizeOf(LongWord)=8... Well, I had to look at the Delphi 10.3.1 help file, which has the following sentence: "Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64." Damn. Then I scrolled the help ten lines up and... "The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord". Confusing, isn't it? The FPC at least is consistent.

It's not obscure if you realise that Longint and Longword map to the corresponding C++ types long int and unsigned long int whose size is determined by the platform ABI.

[Stefan Glienke 2002]

This example shows how bad it is that the Delphi compiler does not actually warn about assignment of differently sized ordinal types but instead silently truncates them. (FPC has a flag for that).

If it did chances are very high you would have found it immediately.

Edited May 8, 2019 by Stefan Glienke

[RonaldK 18]

There is another nice "Enterprise feature" in the Linux compiler (still open):

 

Linux x64 compiler produce very bloated code.

https://quality.embarcadero.com/browse/RSP-17724

Edited May 8, 2019 by RonaldK

[Arnaud Bouchez 407]

18 hours ago, RonaldK said:

Linux x64 compiler produce very bloated code.

https://quality.embarcadero.com/browse/RSP-17724

I like very much those generated lines:
0000000000456FDF 8944243C         mov    DWORD PTR [rsp+0x3c],eax
0000000000456FE3 EB00             jmp    0x456fe5 <Project1.initialization()+85>
0000000000456FE5 8B44243C         mov    eax,DWORD PTR [rsp+0x3c]
... which just do nothing: it jumps to the next opcode, and use an unneeded temporary storage... 🙂

Also check https://web.archive.org/web/20170417182109/https://plus.google.com/103246155735524926641/posts/SbLxpp2DipK
 

The problem is not LLVM, which is able to generate very good assembly, but how LLVM is used as backend from the Delphi compiler.
LLVM is a very complex beast, so I don't blame Embarcadero developpers (how many are working on the compiler?), just know how difficult it should be to maintain this path.

 

I am rather pleased with FPC floating point abilities on Linux x86_64.
It is less optimized than gcc or llvm for sure when using their aggressive settings, but at least FPC generated assembly is clean and efficient. I usually spend hours in the generated assembly to validate algorithms coded in pascal. SSE2 registers allocation and inlining are not bad with FPC, and it is easy to reach good performance on all Operating Systems, once the code is good on a given processor. 

Edited May 9, 2019 by Arnaud Bouchez

[nozz 1]

I would bet most Delphi users hold a license for the Professional edition so I kinda understand why they would gate Linux support. It's a good short term business decision but it also means less bugs will be reported and it will take longer for the platform to mature.

[RonaldK 18]

47 minutes ago, nozz said:

I would bet most Delphi users hold a license for the Professional edition so I kinda understand why they would gate Linux support. It's a good short term business decision but it also means less bugs will be reported and it will take longer for the platform to mature.

One reason could have been the new RAD server. 

[Markus Kinzler 174]

Or the hope more developers would migrate to the more expensive editions.

[dummzeuch 1505]

1 hour ago, Markus Kinzler said:

Or the hope more developers would migrate to the more expensive editions.

With the price for Professional rising the way it does, it feels like I'm on enterprise already. I was pleasantly surprised I got the mobile add-on without paying an arm and a leg though.

[Attila Kovacs 629]

1 hour ago, dummzeuch said:

I was pleasantly surprised I got the mobile add-on without paying an arm and a leg though.

Tell them who:

a.) bought Konopka pack and it was included in the next release

b.) bought mobil add-on and was included in the next release

c.) bought firedac and was included in the next release

 

Imagine those surprised faces.

[Uwe Raabe 2057]

@Attila Kovacs Lucky guy! All those things you rate valuable to pay for you now get for free. Much better than getting some gimmick for free that you never asked for and probably has no value for your either.

[David Schwartz 426]

We've got Delphi Enterprise Edition, and I can't seem to get Linux support to work. All the other platforms work, just not Linux. (We don't use anything other than Windows right now, but I was looking at building a Linux demo of some code that's currently running on a Windows server. Can't get Linux support to work.)

[Sherlock 663]

9 hours ago, David Schwartz said:

Can't get Linux support to work.

What seems to be the problem? 

    ...perhaps in a new thread though.

[Guest]

19 hours ago, Attila Kovacs said:

firedac and was included in the next release

Not with sources though? Is FireDAC sources included in Rio Professional?

[Guest]

Just now, Dany Marmur said:

Not with sources though? Is FireDAC sources included in Rio Professional?

Sorry, wrote too fast. I can find that out for myself. Apologies.