From ca43c7b074d69b1d802090b12d4bf65fe21c3c92 Mon Sep 17 00:00:00 2001 From: bnewbold Date: Sat, 11 Jun 2016 17:09:32 -0400 Subject: clean up networking folder --- ideas/MOSS.page | 108 ++++++++++++++++++++++++++++++++++++ networking/dns.page | 20 +++---- networking/ipv6vpn.page | 21 +++---- networking/misc.page | 4 -- networking/misc.txt | 4 ++ networking/secure-global-comms.page | 7 --- networking/secure-global-comms.txt | 7 +++ products/products.page | 18 ------ products/products.txt | 18 ++++++ software/MOSS.page | 108 ------------------------------------ 10 files changed, 157 insertions(+), 158 deletions(-) create mode 100644 ideas/MOSS.page delete mode 100644 networking/misc.page create mode 100644 networking/misc.txt delete mode 100644 networking/secure-global-comms.page create mode 100644 networking/secure-global-comms.txt delete mode 100644 products/products.page create mode 100644 products/products.txt delete mode 100644 software/MOSS.page diff --git a/ideas/MOSS.page b/ideas/MOSS.page new file mode 100644 index 0000000..c0bba84 --- /dev/null +++ b/ideas/MOSS.page @@ -0,0 +1,108 @@ +--- +format: rst +toc: no +... + +==== +MOSS +==== +-------------------------------- +Many User Operating System Stuff +-------------------------------- + +:Author: Bryan Newbold + +Moss is a vague concept I have for an operating-system-like-system that +attempts to realize some of the promises of distributed universal computing +and user management, continuation-based serializable programming, persistent +data accessibility, file and process versioning, central foreign function +management, and code/content distribution. It'll be easy! + +Implementation +~~~~~~~~~~~~~~~ + +Moss would probably start as "stuff": middleware, userland applications, +utilities, and native shell and GUI interfaces. It could also be a +separate hosted virtual machine, a monolithic application, a kernel +extension, or ultimately run alone over a high performance shim host OS. + +Distribution would be self hosting and viral: users would replicate a copy +of the system from a friend instead of from a central server, patches +and applications would be distributed word-of-mouth, and trust networks +would form naturally via this distribution. Customization and feature sets +would be passed on, which makes it likely that a user would receive a +system already tweaked for their own needs and computing knowledge level. + +*Existing Projects:* Inferno, Xen, vmware, Java, GNU/* + +Universal, distributed file system +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The core of the system would be a universally accessible identity-based +operating system. Some authoritive domain would probably be required, but +public identity brokers would allow anonymous identities. "Strong +Cryptography" is a goal, allowing a user's content to be hosted/cached +on third party machines in an encrypted form. The real challenge of course +is a flexible crypto system than can be transitioned or upgraded if a flaw +is discovered without total data loss. + +My dream path would look something like:: + + /net/user@some.domain.tld/media/ledzep/tangerine.mp3 + +From the application end there would be no concept of "local" or "remote" +files to a particular machine, though perhaps some feedback on access time. +So, for instance, once tokens/authentication is handled, user utilities +like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``. + +Versioning, write locks, etc would have to be considered. + +*Existing projects:* OpenAFS, freeNet, ssh, kerberos, git + +Serializable Programs +~~~~~~~~~~~~~~~~~~~~~~~ + +The state/continuation/environment of a running program or chain of +programs should be a "first level object": a bundle of data like any other +that can be transmitted, copied, and stored away for later. A user should +be able to drag an entire application running on a desktop computer +onto their laptop when then need to travel, or from laptop to workstation +if then need additional computing power. Distributed computing could be +implemented by bundling up applets that are shot off to a cluster or +higher performance computer for processing, and the result state of the +program would simply be bundled back to the requesting client. Such bundles +wouldn't be very large: data would be stored on the distributed filesystem, +which appears identical (*exactly?*) to every node on the network. + +Properly written, such a serializable system could also lead to performance +and power consumption savings by swapping idle programs and processes to +disk, or let low-usage nodes shift their processes off to other nodes +and power down. + +*Existing Projects:* Lisp, Stackless + +Foreign Function Management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It would be nice to see a move away from the library model for shared +code to a more flexible/dynamic foreign function interface that would +allow any appropriate code to announce its availability to other +applications regardless of version, platform, coding language, etc. +This would be a high-level feature, not intended to replace kernel level +operations (read/write) but to make package/library management easier +(it doesn't matter if an image conversion function is coming from a video +editing package or libpng as long as it reads a raw array and returns +a binary stream). + +There's room for dynamic optimization here: if program +realizes it's native string manipulation library sucks for 5meg+ datasets +it could look through the library and see if there's a better one. + +*And,* this too could be distributed, allowing super easy access to +distributed computing resources; underutilized nodes could make their +functions available to nearby nodes, or a machine with tons of matrix +crunching silicon (eg high end video cards) could swap work units +with a machine with a dedicated crypto chip or 64bit+ processor. + +*Existing Projects:* Script-fu from the Gimp + diff --git a/networking/dns.page b/networking/dns.page index dcda2fd..7a49575 100644 --- a/networking/dns.page +++ b/networking/dns.page @@ -1,15 +1,13 @@ -Recommendation Tools ----------------------- -http://domai.nr/ +Domain Name Recommendation Tools +---------------------------------- -http://impossibility.org/ +* [domai.nr](http://domai.nr/) +* [impossibility.org](http://impossibility.org/) -Registrars ------------- +Decent Registrars +------------------- -http://1984.is - -http://name.com - -http://gandi.net +* [1984.is](http://1984.is) (for Icelandic domains) +* [name.com](http://name.com) +* [gandi.net](http://gandi.net) diff --git a/networking/ipv6vpn.page b/networking/ipv6vpn.page index 6a49230..dcb90fb 100644 --- a/networking/ipv6vpn.page +++ b/networking/ipv6vpn.page @@ -15,7 +15,7 @@ ways. ## VPS Host-side (based off -[http://library.linode.com/networking/openvpn/debian-6-squeeze](linode library) +[linode library](http://library.linode.com/networking/openvpn/debian-6-squeeze) instructions, but heavily modified) First off, make sure you have IPv6 correctly configured on the VPS. I added the @@ -44,7 +44,7 @@ On the remote host (runing debian wheezy), as root: cp ca.crt $YOURSITENAME.crt $YOURSITENAME.key $XFER_TO_SITE cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn -Then copy the following to /etc/openvpn/server.conf: +Then copy the following to `/etc/openvpn/server.conf`: # simple machine-machine OpenVPN config file port 1194 @@ -68,7 +68,7 @@ Then copy the following to /etc/openvpn/server.conf: up-delay up /usr/local/bin/ipv6_tunnel_up.sh -Create /usr/local/bin/ipv6_tunnel_up.sh: +Create `/usr/local/bin/ipv6_tunnel_up.sh`: #!/usr/bin/env sh ip link set tun0 up @@ -106,8 +106,8 @@ ip, ip6tables), as well as OpenVPN (luci-app-openvpn): Configure radvd with the site's /64 prefix, and enable on the LAN interface. -Configure OpenVPN; easiest to copy-paste the following to /etc/config/openvpn -and scp credentials to /etc/openvpn: +Configure OpenVPN; easiest to copy-paste the following to `/etc/config/openvpn` +and `scp` credentials to `/etc/openvpn`: package openvpn @@ -150,7 +150,7 @@ the "lan" zone, and allow forwarding to wan6 only as both source and destination. For IPv6 web ui access, add a static IPv6 address to the LAN interface: -$SITEPREFIX::1/64 makes sense. (TODO: does this work?) +`$SITEPREFIX::1/64` makes sense. (TODO: does this work?) Restart the whole kit-and-kaboodle, re-enable openvpn, and see if things work! @@ -168,11 +168,11 @@ tcp-server" on the VPS server). # Lazy plaintext no-config Method (raw, for historical reference) -http://serverfault.com/questions/231950/openvpn-ipv6-tunnel-radvd + -http://wiki.openwrt.org/doc/howto/ipv6.essentials + -On $VPSHOST: +On `$VPSHOST`: sysctl -w net.ipv6.conf.all.forwarding=1 # not sure why this is required... @@ -202,4 +202,5 @@ firewall interface (enclosing tun0) instead of trying to do everything with the # Reference -After writing this, I found: https://www.zagbot.com/openvpn_ipv6_tunnel.html +After writing this, I found + diff --git a/networking/misc.page b/networking/misc.page deleted file mode 100644 index 9e9653e..0000000 --- a/networking/misc.page +++ /dev/null @@ -1,4 +0,0 @@ - -"The Twelve Networking Truths": http://www.ietf.org/rfc/rfc1925.txt - -FCC wireless exclusion zones: http://transition.fcc.gov/ib/sd/3650/grandftr.pdf diff --git a/networking/misc.txt b/networking/misc.txt new file mode 100644 index 0000000..9e9653e --- /dev/null +++ b/networking/misc.txt @@ -0,0 +1,4 @@ + +"The Twelve Networking Truths": http://www.ietf.org/rfc/rfc1925.txt + +FCC wireless exclusion zones: http://transition.fcc.gov/ib/sd/3650/grandftr.pdf diff --git a/networking/secure-global-comms.page b/networking/secure-global-comms.page deleted file mode 100644 index b4ba266..0000000 --- a/networking/secure-global-comms.page +++ /dev/null @@ -1,7 +0,0 @@ - -Consider the "whispering gallery" effect when speaking within a sphere. - -Masers: could a 900MHz maser (including any antenna stuff) fit in a suitcase -and penetrate at least one wall? are there strong wall reflections that could -be detected? Still line of sight (eg, hills would kill signal) - diff --git a/networking/secure-global-comms.txt b/networking/secure-global-comms.txt new file mode 100644 index 0000000..b4ba266 --- /dev/null +++ b/networking/secure-global-comms.txt @@ -0,0 +1,7 @@ + +Consider the "whispering gallery" effect when speaking within a sphere. + +Masers: could a 900MHz maser (including any antenna stuff) fit in a suitcase +and penetrate at least one wall? are there strong wall reflections that could +be detected? Still line of sight (eg, hills would kill signal) + diff --git a/products/products.page b/products/products.page deleted file mode 100644 index 6595c01..0000000 --- a/products/products.page +++ /dev/null @@ -1,18 +0,0 @@ - -Local maxima of value? - -Sneakers: - New Balance Retro/Classic Shoes M574BKS width=D, size=12 - Made in China (only ~25% of NB products actually made in the USA). - Cost: ~$60/pair from many sources circa 2010 - -Hat: - Everest Designs Rainier Beanie (brown) - Made in Nepal, NZ wool. - Cost: ~$22 from http://hatcart.com - -Messenger Bag: - Bailey Works 253 Courier Bag, medium, no options, orange - Made in New Hampshire - Cost: $120 from http://baileyworks.com - diff --git a/products/products.txt b/products/products.txt new file mode 100644 index 0000000..6595c01 --- /dev/null +++ b/products/products.txt @@ -0,0 +1,18 @@ + +Local maxima of value? + +Sneakers: + New Balance Retro/Classic Shoes M574BKS width=D, size=12 + Made in China (only ~25% of NB products actually made in the USA). + Cost: ~$60/pair from many sources circa 2010 + +Hat: + Everest Designs Rainier Beanie (brown) + Made in Nepal, NZ wool. + Cost: ~$22 from http://hatcart.com + +Messenger Bag: + Bailey Works 253 Courier Bag, medium, no options, orange + Made in New Hampshire + Cost: $120 from http://baileyworks.com + diff --git a/software/MOSS.page b/software/MOSS.page deleted file mode 100644 index c0bba84..0000000 --- a/software/MOSS.page +++ /dev/null @@ -1,108 +0,0 @@ ---- -format: rst -toc: no -... - -==== -MOSS -==== --------------------------------- -Many User Operating System Stuff --------------------------------- - -:Author: Bryan Newbold - -Moss is a vague concept I have for an operating-system-like-system that -attempts to realize some of the promises of distributed universal computing -and user management, continuation-based serializable programming, persistent -data accessibility, file and process versioning, central foreign function -management, and code/content distribution. It'll be easy! - -Implementation -~~~~~~~~~~~~~~~ - -Moss would probably start as "stuff": middleware, userland applications, -utilities, and native shell and GUI interfaces. It could also be a -separate hosted virtual machine, a monolithic application, a kernel -extension, or ultimately run alone over a high performance shim host OS. - -Distribution would be self hosting and viral: users would replicate a copy -of the system from a friend instead of from a central server, patches -and applications would be distributed word-of-mouth, and trust networks -would form naturally via this distribution. Customization and feature sets -would be passed on, which makes it likely that a user would receive a -system already tweaked for their own needs and computing knowledge level. - -*Existing Projects:* Inferno, Xen, vmware, Java, GNU/* - -Universal, distributed file system -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The core of the system would be a universally accessible identity-based -operating system. Some authoritive domain would probably be required, but -public identity brokers would allow anonymous identities. "Strong -Cryptography" is a goal, allowing a user's content to be hosted/cached -on third party machines in an encrypted form. The real challenge of course -is a flexible crypto system than can be transitioned or upgraded if a flaw -is discovered without total data loss. - -My dream path would look something like:: - - /net/user@some.domain.tld/media/ledzep/tangerine.mp3 - -From the application end there would be no concept of "local" or "remote" -files to a particular machine, though perhaps some feedback on access time. -So, for instance, once tokens/authentication is handled, user utilities -like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``. - -Versioning, write locks, etc would have to be considered. - -*Existing projects:* OpenAFS, freeNet, ssh, kerberos, git - -Serializable Programs -~~~~~~~~~~~~~~~~~~~~~~~ - -The state/continuation/environment of a running program or chain of -programs should be a "first level object": a bundle of data like any other -that can be transmitted, copied, and stored away for later. A user should -be able to drag an entire application running on a desktop computer -onto their laptop when then need to travel, or from laptop to workstation -if then need additional computing power. Distributed computing could be -implemented by bundling up applets that are shot off to a cluster or -higher performance computer for processing, and the result state of the -program would simply be bundled back to the requesting client. Such bundles -wouldn't be very large: data would be stored on the distributed filesystem, -which appears identical (*exactly?*) to every node on the network. - -Properly written, such a serializable system could also lead to performance -and power consumption savings by swapping idle programs and processes to -disk, or let low-usage nodes shift their processes off to other nodes -and power down. - -*Existing Projects:* Lisp, Stackless - -Foreign Function Management -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It would be nice to see a move away from the library model for shared -code to a more flexible/dynamic foreign function interface that would -allow any appropriate code to announce its availability to other -applications regardless of version, platform, coding language, etc. -This would be a high-level feature, not intended to replace kernel level -operations (read/write) but to make package/library management easier -(it doesn't matter if an image conversion function is coming from a video -editing package or libpng as long as it reads a raw array and returns -a binary stream). - -There's room for dynamic optimization here: if program -realizes it's native string manipulation library sucks for 5meg+ datasets -it could look through the library and see if there's a better one. - -*And,* this too could be distributed, allowing super easy access to -distributed computing resources; underutilized nodes could make their -functions available to nearby nodes, or a machine with tons of matrix -crunching silicon (eg high end video cards) could swap work units -with a machine with a dedicated crypto chip or 64bit+ processor. - -*Existing Projects:* Script-fu from the Gimp - -- cgit v1.2.3