When is Something Built from Source
-
@Danp said in XenOrchestra XOSAN...a pic is worth 1000 words:
@scottalanmiller said in XenOrchestra XOSAN...a pic is worth 1000 words:
I guess, but anyone following it would notice that you never "build from source", it's just a normal install.
Can you provide an example of what you consider to be truly built from source?
The term refers to things that are compiled.
https://www.howtogeek.com/105413/how-to-compile-and-install-from-source-on-ubuntu/
There is a standard "build from source" procedure that is common to system admin interviews.... ...the same procedure of tarball, extract, configure, compile/make and clean is basically always what you do. Your source might not be compressed, you might not have to configure anything, but the general steps never change. "Building" is a reference to compilation. You would never say that you "built" Civilization V when you install it, right? You don't say that you "built" any script that you run, right? That would be misleading, it implies a level of work that is not happening.
Building from source is a standard industry term for a standard industry procedure. RPMs and DEB files, for example, are "pre-built" as we say, meaning that no compilation is necessary.
The idea is that before you "build" the application, it is source, and afterwards it is ready to run. But XO is ready to run when you download it, there is no building steps. It's source, yes, but it runs from source like most things do. Only compiled software doesn't run directly from the source. So you can never use the term "build" when discussing something in a scripting language.
-
Pretty much all normal applications on UNIX systems can be "built from source", but almost never are. It's considered bad form in a production environment to do your own compilation except in extreme cases. RPMs and DEBs are better controlled and more repeatable.
But some platforms, like Gentoo and FreeBSD provide for simple procedures to build all of their compiled components from source. It takes forever because compilation is a major operation, especially when compiling things like the kernel.
There are literally tens of thousands of standard examples on any system. Everything on Linux or BSD that is not a script is "built from source" by somebody (normally somebody else.) Same on Windows, anything that ends in .exe was built from source, but is no longer that source.
https://mariadb.com/kb/en/mariadb/compiling-mariadb-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.
