tiiuae / ghaf Goto Github PK
View Code? Open in Web Editor NEWTII SSRC Secure Technologies: Ghaf Framework
Home Page: https://tiiuae.github.io/ghaf/
License: Apache License 2.0
TII SSRC Secure Technologies: Ghaf Framework
Home Page: https://tiiuae.github.io/ghaf/
License: Apache License 2.0
Line 33 in eeab7f2
Check the entire file and others solution names.
Maybe add this link https://docs.nitrokey.com/hsm/ as well.
I tested the installer and there are some rough edges, for example I was staring away from laptop while it was installing, then it rebooted, and I wasn't fast enough to disconnect the USB-drive. So the system somehow strangely booted up into ghaf desktop but still something was mounted from USB-drive.
But I'm fine with merging this now and improving things later.
Originally posted by @mikatammi in #249 (comment)
On this page https://tiiuae.github.io/ghaf/architecture/adr.html, there is a link to a template in the archived repository. Could you please update it?
@vilvo Please check if this information is still needed, then move template.md to the ghaf repository and update the link.
In the page https://tiiuae.github.io/ghaf/scs/scs.html
in the second paragraph under the illustration, there is a link
Now that we have a dedicated Software Bill of Materials page in Ghaf GitHub pages, we should be pointing to it
-> Replace link URL with: https://tiiuae.github.io/ghaf/scs/sbom.html
Note: in https://tiiuae.github.io/ghaf/scs/sbom.html there is a link also to Fossa page so no information is lost.
On this page https://tiiuae.github.io/ghaf/build_config/build_configurations.html:
If you want to try and check the details, see the build-configurations repository.
Since this repository is now archived, how can we try and verify it now?
Will this instruction be enough? https://github.com/tiiuae/ghaf#build-instructions
TODO: address how the host allocates dedicated filesystems for guest VMs.
Originally posted by @vilvo in #96 (comment)
> Today I had a routing problem in Ghaf, because my default internet router subnet is 192.168.101.0/24.
[ghaf@net-vm:~]$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default net-vm 0.0.0.0 UG 1025 0 0 wlp0s4f0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 ethint0 192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 ethint0 192.168.101.0 0.0.0.0 255.255.255.0 U 1025 0 0 wlp0s4f0 net-vm 0.0.0.0 255.255.255.255 UH 1025 0 0 wlp0s4f0
The problem was that the net-vm was not able to ping my laptop because the default route in that case was through ethint0 and not to wlp0s4f0.
The solution in my case was simple, change the subnet in my Internet router to 192.168.110.0. But, many user could have a similar problem if their Internet routers subnet are 192.168.100.0 or 192.168.101.0. I think that the subnet managed by the net-vm should be one less popular, such as 192.168.170.0/
@jpruiz84 This is good suggestion. However, I left the change of the ghaf subnet ip addresses now out of this PR because it can cause some confusion in development and breaks in testing (when they have relied on IP addresses when the internal host name queries did not work). Now that the internal host name queries work, let's give people in development and testing time to adopt the change. Then the IP address range can be changed to something less likely to conflict.
Originally posted by @vilvo in #427 (comment)
Note for the future: Also the resulting image was 26 gigabytes, so adding (zstd) compression even to the image embedded, would save many gigabytes
Originally posted by @mikatammi in #249 (comment)
https://tiiuae.github.io/ghaf/build_config/reference_implementations.html
the authentication module link is broken
In https://tiiuae.github.io/ghaf/scs/sbom.html#sbom-tooling-in-ghaf paragraph there is text
Initially, sbomnix will support CycloneDX SBOM specification, due to the availability of other open source tools that also support CycloneDX. Support for other SBOM formats to sbomnix might be added in later versions.
Because SPDX specification support has been added to sbomnix, the paragraph should say
Here https://tiiuae.github.io/ghaf/about/overview.html#reference-implementation we have a link to our old repository.
Is it still actual? Can it be replaced with this one https://github.com/tiiuae/ghaf#build-instructions?
I suppose the right one would be CC-BY-SA-4.0 as README is rather documentation, than source code, but it has also Apache-2.0 markings in the beginning.
On building Ghaf lenovo-x1-carbon-gen11-debug
we see occasional build failures:
error: builder for '/nix/store/dyw71dxaaxvgyl3mnl5xc54ryqf5kxay-nixos-disk-image.drv' failed with exit code 1;
last 10 log lines:
> copying path '/nix/store/3z537aq6rbvfrl59bgfm6ls22z2dyy8z-chromium-120.0.6099.71-sandbox' to 'local'...
> copying path '/nix/store/bblyj5b3ii8n6v4ra0nb37cmi3lf8rz9-coreutils-9.3' to 'local'...
> copying path '/nix/store/rpzk0h1d11ciarcjkv1zzgsa1iz8zmv8-libidn-1.41' to 'local'...
> error: hash mismatch importing path '/nix/store/3z537aq6rbvfrl59bgfm6ls22z2dyy8z-chromium-120.0.6099.71-sandbox';
> specified: sha256:01bffjgrkk0saf32pjrgpcx893dksp2mqcbpy8bfn6wrinndd2gs
> got: sha256:1wi876fpb69cv2n8vkzr04mv2p5hbc543mpdci7a2lvk3ghnsr2c
More examples are available from the ~'past month' lenovo-x1-carbon-gen11-debug
build failures in github action pre-merge builds one can search from: https://github.com/tiiuae/ghaf/actions/workflows/build.yml?query=is%3Afailure.
The issue seems to relate to chromium build (hence only lenovo-x1-carbon-gen11-debug
is impacted from the set of targets currently built in pre-merge build workflow). Having many substituters configured seems to increase the likelihood of a build hitting this issue. For instance, github actions pre-merge builds configure the following binary caches: https://github.com/tiiuae/ghaf/blob/main/.github/workflows/build.yml#L146-L147.
As a workaround @brianmcgillion temporarily disabled the lenovo-x1-carbon-gen11-debug
target from the pre-merge build workflow with PR: #441.
We would like to re-enable the lenovo-x1-carbon-gen11-debug
in the pre-merge build action, but this issue needs to be resolved first.
The microvm
component is used for running virtual machines inside Ghaf
environment. It builds a kernel for virtual machines and filesystems. Filesystems contains NixOS components and additional needed by microvm
during runtime (startup scripts, etc.).
Microvm's feature is that it contains hard-coded kernel and package set definitions: kernel configuration and VM's NixOS packages set. There is no way to define a custom packages configuration.
It means that we are unable to define a VM with our own kernel version, configuration, and applied patches. We also cannot change the default package set. I solved this issue in the PR#94, source.
After getting more familiar with Nix/NixOS mechanisms, I have a proposal of solving the problem other way.
The microvm component is added additional options:
microvm.vm.kernel
: VM kernel packagemicrovm.vm.packages
: VM NixOS packages to be included in the buildmicrovm.vm.kernel = pkgs.linuxPackages_5_4.callPackage ./memsharevm-kernel.nix {};
microvm.vm.packages = pkgs.linuxPackages_5_4.extend (_: _: {
kernel = microvm.vm.kernel;
});
Sample kernel configuration: memsharevm-kernel.nix
I think that such change should be easily accepted by microvm's author. I already contacted him regarding other change.
In the page https://tiiuae.github.io/ghaf/build_configurations.html
There is a sentence "The canonical URL for the upstream git repository is: https://github.com/NixOS."
Currently the "https://github.com/NixOS" is not clickable, i.e. does not work as a link.
There are some open questions and possibly overlapping design proposals on how we integrate modules involving kernel patches and device tree configurations into Ghaf.
In the current main branch the kernel and device tree are configured in the hardware module. More precisely the hardware device tree is set here (line42). Kernel patches and configurations are set in the same file (lines19-38).
The device tree is hashed and copied to /dtbs/
in the boot configuration*.
*Explain this process in more detail, possibly commenting the source code as well.
We are in the process of integrating a module that enables bpmp virtualization on the host. The module includes kernel patches, kernel overlays and kernel configurations as well as device tree configurations and it is specific to the Nvidia Jetson Orin AGX target (or any possible future targets in that family).
I'd like to propose design clarifications, documentation and possibly some refactoring as related to the above context.
It is my understanding that we have two different proposals as to how we handle modules that involve kernel patches.
*How do we handle build-specific configurations such as this? Where do we configure them and how do we make sure different configuration options don't clash?
Explain the reasoning behind modules and how they fit our use case?
We should evaluate these approaches, write them out and document a clean way to integrate and test kernel patch modules in Ghaf. Another question is, are this approaches overlapping or complimentary?
We propose that all kernel configurations are defined in the nix file that defines the module or the overlay.
Example:
kernel.override {
kernelPatches = [
# ...
];
extraConfig = ''
CONFIG_PCI_DEBUG=y
'';
}
In current main branch some device tree configurations are added from a .dtb
file in a target specific hardware module in modules/hardware
.
How do we make this modular? Explore device tree overlays.
In the current main branch, target specific modules are mixed with common modules. This makes reading the repository somewhat challenging. Maybe we could move to something that separates architecture specific configurations more clearly.
ghaf/modules/
target/
nvidia-jetson-orin/
bpmp-virt/ # Possibly a git submodule (separate repo)?
...
generic-x86/
...
common/
module.nix
...
Ghaf flake evaluation against nixos-unstable
fails after commit c7cc82b which was merged in PR #550.
Repro steps
nixos-unstable
:❯ git diff flake.nix
diff --git a/flake.nix b/flake.nix
index 1d1d736..eee65e2 100644
--- a/flake.nix
+++ b/flake.nix
@@ -25,7 +25,7 @@
};
inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
#
# Flake and repo structuring configurations
❯ nix flake lock --update-input nixpkgs
error: infinite recursion encountered
:❯ nix eval --raw .#packages.x86_64-linux.lenovo-x1-carbon-gen11-debug -v
...
at /nix/store/450afzqlzzgw6wnyc3dwysf3i5yxyqkr-source/lib/customisation.nix:80:32:
79| newDrv = derivation (drv.drvAttrs // (f drv));
80| in flip (extendDerivation (seq drv.drvPath true)) newDrv (
| ^
81| { meta = drv.meta or {};
(stack trace truncated; use '--show-trace' to show the full trace)
error: infinite recursion encountered
...
❯ git revert c7cc82b1e2360cd94cdf55a23ff1b3a896f7dff0
[main 554965f] Revert "Add USB network card kernel patch"
2 files changed, 26 deletions(-)
delete mode 100644 modules/common/hardware/usb-network-kernel-patch.nix
❯ nix eval --raw .#packages.x86_64-linux.lenovo-x1-carbon-gen11-debug
...
/nix/store/w0yanw2x2m1nh62awapzzlnf35pjv6ir-ghaf-host-disko-images
VM specific development modules I’d rather break to VM specific based on categories eventually. It would reduce VM/host size in development mode (think tools useful in GUIVM).
Originally posted by @vilvo in #107 (comment)
`allow_unsafe_interrupts` enables threat vector via MSI (message signaled interrupts). This is possible with PCI devices if there's access to device configuration space. See https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf - pages 6-7.
I'll add this note to acknowledge the threat from within the netvm and make a ghaf issue out of this to document it - at least until we have iommu group interrupt remapping support or other documented VMM mitigations. It may be that there's other mitigations these days that I'm not aware of. If that turns out to be the case, let's document those and close the issue after the fact.
Originally posted by @vilvo in #93 (comment)
Currently the way of adding a new application to GHAF is not clear. (at least I have not found any instructions and rules). What the app should be on GHAF: module, package or smth else.
As an example I took a look at the GALA app. The GALA app already added to the GHAF. Is the way it was added right/suitable for all?
Change in flake.nix the description value from this
description = "Ghaf - Documentation and implementation for TII SSRC Secure Technologies Ghaf Framework";
to this
description = "Ghaf Framework: Documentation and implementation for TII SSRC Secure Technologies";
This whole `features.md` file needs status update based on the the current progress.
Originally posted by @vilvo in #121 (comment)
Address host NAT in the minimal host documentation
Originally posted by @vilvo in #93 (comment)
PR #167 introduced Ghaf dependency to git revision. After that change, every new revision in Ghaf repository requires a re-build even if the pushed change does not impact any (other) relevant inputs for the build target. This causes unnecessary rebuilds and sub-optimal caching.
This is especially bad for Ghaf, where we are building debug images with the size of each image roughly at 8GB. Since we are now building around 12 targets on each new revision and caching the build results, it means each new change (any change!) generates roughly 100GB of cached images that are largely unnecessary. Since hydra builds all commits merged to main, I assume this generates a lot of problems for remote caches.
We need to think if the trade-off of having the git revision conveniently available on the running system is worth the cost of slowing down the builds and filling our local and remote binary caches with all of these nixos images.
If the ghaf revision must be available in the image, we should think of alternative ways of mapping the running image to the ghaf git revision without introducing the dependency.
When checking the ghaf flake with nix flake check --all-systems
I get the following:
ghaf git:(main) nix flake check --all-systems
error:
… while checking flake output 'hydraJobs'
at «none»:0: (source not available)
… while checking the Hydra jobset 'hydraJobs'
at «none»:0: (source not available)
(stack trace truncated; use '--show-trace' to show the full trace)
error: cannot build '/nix/store/qlzv68cp8ks2plr60wqwzhrg5bwvl8gs-waypipe-ssh.dr
v' during evaluation because the option 'allow-import-from-derivation' is disabled
Background: In Nix, the act of "importing from a derivation" allows for the dynamic generation of Nix expressions during the build process. By default, the allow-import-from-derivation option is disabled because IFD can have potential complications when used with Hydra, Nix's CI server.
Maybe we could also add the flake check into Github Actions CI maybe as part of #293
I would propose to keep common target headless and have graphics enabler separately.
Originally posted by @unbel13ver in #77 (comment)
x86_64-generic
as an example.
$ nix flake new --template github:tiiuae/ghaf#target-x86_64-generic ~/test-ghaf-downstream
wrote: /home/vilvo/test-ghaf-downstream/flake.nix
[vilvo@carrie:~]$ cd test-ghaf-downstream/
[vilvo@carrie:~/test-ghaf-downstream]$ nix flake show
warning: creating lock file '/home/vilvo/test-ghaf-downstream/flake.lock'
path:/home/vilvo/test-ghaf-downstream?lastModified=1712815534&narHash=sha256-2mIRO3JZxIvS4cBpLzQDpDxVZIaGKlfOvEYs37Yka70%3D
error:
… in the left operand of the update (//) operator
at «string»:56:13:
55| # This is shadowed in the next //
56| // sourceInfo
| ^
57| // {
… from call site
at «string»:47:21:
46|
47| outputs = flake.outputs (inputs // { self = result; });
| ^
48|
error: function 'outputs' called with unexpected argument 'nixos-hardware'
at /nix/store/bwf2bjngr2nyp28nx33fqnnl87ammiz4-source/flake.nix:41:13:
40|
41| outputs = {
| ^
42| self,
[vilvo@carrie:~/test-ghaf-downstream]$
Affected guides - https://tiiuae.github.io/ghaf/ref_impl/ghaf-based-project.html
Is this really the minimal we want? This is minimal for a generic headless device, I envisaged us creating minimal-minimal.nix, or barely-enough-to-boot.nix profiles, which we could contribute back.
Originally posted by @brianmcgillion in #41 (review)
❯ nix flake show
warning: Git tree '/home/brian/projects/code/github.com/tiiuae/ghaf' is dirty
git+file:///home/brian/projects/code/github.com/tiiuae/ghaf
├───formatter
│ ├───aarch64-linux: package 'alejandra-3.0.0'
│ └───x86_64-linux: package 'alejandra-3.0.0'
├───hydraJobs
│ ├───intel-nuc-debug
│ │ └───x86_64-linux: derivation 'nixos-disk-image'
│ └───nvidia-jetson-orin-debug
│ └───aarch64-linux: derivation 'nixos-disk-image'
├───nixosConfigurations
│ ├───imx8qm-mek-debug: NixOS configuration
│ ├───imx8qm-mek-release: NixOS configuration
│ ├───intel-nuc-debug: NixOS configuration
│ ├───intel-nuc-release: NixOS configuration
│ ├───netvm-imx8qm-mek-debug: NixOS configuration
│ ├───netvm-imx8qm-mek-release: NixOS configuration
│ ├───netvm-intel-nuc-debug: NixOS configuration
│ ├───netvm-intel-nuc-release: NixOS configuration
│ ├───netvm-nvidia-jetson-orin-debug: NixOS configuration
│ ├───netvm-nvidia-jetson-orin-release: NixOS configuration
│ ├───netvm-vm-debug: NixOS configuration
│ ├───netvm-vm-release: NixOS configuration
│ ├───nvidia-jetson-orin-debug: NixOS configuration
│ ├───nvidia-jetson-orin-debug-from-x86_64: NixOS configuration
│ ├───nvidia-jetson-orin-release: NixOS configuration
│ ├───nvidia-jetson-orin-release-from-x86_64: NixOS configuration
│ ├───vm-debug: NixOS configuration
│ └───vm-release: NixOS configuration
└───packages
├───aarch64-linux
│ ├───doc: package 'ghaf-doc'
error: The option boot.loader.grub.enable' has conflicting definition values: - In
/nix/store/lzv828iaf3p4kjhdsj1vgfn4n510a94x-source/nxp/common/modules.nix': true
- In `/nix/store/5592s3m0cf14nmqm2g14f6mz6plqb9f7-source/nixos/modules/system/boot/loader/systemd-boot/systemd-boot.nix': false
(use '--show-trace' to show detailed location information)
This is caused by the modules/host/minimal.nix declaring systemd boot, while the imx8 is declaring grub.
Added a 'go' package to my ghaf repo "ghaf/modules/development/packages.nix". and ran Ghaf with “nix run .#packages.x86_64-linux.vm-debug“. Then tried to install Kopia in Ghaf's terminal with "go install github.com/kopia/kopia@latest", but the reserved disk space ran out with few of its last parts. Looked like there was < 1GB space on the Ghaf's reserved disk originally and about 700MB got installed of Kopia when the space ran out. Is there some configuration that is limiting this to only 1GBish? What could be done?
Running Ghaf on Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64).
> fyi @henrirosten
This is definitely better than no check at all, but notice that there is a tool already that checks the project's compliance for REUSE. pkgs.reuse
is also available in nixpkgs. Although, manually running reuse lint
for Ghaf project indicates a large number of issues, which we should resolve first if we would start using pkgs.reuse
instead of the scripts in this PR.
Maybe we'll start with @mikatammi's scritps and possibly gradually move to reuse lint
compliance later?
For reference, issues currently reported by reuse lint
:
ghaf$ nix-shell -p reuse --run "reuse lint"
reuse.project - WARNING - Could not resolve SPDX License Identifier of LICENSES/LICENSE.Apache-2.0, resolving to LICENSE.Apache-2. Make sure the license is in the license list found at <https://spdx.org/licenses/> or that it starts with 'LicenseRef-', and that it has a file extension.
reuse.project - WARNING - Could not resolve SPDX License Identifier of LICENSES/LICENSE.CC-BY-SA-4.0, resolving to LICENSE.CC-BY-SA-4. Make sure the license is in the license list found at <https://spdx.org/licenses/> or that it starts with 'LicenseRef-', and that it has a file extension.
reuse._util - ERROR - Could not parse 'Apache-2.0" && exit 1)'
reuse.project - ERROR - 'scripts/spdx_nix_checker/check_file' holds an SPDX expression that cannot be parsed, skipping the file
# BAD LICENSES
'LICENSE.Apache-2' found in:
* LICENSES/LICENSE.Apache-2.0
'LICENSE.CC-BY-SA-4' found in:
* LICENSES/LICENSE.CC-BY-SA-4.0
# MISSING LICENSES
'Apache-2.0' found in:
* CONTRIBUTING.md
* README.md
* docs/doc.nix
* flake.nix
* hydrajobs.nix
* microvmConfigurations/netvm/default.nix
* modules/development/authentication.nix
* modules/development/intel-nuc-getty.nix
* modules/development/nix.nix
* modules/development/packages.nix
* modules/development/ssh.nix
* modules/graphics/weston.nix
* modules/hardware/nvidia-jetson-orin.nix
* modules/host/default.nix
* modules/host/microvm.nix
* modules/host/networking.nix
* targets/common-debug.nix
* targets/common-release.nix
* targets/common.nix
* targets/default.nix
* targets/intel-nuc.nix
* targets/nvidia-jetson-orin-flash-script.nix
* targets/nvidia-jetson-orin.nix
* targets/vm.nix
'CC-BY-SA-4.0' found in:
* CONTRIBUTING.md
* README.md
* docs/README.md
* docs/src/appendices/contributing_general.md
* docs/src/appendices/glossary.md
* docs/src/architecture/adr/minimal-host.md
* docs/src/architecture/adr.md
* docs/src/architecture/architecture.md
* docs/src/build_config/build_configurations.md
* docs/src/build_config/cross_compilation.md
* docs/src/build_config/passthrough/nvidia_agx_pt_uart.md
* docs/src/build_config/passthrough/passthrough.md
* docs/src/build_config/reference_implementations.md
* docs/src/index.md
* docs/src/research/passthrough/ethernet.md
* docs/src/research/research.md
* docs/src/scs/basics.md
* docs/src/scs/patching-automation.md
* docs/src/scs/pki.md
* docs/src/scs/sbom.md
* docs/src/scs/scs.md
* docs/src/scs/slsa-framework.md
* docs/src/technologies/technologies.md
# UNUSED LICENSES
The following licenses are not used:
* LICENSE.Apache-2
* LICENSE.CC-BY-SA-4
# MISSING COPYRIGHT AND LICENSING INFORMATION
The following files have no copyright and licensing information:
* .git-blame-ignore-revs
* .github/workflows/doc.yml
* .gitignore
* docs/book.toml
* docs/src/SUMMARY.md
* docs/src/architecture/adr/template.md
* docs/src/img/autopatching.drawio.png
* docs/src/img/ca_implementation.drawio.png
* docs/src/img/overview.png
* docs/src/img/threat_processing.drawio.png
* docs/src/img/threat_processing_1serv.drawio.png
* docs/src/img/threat_processing_2serv.drawio.png
* docs/src/research/passthrough/imx8qm-mek_conn-guest.dts
* docs/src/research/passthrough/imx8qm-mek_conn-host.dts
* docs/style_guide.md
* flake.lock
* scripts/spdx_nix_checker/check_file
The following files have no licensing information:
* .github/workflows/fmt-check.yml
* scripts/spdx_nix_checker/check_all
# SUMMARY
* Bad licenses: LICENSE.Apache-2, LICENSE.CC-BY-SA-4
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses: Apache-2.0, CC-BY-SA-4.0
* Unused licenses: LICENSE.Apache-2, LICENSE.CC-BY-SA-4
* Used licenses: Apache-2.0, CC-BY-SA-4.0
* Read errors: 0
* Files with copyright information: 47 / 64
* Files with license information: 45 / 64
Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(
Originally posted by @henrirosten in #79 (comment)
https://nixos.org/manual/nix/unstable/language/import-from-derivation
This causes slow evaluation times as packages have to be realised along the way. It can also constitute final images being built numerous times making e.g. nix flake check
and nix-fast-build
take inordinate amounts of time and in part is leading to the OOM that is encountered when running these on standard hardware.
Currently, nix flake check only succeeds in the following situation nix flake check --allow-import-from-derivation
as flakes generally disallow IFD in their evaluation.
SSID / password we could also refactor like authentication.nix - would also support .gitignore for developer local secrets until we develop proper way to support these.
Originally posted by @vilvo in #107 (comment)
nix flake check
runs out of memory even after #372.
Following reproduction steps were run on x86_64-linux with 16-cores and 32GB memory (no remote builder is configured):
Git HEAD:
$ git log -1 --pretty=oneline
8f8f6538807f8afd9f08dc6a162c5f407f69bc5b (HEAD -> main, origin/main, origin/HEAD) Fix reuse compliance
Run nix flake check
to repro OOM:
$ nix flake check
checking flake output 'checks'Killed
Verify from journactl
that it's killed due to OOM:
$ journalctl | tail -n500 | grep -i "Out of memory"
Dec 01 09:35:07 duamix kernel: Out of memory: Killed process 1808882 (nix) total-vm:27647872kB, anon-rss:27439060kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:53844kB oom_score_adj:0
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.