How to Distinguish Between Different Operating System Distros in Node.Js

How to distinguish between different operating system distros in node.js?

To summarize all the responses: There is no easy way to determine the current Linux distribution.

However here are a few thing you could start with.

• uname -v usually gives you a long string with some informations. (E.g.: #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013)
• Debian /etc/debian_version, but this is set in Ubuntu, too!
• Ubuntu: /etc/lsb-release and /etc/os-release
• SuSe: /etc/SuSE-release
• Many distros also write to /etc/issue

If you have a list of possible distributions that could happen, you should be able to get that information somehow. If you want a generic approach I'll guess there will be no absolute answer.

Distinguish between different linux distros in nodejs

Getting the active desktop environment/window manager is not a node-specific problem. There are different approaches (some better than others) that include using pgrep to check running process names against known DE/WM binary names and using other tools such as HardInfo or wmctrl.

How do I determine the current operating system with Node.js

The variable to use would be process.platform

On Mac the variable is set to darwin. On Windows, it is set to win32 (even on 64 bit).

Current possible values are:

• aix
• darwin
• freebsd
• linux
• openbsd
• sunos
• win32
• android (Experimental, according to the link)

I just set this at the top of my jakeFile:

var isWin = process.platform === "win32";

Node.js development, windows or linux?

We have a system via which we just use a config file, which handles all our problems like path differences ("c:\blarg" vs "~user/blarg") and, as a bonus, lets us control differences between debug and production environments.

Node.js is cross platform, so we totally have developers working on all sorts of computers, and it's no problem at all.

This is an example config file I use on a file storage project:

/**
 * All of these are mandatory except for log_level (which defaults to "info", 1) 
 * and log_echo_to_console (which defaults to false)
 */
exports.config = {
    log_level: 0,
    log_file: "/path/to/send.log",
    request_log_file: "/path/to/send_requests.log",
    log_echo_to_console: true,
    port_number: 8088,
    no_notification_emails: true,
    image_url_base: "http://s3.amazonaws.com/",      // MAKE SURE THIS ENDS IN "/"
    tmp_file_folder:"/tmp/",
    s3_info: {
        key: 'xxxxxx',
        secret: 'yyyyy',
        file_bucket: 'sendtransfer/',
    },
    backend_info: {
        db_info: {
            server: "localhost",
            user: "db_user",
            password: "secret",
            database: "SendRemote",
            pooled_connections: 125,
            idle_timeout_millis: 30000
        },
        memcache_info: {
            host: "127.0.0.1",
            port: "31111",
            pooled_connections: 200,
            timeout: 20000
        }
    },

    debug_server: true
};

For Windows machines, just change the paths. It's all good!

Then in code, you can just type:

var local = require('local.config.js');
fs.writeFile(local.config.log_file);
// etc

Embrace multiculturalism!!!

What are the functional differences between NW.js, Brackets-Shell and Electron?

I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.

Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.

https://github.com/adobe/brackets-shell#overview

Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.

I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.

These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.

The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.

Number of threads Workers in NodeJS will spawn

So will the below code spawn 50 threads?

....

for (let i = 0; i < 50; i++) {
  run().catch(error => console.log(error));
}

Yes.

How is it distributed over the cpu cores?

The OS will handle this.

Depending on the OS, there is a feature called processor affinity that allow you to manually set the "affinity" or preference a task has for a CPU core. On many OSes this is just a hint and the OS will override your preference if it needs to. Some real-time OSes treat this as mandatory allowing you more control over the hardware (when writing algorithms for self-driving cars or factory robots you sometimes don't want the OS to take control of your carefully crafted software at random times).

Some OSes like Linux allow you to set processor affinity with command line commands so you can easily write a shell script or use child_process to fine-tune your threads. At the moment there is no built-in way to manage processor affinity for worker threads. There is a third party module that I'm aware of that does this on Windows and Linux: nodeaffinity but it doesn't work on Max OSX (and other OSes like BSD, Solaris/Illumos etc.).

---

Related Topics