Modified items

All recently modified items, latest first.

erlang-esdl-1.3.1-20.lbn25.x86_64: A library that gives you access to SDL and OpenGL functionality in your Erlang program.

erlang-esasl-0.1-29.20120116git665cc80.lbn25.x86_64: Simple Authentication and Security Layer (SASL) support for Erlang.

erlang-erlydtl-0.11.1-6.lbn25.x86_64: ErlyDTL is an Erlang implementation of the Django Template Language. The erlydtl module compiles Django Template source code into Erlang bytecode. The compiled template has a "render" function that takes a list of variables and returns a fully rendered document.

erlang-erlsyslog-0.8.0-9.lbn25.x86_64: Syslog facility for Erlang.

erlang-cowlib-2.2.0-2.lbn25.x86_64: Support library for manipulating Web protocols.

erlang-cl-1.2.4-6.lbn25.x86_64: OpenCL binding for Erlang.

erlang-cache_tab-1.0.25-1.lbn25.x86_64: This application is intended to proxy back-end operations for Key-Value insert, lookup and delete and maintain a cache of those Key-Values in-memory, to save back-end operations. Operations are intended to be atomic between back-end and cache tables. The lifetime of the cache object and the max size of the cache can be defined as table parameters to limit the size of the in-memory tables.

environment-modules-3.2.10-17.fc24.x86_64: The Environment Modules package provides for the dynamic modification of a user's environment via modulefiles. Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the module command which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. modulefiles may be shared by many users on a system and users may have their own collection to supplement or replace the shared modulefiles. Modules can be loaded and unloaded dynamically and atomically, in an clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh, tcsh, as well as some scripting languages such as perl. Modules are useful in managing different versions of applications. Modules can also be bundled into metamodules that will load an entire suite of different applications. NOTE: You will need to get a new shell after installing this package to have access to the module alias.

electrum-server-1.12.0-1.lbn25.noarch: Features Efficient, lightweight reimplementation of electrum-server Fast synchronization of bitcoin mainnet from Genesis. Recent hardware should synchronize in well under 24 hours. The fastest time to height 448k (mid January 2017) reported is under 4h 30m. On the same hardware JElectrum would take around 4 days and electrum-server probably around 1 month. The full Electrum protocol is implemented. The only exception is the blockchain.address.get_proof RPC call, which is not used by Electrum GUI clients, and can only be invoked from the command line. Various configurable means of controlling resource consumption and handling denial of service attacks. These include maximum connection counts, subscription limits per-connection and across all connections, maximum response size, per-session bandwidth limits, and session timeouts. Minimal resource usage once caught up and serving clients; tracking the transaction mempool appears to be the most expensive part. Fully asynchronous processing of new blocks, mempool updates, and client requests. Busy clients should not noticeably impede other clients' requests and notifications, nor the processing of incoming blocks and mempool updates. Daemon failover. More than one daemon can be specified, and ElectrumX will failover round-robin style if the current one fails for any reason. Peer discovery protocol removes need for IRC Coin abstraction makes compatible altcoin and testnet support easy. Motivation Mainly for privacy reasons, I have long wanted to run my own Electrum server, but I struggled to set it up or get it to work on my DragonFlyBSD system and lost interest for over a year. In September 2016 I heard that electrum-server databases were getting large (35-45GB when gzipped), and it would take several weeks to sync from Genesis (and was sufficiently painful that no one seems to have done it for about a year). This made me curious about improvements and after taking a look at the code I decided to try a different approach. I prefer Python3 over Python2, and the fact that Electrum is stuck on Python2 has been frustrating for a while. It's easier to change the server to Python3 than the client, so I decided to write my effort in Python3. It also seemed like a good opportunity to learn about asyncio, a wonderful and powerful feature introduced in Python 3.4. Incidentally, asyncio would also make a much better way to implement the Electrum client. Finally though no fan of most altcoins I wanted to write a codebase that could easily be reused for those alts that are reasonably compatible with Bitcoin. Such an abstraction is also useful for testnets. Implementation ElectrumX does not do any pruning or throwing away of history. I want to retain this property for as long as it is feasible, and it appears efficiently achievable for the forseeable future with plain Python. The following all play a part in making ElectrumX very efficient as a Python blockchain indexer: aggressive caching and batching of DB writes more compact and efficient representation of UTXOs, address index, and history. Electrum Server stores full transaction hash and height for each UTXO, and does the same in its pruned history. In contrast ElectrumX just stores the transaction number in the linear history of transactions. For at least another 5 years this transaction number will fit in a 4-byte integer, and when necessary expanding to 5 or 6 bytes is trivial. ElectrumX can determine block height from a simple binary search of tx counts stored on disk. ElectrumX stores historical transaction hashes in a linear array on disk. placing static append-only metadata indexable by position on disk rather than in levelDB. It would be nice to do this for histories but I cannot think of a way. avoiding unnecessary or redundant computations, such as converting address hashes to human-readable ASCII strings with expensive bignum arithmetic, and then back again. better choice of Python data structures giving lower memory usage as well as faster traversal leveraging asyncio for asynchronous prefetch of blocks to mostly eliminate CPU idling. As a Python program ElectrumX is unavoidably single-threaded in its essence; we must keep that CPU core busy. Python's asyncio means ElectrumX has no (direct) use for threads and associated complications.

electrum-4.1.5-1.lbn25.noarch: Electrum is an easy to use Bitcoin client. It protects you from losing coins in a backup mistake or computer failure, because your wallet can be recovered from a secret phrase that you can write on paper or learn by heart. There is no waiting time when you start the client, because it does not download the Bitcoin blockchain. Features: Instant on: Your client does not download the blockchain, it uses a remote server. Forgiving: Your wallet can be recovered from a secret seed. Safe: Your seed or private keys are not sent to the server. Information received from the server is verified using SPV No downtimes: Several public servers are available, you can switch instantly. Ubiquitous: You can use the same wallet on different computers, it will auto-synchronize. Cold Storage: You can have secure offline wallets and still safely spend from an online computer. Open: You can export your private keys into other Bitcoin clients. Tested and audited: Electrum is open source and was first released in November 2011. User interfaces Electrum has several user interfaces, that share the same wallet code: Classic (Qt), Lite, Gtk, Android, Text (using curses). Go to screenshots to see some examples

ejabberd-17.01-2.lbn25.x86_64: ejabberd is a Free and Open Source distributed fault-tolerant Jabber/XMPP server. It is mostly written in Erlang, and runs on many platforms (tested on Linux, FreeBSD, NetBSD, Solaris, Mac OS X and Windows NT/2000/XP).

dev86-0.16.21-7.lbn25.x86_64: The dev86 package provides an assembler and linker for real mode 80x86 instructions. You'll need to have this package installed in order to build programs that run in real mode, including LILO and the kernel's bootstrapping code, from their sources. You should install dev86 if you intend to build programs that run in real mode from their source code.

chef-bastionlinux-13.10.30.4-1.lbn25.noarch: Knife bootstrap for BastionLinux. This is a complete RPM-only install which does not stick a full C/Ruby development environment onto a BastionLinux server.

bitcoin-sysv-0.21.1-1.lbn25.noarch: bitcoin daemon start/stop/control

bitcoin-systemd-0.21.1-1.lbn25.noarch: bitcoin daemon start/stop/control

bitcoin-client-0.21.1-1.lbn25.x86_64: bitcoin gui client

bitcoin-0.21.1-1.lbn25.x86_64: Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin is also the name of the open source software which enables the use of this currency. For more information, as well as an immediately useable, binary version of the Bitcoin client sofware, see http://www.bitcoin.org.

bastion-repos-25-0.4.noarch: BastionLinux package repository files for yum and dnf along with gpg public keys

bastion-release-25-3.noarch: Fedora release files such as various /etc/ files that define the release.

apr-util-sqlite-1.6.1-11.lbn25.x86_64: This package provides the SQLite driver for the apr-util DBD (database abstraction) interface.

« Previous 20 items Next 20 items » 1 ... 988 989 990 991 992 993 994 ... 2435


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items