DOOM Gaming on LINUX

[xX_Lol6_Xx]

Little fun fact: If you plan to use only windows exes with wine, you can actually create batch files and launch them via wine. I've done it before in Ubuntu

Spoiler

Now, I strongly recommend you either install the source ports for your distribution or compile them from source to avoid any bugs

 

[act]

Well first of all, in order to play Doom on Linux, you have one of two options.

A) You run the Source Port through WINE. Wine stands for "Wine Is Not an Emulator", because it's a program that - rather then running a little mini version of Windows like an emulator - translates the "language" that Windows Programs/Executable/Binaries (Binaries being 0's and 1's, compiled code that is very easy to run.) use into something that the Linux Operating System can read.

B) You compile a Source Port yourself. By nature, all Source Ports have publicly available Source Code for you to use. Most of them come with instructions on what Libraries (Those being different pre-made blocks of code that simplify complicated things like displaying an image on your computer) must be installed. Then, you use one of many types of Build Tools (Binaries that instruct the Compiler, the binary that turns the code into another binary) such as Make, CMake, etc. to create the Source Port's binary.

As for editing tools, I use Slade 3 and Ultimate Doom Builder simply ran through WINE. It takes a bit of setup, but is well documented.

For a tutorial on how to compile a Source Port on Linux, I made a video on how to compile Crispy Doom:

https://www.youtube.com/watch?v=C-UPHGaHX8o

[xX_Lol6_Xx]

43 minutes ago, act said:

By nature, all Source Ports have publicly available Source Code for you to use.

I am absolutely sorry for being that guy, but there are a few exceptions. ZDaemon (A multiplayer port based on ZDoom) for example is closed source, meaning that you'd have to play with Wine. Doom95 (No idea why you would use this, but whatever) is closed source too.

[act]

10 minutes ago, Lol 6 said:

I am absolutely sorry for being that guy, but there are a few exceptions. ZDaemon (A multiplayer port based on ZDoom) for example is closed source, meaning that you'd have to play with Wine. Doom95 (No idea why you would use this, but whatever) is closed source too.

Thanks for the correction.

Hey wait, isn't ZDaemon using code from something released under the GNU GPL? How does it get away with being Closet

[Edward850]

5 minutes ago, act said:

Hey wait, isn't ZDaemon using code from something released under the GNU GPL? How does it get away with being Closet

They are using the original Doom non commercial license ZDoom used to be distributed under. Nobody can (or rather has cared to) actually prove they've used any GPL code in the process.

[CBM]

7 hours ago, smeghammer said:

 

ACS script, not ZScript, but yes.

 

In PK3 land, the compiled acs scripts live in the /acs namespace.

 

Take a look at https://github.com/smeghammer/departure and look in the /src/acs directory. Here you will see four files:

- myscripts.acs (plain text source file),

- myscripts.o (compiled bytecode file),

- myscripts.bat - a windows batch file that accepts drag and drop filename

- the 'myscripts' dummy file (this just allows me to be lazy and drag and drop  this file as a name placeholder onto the batch file rather than edit a script every time).

 

I have a similar .sh file on my Ubuntu machine. 

 

As you probably know, the compiled PK3 is just the directory structure zipped up and given a.pk3 extension. You'll find that in the /compiled directory.

 

 

the code looks very similar to the code I would write from inside ultimate doom builder for a specific map...

how is the relation between the code for a specific map and code that lives outside the maps like this?

and how does it relate to zscript and decorate that only lives outside a map?

 

yes a pk3 file is just the directory structure zipped and renamed to pk3.

I've been learning about what directories that can be used in a pk3 and what each of them can contain and what their names must be.

 

@act

hehe, I love all those recursive abbrevations that lives in Linux like WINE, GNU etc...

 

@Lol 6

well, there are some who say that for example slade works better with wine than using the native version.

But in an introduction phase, wouldnt it make sense to avoid having to compile stuff?

[Gibbon]

7 hours ago, act said:

Well first of all, in order to play Doom on Linux, you have one of two options.

A) You run the Source Port through WINE. Wine stands for "Wine Is Not an Emulator", because it's a program that - rather then running a little mini version of Windows like an emulator - translates the "language" that Windows Programs/Executable/Binaries (Binaries being 0's and 1's, compiled code that is very easy to run.) use into something that the Linux Operating System can read.

B) You compile a Source Port yourself. By nature, all Source Ports have publicly available Source Code for you to use. Most of them come with instructions on what Libraries (Those being different pre-made blocks of code that simplify complicated things like displaying an image on your computer) must be installed. Then, you use one of many types of Build Tools (Binaries that instruct the Compiler, the binary that turns the code into another binary) such as Make, CMake, etc. to create the Source Port's binary.

As for editing tools, I use Slade 3 and Ultimate Doom Builder simply ran through WINE. It takes a bit of setup, but is well documented.

For a tutorial on how to compile a Source Port on Linux, I made a video on how to compile Crispy Doom:

https://www.youtube.com/watch?v=C-UPHGaHX8o

Or... ;)

 

 

[ducon]

17 hours ago, CBM said:

that would be interesting and it would also be nice to see what solution you went with for each game

 

OK, let’s go.

Games installed with an installer are prefixed by a @.

 

For Doom, all these WADS are OK:

blasphemer.wad  doom2i.wad  doom.wad    freedoom1.wad  heretic.wad  hexen.wad     remood.wad   tnt.wad
doom1.wad       doom2.wad   freedm.wad  freedoom2.wad  hexdd.wad    plutonia.wad  strife1.wad  voices.wad

Which ports? A lot: ZDoom, prboom+, GZDoom, LZDoom, QZDoom, crispy-doom, chocolate-doom…

Then, for Quake:

aop  id1  malice  hipnotic  rogue (with darkplaces or other ports like tenebrae)

For Quake 2:

baseq2  rogue  xatrix (a few ports)

For other id games:

@ Quake 3, @ RtCW (with @ ET), @ Doom³ (with @ RoE but now the installers are unuseful), @ Quake 4 (and @ ET:QW), @ Prey, Heretic, Hexen, Hexen 2, @ Heretic 2’s demo…

Build games:

duke3d, Shadow warrior

Unreal series:

@ Unreal (with @ NaPali), @ UT 99, @ UT 2003, @ UT2004

Other games:

Serious Sam @ TFE, @ TSE, @ 2 (buggy sometimes), Penumbra (@ overture, @ black plague and @ requiem), Alephone, Arx fatalis (with Arx libertatis), @ Braid, @ World of Goo, Descent 1 and 2

Edited November 3, 2021 by ducon

[Lemonzest]

I use wine for everything even dooms with native ports as I like everything organised under one thing, so Doom ports (Odamex/Zdaemon/GZDoom) are in one prefix with Doom Explorer and Doom Runner, then I have other prefixes for Quakes/Unreal/Steam etc. Here's a pic of Ultimate Doom Builder running on wine.

 

 

[Martin Howe]

I moved permanently to Linux when the issues with W10 became unsurmountable and support for 7 was dropped; did dual boot but got fed up with the clumsy and amateurish way Windows handles boot managing and so on; had enough of Windows polluting my computer. Fortunately, I'd dabbled with Linux before and had UNIX experience for over 30 years, so moving to Linux wasn't hard. Getting everything set up was; I have UDB built natively and running on WINE as the functionality of DB varies between them; game engines and tools, I just compile natively from source.

 

In sort, it's great to have total control over one's system, but it does mean extra work to get games and their editors running as so much of their environment are assumed to be Windows by the devs or have only patchy non-Windows support.

 

Once the chip shortage is over, I'll build a new computer and run W10 as a VM, with an extra (medium-power) GPU dedicated to that VM; I don't play AAA titles so even a low-profile 1050 should be enough.

 

[Gibbon]

10 minutes ago, Martin Howe said:

I moved permanently to Linux when the issues with W10 became unsurmountable and support for 7 was dropped; did dual boot but got fed up with the clumsy and amateurish way Windows handles boot managing and so on; had enough of Windows polluting my computer. Fortunately, I'd dabbled with Linux before and had UNIX experience for over 30 years, so moving to Linux wasn't hard. Getting everything set up was; I have UDB built natively and running on WINE as the functionality of DB varies between them; game engines and tools, I just compile natively from source.

 

In sort, it's great to have total control over one's system, but it does mean extra work to get games and their editors running as so much of their environment are assumed to be Windows by the devs or have only patchy non-Windows support.

 

Once the chip shortage is over, I'll build a new computer and run W10 as a VM, with an extra (medium-power) GPU dedicated to that VM; I don't play AAA titles so even a low-profile 1050 should be enough.

 

I'd love to liberate my SSD of Windows 10 (I'll never touch 11).  Though, being a source port dev, I need MSVC for my projects until I get a decent cross-compilation setup working.

 

I wouldn't call Windows' boot management amateurish, it is 'by design' ;)

[xX_Lol6_Xx]

7 hours ago, CBM said:

 

@Lol 6

well, there are some who say that for example slade works better with wine than using the native version.

But in an introduction phase, wouldnt it make sense to avoid having to compile stuff?

IDK for slade, I used the native version for a while and had no problems, but if you want to use it with Wine, go ahead

 

About avoiding compiling stuff,I'd say yes, if you don't have much experience. But once you get used to it, compiling stuff is not that hard

[MFG38]

20 hours ago, CBM said:

I tried to open UDMF maps

 

Yeah, Eureka sadly doesn't support the UDMF format as far as I know.

[CBM]

from what I've found out so far, pop os will be the best choice for me.

[Marisa the Magician]

I've been avoiding Windows like the plague for a couple years now since I made the move to Linux (insert obligatory "btw I use Arch" here). Honestly, I do feel like there are some limitations for me with modding because all I have is SLADE and it's not exactly the best tool for mapping, really would love to at least have some of the conveniences of UDB like 3d floor previews, models, dynamic lights... Without having to use UDB (mainly because I don't even know how to use it, but it's also a pain to set up). But on the other hand, there's also advantages. The fact that Linux is so programmer-oriented makes it piss easy to just write my own little command line tools for pretty much everything, and shell scripting is a godsend, too.

 

Suffice to say, I'm never touching Windows ever again. There's nothing it can offer to me, nothing it can seduce me with. I've got all my Dooming action natively over here (excluding the reboots, but those don't count).

[smeghammer]

12 hours ago, CBM said:

the code looks very similar to the code I would write from inside ultimate doom builder for a specific map...

 

haha yeah - that could be a bit of a limitation with .pk3s.

 

I have been converting one of my multi-map .wad files into a .pk3 (the whole namespacing thing makes much more sense to me than the flat lump structure inside a .wad) and of course moving the .acs into the /acs/ namespace of the .pk3  hierarchy. Sometimes, I will have a script on e.g. MAP01 that is script and triggered by a line action, and on MAP02, I'll have another script, also with a reference to script 1.

 

I had to add a bunch of map number conditionals and combine into a single 'script 1' code into if(mapnum==x){} blocks. It works OK but is a bit of a faff...

 

You can of course also have compiled ACS as BEHAVIOR lumps inside your individual .wad files in the /maps/ namespace, and they will be specific to that map. 

 

I don't really know which option is more efficient though.

 

You'll need the ACC compiler anyway, but if you compile in isolation from a WAD file, you will get a [scriptname].o file (rather than a BEHAVIOR lump) - which is the bytecode that will actually be executed in the /maps/ directory. As the wiki says, the /acs/ namespace is for mapnum agnostic libraries really.

 

https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

https://zdoom.org/wiki/Scope

 

[smeghammer]

4 hours ago, MFG38 said:

Yeah, Eureka sadly doesn't support the UDMF format as far as I know

 

It's coming...

 

See top todo item here: https://github.com/ioan-chera/eureka-editor/projects/2

[CBM]

3 minutes ago, smeghammer said:

 

It's coming...

 

See top todo item here: https://github.com/ioan-chera/eureka-editor/projects/2

nice!

15 minutes ago, smeghammer said:

 

haha yeah - that could be a bit of a limitation with .pk3s.

 

I have been converting one of my multi-map .wad files into a .pk3 (the whole namespacing thing makes much more sense to me than the flat lump structure inside a .wad) and of course moving the .acs into the /acs/ namespace of the .pk3  hierarchy. Sometimes, I will have a script on e.g. MAP01 that is script and triggered by a line action, and on MAP02, I'll have another script, also with a reference to script 1.

 

I had to add a bunch of map number conditionals and combine into a single 'script 1' code into if(mapnum==x){} blocks. It works OK but is a bit of a faff...

 

You can of course also have compiled ACS as BEHAVIOR lumps inside your individual .wad files in the /maps/ namespace, and they will be specific to that map. 

 

I don't really know which option is more efficient though.

 

You'll need the ACC compiler anyway, but if you compile in isolation from a WAD file, you will get a [scriptname].o file (rather than a BEHAVIOR lump) - which is the bytecode that will actually be executed in the /maps/ directory. As the wiki says, the /acs/ namespace is for mapnum agnostic libraries really.

 

https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

https://zdoom.org/wiki/Scope

 

I just dont quite yet understand when and how its limited to a single map and when its not

[smeghammer]

1 hour ago, CBM said:

nice!

I just dont quite yet understand when and how its limited to a single map and when its not

 

I *think* (i've not actually tested yet...) that it is like this:

 

If you have a BEHAVIOR lump in MAP01 that is compiled from: 

script 1 (void){
   print(s:"script for MAP01");
}

 

and in MAP02:

script 1 (void){
   print(s:"script for MAP02");
}

 

and you have a linedef cross action of type 80 with (1,0,0,0,0) on each map (see https://zdoom.org/wiki/ACS_Execute), on crossing in map01, you will see "script for map01" printed, and if you cross the line in map02, you will see "script for map02" printed. However, if you have a compiled script in the /acs/ namespace of 

script 2 (void){
    print(s:"which map am I?");
}

and a linedef action 80 set on MAP01 and MAP02 of  (2,0,0,0,0), you will get "which map am I?" printed in both cases. The scope of the script function 2, in the /acs/ namespace is world (I think) NOT map. 

 

** this holds true even if the maps are separate .wad files inside the /maps/ namespace of a .pk3 archive **

 

 

 

It's quite easy to resolve though:

 

world int 1:CURRENTLEVEL;

...
  /* set CURRENTLEVEL */
script 100 ENTER{
	CURRENTLEVEL = GetLevelInfo(LEVELINFO_LEVELNUM);
    ...
}

script 2 (int target,int source){
    log(s:"triggering script 2");
    /* loop while still alive */
    if(CURRENTLEVEL == 17){
        While(ThingCount(T_BARON, 101) > 0)
            Delay(35);
        log(s:"All barons killed! Time to go...");
        //now separate the exit teleporters:
        changeSectorHeight(1,4,32,SECTOR_MVFLOORANDCEILING);
    }
    
    if(CURRENTLEVEL == 18){
        /*
        Triggered by walking over a linedef at the top of the pyramids. Each linedef cross passes an argument 0 to 11 (depending on which
        pyramid) and this is then used as the index of the randomized target array 'randomIndexAssigned' set up in the ENTER script
        */
        log(s:"TELEPORTING OUT: script 2: plat to lower:");
        log(i:source);
        _currentPlatformToLower = source;    //now we can use this on clicking the buttons!
        Teleport(0,randomIndexAssigned[target],0);
    }
}

I had two scripts (in BEHAVIOR lumps) with the same number in my .wad file (the one I am breaking up into a .pk3), each triggered by crossing a line somewhere, but with completely different code. I just looked for the number of the current level and combined the different codeblocks, and separated them logically by level number.

 

I could of course have made different scripts with different numbers, but then I'd need to find all the linedefs that trigger, and make sure they were all updated properly. It seemed safer to code it like this...

 

 

 

Edited November 3, 2021 by smeghammer

[Catoptromancy]

Slade has great support for UDMF, at least the stuff I have tried. I wish UDB didnt require a such high GL version. Just basic 3d mode visuals in software would be fine for me. Lots of extra tools I wish I could use. If it could be compiled with 3d mode disabled, I wouldnt mind if it avoids the GL requirement. I managed to get UDB compiled, but my graphics card doesnt support the gl version. Whatever slade uses for graphics is fine. 

[CBM]

13 hours ago, smeghammer said:

 

I *think* (i've not actually tested yet...) that it is like this:

 

If you have a BEHAVIOR lump in MAP01 that is compiled from: 

script 1 (void){
   print(s:"script for MAP01");
}

 

and in MAP02:

script 1 (void){
   print(s:"script for MAP02");
}

 

and you have a linedef cross action of type 80 with (1,0,0,0,0) on each map (see https://zdoom.org/wiki/ACS_Execute), on crossing in map01, you will see "script for map01" printed, and if you cross the line in map02, you will see "script for map02" printed. However, if you have a compiled script in the /acs/ namespace of 

script 2 (void){
    print(s:"which map am I?");
}

and a linedef action 80 set on MAP01 and MAP02 of  (2,0,0,0,0), you will get "which map am I?" printed in both cases. The scope of the script function 2, in the /acs/ namespace is world (I think) NOT map. 

 

** this holds true even if the maps are separate .wad files inside the /maps/ namespace of a .pk3 archive **

 

 

 

It's quite easy to resolve though:

 

world int 1:CURRENTLEVEL;

...
  /* set CURRENTLEVEL */
script 100 ENTER{
	CURRENTLEVEL = GetLevelInfo(LEVELINFO_LEVELNUM);
    ...
}

script 2 (int target,int source){
    log(s:"triggering script 2");
    /* loop while still alive */
    if(CURRENTLEVEL == 17){
        While(ThingCount(T_BARON, 101) > 0)
            Delay(35);
        log(s:"All barons killed! Time to go...");
        //now separate the exit teleporters:
        changeSectorHeight(1,4,32,SECTOR_MVFLOORANDCEILING);
    }
    
    if(CURRENTLEVEL == 18){
        /*
        Triggered by walking over a linedef at the top of the pyramids. Each linedef cross passes an argument 0 to 11 (depending on which
        pyramid) and this is then used as the index of the randomized target array 'randomIndexAssigned' set up in the ENTER script
        */
        log(s:"TELEPORTING OUT: script 2: plat to lower:");
        log(i:source);
        _currentPlatformToLower = source;    //now we can use this on clicking the buttons!
        Teleport(0,randomIndexAssigned[target],0);
    }
}

I had two scripts (in BEHAVIOR lumps) with the same number in my .wad file (the one I am breaking up into a .pk3), each triggered by crossing a line somewhere, but with completely different code. I just looked for the number of the current level and combined the different codeblocks, and separated them logically by level number.

 

I could of course have made different scripts with different numbers, but then I'd need to find all the linedefs that trigger, and make sure they were all updated properly. It seemed safer to code it like this...

 

 

 

cool!

 

then this technique for passing a global variable between the scripts that live in seperate maps is not as needed then... 

 

I guess an ACS script in the pk3 could then have all the global stuff like when doing an RPG where stuff needs to be remembered between maps

as well as all the general functions one might want to use for doors, lifts etc

 

I assume a script specific to a map can also use stuff defined in an ACS script placed inside the pk3?

[CBM]

12 hours ago, Catoptromancy said:

Slade has great support for UDMF, at least the stuff I have tried. I wish UDB didnt require a such high GL version. Just basic 3d mode visuals in software would be fine for me. Lots of extra tools I wish I could use. If it could be compiled with 3d mode disabled, I wouldnt mind if it avoids the GL requirement. I managed to get UDB compiled, but my graphics card doesnt support the gl version. Whatever slade uses for graphics is fine. 

well slade is great for many things but the buildin map editor is..basic at best... still better than edmap was bit still no eureka or doombuilder

 

14 hours ago, smeghammer said:

 

I *think* (i've not actually tested yet...) that it is like this:

 

If you have a BEHAVIOR lump in MAP01 that is compiled from: 

script 1 (void){
   print(s:"script for MAP01");
}

 

and in MAP02:

script 1 (void){
   print(s:"script for MAP02");
}

 

and you have a linedef cross action of type 80 with (1,0,0,0,0) on each map (see https://zdoom.org/wiki/ACS_Execute), on crossing in map01, you will see "script for map01" printed, and if you cross the line in map02, you will see "script for map02" printed. However, if you have a compiled script in the /acs/ namespace of 

script 2 (void){
    print(s:"which map am I?");
}

and a linedef action 80 set on MAP01 and MAP02 of  (2,0,0,0,0), you will get "which map am I?" printed in both cases. The scope of the script function 2, in the /acs/ namespace is world (I think) NOT map. 

 

** this holds true even if the maps are separate .wad files inside the /maps/ namespace of a .pk3 archive **

 

 

 

It's quite easy to resolve though:

 

world int 1:CURRENTLEVEL;

...
  /* set CURRENTLEVEL */
script 100 ENTER{
	CURRENTLEVEL = GetLevelInfo(LEVELINFO_LEVELNUM);
    ...
}

script 2 (int target,int source){
    log(s:"triggering script 2");
    /* loop while still alive */
    if(CURRENTLEVEL == 17){
        While(ThingCount(T_BARON, 101) > 0)
            Delay(35);
        log(s:"All barons killed! Time to go...");
        //now separate the exit teleporters:
        changeSectorHeight(1,4,32,SECTOR_MVFLOORANDCEILING);
    }
    
    if(CURRENTLEVEL == 18){
        /*
        Triggered by walking over a linedef at the top of the pyramids. Each linedef cross passes an argument 0 to 11 (depending on which
        pyramid) and this is then used as the index of the randomized target array 'randomIndexAssigned' set up in the ENTER script
        */
        log(s:"TELEPORTING OUT: script 2: plat to lower:");
        log(i:source);
        _currentPlatformToLower = source;    //now we can use this on clicking the buttons!
        Teleport(0,randomIndexAssigned[target],0);
    }
}

 

 

I like the structure in pk3 as well vs wads

 

you should definetly test this and it baffles me that we dont have lots of usercreated acs libraries yet for all those generic map independent things like custom doors, lifts etc etc

 

 

[smeghammer]

https://youtu.be/OX-h9hyoGOA

2 hours ago, CBM said:

 

I guess an ACS script in the pk3 could then have all the global stuff like when doing an RPG where stuff needs to be remembered between maps

as well as all the general functions one might want to use for doors, lifts etc

 

I assume a script specific to a map can also use stuff defined in an ACS script placed inside the pk3?

 

I believe that is correct yes.

 

1 hour ago, CBM said:

you should definetly test this and it baffles me that we dont have lots of usercreated acs libraries yet for all those generic map independent things like custom doors, lifts etc etc

 

I will certainly test this.

I have a bunch of test maps I have made during the last 18 months or so as I have been learning all this shit and I agree that actually finding useful real-life code examples is quite difficult. The core documentation on the zdoom wiki is OK but could certainly do with more and better example code snippets. I have found more examples (with some careful Googling) on the zdoom forum. I do agree that a resource of categorised ACS code snippets would be really useful, as well as DECORATE and ZScript snippets. It's all about time though...

 

My code/map snippets repo can be found on my github site, along with my maps. I will add to this when I have made a little .pk3 to test the above. I'll also try to update my smeghammer website too. As and when I get time to do so...

[CBM]

5 hours ago, smeghammer said:

https://youtu.be/OX-h9hyoGOA

 

I believe that is correct yes.

 

 

I will certainly test this.

I have a bunch of test maps I have made during the last 18 months or so as I have been learning all this shit and I agree that actually finding useful real-life code examples is quite difficult. The core documentation on the zdoom wiki is OK but could certainly do with more and better example code snippets. I have found more examples (with some careful Googling) on the zdoom forum. I do agree that a resource of categorised ACS code snippets would be really useful, as well as DECORATE and ZScript snippets. It's all about time though...

 

My code/map snippets repo can be found on my github site, along with my maps. I will add to this when I have made a little .pk3 to test the above. I'll also try to update my smeghammer website too. As and when I get time to do so...

pretty cool! Thanks.

[act]

On 11/3/2021 at 3:04 AM, Gibbon said:

Or... ;)

 

 

I think it's very important for new Linux users to learn things like compiling and the like, because a lot of time, they won't have the option to get a package.

I'm fully willing to accept responsibility, if you need any help with compiling a source port, please reach out to me.

[Gibbon]

13 minutes ago, act said:

I think it's very important for new Linux users to learn things like compiling and the like, because a lot of time, they won't have the option to get a package.

I'm fully willing to accept responsibility, if you need any help with compiling a source port, please reach out to me.

Ooof you're taking a big risk there.  Sometimes users who have no knowledge of programming aren't the best ones to say "I will help you" to do it, because then you're on the hook for any newbie questions and believe me it's a time sink.

 

I also don't believe that just to use Linux you need to be able to compile.  Plenty of users especially to Ubuntu are coming from Windows and want something that works.  However it's good you've said it because now you're the 'compiler questioner'.

 

Sure I like helping people but there is a minimum amount of knowledge someone should have, such as knowing their system, knowing what dependencies they have, knowing how to invoke a compiler and knowing their libc version.

 

But go ahead, makes no difference to me in providing the binaries.

[CBM]

1 hour ago, Gibbon said:

Ooof you're taking a big risk there.  Sometimes users who have no knowledge of programming aren't the best ones to say "I will help you" to do it, because then you're on the hook for any newbie questions and believe me it's a time sink.

 

I also don't believe that just to use Linux you need to be able to compile.  Plenty of users especially to Ubuntu are coming from Windows and want something that works.  However it's good you've said it because now you're the 'compiler questioner'.

 

Sure I like helping people but there is a minimum amount of knowledge someone should have, such as knowing their system, knowing what dependencies they have, knowing how to invoke a compiler and knowing their libc version.

 

But go ahead, makes no difference to me in providing the binaries.

I have been working as a software programmer on and off since 2007

[Gibbon]

17 minutes ago, CBM said:

I have been working as a software programmer on and off since 2007

Sure, but that post / project isn't just for you.  That was my point.  You may not need help, but others' might.

[CBM]

8 minutes ago, Gibbon said:

Sure, but that post / project isn't just for you.  That was my point.  You may not need help, but others' might.

Ah yes ok.

That being said, I have never compiled anything on Linux, yet.

 

But I do think that Linux does need more people that are willing to help.

 

[Gibbon]

8 minutes ago, CBM said:

Ah yes ok.

That being said, I have never compiled anything on Linux, yet.

 

But I do think that Linux does need more people that are willing to help.

 

Indeed it does, the danger however is when compilation doesn't go to plan and you need to fix some code files or a few lines to make it work.  Compilation is indeed easy, but it doesn't always go that way.  I'm sure though that you'll steam through it.  With your background, you'll get the hang of it.