@@123gostly Short answer; no. While NixOS by default includes version control in the form of 'generations', it is far more limited than Git. Basically, each time you modify the NixOS configuration file and ask the system to apply the changes, it stores the changes (i.e. software versions, software configuration and even kernel version) as a 'generation' which you could pick from a menu at boot time. Long answer; not by default, but it is definitely more suited to being managed by Git! The main value of NixOS is that it's configuration format is a full-on programming language, and hence let's you control EVERYTHING about the system within 1 text file (or a collection of text files with full blown 'imports' between each other just like a program's source code). What software or kernel you're installing, if and which patches you're applying to software and hence needs re-compiling, what configuration options all the packages normally expose under /etc can ALL be controlled from the Nix configuration! Git is far more suited for tracking this as its similar to software source code and there are no binary formats which would likely be the case on a regular Linux FHS-compliant /etc directory. When it comes to servers specifically, NixOS even let's you create disk images based on an existing NixOS config, which could be useful in deploying a fleet of servers without needing to customize the server from a base image provided by a cloud provider like with Ansible. Not to mention, the reproducibility benefit of nixOS which means you don't need to worry about your configs breaking in the future. P.S. Some disambiguation - Nix refers both to the configuration language used to configure a nix-based system and the packaging manager. Nix can be used in two ways - nixpkgs which let's you set-up reproducible software environments on any Linux distro (think Python venv but on steroids and applying to every program you can run in a shell) but also, nixOS which is when you let the Nix package manager manage your entire system and have the Nix package repository as your distro. Both of the aforementioned methods are officially supported by the Nix team! P.P.S. - Since I'm plugging Nix super hard here, I need to offer some down-sides. 1. The learning curve for Nix (both the language and paradigm) is very high. Although there were recent efforts to help flatten the curve by creating some beginner-friendly documentation, don't get into it you're ready to treat it as learning a new programming language. 2. Proprietary (and sometimes niche FOSS ones even!) software tends to not play nice with the Nix package management paradigm. Due to the needing to provide reproducibility and the aforementioned 'generations' feature, Nix is capable of (and usually does) storing multiple versions of library and apps on a single system. Getting software that depends on libraries to run therefore, usually requires patching them, which could delay package updates for newer versions or break DRM measures for proprietary software (e.g. Discord's Krisp noise cancellation feature which is DRM-protected). 3. Nix can be hard to debug and troubleshoot due to lack of documentation and appropriate tools. This is as much a demographics problem and as it is a technical problem. So many changes occur between nixpkgs/nixOS versions that if anything breaks, it is hard to tell which package (if it at all you were able to decipher the crazy syntax and error messages) was the culprit. Due to (afaict) the small user base and non-mainstream nature of Nix, up-to-date documentation is hard to come by, you often have to read the upstream packaging Nix to understand what the issue was. 4. Integration of software configuration options depend on the community. Despite one of the major selling-points of NixOS being the ability to control the configuration of all software from within Nix files, these integrations are written upstream by individual packagers. And well, packagers are people like you and me, who may not share the same needs for configuring the software as you and or can decide to leave, abandoning the package. When that happens, you often need to figure out how to write your own integrations, or just give up and configure the software manually.
@123ghostly Short answer; no. While NixOS by default includes version control in the form of 'generations', it is far more limited than Git. Basically, each time you modify the NixOS configuration file and ask the system to apply the changes, it stores the changes (i.e. software versions, software configuration and even kernel version) as a 'generation' which you could pick from a menu at boot time. Long answer; not by default, but it is definitely more suited to being managed by Git! The main value of NixOS is that it's configuration format is a full-on programming language, and hence let's you control EVERYTHING about the system within 1 text file (or a collection of text files with full blown 'imports' between each other just like a program's source code). What software or kernel you're installing, if and which patches you're applying to software and hence needs re-compiling, what configuration options all the packages normally expose under /etc can ALL be controlled from the Nix configuration! Git is far more suited for tracking this as its similar to software source code and there are no binary formats which would likely be the case on a regular Linux FHS-compliant /etc directory. When it comes to servers specifically, NixOS even let's you create disk images based on an existing NixOS config, which could be useful in deploying a fleet of servers without needing to customize the server from a base image provided by a cloud provider like with Ansible. Not to mention, the reproducibility benefit of nixOS which means you don't need to worry about your configs breaking in the future. P.S. Some disambiguation - Nix refers both to the configuration language used to configure a nix-based system and the packaging manager. Nix can be used in two ways - nixpkgs which let's you set-up reproducible software environments on any Linux distro (think Python venv but on steroids and applying to every program you can run in a shell) but also, nixOS which is when you let the Nix package manager manage your entire system and have the Nix package repository as your distro. Both of the aforementioned methods are officially supported by the Nix team! P.P.S. - Since I'm plugging Nix super hard here, I need to offer some down-sides. 1. The learning curve for Nix (both the language and paradigm) is very high. Although there were recent efforts to help flatten the curve by creating some beginner-friendly documentation, don't get into it you're ready to treat it as learning a new programming language. 2. Proprietary (and sometimes niche FOSS ones even!) software tends to not play nice with the Nix package management paradigm. Due to the needing to provide reproducibility and the aforementioned 'generations' feature, Nix is capable of (and usually does) storing multiple versions of library and apps on a single system. Getting software that depends on libraries to run therefore, usually requires patching them, which could delay package updates for newer versions or break DRM measures for proprietary software (e.g. Discord's Krisp noise cancellation feature which is DRM-protected). 3. Nix can be hard to debug and troubleshoot due to lack of documentation and appropriate tools. This is as much a demographics problem and as it is a technical problem. So many changes occur between nixpkgs/nixOS versions that if anything breaks, it is hard to tell which package (if it at all you were able to decipher the crazy syntax and error messages) was the culprit. Due to (afaict) the small user base and non-mainstream nature of Nix, up-to-date documentation is hard to come by, you often have to read the upstream packaging Nix to understand what the issue was. 4. Integration of software configuration options depend on the community. Despite one of the major selling-points of NixOS being the ability to control the configuration of all software from within Nix files, these integrations are written upstream by individual packagers. And well, packagers are people like you and me, who may not share the same needs for configuring the software as you and or can decide to leave, abandoning the package. When that happens, you often need to figure out how to write your own integrations, or just give up and configure the software manually.
![Gucci Mane & Sexyy Red - You Don't Love Me [Official Music Video]](http://i.ytimg.com/vi/j7IBqyFKT4c/mqdefault.jpg)
I use NixOS, btw
nixOS has joined the chat
Great!
Does nixOS do something like this automatically?
@@123gostly Short answer; no. While NixOS by default includes version control in the form of 'generations', it is far more limited than Git. Basically, each time you modify the NixOS configuration file and ask the system to apply the changes, it stores the changes (i.e. software versions, software configuration and even kernel version) as a 'generation' which you could pick from a menu at boot time.
Long answer; not by default, but it is definitely more suited to being managed by Git! The main value of NixOS is that it's configuration format is a full-on programming language, and hence let's you control EVERYTHING about the system within 1 text file (or a collection of text files with full blown 'imports' between each other just like a program's source code). What software or kernel you're installing, if and which patches you're applying to software and hence needs re-compiling, what configuration options all the packages normally expose under /etc can ALL be controlled from the Nix configuration! Git is far more suited for tracking this as its similar to software source code and there are no binary formats which would likely be the case on a regular Linux FHS-compliant /etc directory.
When it comes to servers specifically, NixOS even let's you create disk images based on an existing NixOS config, which could be useful in deploying a fleet of servers without needing to customize the server from a base image provided by a cloud provider like with Ansible. Not to mention, the reproducibility benefit of nixOS which means you don't need to worry about your configs breaking in the future.
P.S. Some disambiguation - Nix refers both to the configuration language used to configure a nix-based system and the packaging manager. Nix can be used in two ways - nixpkgs which let's you set-up reproducible software environments on any Linux distro (think Python venv but on steroids and applying to every program you can run in a shell) but also, nixOS which is when you let the Nix package manager manage your entire system and have the Nix package repository as your distro. Both of the aforementioned methods are officially supported by the Nix team!
P.P.S. - Since I'm plugging Nix super hard here, I need to offer some down-sides.
1. The learning curve for Nix (both the language and paradigm) is very high. Although there were recent efforts to help flatten the curve by creating some beginner-friendly documentation, don't get into it you're ready to treat it as learning a new programming language.
2. Proprietary (and sometimes niche FOSS ones even!) software tends to not play nice with the Nix package management paradigm. Due to the needing to provide reproducibility and the aforementioned 'generations' feature, Nix is capable of (and usually does) storing multiple versions of library and apps on a single system. Getting software that depends on libraries to run therefore, usually requires patching them, which could delay package updates for newer versions or break DRM measures for proprietary software (e.g. Discord's Krisp noise cancellation feature which is DRM-protected).
3. Nix can be hard to debug and troubleshoot due to lack of documentation and appropriate tools. This is as much a demographics problem and as it is a technical problem. So many changes occur between nixpkgs/nixOS versions that if anything breaks, it is hard to tell which package (if it at all you were able to decipher the crazy syntax and error messages) was the culprit. Due to (afaict) the small user base and non-mainstream nature of Nix, up-to-date documentation is hard to come by, you often have to read the upstream packaging Nix to understand what the issue was.
4. Integration of software configuration options depend on the community. Despite one of the major selling-points of NixOS being the ability to control the configuration of all software from within Nix files, these integrations are written upstream by individual packagers. And well, packagers are people like you and me, who may not share the same needs for configuring the software as you and or can decide to leave, abandoning the package. When that happens, you often need to figure out how to write your own integrations, or just give up and configure the software manually.
@123ghostly Short answer; no. While NixOS by default includes version control in the form of 'generations', it is far more limited than Git. Basically, each time you modify the NixOS configuration file and ask the system to apply the changes, it stores the changes (i.e. software versions, software configuration and even kernel version) as a 'generation' which you could pick from a menu at boot time.
Long answer; not by default, but it is definitely more suited to being managed by Git! The main value of NixOS is that it's configuration format is a full-on programming language, and hence let's you control EVERYTHING about the system within 1 text file (or a collection of text files with full blown 'imports' between each other just like a program's source code). What software or kernel you're installing, if and which patches you're applying to software and hence needs re-compiling, what configuration options all the packages normally expose under /etc can ALL be controlled from the Nix configuration! Git is far more suited for tracking this as its similar to software source code and there are no binary formats which would likely be the case on a regular Linux FHS-compliant /etc directory.
When it comes to servers specifically, NixOS even let's you create disk images based on an existing NixOS config, which could be useful in deploying a fleet of servers without needing to customize the server from a base image provided by a cloud provider like with Ansible. Not to mention, the reproducibility benefit of nixOS which means you don't need to worry about your configs breaking in the future.
P.S. Some disambiguation - Nix refers both to the configuration language used to configure a nix-based system and the packaging manager. Nix can be used in two ways - nixpkgs which let's you set-up reproducible software environments on any Linux distro (think Python venv but on steroids and applying to every program you can run in a shell) but also, nixOS which is when you let the Nix package manager manage your entire system and have the Nix package repository as your distro. Both of the aforementioned methods are officially supported by the Nix team!
P.P.S. - Since I'm plugging Nix super hard here, I need to offer some down-sides.
1. The learning curve for Nix (both the language and paradigm) is very high. Although there were recent efforts to help flatten the curve by creating some beginner-friendly documentation, don't get into it you're ready to treat it as learning a new programming language.
2. Proprietary (and sometimes niche FOSS ones even!) software tends to not play nice with the Nix package management paradigm. Due to the needing to provide reproducibility and the aforementioned 'generations' feature, Nix is capable of (and usually does) storing multiple versions of library and apps on a single system. Getting software that depends on libraries to run therefore, usually requires patching them, which could delay package updates for newer versions or break DRM measures for proprietary software (e.g. Discord's Krisp noise cancellation feature which is DRM-protected).
3. Nix can be hard to debug and troubleshoot due to lack of documentation and appropriate tools. This is as much a demographics problem and as it is a technical problem. So many changes occur between nixpkgs/nixOS versions that if anything breaks, it is hard to tell which package (if it at all you were able to decipher the crazy syntax and error messages) was the culprit. Due to (afaict) the small user base and non-mainstream nature of Nix, up-to-date documentation is hard to come by, you often have to read the upstream packaging Nix to understand what the issue was.
4. Integration of software configuration options depend on the community. Despite one of the major selling-points of NixOS being the ability to control the configuration of all software from within Nix files, these integrations are written upstream by individual packagers. And well, packagers are people like you and me, who may not share the same needs for configuring the software as you and or can decide to leave, abandoning the package. When that happens, you often need to figure out how to write your own integrations, or just give up and configure the software manually.