When is Something Built from Source
-
And wikipedia has the same definition for "software build": In the field of software development, the term build is similar to that of any other field. That is, the construction of something that has an observable and tangible result. Historically, build has often referred either to the process of converting source code files into standalone software artifact(s) that can be run on a computer, or the result of doing so
-
@scottalanmiller So then why do we call these if the source is ready to run as-is and we aren't building anything?
sudo npm install sudo npm run build -
This definition is extremely important for many reasons. One is simply that everything in IT is about terminology and semantics and getting these accurate is critical to conveying information properly. Because "build from source" is often forbidden in large companies and is considered to be a bad practice generally in production, the use of the term conveys something dramatic. It also implies that a compiler is needed (many companies forbid installation of compilers at all) and a lack of repeatability which causes concern. So system admins are trained, and have been for a very long time, to see building from source as a very, very negative thing in a production environment and something that is important to know, but is generally only done with any regularity by hobbyists.
But with interpreted software, something that we use for nearly all enterprise software today (certainly not all, but it is the dominant means of writing this type of software - it's where all of the hot development has been for years) we use source for the running system, there is no "build" and the source itself is the final artefact of the development process. So using source for things like WordPress, Drupal, XenOrchestra, Spiceworks, ERPNext, Rocket.Chat, NodeBB, or anything that runs on LAMP, anything in Ruby or Python, utilities written in Perl or any BASH script - is the only thing that there is. So simply copying a script from one place to another is "installation" potentially. That's not building, in any way. But applying that term to it makes it sound inappropriate and scary.
-
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller So then why do we call these if the source is ready to run as-is and we aren't building anything?
sudo npm install sudo npm run buildInstalling is unrelated to building. You install WordPress, but you don't say that you built it. You install RPMs, which are literally the exact opposite of building. So that term implies nothing like building.
The NPM build command is an unfortunate naming convention, but NPM is a package manager like RPM (but for NodeJS instead of for Linux) and is, again, the polar opposite of the term "build". There is no compilation step, it's just going through a dependency list and downloading what is needed, same as RPM does or apt-get.
Ask it in the opposite way, if you consider XO as "building" can you name any installation of anything, ever, that is not? Because if "downloading a prebuilt system" is building to you, then we "Build XOA" as well.
-
Here is an example that might help.... you are in a job interview for a system admin role and they ask you the very standard question of "have you built software from source" and "can you take us through the steps of doing so"....
Would you feel confident claiming to know how to build from source based solely on having used XO and would you use NPM Build as an example?
I can tell you, that any interviewer would not consider that a passing answer. And giving that as an answer I would expect to end the interview. Maybe not, but it would not go over well. At best you'd hope that they would think that you were just joking.
-
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
The NPM build command is an unfortunate naming convention, but NPM is a package manager like RPM (but for NodeJS instead of for Linux) and is, again, the polar opposite of the term "build". There is no compilation step, it's just going through a dependency list and downloading what is needed, same as RPM does or apt-get.
If this is accurate, then I should be able to make a change to the XO source and then restart xo-server to see the changes without rerunning the above commands.
IIRC, it doesn't work like this. I'll have to test it again in a bit.
-
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
The NPM build command is an unfortunate naming convention, but NPM is a package manager like RPM (but for NodeJS instead of for Linux) and is, again, the polar opposite of the term "build". There is no compilation step, it's just going through a dependency list and downloading what is needed, same as RPM does or apt-get.
If this is accurate, then I should be able to make a change to the XO source and then restart xo-server to see the changes without rerunning the above commands.
It definitely works like that without any doubt. It's NodeJS and has no other way to run. There is no exception to this with Node software - except the ones where you don't even need to bother restarting!
-
It's possible that you made a change to a copy of the code that is not the running copy. NPM can easily copy files to different places. But NodeJS, by definition, is running code. There is no grey area there, it is simply what it is. It is not compiled and currently no one makes a compiler for it (in theory someone could, but that would be for JavaScript, not for NodeJS, NodeJS is a reference to the interpreter itself so can never be compiled.)
NodeJS runs on the Google V8 JS engine interpreter. So if you consider XO to be "built from source" then, by obvious extension, it would mean that going to any website that uses JavaScript would be "building from source" simply by navigating to the page.
-
Getting closer.
-
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
IIRC, it doesn't work like this. I'll have to test it again in a bit.
What code changes were you making previously?
-
@scottalanmiller We have to pull down all changes from github, and then have NPM rerun the code.
-
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
What code changes were you making previously?
Here's one example where this could occur.
-
@DustinB3403 said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller We have to pull down all changes from github, and then have NPM rerun the code.
NPM puts things where they go, it's copying things and checking dependencies. Git does not necessarily pull down and overwrite the running files. If that is what he means, that explains the confusion. If you were to modify the actual source files being used, it would change instantly - there is no possibility of it not changing.
-
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
What code changes were you making previously?
Here's one example where this could occur.
What do you mean? If you change the code and restart, it will always be modified in the running system. Always. Your example here doesn't state anything contrary to that.
Did you actually add that functionality and not have it work?
-
Remember, the source code is the running code. It's literally impossible for it to be changed and have the changes not be reflected once the system restarts. There is no way around this. It's the actual program being modified.
-
I'm not sure where the disconnect is. Is it that interpreted languages are not understood? Or that JavaScript is believed to be a compiled language? I'm not sure how to explain this more clearly because it isn't something that needs to be tested, this is basic computing. When the code is changed, it's changed. There is no original file to be run, so the interpreter knows nothing about "how it used to be."
-
There could, of course, be a cache mechanism that would hold the old file in memory for some time, but NodeJS does not do this. And no interpreter does that I know of. Because it reloads from from disk each time and runs a unique process for every script it would need to store the memory dump to disk somewhere to persist through a restart and would have to know to pick it up. It would be a dangerous cache mechanism to use, possible, but no one does it. Not even systems like Java. It's definitely not existing here. But even if it were, it would not change the underlying principles, it would only be that a cache had not flushed yet.
-
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
What code changes were you making previously?
Here's one example where this could occur.
What do you mean? If you change the code and restart, it will always be modified in the running system. Always. Your example here doesn't state anything contrary to that.
Did you actually add that functionality and not have it work?
We added the functionality to XO and it does work. https://github.com/Jarli01/xenorchestra_updater/commit/a3d8f60cff8cbfc3bc4c1a09346f2d786c759052
-
Another example of actual building, was the old PBX in a Flash process. Their process was install CentOS 5 and then run their script which would download and build Asterisk from the source code.
-
@JaredBusch said in XenOrchestra XOSAN...a pic is worth 1000 words:
Another example of actual building, was the old PBX in a Flash process. Their process was install CentOS 5 and then run their script which would download and build Asterisk from the source code.
Oh yeah, great example as Asterisk is, or was until a few years ago, often built that way and even moreso the DAHDI drivers for it, even when you were on Elastix 2.4 you had to rebuild the DAHDI drivers after any kernel update!
