Free posix software for mac

Privoxy 3.0.14 Beta offers you a complete non-caching web proxy with advanced filtering capabilities which is designed for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk.

Privoxy has a flexible configuration and can be customized to suit individual needs and tastes. It has application for both stand-alone systems and multi-user networks. Privoxy is Free Software and licensed under the GPL2. Privoxy is an associated project of Software in the Public Interest (SPI).

Major Features:

1. Can keep outgoing connections alive and reuse them later on.
2. Supports tagging which allows to change the behavior based on client and server headers.
3. Can be run as an "intercepting" proxy, which obviates the need to configure browsers individually.
4. Sophisticated actions and filters for manipulating both server and client headers.
5. Can be chained with other proxies.
6. Integrated browser based configuration and control utility. Browser-based tracing of rule and filter effects. Remote toggling.
7. Web page filtering (text replacements, removes banners based on size, invisible "web-bugs", JavaScript and HTML annoyances, pop-up windows, etc.)
8. Modularized configuration that allows for standard settings and user settings to reside in separate files, so that installing updated actions files won't overwrite individual user settings.
9. Support for Perl Compatible Regular Expressions in the configuration files, and a more sophisticated and flexible configuration syntax.
10. Improved cookie management features (e.g. session based cookies).
11. GIF de-animation.
12. Bypass many click-tracking scripts (avoids script redirection).
13. Multi-threaded (POSIX and native threads).
14. User-customizable HTML templates for most proxy-generated pages (e.g. "blocked" page).
15. Auto-detection and re-reading of config file changes.
16. Improved signal handling, and a true daemon mode (Unix).
17. Every feature now controllable on a per-site or per-location basis, configuration more powerful and versatile over-all.
18. Many smaller new features added, limitations and bugs removed.

Enhancements:

• The latency is taken into account when evaluating whether or not to reuse a connection. This should significantly reduce the number of connections problems several users reported.
• If the server doesn't specify how long the connection stays alive, Privoxy errs on the safe side of caution and assumes it's only a second.
• The error pages for connection timeouts or missing server data use a Last-Modified date in the past. Retry attempts are detected and Privoxy removes the If-Modified-Since header to prevent the server from responding with status code 304 in which case the client would reuse the error message.
• Setting keep-alive-timeout to 0 disables keep-alive support. Previously Privoxy would claim to allow persistence but not reuse the connection.
• Pipelined requests are less likely to be mistaken for the request body of the previous request. Note that Privoxy still has no real pipeline support and will either serialize pipelined requests or drop them in which case the client has to resent them.
• Fixed a crash on some Windows versions when header randomization is enabled and the date couldn't be parsed.
• Privoxy's keep-alive timeout for the current connection is reduced to the one specified in the client's Keep-Alive header.
• For HTTP/1.1 requests, Privoxy implies keep-alive support by not If the socket isn't reusable, Privoxy doesn't temporarily waste a socket slot to remember the connection.
• If keep-alive support is disabled but compiled in, the client's Keep-Alive header is removed.
• Fixed a bug on mingw32 where downloading large files failed if keep-alive support was enabled.
• Fixed a bug that (at least theoretically) could cause log timestamps to be occasionally off by about a second.
• No Proxy-Connection header if added if there already is one.
• The configure script respects the $PATH variable when searching for groups and id.

MogileFS is an open source distributed filesystem. MogileFS is not:
- POSIX Compliant -- you dont run regular Unix applications or databases against MogileFS. Its meant for archiving write-once files and doing only sequential reads. (though you can modify a file by way of overwriting it with a new version)
- Completely portable ... yet -- there still is some Linux-ism in the code, at least in the HTTP transport cod, but the plan is to scrap that and make it portable

Main features:>
- Application level -- no special kernel modules required.
- No single point of failure -- all three components of a MogileFS setup (storage nodes, trackers, and the trackers database(s)) can be run on multiple machines, so theres no single point of failure. (you can run trackers on the same machines as storage nodes, too, so you dont need 4 machines...) A minimum of 2 machines is recommended.
- Automatic file replication -- files, based on their "class", are automatically replicated between enough different storage nodes as to satisfy the minimum replica count as requested by their class. For instance, for a photo hosting site you can make original JPEGs have a minimum replica count of 3, but thumbnails and scaled versions only have a replica count of 1 or 2. If you lose the only copy of a thumbnail, the application can just rebuild it. In this way, MogileFS (without RAID) can save money on disks that would otherwise be storing multiple copies of data unnecessarily.
- "Better than RAID" -- in a non-SAN RAID setup, the disks are redundant, but the host isnt. If you lose the entire machine, the files are inaccessible. MogileFS replicates the files between devices which are on different hosts, so files are always available.
- Flat Namespace -- Files are identified by named keys in a flat, global namespace. You can create as many namespaces as youd like, so multiple applications with potentially conflicting keys can run on the same MogileFS installation.
- Shared-Nothing -- MogileFS doesnt depend on a pricey SAN with shared disks. Every machine maintains its own local disks.
- No RAID required -- Local disks on MogileFS storage nodes can be in a RAID, or not. Its cheaper not to, as RAID doesnt buy you any safety that MogileFS doesnt already provide.
- Local filesystem agnostic -- Local disks on MogileFS storage nodes can be formatted with your filesystem of choice (ext3, XFS, etc..). MogileFS does its own internal directory hashing so it doesnt hit filesystem limits such as "max files per directory" or "max directories per directory". Use what youre comfortable with.

Duplicity 0.6.03 is a helpful tool with which you can back directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.

The duplicity package also includes the rdiffdir utility. Rdiffdir is an extension of librsync's rdiff to directories---it can be used to produce signatures and deltas of directories as well as regular files. These signatures and deltas are in GNU tar format.

Duplicity is still in Beta. As any software, it may still have a few bugs, but will work for normal usage and is in use now for large personal and corporate backups.

In theory many protocols for connecting to a file server could be supported; so far ssh/scp, local file access, rsync, ftp, HSI, WebDAV, and Amazon S3 have been written. Currently duplicity supports deleted files, full unix permissions, directories, and symbolic links, fifos, and device files, but not hard links.

Major Features:

1. Easy to use: Although duplicity is a command-line utility, the semantics are relative simply. To take a basic example, this command: duplicity /usr scp://host.net/target_dir backs up the /usr directory to the remost host host.net via scp.
2. Encrypted and signed archives: The archives that duplicity produces can be encrypted and signed using GnuPG, the standard for free software cryptology. The remote location will not be able to infer much about the backups other than their size and when they are uploaded. Also, if the archives are modified on the remote side, this will be detected when restoring.
3. Bandwidth and space efficient: Duplicity uses the rsync algorithm so only the changed parts of files are sent to the archive when doing an incremental backup. For instance, if a long log file increases by just a few lines of text, a small diff will be sent to and saved in the archive. Other backup programs may save a complete copy of the file.
4. Standard file format: Athough archive data will be encrypted, inside it is in standard GNU-tar format archives. A full backup contains normal tarballs, and incremental backups are tar archives of new files and the deltas from previous backups. The deltas are in the format produced by librsync's command-line utility rdiff.
5. Although you should never have to look at a duplicity archive manually, if the need should arise they can be produced and processed using GnuPG, rdiff, and tar.
6. Choice of remote protocol: Duplicity does not make many demands on its archive server. As long as files can be saved to, read from, listed, and deleted from a location, that location can be used as a duplicity backend. Besides increasing choice for the user, it can make a server more secure, as clients only require minimal access. Currently local file storage, scp/ssh, ftp, rsync, HSI, WebDAV, and Amazon S3 are supported, and others shouldn't be difficult to add.

Requirements:

• Duplicity requires a POSIX-like operating system. It is best used under GNU/Linux. It also requires:
• • Python v2.3 or later (Python Home)
  • librsync v0.9.6 or later (librsync Home)
  • GnuPG for encryption (GnuPG Home)
  • NcFTP version 3.1.9 or later (NcFTP Home)
  • Boto 0.9d or later (Boto Home)
• If you install from the source package, you will also need:
• • Python development files, normally found in module 'python-dev'
  • librsync development files, normally found in module 'librsync-dev'

Enhancements:

• Restart error handling has been smoothed out a great deal and it "does what is right" in order to keep going.
• Backends are now optional, if they fail an Info message is put out to notify of the failure and why.
• There was more work on translations and internationalization.