GitHub C Daily Trending

curl/curl

A command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features

curl is a command-line tool for transferring data from or to a server using URLs. It supports these protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS.

Learn how to use curl by reading the man page or everything curl.

Find out how to install curl by reading the INSTALL document.

libcurl is the library curl is using to do its job. It is readily available to be used by your software. Read the libcurl man page to learn how.

Open Source

curl is Open Source and is distributed under an MIT-like license.

Contact

All contributors to the project are listed in the THANKS document.

Commercial support

For commercial support, maybe private and dedicated help with your problems or applications using (lib)curl visit the support page.

Website

Visit the curl website for the latest news and downloads.

Source code

Download the latest source from the Git server:

git clone https://github.com/curl/curl

Security problems

Report suspected security problems privately and not in public.

Backers

Thank you to all our backers 🙏 Become a backer.

FreeRTOS/FreeRTOS-Kernel

FreeRTOS kernel files only, submoduled into https://github.com/FreeRTOS/FreeRTOS and various other repos.

Getting started

This repository contains FreeRTOS kernel source/header files and kernel ports only. This repository is referenced as a submodule in FreeRTOS/FreeRTOS repository, which contains pre-configured demo application projects under FreeRTOS/Demo directory.

The easiest way to use FreeRTOS is to start with one of the pre-configured demo application projects. That way you will have the correct FreeRTOS source files included, and the correct include paths configured. Once a demo application is building and executing you can remove the demo application files, and start to add in your own application source files. See the FreeRTOS Kernel Quick Start Guide for detailed instructions and other useful links.

Additionally, for FreeRTOS kernel feature information refer to the Developer Documentation, and API Reference.

Also for contributing and creating a Pull Request please refer to the instructions here.

FreeRTOS-Kernel V11.1.0 source code is part of the FreeRTOS 202406.00 LTS release.

Getting help

If you have any questions or need assistance troubleshooting your FreeRTOS project, we have an active community that can help on the FreeRTOS Community Support Forum.

To consume FreeRTOS-Kernel

Consume with CMake

If using CMake, it is recommended to use this repository using FetchContent. Add the following into your project's main or a subdirectory's CMakeLists.txt:

Define the source and version/tag you want to use:

FetchContent_Declare( freertos_kernel
  GIT_REPOSITORY https://github.com/FreeRTOS/FreeRTOS-Kernel.git
  GIT_TAG        main #Note: Best practice to use specific git-hash or tagged version
)

In case you prefer to add it as a git submodule, do:

git submodule add https://github.com/FreeRTOS/FreeRTOS-Kernel.git <path of the submodule>
git submodule update --init

Add a freertos_config library (typically an INTERFACE library) The following assumes the directory structure:
- include/FreeRTOSConfig.h

add_library(freertos_config INTERFACE)

target_include_directories(freertos_config SYSTEM
INTERFACE
    include
)

target_compile_definitions(freertos_config
  INTERFACE
    projCOVERAGE_TEST=0
)

In case you installed FreeRTOS-Kernel as a submodule, you will have to add it as a subdirectory:

add_subdirectory(${FREERTOS_PATH})

Configure the FreeRTOS-Kernel and make it available
- this particular example supports a native and cross-compiled build option.

set( FREERTOS_HEAP "4" CACHE STRING "" FORCE)
# Select the native compile PORT
set( FREERTOS_PORT "GCC_POSIX" CACHE STRING "" FORCE)
# Select the cross-compile PORT
if (CMAKE_CROSSCOMPILING)
  set(FREERTOS_PORT "GCC_ARM_CA9" CACHE STRING "" FORCE)
endif()

FetchContent_MakeAvailable(freertos_kernel)

In case of cross compilation, you should also add the following to freertos_config:

target_compile_definitions(freertos_config INTERFACE ${definitions})
target_compile_options(freertos_config INTERFACE ${options})

Consuming stand-alone - Cloning this repository

To clone using HTTPS:

git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git

Using SSH:

git clone git@github.com:FreeRTOS/FreeRTOS-Kernel.git

Repository structure

The root of this repository contains the three files that are common to every port - list.c, queue.c and tasks.c. The kernel is contained within these three files. croutine.c implements the optional co-routine functionality - which is normally only used on very memory limited systems.
The ./portable directory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the ./portable directory for more information.
The ./include directory contains the real time kernel header files.
The ./examples/template_configuration directory contains a sample FreeRTOSConfig.h to help jumpstart a new project. See the FreeRTOSConfig.h file for instructions.

Code Formatting

FreeRTOS files are formatted using the "uncrustify" tool. The configuration file used by uncrustify can be found in the FreeRTOS/CI-CD-GitHub-Actions's uncrustify.cfg file.

Line Endings

File checked into the FreeRTOS-Kernel repository use unix-style LF line endings for the best compatibility with git.

For optimal compatibility with Microsoft Windows tools, it is best to enable the git autocrlf feature. You can enable this setting for the current repository using the following command:

git config core.autocrlf true

Git History Optimizations

Some commits in this repository perform large refactors which touch many lines and lead to unwanted behavior when using the git blame command. You can configure git to ignore the list of large refactor commits in this repository with the following command:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Spelling and Formatting

We recommend using Visual Studio Code, commonly referred to as VSCode, when working on the FreeRTOS-Kernel. The FreeRTOS-Kernel also uses cSpell as part of its spelling check. The config file for which can be found at cspell.config.yaml There is additionally a cSpell plugin for VSCode that can be used as well. .cSpellWords.txt contains words that are not traditionally found in an English dictionary. It is used by the spellchecker to verify the various jargon, variable names, and other odd words used in the FreeRTOS code base are correct. If your pull request fails to pass the spelling and you believe this is a mistake, then add the word to .cSpellWords.txt. When adding a word please then sort the list, which can be done by running the bash command: sort -u .cSpellWords.txt -o .cSpellWords.txt Note that only the FreeRTOS-Kernel Source Files, include, portable/MemMang, and portable/Common files are checked for proper spelling, and formatting at this time.

Third Party Tools

Visit this link for detailed information about third-party tools with FreeRTOS support.

HarbourMasters/Shipwright

Website

Official Website: https://www.shipofharkinian.com/

Discord

Official Discord: https://discord.com/invite/shipofharkinian

If you're having any trouble after reading through this README, feel free to ask for help in the Support text channels. Please keep in mind that we do not condone piracy.

Quick Start

The Ship does not include any copyrighted assets. You are required to provide a supported copy of the game.

1. Verify your ROM dump

You can verify you have dumped a supported copy of the game by using the compatibility checker at https://ship.equipment/. If you'd prefer to manually validate your ROM dump, you can cross-reference its sha1 hash with the hashes here.

2. Download The Ship of Harkinian from Releases

3. Launch the Game!

Windows

Extract the zip
Launch soh.exe

Linux

Place your supported copy of the game in the same folder as the appimage.
Execute soh.appimage. You may have to chmod +x the appimage via terminal.

macOS

Run soh.app. When prompted, select your supported copy of the game.
You should see a notification saying Processing OTR, then, once the process is complete, you should get a notification saying OTR Successfully Generated, then the game should start.

Nintendo Switch

Run one of the PC releases to generate an oot.o2r and/or oot-mq.o2r file. After launching the game on PC, you will be able to find these files in the same directory as soh.exe or soh.appimage. On macOS, these files can be found in /Users/<username>/Library/Application Support/com.shipofharkinian.soh/
Copy the files to your sd card

sdcard
└── switch
    └── soh
        ├── oot-mq.o2r
        ├── oot.o2r
        ├── soh.nro
        └── soh.o2r

Launch via Atmosphere's Game+R launcher method.

4. Play!

Congratulations, you are now sailing with the Ship of Harkinian! Have fun!

Configuration

Default keyboard configuration

N64	A	B	Z	Start	Analog stick	C buttons	D-Pad
Keyboard	X	C	Z	Space	WASD	Arrow keys	TFGH

Other shortcuts

Keys	Action
ESC	Toggle menu
F2	Toggle capture mouse input
F5	Save state
F6	Change state
F7	Load state
F9	Toggle Text-to-Speech (Windows and Mac only)
F11	Fullscreen
Tab	Toggle Alternate assets
Ctrl+R	Reset

Project Overview

Ship of Harkinian (SOH) is built atop a custom library dubbed libultraship (LUS). Back in the N64 days, there was an SDK distributed to developers named libultra; LUS is designed to mimic the functionality of libultra on modern hardware. In addition, we are dependant on the source code provided by the OOT decompilation project.

In order for the game to function, you will require a legally acquired ROM for Ocarina of Time. Click here to check the compatibility of your specific rom. Any copyrighted assets are extracted from the ROM and reformatted as a .o2r archive file which the code uses.

Graphics Backends

Currently, there are three rendering APIs supported: DirectX11 (Windows), OpenGL (all platforms), and Metal (MacOS). You can change which API to use in the Settings menu of the menubar, which requires a restart. If you're having an issue with crashing, you can change the API in the shipofharkinian.json file by finding the line gfxbackend:"" and changing the value to sdl for OpenGL. DirectX 11 is the default on Windows.

Custom Assets

Custom assets are packed in .otr archive files. To use custom assets, place them in the mods folder.

If you're interested in creating and/or packing your own custom asset .otr files, check out the following tools:

Development

Building

If you want to manually compile SoH, please consult the building instructions.

Playtesting

If you want to playtest a continuous integration build, you can find them at the links below. Keep in mind that these are for playtesting only, and you will likely encounter bugs and possibly crashes.

facebook/zstd

Zstandard - Fast real-time compression algorithm

Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. It's backed by a very fast entropy stage, provided by Huff0 and FSE library.

Zstandard's format is stable and documented in RFC8878. Multiple independent implementations are already available. This repository represents the reference implementation, provided as an open-source dual BSD OR GPLv2 licensed C library, and a command line utility producing and decoding .zst, .gz, .xz and .lz4 files. Should your project require another programming language, a list of known ports and bindings is provided on Zstandard homepage.

Development branch status:

Benchmarks

For reference, several fast compression algorithms were tested and compared on a desktop featuring a Core i7-9700K CPU @ 4.9GHz and running Ubuntu 24.04 (Linux 6.8.0-53-generic), using lzbench, an open-source in-memory benchmark by @inikep compiled with gcc 14.2.0, on the Silesia compression corpus.

Compressor name	Ratio	Compression	Decompress.
zstd 1.5.7 -1	2.896	510 MB/s	1550 MB/s
brotli 1.1.0 -1	2.883	290 MB/s	425 MB/s
zlib 1.3.1 -1	2.743	105 MB/s	390 MB/s
zstd 1.5.7 --fast=1	2.439	545 MB/s	1850 MB/s
quicklz 1.5.0 -1	2.238	520 MB/s	750 MB/s
zstd 1.5.7 --fast=4	2.146	665 MB/s	2050 MB/s
lzo1x 2.10 -1	2.106	650 MB/s	780 MB/s
lz4 1.10.0	2.101	675 MB/s	3850 MB/s
snappy 1.2.1	2.089	520 MB/s	1500 MB/s
lzf 3.6 -1	2.077	410 MB/s	820 MB/s

The negative compression levels, specified with --fast=#, offer faster compression and decompression speed at the cost of compression ratio.

Zstd can also offer stronger compression ratios at the cost of compression speed. Speed vs Compression trade-off is configurable by small increments. Decompression speed is preserved and remains roughly the same at all settings, a property shared by most LZ compression algorithms, such as zlib or lzma.

The following tests were run on a server running Linux Debian (Linux version 4.14.0-3-amd64) with a Core i7-6700K CPU @ 4.0GHz, using lzbench, an open-source in-memory benchmark by @inikep compiled with gcc 7.3.0, on the Silesia compression corpus.

Compression Speed vs Ratio	Decompression Speed

A few other algorithms can produce higher compression ratios at slower speeds, falling outside of the graph. For a larger picture including slow modes, click on this link.

The case for Small Data compression

Previous charts provide results applicable to typical file and stream scenarios (several MB). Small data comes with different perspectives.

The smaller the amount of data to compress, the more difficult it is to compress. This problem is common to all compression algorithms, and reason is, compression algorithms learn from past data how to compress future data. But at the beginning of a new data set, there is no "past" to build upon.

To solve this situation, Zstd offers a training mode, which can be used to tune the algorithm for a selected type of data. Training Zstandard is achieved by providing it with a few samples (one file per sample). The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression. Using this dictionary, the compression ratio achievable on small data improves dramatically.

The following example uses the github-users sample set, created from github public API. It consists of roughly 10K records weighing about 1KB each.

Compression Ratio	Compression Speed	Decompression Speed

These compression gains are achieved while simultaneously providing faster compression and decompression speeds.

Training works if there is some correlation in a family of small data samples. The more data-specific a dictionary is, the more efficient it is (there is no universal dictionary). Hence, deploying one dictionary per type of data will provide the greatest benefits. Dictionary gains are mostly effective in the first few KB. Then, the compression algorithm will gradually use previously decoded content to better compress the rest of the file.

Dictionary compression How To:

Create the dictionary

zstd --train FullPathToTrainingSet/* -o dictionaryName
Compress with dictionary

zstd -D dictionaryName FILE
Decompress with dictionary

zstd -D dictionaryName --decompress FILE.zst

Build instructions

make is the main build system of this project. It is the reference, and other build systems are periodically updated to stay compatible. However, small drifts and feature differences can be present, since perfect synchronization is difficult. For this reason, when your build system allows it, prefer employing make.

Makefile

Assuming your system supports standard make (or gmake), just invoking make in root directory generates zstd cli at root, and also generates libzstd into lib/.

Other standard targets include:

make install : install zstd cli, library and man pages
make check : run zstd, test its essential behavior on local platform

The Makefile follows the GNU Standard Makefile conventions, allowing staged install, standard compilation flags, directory variables and command variables.

For advanced use cases, specialized flags which control binary generation and installation paths are documented in lib/README.md for the libzstd library and in programs/README.md for the zstd CLI.

cmake

A cmake project generator is available for generating Makefiles or other build scripts to create the zstd binary as well as libzstd dynamic and static libraries. The repository root now contains a minimal CMakeLists.txt that forwards to build/cmake, so you can configure the project with a standard cmake -S . invocation, while the historical cmake -S build/cmake entry point remains fully supported.

cmake -S . -B build-cmake
cmake --build build-cmake

By default, CMAKE_BUILD_TYPE is set to Release.

Support for Fat (Universal2) Output

zstd can be built and installed with support for both Apple Silicon (M1/M2) as well as Intel by using CMake's Universal2 support. To perform a Fat/Universal2 build and install use the following commands:

cmake -S . -B build-cmake-debug -G Ninja -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h;arm64"
cd build-cmake-debug
ninja
sudo ninja install

Meson

A Meson project is provided within build/meson. Follow build instructions in that directory.

You can also take a look at .travis.yml file for an example about how Meson is used to build this project.

Note that default build type is release.

VCPKG

You can build and install zstd vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install zstd

The zstd port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Conan

You can install pre-built binaries for zstd or build it from source using Conan. Use the following command:

conan install --requires="zstd/[*]" --build=missing

The zstd Conan recipe is kept up to date by Conan maintainers and community contributors. If the version is out of date, please create an issue or pull request on the ConanCenterIndex repository.

Visual Studio (Windows)

Going into build directory, you will find additional possibilities:

Projects for Visual Studio 2008 and 2010.
- VS2010 project is compatible with VS2012, VS2013, VS2015 and VS2017.
Automated build scripts for Visual compiler by @KrzysFR, in build/VS_scripts, which will build zstd cli and libzstd library without any need to open Visual Studio solution.
It is now recommended to generate Visual Studio solutions from cmake

Buck

You can build the zstd binary via buck by executing: buck build programs:zstd from the root of the repo. The output binary will be in buck-out/gen/programs/.

Bazel

You can integrate zstd into your Bazel project by using the module hosted on the Bazel Central Repository.

Testing

You can run quick local smoke tests by running make check. If you can't use make, execute the playTest.sh script from the src/tests directory. Two env variables $ZSTD_BIN and $DATAGEN_BIN are needed for the test script to locate the zstd and datagen binary. For information on CI testing, please refer to TESTING.md.

Status

Zstandard is deployed within Meta and many other large cloud infrastructures, to compress humongous amounts of data in various formats and use cases. It is also continuously fuzzed for security issues by Google's oss-fuzz program.

License

Zstandard is dual-licensed under BSD OR GPLv2.

Contributing

The dev branch is the one where all contributions are merged before reaching release. Direct commit to release are not permitted. For more information, please read CONTRIBUTING.

AcademySoftwareFoundation/openexr

The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

OpenEXR

OpenEXR provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

The purpose of EXR format is to accurately and efficiently represent high-dynamic-range scene-linear image data and associated metadata, with strong support for multi-part, multi-channel use cases.

OpenEXR is widely used in host application software where accuracy is critical, such as photorealistic rendering, texture access, image compositing, deep compositing, and DI.

OpenEXR Project Mission

The goal of the OpenEXR project is to keep the EXR format reliable and modern and to maintain its place as the preferred image format for entertainment content creation.

Major revisions are infrequent, and new features will be carefully weighed against increased complexity. The principal priorities of the project are:

Robustness, reliability, security
Backwards compatibility, data longevity
Performance - read/write/compression/decompression time
Simplicity, ease of use, maintainability
Wide adoption, multi-platform support - Linux, Windows, macOS, and others

OpenEXR is intended solely for 2D data. It is not appropriate for storage of volumetric data, cached or lit 3D scenes, or more complex 3D data such as light fields.

The goals of the Imath project are simplicity, ease of use, correctness and verifiability, and breadth of adoption. Imath is not intended to be a comprehensive linear algebra or numerical analysis package.

Project Governance

OpenEXR is a project of the Academy Software Foundation. See the project's governance policies, contribution guidelines, and code of conduct for more information.

Building OpenEXR

See the Install instructions for instructions on how to build OpenEXR and its required prerequisites.

Quick Start

See the technical documentation for complete details, but to get started, the "Hello, world" exrwriter.cpp writer program is:

#include <ImfRgbaFile.h>
#include <ImfArray.h>
#include <iostream>

using namespace OPENEXR_IMF_NAMESPACE;

int
main()
{
    int width =  100;
    int height = 50;

    Array2D<Rgba> pixels(height, width);
    for (int y=0; y<height; y++)
    {
        float c = (y / 5 % 2 == 0) ? (y / (float) height) : 0.0;
        for (int x=0; x<width; x++)
            pixels[y][x] = Rgba(c, c, c);
    }

    try {
        RgbaOutputFile file ("stripes.exr", width, height, WRITE_RGBA);
        file.setFrameBuffer (&pixels[0][0], 1, width);
        file.writePixels (height);
    } catch (const std::exception &e) {
        std::cerr << "error writing image file stripes.exr:" << e.what() << std::endl;
        return 1;
    }
    return 0;
}

This creates an image 100 pixels wide and 50 pixels high with horizontal stripes 5 pixels high of graduated intensity, bright on the bottom of the image and dark towards the top. Note that pixel[0][0] is in the upper left:

The CMakeLists.txt to build:

cmake_minimum_required(VERSION 3.12)
project(exrwriter)
find_package(OpenEXR REQUIRED)

add_executable(${PROJECT_NAME} exrwriter.cpp)
target_link_libraries(${PROJECT_NAME} OpenEXR::OpenEXR)

To build:

$ cmake -S . -B _build -DCMAKE_PREFIX_PATH=<path to OpenEXR libraries/includes>
$ cmake --build _build

For more details, see The OpenEXR API.

Community

Ask a question:
- Email: openexr-dev@lists.aswf.io
- Slack: academysoftwarefdn#openexr
Attend a meeting:
- Technical Steering Committee meetings are open to the public, fortnightly on Thursdays, 1:30pm Pacific Time.
- Calendar: https://zoom-lfx.platform.linuxfoundation.org/meetings/openexr
- Meeting Notes: https://wiki.aswf.io/display/OEXR/TSC+Meetings
Report a bug:
- Submit an Issue: https://github.com/AcademySoftwareFoundation/openexr/issues
Report a security vulnerability:
- File a GitHub security advisory. Email security@openexr.com for private/secure discussion with the project maintainers.
Contribute a Fix, Feature, or Improvement:
- Read the Contribution Guidelines and Code of Conduct
- Sign the Contributor License Agreement
- Submit a Pull Request: https://github.com/AcademySoftwareFoundation/openexr/pulls
- If you'd like to contribute and could use some ideas of what to do, browse "good first issues" here or on Clotributor.

Resources

Website: http://www.openexr.com
Technical documentation: https://openexr.readthedocs.io
Porting help: OpenEXR/Imath Version 2.x to 3.x Porting Guide
Reference images: https://github.com/AcademySoftwareFoundation/openexr-images
Security policy: SECURITY.md
Release notes: CHANGES.md
Contributors: CONTRIBUTORS.md

License

OpenEXR is licensed under the BSD-3-Clause license.

jqlang/jq

Command-line JSON processor

jq

jq is a lightweight and flexible command-line JSON processor akin to sed,awk,grep, and friends for JSON data. It's written in portable C and has zero runtime dependencies, allowing you to easily slice, filter, map, and transform structured data.

Documentation

Official Documentation: jqlang.org
Try jq Online: play.jqlang.org

Installation

Prebuilt Binaries

Download the latest releases from the GitHub release page.

Docker Image

Pull the jq image to start quickly with Docker.

Run with Docker

Example: Extracting the version from a `package.json` file

docker run --rm -i ghcr.io/jqlang/jq:latest < package.json '.version'

Example: Extracting the version from a `package.json` file with a mounted volume

docker run --rm -i -v "$PWD:$PWD" -w "$PWD" ghcr.io/jqlang/jq:latest '.version' package.json

Building from source

Dependencies

libtool
make
automake
autoconf

Instructions

git submodule update --init    # if building from git to get oniguruma
autoreconf -i                  # if building from git
./configure --with-oniguruma=builtin
make clean                     # if upgrading from a version previously built from source
make -j8
make check
sudo make install

Build a statically linked version:

make LDFLAGS=-all-static

If you're not using the latest git version but instead building a released tarball (available on the release page), skip the autoreconf step, and flex or bison won't be needed.

Cross-Compilation

For details on cross-compilation, check out the GitHub Actions file and the cross-compilation wiki page.

Community & Support

Questions & Help: Stack Overflow (jq tag)
Chat & Community: Join us on Discord
Wiki & Advanced Topics: Explore the Wiki

License

jq is released under the MIT License. jq's documentation is licensed under the Creative Commons CC BY 3.0. jq uses parts of the open source C library "decNumber", which is distributed under ICU License

tmux/tmux

tmux source code

Welcome to tmux!

tmux is a terminal multiplexer: it enables a number of terminals to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached.

This release runs on OpenBSD, FreeBSD, NetBSD, Linux, macOS and Solaris.

Dependencies

tmux depends on libevent 2.x, available from this page.

It also depends on ncurses, available from this page.

To build tmux, a C compiler (for example gcc or clang), make, pkg-config and a suitable yacc (yacc or bison) are needed.

Installation

Binary packages

Some platforms provide binary packages for tmux, although these are sometimes out of date. Examples are listed on this page.

From release tarball

To build and install tmux from a release tarball, use:

./configure && make
sudo make install

tmux can use the utempter library to update utmp(5), if it is installed - run configure with --enable-utempter to enable this.

For more detailed instructions on building and installing tmux, see this page.

From version control

To get and build the latest from version control - note that this requires autoconf, automake and pkg-config:

git clone https://github.com/tmux/tmux.git
cd tmux
sh autogen.sh
./configure && make

Contributing

Bug reports, feature suggestions and especially code contributions are most welcome. Please send by email to:

tmux-users@googlegroups.com

Or open a GitHub issue or pull request. Please read this document before opening an issue.

There is a list of suggestions for contributions. Please feel free to ask on the mailing list if you're thinking of working on something or need further information.

Documentation

For documentation on using tmux, see the tmux.1 manpage. View it from the source tree with:

nroff -mdoc tmux.1|less

A small example configuration is in example_tmux.conf.

And a bash(1) completion file at:

https://github.com/scop/bash-completion/blob/main/completions-core/tmux.bash

For debugging, run tmux with -v or -vv to generate server and client log files in the current directory.

Support

The tmux mailing list for general discussion and bug reports is:

https://groups.google.com/forum/#!forum/tmux-users

Subscribe by sending an email to:

tmux-users+subscribe@googlegroups.com

OISF/suricata

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine developed by the OISF and the Suricata community.

Suricata

Introduction

Suricata is a network IDS, IPS and NSM engine developed by the OISF and the Suricata community.

Resources

Contributing

We're happily taking patches and other contributions. Please see our Contribution Process for how to get started.

Suricata is a complex piece of software dealing with mostly untrusted input. Mishandling this input will have serious consequences:

in IPS mode a crash may knock a network offline
in passive mode a compromise of the IDS may lead to loss of critical and confidential data
missed detection may lead to undetected compromise of the network

In other words, we think the stakes are pretty high, especially since in many common cases the IDS/IPS will be directly reachable by an attacker.

For this reason, we have developed a QA process that is quite extensive. A consequence is that contributing to Suricata can be a somewhat lengthy process.

On a high level, the steps are:

GitHub-CI based checks. This runs automatically when a pull request is made.
Review by devs from the team and community
QA runs from private QA setups. These are private due to the nature of the test traffic.

Overview of Suricata's QA steps

OISF team members are able to submit builds to our private QA setup. It will run a series of build tests and a regression suite to confirm no existing features break.

The final QA runs takes a few hours minimally, and generally runs overnight. It currently runs:

extensive build tests on different OS', compilers, optimization levels, configure features
static code analysis using cppcheck, scan-build
runtime code analysis using valgrind, AddressSanitizer, LeakSanitizer
regression tests for past bugs
output validation of logging
unix socket testing
pcap based fuzz testing using ASAN and LSAN
traffic replay based IDS and IPS tests

Next to these tests, based on the type of code change further tests can be run manually:

traffic replay testing (multi-gigabit)
large pcap collection processing (multi-terabytes)
fuzz testing (might take multiple days or even weeks)
pcap based performance testing
live performance testing
various other manual tests based on evaluation of the proposed changes

It's important to realize that almost all of the tests above are used as acceptance tests. If something fails, it's up to you to address this in your code.

One step of the QA is currently run post-merge. We submit builds to the Coverity Scan program. Due to limitations of this (free) service, we can submit once a day max. Of course it can happen that after the merge the community will find issues. For both cases we request you to help address the issues as they may come up.

FAQ

Q: Will you accept my PR?

A: That depends on a number of things, including the code quality. With new features it also depends on whether the team and/or the community think the feature is useful, how much it affects other code and features, the risk of performance regressions, etc.

Q: When will my PR be merged?

A: It depends, if it's a major feature or considered a high risk change, it will probably go into the next major version.

Q: Why was my PR closed?

A: As documented in the Suricata GitHub workflow, we expect a new pull request for every change.

Normally, the team (or community) will give feedback on a pull request after which it is expected to be replaced by an improved PR. So look at the comments. If you disagree with the comments we can still discuss them in the closed PR.

If the PR was closed without comments it's likely due to QA failure. If the GitHub-CI checks failed, the PR should be fixed right away. No need for a discussion about it, unless you believe the QA failure is incorrect.

Q: The compiler/code analyser/tool is wrong, what now?

A: To assist in the automation of the QA, we're not accepting warnings or errors to stay. In some cases this could mean that we add a suppression if the tool supports that (e.g. valgrind, DrMemory). Some warnings can be disabled. In some exceptional cases the only 'solution' is to refactor the code to work around a static code checker limitation false positive. While frustrating, we prefer this over leaving warnings in the output. Warnings tend to get ignored and then increase risk of hiding other warnings.

Q: I think your QA test is wrong

A: If you really think it is, we can discuss how to improve it. But don't come to this conclusion too quickly, more often it's the code that turns out to be wrong.

Q: Do you require signing of a contributor license agreement?

A: Yes, we do this to keep the ownership of Suricata in one hand: the Open Information Security Foundation. See http://suricata.io/about/open-source/ and http://suricata.io/about/contribution-agreement/

nrfconnect/sdk-nrf

nRF Connect SDK main repository

nRF Connect SDK: sdk-nrf ########################

.. contents:: :local: :depth: 2

This repository contains the core of nRF Connect SDK, including subsystems, libraries, samples, and applications. It is also the SDK's west manifest repository, containing the nRF Connect SDK manifest (west.yml).

Documentation

Official latest documentation at https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/index.html

For earlier versions, open the latest version and use the drop-down under the title header.

taosdata/TDengine

High-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios

English | 简体中文 | TDengine Cloud | Learn more about TSDB

1. Introduction

TDengine is an open source, high-performance, cloud native and AI powered time-series database designed for Internet of Things (IoT), Connected Cars, and Industrial IoT. It enables efficient, real-time data ingestion, processing, and analysis of TB and even PB scale data per day, generated by billions of sensors and data collectors. TDengine differentiates itself from other time-series databases with the following advantages:

High Performance: TDengine is the only time-series database to solve the high cardinality issue to support billions of data collection points while out performing other time-series databases for data ingestion, querying and data compression.
Simplified Solution: Through built-in caching, stream processing, data subscription and AI agent features, TDengine provides a simplified solution for time-series data processing. It reduces system design complexity and operation costs significantly.
Cloud Native: Through native distributed design, sharding and partitioning, separation of compute and storage, RAFT, support for kubernetes deployment and full observability, TDengine is a cloud native Time-Series Database and can be deployed on public, private or hybrid clouds.
AI Powered: Through the built in AI agent TDgpt, TDengine can connect to a variety of time series foundation model, large language model, machine learning and traditional algorithms to provide time series data forecasting, anomaly detection, imputation and classification.
Ease of Use: For administrators, TDengine significantly reduces the effort to deploy and maintain. For developers, it provides a simple interface, simplified solution and seamless integrations for third party tools. For data users, it gives easy data access.
Easy Data Analytics: Through super tables, storage and compute separation, data partitioning by time interval, pre-computation and AI agent, TDengine makes it easy to explore, format, and get access to data in a highly efficient way.
Open Source: TDengine’s core modules, including cluster feature and AI agent, are all available under open source licenses. It has gathered 23.7k stars on GitHub. There is an active developer community, and over 730k running instances worldwide.

For a full list of TDengine competitive advantages, please check here. The easiest way to experience TDengine is through TDengine Cloud. For the latest TDengine component TDgpt, please refer to TDgpt README for details.

2. Documentation

For user manual, system design and architecture, please refer to TDengine Documentation (TDengine 文档)

You can choose to install TDengine via container, installation package, Kubernetes or try fully managed service without installation. This quick guide is for developers who want to contribute, build, release and test TDengine by themselves.

For contributing/building/testing TDengine Connectors, please check the following repositories: JDBC Connector, Go Connector, Python Connector, Node.js Connector, C# Connector, Rust Connector.

3. Prerequisites

At the moment, TDengine server supports running on Linux/MacOS systems. Any application can also choose the RESTful interface provided by taosAdapter to connect the taosd service. TDengine supports X64/ARM64 CPU, and it will support MIPS64, Alpha64, ARM32, RISC-V and other CPU architectures in the future. Right now we don't support build with cross-compiling environment.

Starting from version 3.1.0.0, TDengine supports the Windows system exclusively in its TSDB-Enterprise edition.

If you want to compile taosAdapter or taosKeeper, you need to install Go 1.23 or above.

3.1 Prerequisites on Linux

Install required tools on Linux

3.1.1 For Ubuntu

Verified on Ubuntu 18.04, 20.04, 22.04.

sudo apt-get update
sudo apt-get install -y gcc cmake build-essential git libjansson-dev \
  libsnappy-dev liblzma-dev zlib1g-dev pkg-config libtool autoconf automake groff

3.1.2 For CentOS

Verified on CentOS 8.

sudo yum update
yum install -y epel-release gcc gcc-c++ make cmake git perl dnf-plugins-core autoconf automake libtool groff
yum config-manager --set-enabled powertools
yum install -y zlib-static xz-devel snappy-devel jansson-devel pkgconfig libatomic-static libstdc++-static

3.2 Prerequisites on macOS

Install required tools on macOS

Please install the dependencies with brew.

brew install argp-standalone gflags pkgconfig

3.3 Prerequisites on Windows

Not available for TDengine TSDB-OSS.

3.4 Clone the repo

Clone the repository to the target machine:

git clone https://github.com/taosdata/TDengine.git
cd TDengine

4. Building

TDengine provide a few useful tools such as taosBenchmark (was named taosdemo) and taosdump. They were part of TDengine. By default, TDengine compiling does not include taosTools. You can use cmake .. -DBUILD_TOOLS=true to make them be compiled with TDengine.

TDengine requires GCC 9.3.1 or higher and CMake 3.18.0 or higher for building.

4.1 Build on Linux

Detailed steps to build on Linux

You can run the bash script build.sh to build both TDengine and taosTools including taosBenchmark and taosdump as below:

./build.sh

It equals to execute following commands:

mkdir debug && cd debug
cmake .. -DBUILD_TOOLS=true -DBUILD_CONTRIB=true
make

If you want to compile taosAdapter, you need to add the -DBUILD_HTTP=false option.

If you want to compile taosKeeper, you need to add the -DBUILD_KEEPER=true option.

You can use Jemalloc as memory allocator instead of glibc:

cmake .. -DJEMALLOC_ENABLED=ON

TDengine build script can auto-detect the host machine's architecture on x86, x86-64, arm64 platform. You can also specify architecture manually by CPUTYPE option:

cmake .. -DCPUTYPE=aarch64 && cmake --build .

4.2 Build on macOS

Detailed steps to build on macOS

Please install XCode command line tools and cmake. Verified with XCode 11.4+ on Catalina and Big Sur.

mkdir debug && cd debug
cmake .. && cmake --build .

If you want to compile taosAdapter, you need to add the -DBUILD_HTTP=false option.

If you want to compile taosKeeper, you need to add the -DBUILD_KEEPER=true option.

4.3 Build on Windows

Not available for TDengine TSDB-OSS.

5. Packaging

The TDengine TSDB-OSS installer can NOT be created by this repository only, due to some component dependencies. We are still working on this improvement.

6. Installation

6.1 Install on Linux

Detailed steps to install on Linux

After building successfully, TDengine can be installed by:

sudo make install

Installing from source code will also configure service management for TDengine. Users can also choose to install from packages for it.

6.2 Install on macOS

Detailed steps to install on macOS

After building successfully, TDengine can be installed by:

sudo make install

6.3 Install on Windows

Not available for TDengine TSDB-OSS.

7. Running

7.1 Run TDengine on Linux

Detailed steps to run on Linux

To start the service after installation on linux, in a terminal, use:

sudo systemctl start taosd

Then users can use the TDengine CLI to connect the TDengine server. In a terminal, use:

taos

If TDengine CLI connects the server successfully, welcome messages and version info are printed. Otherwise, an error message is shown.

If you don't want to run TDengine as a service, you can run it in current shell. For example, to quickly start a TDengine server after building, run the command below in terminal: (We take Linux as an example, command on Windows will be taosd.exe)

./build/bin/taosd -c test/cfg

In another terminal, use the TDengine CLI to connect the server:

./build/bin/taos -c test/cfg

Option -c test/cfg specifies the system configuration file directory.

7.2 Run TDengine on macOS

Detailed steps to run on macOS

To start the service after installation on macOS, double-click the /applications/TDengine to start the program, or in a terminal, use:

sudo launchctl start com.tdengine.taosd

Then users can use the TDengine CLI to connect the TDengine server. In a terminal, use:

taos

If TDengine CLI connects the server successfully, welcome messages and version info are printed. Otherwise, an error message is shown.

7.3 Run TDengine on Windows

Not available for TDengine TSDB-OSS.

8. Testing

For how to run different types of tests on TDengine, please see Testing TDengine.

9. Releasing

For the complete list of TDengine Releases, please see Releases.

10. Workflow

TDengine build check workflow can be found in this Github Action. More workflows will be available soon.

11. Coverage

Latest TDengine test coverage report can be found on coveralls.io

How to run the coverage report locally?

To create the test coverage report (in HTML format) locally, please run following commands:

cd tests
bash setup-lcov.sh -v 1.16 && ./run_local_coverage.sh -b main -c task 
# on main branch and run cases in longtimeruning_cases.task 
# for more information about options please refer to ./run_local_coverage.sh -h

NOTE: Please note that the -b and -i options will recompile TDengine with the -DCOVER=true option, which may take a amount of time.

12. Contributing

Please follow the contribution guidelines to contribute to TDengine.

lz4/lz4

Extremely Fast Compression algorithm

LZ4 - Extremely fast compression

LZ4 is lossless compression algorithm, providing compression speed > 500 MB/s per core, scalable with multi-cores CPU. It features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems.

Speed can be tuned dynamically, selecting an "acceleration" factor which trades compression ratio for faster speed. On the other end, a high compression derivative, LZ4_HC, is also provided, trading CPU time for improved compression ratio. All versions feature the same decompression speed.

LZ4 is also compatible with dictionary compression, both at API and CLI levels. It can ingest any input file as dictionary, though only the final 64KB are used. This capability can be combined with the Zstandard Dictionary Builder, in order to drastically improve compression performance on small files.

LZ4 library is provided as open-source software using BSD 2-Clause license.

Benchmarks

The benchmark uses lzbench, from @inikep compiled with GCC v8.2.0 on Linux 64-bits (Ubuntu 4.18.0-17). The reference system uses a Core i7-9700K CPU @ 4.9GHz (w/ turbo boost). Benchmark evaluates the compression of reference Silesia Corpus in single-thread mode.

Compressor	Factor	Compression	Decompression
memcpy	1.000	13700 MB/s	13700 MB/s
LZ4 default (v1.9.0)	2.101	780 MB/s	4970 MB/s
LZO 2.09	2.108	670 MB/s	860 MB/s
QuickLZ 1.5.0	2.238	575 MB/s	780 MB/s
Snappy 1.1.4	2.091	565 MB/s	1950 MB/s
Zstandard 1.4.0 -1	2.883	515 MB/s	1380 MB/s
LZF v3.6	2.073	415 MB/s	910 MB/s
zlib deflate 1.2.11 -1	2.730	100 MB/s	415 MB/s
LZ4 HC -9 (v1.9.0)	2.721	41 MB/s	4900 MB/s
zlib deflate 1.2.11 -6	3.099	36 MB/s	445 MB/s

Installation

make
make install     # this command may require root permissions

LZ4's Makefile supports standard Makefile conventions, including staged installs, redirection, or command redefinition. It is compatible with parallel builds (-j#).

Building LZ4 - Using vcpkg

You can download and install LZ4 using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg.exe install lz4

The LZ4 port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Documentation

The raw LZ4 block compression format is detailed within lz4_Block_format.

Arbitrarily long files or data streams are compressed using multiple blocks, for streaming requirements. These blocks are organized into a frame, defined into lz4_Frame_format. Interoperable versions of LZ4 must also respect the frame format.

Other source versions

Beyond the C reference source, many contributors have created versions of lz4 in multiple languages (Java, C#, Python, Perl, Ruby, etc.). A list of known source ports is maintained on the LZ4 Homepage.

Packaging status

Most distributions are bundled with a package manager which allows easy installation of both the liblz4 library and the lz4 command line interface.

Special Thanks

Takayuki Matsuoka, aka @t-mat, for exceptional first-class support throughout the lifetime of this project

php/php-src

The PHP Interpreter

PHP is a popular general-purpose scripting language that is especially suited to web development. Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.

PHP is distributed under the Modified BSD License (SPDX-License-Identifier: BSD-3-Clause).

Documentation

The PHP manual is available at php.net/docs.

Installation

Prebuilt packages and binaries

Prebuilt packages and binaries can be used to get up and running fast with PHP.

For Windows, the PHP binaries can be obtained from windows.php.net. After extracting the archive the *.exe files are ready to use.

For other systems, see the installation chapter.

Building PHP source code

For Windows, see Build your own PHP on Windows.

For a minimal PHP build from Git, you will need autoconf, bison, and re2c. For a default build, you will additionally need libxml2 and libsqlite3.

On Ubuntu, you can install these using:

sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev

On Fedora, you can install these using:

sudo dnf install re2c bison autoconf make ccache libxml2-devel sqlite-devel

On MacOS, you can install these using brew:

brew install autoconf bison re2c libiconv libxml2 sqlite

or with MacPorts:

sudo port install autoconf bison re2c libiconv libxml2 sqlite3

Generate configure:

./buildconf

Configure your build. --enable-debug is recommended for development, see ./configure --help for a full list of options.

# For development
./configure --enable-debug
# For production
./configure

Build PHP. To speed up the build, specify the maximum number of jobs using the -j argument:

make -j4

The number of jobs should usually match the number of available cores, which can be determined using nproc.

Testing PHP source code

PHP ships with an extensive test suite, the command make test is used after successful compilation of the sources to run this test suite.

It is possible to run tests using multiple cores by setting -jN in TEST_PHP_ARGS or TESTS:

make TEST_PHP_ARGS=-j4 test

Shall run make test with a maximum of 4 concurrent jobs: Generally the maximum number of jobs should not exceed the number of cores available.

Use the TEST_PHP_ARGS or TESTS variable to test only specific directories:

make TESTS=tests/lang/ test

The qa.php.net site provides more detailed info about testing and quality assurance.

Installing PHP built from source

After a successful build (and test), PHP may be installed with:

make install

Depending on your permissions and prefix, make install may need superuser permissions.

PHP extensions

Extensions provide additional functionality on top of PHP. PHP consists of many essential bundled extensions. Additional extensions can be found in the PHP Extension Community Library - PECL.

Contributing

The PHP source code is located in the Git repository at github.com/php/php-src. Contributions are most welcome by forking the repository and sending a pull request.

Discussions are done on GitHub, but depending on the topic can also be relayed to the official PHP developer mailing list internals@lists.php.net.

New features require an RFC and must be accepted by the developers. See Request for comments - RFC and Voting on PHP features for more information on the process.

Bug fixes don't require an RFC. If the bug has a GitHub issue, reference it in the commit message using GH-NNNNNN. Use #NNNNNN for tickets in the old bugs.php.net bug tracker.

Fix GH-7815: php_uname doesn't recognise latest Windows versions
Fix #55371: get_magic_quotes_gpc() throws deprecation warning

See Git workflow for details on how pull requests are merged.

Guidelines for contributors

See further documents in the repository for more information on how to contribute:

Credits

For the list of people who've put work into PHP, please see the PHP credits page.

HarbourMasters/Starship

SF64 PC Port

Starship

Lead Developers:

Discord

Official Discord: https://discord.com/invite/shipofharkinian

If you're having any trouble after reading through this README, feel free ask for help in the Starship Support text channels. Please keep in mind that we do not condone piracy.

Quick Start

Starship does not include any copyrighted assets. You are required to provide a supported copy of the game.

1. Verify your ROM dump

The supported ROMs are US 1.0 and US 1.1 Rev A versions. You can verify you have dumped a supported copy of the game by using the SHA-1 File Checksum Online at https://www.romhacking.net/hash/.

The SHA-1 hash for a US 1.0 ROM is D8B1088520F7C5F81433292A9258C1184AFA1457.
The SHA-1 hash for a US 1.1 ROM is 09F0D105F476B00EFA5303A3EBC42E60A7753B7A.

Starship also supports voice language replacement use from both EU (Lylat) and JP (Japanese) when used in conjunction with an US ROM.

Note: JP and EU versions of the game are not supported for the base asset O2R creation, a US ROM must be used for it, and you can only use one voice language replacement at a time (Either EU or JP).

2. Verify your ROM is in .z64 format

Your ROM needs to be in .z64 format. If it's in .n64 format, use the following to convert it to a .z64: https://hack64.net/tools/swapper.php

2. Download Starship from Releases

3. Generating the OTR from the ROM and Play!

Windows

Extract every file from the zip into a folder of your choosing.
Run starship.exe and select your US 1.0 or US 1.1 ROM.

Linux

Extract every file from the zip into a folder of your choosing.
Execute starship.appimage. You may have to chmod +x the appimage via terminal.

MacOS

Extract every file from the zip into a folder of your choosing.
Run starship and select your US 1.0 or US 1.1 ROM.

Nintendo Switch

Run one of the PC releases to generate an sf64.o2r file. After launching the game on PC, you will be able to find these files in the same directory as starship.exe or starship.appimage.
Copy the files to your sd card

Configuration

Default keyboard configuration

N64	A	B	Z	Start	Analog stick	C buttons	D-Pad
Keyboard	X	C	Z	Space	WASD	Arrow keys	TFGH

Other shortcuts

Keys	Action
F1	Toggle menubar
F4	Reset
F11	Fullscreen
Tab	Toggle Alternate assets

Graphics Backends

Currently, there are three rendering APIs supported: DirectX11 (Windows), OpenGL (all platforms), and Metal (macOS). You can change which API to use in the Settings menu of the menubar, which requires a restart. If you're having an issue with crashing, you can change the API in the starship.cfg.json file by finding the line "Backend":{... and changing the id value to 3 and set the Name to OpenGL. DirectX 11 with id 2 is the default on Windows. Metal with id 4 is the default on macOS.

Custom Assets

Custom assets are packed in .o2r or .otr files. To use custom assets, place them in the mods folder.

If you're interested in creating and/or packing your own custom asset .o2r/.otr files, check out the following tools:

Development

Building

If you want to manually compile Starship, please consult the building instructions.

Playtesting

Special Thanks:

ZeldaRET : for teaching me the fundamental knowledge of N64 decompilation.
Decompals : for helping in the initial disassembly and decompilation of the game.
HM64 Team : for creating Libultraship and helping with various issues.
DarioSamo : for providing important fixes to the renderer and information about the inner workings of the game graphics system.
garrettjoecox : for contributing with interpolation fixes to this port.
inspectredc : for contributing to the SF64 decompilation project.
Lywx : for co-developing this port as a lead and creating Torch asset extraction system.
m4xw : for helping with audio issues in this port.
Malkierian : for contributing with important fixes to this port.
petrie911 : for contributing to the SF64 decompilation project as a lead.
Ryan-Myers : for contributing to the SF64 decompilation project.
Thar0 : for contributing with an improved Starfield that can be interpolated to any framerate.
TheBoy181 : for contributing to this project with various widescreen enhancements such as level floors, an extended Starfield among other things.
Wiseguy : for providing important information about the inner workings of the N64 platform, as well as helping with the decompilation process.

openssl/openssl

General purpose TLS and crypto library

Welcome to the OpenSSL Project

OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit for the Transport Layer Security (TLS, formerly SSL), Datagram TLS (DTLS), and QUIC protocols.

The protocol implementations are based on a full-strength general purpose cryptographic library, which can also be used stand-alone. Also included is a cryptographic module validated to conform with FIPS standards.

OpenSSL is descended from the SSLeay library developed by Eric A. Young and Tim J. Hudson.

The official Home Page of the OpenSSL Project is www.openssl.org.

Overview

The OpenSSL toolkit includes:

libssl an implementation of all TLS protocol versions up to TLSv1.3 (RFC 8446), DTLS protocol versions up to DTLSv1.2 (RFC 6347) and the QUIC version 1 protocol (RFC 9000).
libcrypto a full-strength general purpose cryptographic library. It constitutes the basis of the TLS implementation, but can also be used independently.
openssl the OpenSSL command line tool, a swiss army knife for cryptographic tasks, testing and analyzing. It can be used for
- creation of key parameters
- creation of X.509 certificates, CSRs and CRLs
- calculation of message digests
- encryption and decryption
- SSL/TLS/DTLS and client and server tests
- QUIC client tests
- handling of S/MIME signed or encrypted mail
- and more...

Download

For Production Use

Source code tarballs of the official releases can be downloaded from openssl-library.org/source/. The OpenSSL project does not distribute the toolkit in binary form.

However, for a large variety of operating systems precompiled versions of the OpenSSL toolkit are available. In particular, on Linux and other Unix operating systems, it is normally recommended to link against the precompiled shared libraries provided by the distributor or vendor.

We also maintain a list of third parties that produce OpenSSL binaries for various Operating Systems (including Windows) on the Binaries page on our wiki.

For Testing and Development

Although testing and development could in theory also be done using the source tarballs, having a local copy of the git repository with the entire project history gives you much more insight into the code base.

The main OpenSSL Git repository is private. There is a public GitHub mirror of it at github.com/openssl/openssl, which is updated automatically from the former on every commit.

A local copy of the Git repository can be obtained by cloning it from the GitHub mirror using

git clone https://github.com/openssl/openssl.git

If you intend to contribute to OpenSSL, either to fix bugs or contribute new features, you need to fork the GitHub mirror and clone your public fork instead.

git clone https://github.com/yourname/openssl.git

This is necessary because all development of OpenSSL nowadays is done via GitHub pull requests. For more details, see Contributing.

Build and Install

After obtaining the Source, have a look at the INSTALL file for detailed instructions about building and installing OpenSSL. For some platforms, the installation instructions are amended by a platform specific document.

Specific notes on upgrading to OpenSSL 3.x from previous versions can be found in the ossl-guide-migration(7ossl) manual page.

Documentation

README Files

There are some README.md files in the top level of the source distribution containing additional information on specific topics.

The OpenSSL Guide

There are some tutorial and introductory pages on some important OpenSSL topics within the OpenSSL Guide.

Manual Pages

The manual pages for the master branch and all current stable releases are available online.

Demos

There are numerous source code demos for using various OpenSSL capabilities in the demos subfolder.

Wiki

There is a GitHub Wiki which is currently not very active.

License

OpenSSL is licensed under the Apache License 2.0, which means that you are free to get and use it for commercial and non-commercial purposes as long as you fulfill its conditions.

See the LICENSE.txt file for more details.

Support

There are various ways to get in touch. The correct channel depends on your requirement. See the SUPPORT file for more details.

Contributing

If you are interested and willing to contribute to the OpenSSL project, please take a look at the CONTRIBUTING file.

Legalities

A number of nations restrict the use or export of cryptography. If you are potentially subject to such restrictions, you should seek legal advice before attempting to develop or distribute cryptographic code.

Copyright

Zelda64Recomp/Zelda64Recomp

Static recompilation of Majora's Mask (and soon Ocarina of Time) for PC (Windows/Linux/Mac)

Zelda 64: Recompiled

Zelda 64: Recompiled is a project that uses N64: Recompiled to statically recompile Majora's Mask (and soon Ocarina of Time) into a native port with many new features, enhancements, and extensive mod support. This project uses RT64 as the rendering engine to provide graphical enhancements.

Check out the latest release here.

Join the N64: Recompiled Community Discord to discuss this and other N64: Recompiled projects!

This repository and its releases do not contain game assets. The original game is required to build or run this project.

Special thanks to Blaze for their support of this project. They provide high-performance Linux (AMD64 & ARM64) and Apple Silicon macOS runners for GitHub Actions, greatly reducing our automated build times.

System Requirements

A GPU supporting Direct3D 12.0 (Shader Model 6), Vulkan 1.2, or Metal Argument Buffers Tier 2 support is required to run this project. The oldest GPUs that should be supported for each vendor are:

GeForce GT 630
Radeon HD 7750 (the one from 2012, not to be confused with the RX 7000 series) and newer
Intel HD 510 (Skylake)
A Mac with Apple Silicon or an Intel 7th Gen CPU with MacOS 13.0+

On x86-64 PCs, a CPU supporting the SSE4.1 instruction set is also required (Intel Core 2 Penryn series or AMD Bulldozer and newer). ARM64 builds will work on any ARM64 CPU.

If you have issues with crashes on startup, make sure your graphics drivers are fully up to date.

Features

Plug and Play

Simply provide your copy of the North American version of the game in the main menu and start playing! This project will automatically load assets from the provided copy, so there is no need to go through a separate extraction step or build the game yourself. Other versions of the game may be supported in the future.

Fully Intact N64 Effects

A lot of care was put into RT64 to make sure all graphical effects were rendered exactly as they did originally on the N64. No workarounds or "hacks" were made to replicate these effects, with the only modifications to them being made for enhancement purposes such as widescreen support. This includes framebuffer effects like the grayscale cutscenes and the Deku bubble projectile, depth effects like the lens of truth, decals such as shadows or impact textures, accurate lighting, shading effects like the fire arrows and bomb explosions, and various textures that are often rendered incorrectly.

Easy-to-Use Menus

Gameplay settings, graphics settings, input mappings, and audio settings can all be configured with the in-game config menu. The menus can all be used with mouse, controller, or keyboard for maximum convenience.

High Framerate Support

Play at any framerate you want thanks to functionality provided by RT64! Game objects and terrain, texture scrolling, screen effects, and most HUD elements are all rendered at high framerates. By default, this project is configured to run at your monitor's refresh rate. You can also play at the original framerate of the game if you prefer. Changing framerate has no effect on gameplay.

Note: External framerate limiters (such as the NVIDIA Control Panel) are known to potentially cause problems, so if you notice any stuttering then turn them off and use the manual framerate slider in the in-game graphics menu instead.

Widescreen and Ultrawide Support

Any aspect ratio is supported, with most effects modded to work correctly in widescreen. The HUD can also be positioned at 16:9 when using ultrawide aspect ratios if preferred.

Note: Some animation quirks can be seen at the edges of the screen in certain cutscenes when using very wide aspect ratios.

Mod Support

Install community made mods and texture packs! Mods can change any part of the game, including adding completely new features and content. You can install mods by simply dragging the mod files onto the game window before starting the game or by clicking the Install Mods button in the mod menu. Mods can be toggled in the mod menu, and some mods can be configured there as well.

Many mods are available on the project's Thunderstore page: https://thunderstore.io/c/zelda-64-recompiled/. The Thunderstore mod manager/r2modman is not required or supported, so be sure to click the "Manual Download" button when downloading a mod instead of the "Install with Mod Manager" button.

If you're interested in making mods for this project, check out the mod template and the modding documentation. If you're interested in making texture packs, check out the RT64 documentation.

Dual Analog Camera

Play with a dual analog control layout like later entries in the series! When this option is enabled, the right stick will control the camera. You can still have the C-Buttons mapped to the right stick if you so wish, so long as you also map them to other buttons on the controller. The right stick C-button inputs will be "silenced", except when you take out the ocarina, so you can still play the ocarina with the right stick.

Gyro Aim

When playing with a supported controller, first-person items such as the bow can be aimed with your controller's gyro sensor. This includes (but is not limited to) controllers such as the Dualshock 4, Dualsense, Switch Pro, and most third party Switch controllers (such as the 8BitDo Pro 2 in Switch mode).

Note: Gamepad mappers such as BetterJoy or DS4Windows may intercept gyro data and prevent the game from receiving it. Most controllers are natively supported, so turning gamepad mappers off is recommended if you want to use gyro.

Additional Control Options

Customize your experience by setting your stick deadzone to your liking, as well as adjusting the X and Y axis inversion for both aiming and the optional dual analog camera.

Autosaving

Never worry about losing progress if your power goes out thanks to autosaving! The autosave system is designed to respect Majora's Mask's original save system and maintain the intention of owl saves by triggering automatically and replacing the previous autosave or owl save. However, if you'd still rather play with the untouched save system, simply turn off autosaving in the ingame menu.

Low Input Lag

This project has been optimized to have as little input lag as possible, making the game feel more responsive than ever!

Instant Load Times

Saving and loading files, going from place to place, and pausing all happen in the blink of an eye thanks to the game running natively on modern hardware.

Linux and Steam Deck Support

A Linux binary as well as a Flatpak is available for playing on most up-to-date distros, including on the Steam Deck.

To play on Steam Deck, extract the Linux build onto your deck. Then, in desktop mode, right click the Zelda64Recompiled executable file and select "Add to Steam". From there, you can return to Gaming mode and configure the controls as needed. See the Steam Deck gyro aim FAQ section for more detailed instructions.

Planned Features

Ocarina of Time support
Ray Tracing and Higher Quality Model Replacements (via RT64)
Multi-language support with support for loading custom translations

FAQ

What is static recompilation?

Static recompilation is the process of automatically translating an application from one platform to another. For more details, check out the full description of how this project's recompilation works here: N64: Recompiled.

How is this related to the decompilation project?

Unlike N64 ports in the past, this project is not based on the source code provided by a decompilation of the game. This is because static recompilation bypasses the need for decompiled source code when making a port, allowing ports to be made without source code. However, the reverse engineering work done by the decompilation team was invaluable for providing some of the enhancements featured in this project. For this reason, the project uses headers and some functions from the decompilation project in order to make modifications to the game. Many thanks to the decompilation team for all of the hard work they've done.

How do I set up gyro aiming on Steam Deck?

This project provides mouse aiming as a way to allow using gyro on Steam Deck, as the Steam Deck's gyro sensors cannot be read directly. First, launch the game in Gaming Mode, press the Steam button and go to "Controller Settings". Choose "Controller Settings" again in the menu that follows, and then set "Gyro Behavior" to "As Mouse".

You'll probably also want to change the default behavior so that you don't need to be touching the right stick to allow gyro input. To do so, click on the Gear icon to the right of "Gyro Behavior" and ensure that "Gyro Activation Buttons" is set to "None Selected (Gyro Always On)." If this isn't the case, then select that option and then press "Select None" in the following menu.

Where is the savefile stored?

Windows: %LOCALAPPDATA%\Zelda64Recompiled\saves
Linux: ~/.config/Zelda64Recompiled/saves
macOS: ~/Library/Application Support/Zelda64Recompiled/saves

How do I choose a different ROM?

You don't. This project is only a port of Majora's Mask (and Ocarina of Time in the future), and it will only accept one specific ROM: the US version of the N64 release of Majora's Mask. ROMs in formats other than .z64 will be automatically converted, as long as it is the correct ROM. It is not an emulator and it cannot run any arbitrary ROM.

Instead, you can change the game by installing mods. See the mod support section for details.

Does this project have a randomizer?

Yes, there is a randomizer available as a mod for this project which can be found at https://github.com/RecompRando/MMRecompRando/releases/latest. Simply download MMRecompRando.zip from the releases and install it like any other mod.

Can you run this project as a portable application?

Yes, if you place a file named portable.txt in the same folder as the executable then this project will run in portable mode. In portable mode, the save files, config files, and mods are placed in the same folder as the executable.

Known Issues

Overlays such as MSI Afterburner and other software such as Wallpaper Engine can cause performance issues with this project that prevent the game from rendering correctly. Disabling such software is recommended.

Building

Building is not required to play this project, as prebuilt binaries (which do not contain game assets) can be found in the Releases section. Instructions on how to build this project can be found in the BUILDING.md file.

Libraries Used and Projects Referenced

RT64 for the project's rendering engine
RmlUi for building the menus and launcher
lunasvg for SVG rendering, used by RmlUi
FreeType for font rendering, used by RmlUi
moodycamel::ConcurrentQueue for semaphores and fast, lock-free MPMC queues
Gamepad Motion Helpers for sensor fusion and calibration algorithms to implement gyro aiming
Majora's Mask Decompilation for headers and some function definitions, used for making patches or some enhancements
Ares emulator for RSP vector instruction reference implementations, used in RSP recompilation

portapack-mayhem/mayhem-firmware

The firmware for the HackRF+PortaPack H1/H2/H4/H4M

PortaPack Mayhem

This is a fork of the Havoc firmware, which itself was a fork of the PortaPack firmware, an add-on for the HackRF. A fork is a derivate, in this case one that has extra features and fixes when compared to the older versions.

What is this?

If you are new to HackRF+PortaPack+Mayhem, check these:

Frequently Asked Questions

This repository expands upon the previous work by many people and aims to constantly add new features, bugfixes and generate documentation to make further development easier. Collaboration is always welcomed and appreciated.

What to buy?

✔️ The fabulous H4M complete or upgrade, featuring numerous improvements and accessories. Sold by our friends at OpenSourceSDRLab. Join their giveaways on discord (check the badge on top). EU customers can purchase via Lab401.

✔️ A recommended one is this PortaPack H2, that includes everything you need with the plastic case "inspired" on this.

✔️ Some individuals lean towards the H2 with a metal enclosure, but its advantages remain debated. Share your insights on our wiki.

⚠️ Be cautious , ask the seller about compatibility with the latest releases. Look out for the description of the item, if they provide the firmware files for an older version or they have custom setup instructions, this means it might be NOT compatible, for example:

⚠️ If it looks too different, this might mean that they are using their own recipe, check the different models in our wiki. For example all the H3 and clones of that version use their own version of the firmware. They do not contribute the changes back and eventually you will be left with a device that nobody maintains:

Where is the latest version?

The current stable release is on the page. Follow the instructions you can find in the release description. The latest (nightly) release can be found here.

How can I collaborate

We warmly welcome your contributions! Please refer to our Contributing Guidelines for details.

You can write documentation, fix bugs and answer issues or add new functionality. Please also check the following guide with details.

Consider that the hardware and firmware has been created and maintain by a lot of people, so always try collaborating your time and effort first. For coding related questions, if something does not fit as an issue, please join our Discord by clicking the chat badge on top.

To support the people behind the hardware, please buy a genuine HackRF and PortaPack.

What if I really want something specific?

If what you need can be relevant in general, you can request a feature. Alternatively, go to our Discord by clicking the chat badge on top and discuss there.

What if I need help?

First, check the documentation. If you find a bug or you think the problem is related to the current repository, please open an issue.

You can reach the official community in Facebook, and our Discord by clicking the chat badge on top.

nginx/nginx

The official NGINX Open Source repository.

NGINX (pronounced "engine x" or "en-jin-eks") is the world's most popular Web Server, high performance Load Balancer, Reverse Proxy, API Gateway and Content Cache.

NGINX is free and open source software, distributed under the terms of a simplified 2-clause BSD-like license.

Enterprise distributions, commercial support and training are available from F5, Inc.

Important

The goal of this README is to provide a basic, structured introduction to NGINX for novice users. Please refer to the full NGINX documentation for detailed information on installing, building, configuring, debugging, and more. These documentation pages also contain a more detailed Beginners Guide, How-Tos, Development guide, and a complete module and directive reference.

How it works

NGINX is installed software with binary packages available for all major operating systems and Linux distributions. See Tested OS and Platforms for a full list of compatible systems.

Important

While nearly all popular Linux-based operating systems are distributed with a community version of nginx, we highly advise installation and usage of official packages or sources from this repository. Doing so ensures that you're using the most recent release or source code, including the latest feature-set, fixes and security patches.

Modules

NGINX is comprised of individual modules, each extending core functionality by providing additional, configurable features. See "Modules reference" at the bottom of nginx documentation for a complete list of official modules.

NGINX modules can be built and distributed as static or dynamic modules. Static modules are defined at build-time, compiled, and distributed in the resulting binaries. See Dynamic Modules for more information on how they work, as well as, how to obtain, install, and configure them.

Tip

You can issue the following command to see which static modules your NGINX binaries were built with:

nginx -V

See Configuring the build for information on how to include specific Static modules into your nginx build.

Configurations

NGINX is highly flexible and configurable. Provisioning the software is achieved via text-based config file(s) accepting parameters called "Directives". See Configuration File's Structure for a comprehensive description of how NGINX configuration files work.

Note

The set of directives available to your distribution of NGINX is dependent on which modules have been made available to it.

Runtime

Rather than running in a single, monolithic process, NGINX is architected to scale beyond Operating System process limitations by operating as a collection of processes. They include:

A "master" process that maintains worker processes, as well as, reads and evaluates configuration files.
One or more "worker" processes that process data (eg. HTTP requests).

The number of worker processes is defined in the configuration file and may be fixed for a given configuration or automatically adjusted to the number of available CPU cores. In most cases, the latter option optimally balances load across available system resources, as NGINX is designed to efficiently distribute work across all worker processes.

Tip

Processes synchronize data through shared memory. For this reason, many NGINX directives require the allocation of shared memory zones. As an example, when configuring rate limiting, connecting clients may need to be tracked in a common memory zone so all worker processes can know how many times a particular client has accessed the server in a span of time.

Downloading and installing

Follow these steps to download and install precompiled NGINX binaries. You may also choose to build NGINX locally from source code.

Stable and Mainline binaries

NGINX binaries are built and distributed in two versions: stable and mainline. Stable binaries are built from stable branches and only contain critical fixes backported from the mainline version. Mainline binaries are built from the master branch and contain the latest features and bugfixes. You'll need to decide which is appropriate for your purposes.

Linux binary installation process

The NGINX binary installation process takes advantage of package managers native to specific Linux distributions. For this reason, first-time installations involve adding the official NGINX package repository to your system's package manager. Follow these steps to download, verify, and install NGINX binaries using the package manager appropriate for your Linux distribution.

Upgrades

Future upgrades to the latest version can be managed using the same package manager without the need to manually download and verify binaries.

FreeBSD installation process

For more information on installing NGINX on FreeBSD system, visit https://nginx.org/en/docs/install.html

Windows executables

Windows executables for mainline and stable releases can be found on the main NGINX download page. Note that the current implementation of NGINX for Windows is at the Proof-of-Concept stage and should only be used for development and testing purposes. For additional information, please see nginx for Windows.

Dynamic modules

NGINX version 1.9.11 added support for Dynamic Modules. Unlike Static modules, dynamically built modules can be downloaded, installed, and configured after the core NGINX binaries have been built. Official dynamic module binaries are available from the same package repository as the core NGINX binaries described in previous steps.

Tip

NGINX JavaScript (njs), is a popular NGINX dynamic module that enables the extension of core NGINX functionality using familiar JavaScript syntax.

Important

If desired, dynamic modules can also be built statically into NGINX at compile time.

Getting started with NGINX

For a gentle introduction to NGINX basics, please see our Beginner’s Guide.

Installing SSL certificates and enabling TLS encryption

See Configuring HTTPS servers for a quick guide on how to enable secure traffic to your NGINX installation.

Load Balancing

For a quick start guide on configuring NGINX as a Load Balancer, please see Using nginx as HTTP load balancer.

Rate limiting

See our Rate Limiting with NGINX blog post for an overview of core concepts for provisioning NGINX as an API Gateway.

Content caching

See A Guide to Caching with NGINX and NGINX Plus blog post for an overview of how to use NGINX as a content cache (e.g. edge server of a content delivery network).

Building from source

The following steps can be used to build NGINX from source code available in this repository.

Installing dependencies

Most Linux distributions will require several dependencies to be installed in order to build NGINX. The following instructions are specific to the apt package manager, widely available on most Ubuntu/Debian distributions and their derivatives.

Tip

It is always a good idea to update your package repository lists prior to installing new packages.

sudo apt update

Installing compiler and make utility

Use the following command to install the GNU C compiler and Make utility.

sudo apt install gcc make

Installing dependency libraries

sudo apt install libpcre3-dev zlib1g-dev

Warning

This is the minimal set of dependency libraries needed to build NGINX with rewriting and gzip capabilities. Other dependencies may be required if you choose to build NGINX with additional modules. Monitor the output of the configure command discussed in the following sections for information on which modules may be missing. For example, if you plan to use SSL certificates to encrypt traffic with TLS, you'll need to install the OpenSSL library. To do so, issue the following command.

sudo apt install libssl-dev

Cloning the NGINX GitHub repository

Using your preferred method, clone the NGINX repository into your development directory. See Cloning a GitHub Repository for additional help.

git clone https://github.com/nginx/nginx.git

Configuring the build

Prior to building NGINX, you must run the configure script with appropriate flags. This will generate a Makefile in your NGINX source root directory that can then be used to compile NGINX with options specified during configuration.

From the NGINX source code repository's root directory:

auto/configure

Important

Configuring the build without any flags will compile NGINX with the default set of options. Please refer to https://nginx.org/en/docs/configure.html for a full list of available build configuration options.

Compiling

The configure script will generate a Makefile in the NGINX source root directory upon successful execution. To compile NGINX into a binary, issue the following command from that same directory:

make

Location of binary and installation

After successful compilation, a binary will be generated at <NGINX_SRC_ROOT_DIR>/objs/nginx. To install this binary, issue the following command from the source root directory:

sudo make install

Important

The binary will be installed into the /usr/local/nginx/ directory.

Running and testing the installed binary

To run the installed binary, issue the following command:

sudo /usr/local/nginx/sbin/nginx

You may test NGINX operation using curl.

curl localhost

The output of which should start with:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

Asking questions and reporting issues

See our Support guidelines for information on how discuss the codebase, ask troubleshooting questions, and report issues.

Contributing code

Please see the Contributing guide for information on how to contribute code.

Additional help and resources

See the NGINX Community Blog for more tips, tricks and HOW-TOs related to NGINX and related projects.
Access nginx.org, your go-to source for all documentation, information and software related to the NGINX suite of projects.

Changelog

See our changelog to keep track of updates.

License

2-clause BSD-like license

Additional documentation available at: https://nginx.org/en/docs

GitHub C Daily Trending

curl/curl

Open Source

Contact

Commercial support

Website

Source code

Security problems

Backers

Sponsors

FreeRTOS/FreeRTOS-Kernel

Getting started

Getting help

To consume FreeRTOS-Kernel

Consume with CMake

Consuming stand-alone - Cloning this repository

Repository structure

Code Formatting

Line Endings

Git History Optimizations

Spelling and Formatting

Third Party Tools

HarbourMasters/Shipwright

Website

Discord

Quick Start

1. Verify your ROM dump

2. Download The Ship of Harkinian from Releases

3. Launch the Game!

Windows

Linux

macOS

Nintendo Switch

4. Play!

Configuration

Default keyboard configuration

Other shortcuts

Project Overview

Graphics Backends

Custom Assets

Development

Building

Playtesting

Further Reading

facebook/zstd

Benchmarks

The case for Small Data compression

Dictionary compression How To:

Build instructions

Makefile

cmake

Support for Fat (Universal2) Output

Meson

VCPKG

Conan

Visual Studio (Windows)

Buck

Bazel

Testing

Status

License

Contributing

AcademySoftwareFoundation/openexr

OpenEXR

OpenEXR Project Mission

Project Governance

Building OpenEXR

Quick Start

Community

Resources

License

jqlang/jq

jq

Documentation

Installation

Prebuilt Binaries

Docker Image

Run with Docker

Example: Extracting the version from a package.json file

Example: Extracting the version from a package.json file with a mounted volume

Example: Extracting the version from a `package.json` file

Example: Extracting the version from a `package.json` file with a mounted volume