Byzantium v0.1a (Scarab) Released!
Thu, 2012-01-12 00:16
Approved for: GENERAL RELEASE, DISTRIBUTION UNLIMITED
Project Byzantium, a working group of HacDC, is proud to announce the release of v0.1 alpha of Byzantium Linux, a live distribution of Linux designed to fulfill a crucial role in the evolution of the Internet. That role is a rapidly deployable ad-hoc wireless mesh network which can augment or replace the current telecommunications infrastructure in the event that it is knocked offline (for example, due to a natural disaster) or rendered untrustworthy (widespread surveillance or disconnection by hostile entities). Unlike other mesh networking projects Byzantium was designed to be run on any x86 computer with at least one 802.11 a/b/g/n wireless interface. Byzantium can be burned to a CD- or DVD-ROM (the .iso image is just over 300 megabytes in size), booted from an external hard drive, or can even be installed in parallel with an existing operating system without risk to the user's data and software. Byzantium Linux will then act as a node within the mesh and will automatically connect to other mesh nodes and act as an access point for WiFi-enabled mobile devices.
THIS IS AN ALPHA RELEASE! Do NOT expect Byzantium to be perfect. Some features are not ready yet, others need work. Things are going to break in weird ways and we need to know what those ways are so we can fix them. Please, for the love of LOLcats, do not deploy Byzantium in situations where lives are at stake.
FEATURES:
-
Binary compatible with Slackware v13.37, so existing packages can be converted with a single command.
Able to act as a gateway to the Internet if a link is available.
Linux kernel v2.6.38.8
Drivers for dozens of wireless chipsets
KDE v3.5
LXDE (2010 release of all components)
Mplayer
GCC v4.5.2
Perl v5.12.3
Python v2.6.6
Firefox v4.0.1
X.org v7.4 (? - hard to tell because each module has its own release code)
Custom web-based control panel
SYSTEM REQUIREMENTS (to use)
-
Minimum of 512MB of RAM
i586 CPU or better
CD- or DVD-ROM drive
BIOS must boot removable media
At least one (1) 802.11 a/b/g/n interface
SYSTEM REQUIREMENTS (for persistent changes)
-
The above requirements to use Byzantium
2+GB of free space on thumbdrive or harddrive
WHAT WE NEED:
-
Developers.
Developers!
DEVELOPERS!
No more Bill Ballmer impersonations.
People downloading and running Byzantium to find bugs and tell us where the problems are so we can fix them.
People filing bug reports on our Github page. We can't fix what we don't know about!
People submitting patches.
People booting Byzantium and setting up small meshes (2-5 clients) to tell us how well it works for you with your hardware. We have a hardware compatibility list on our wiki that needs to be expanded.
People who can help us translate the user interface. We especially need people fluent in dialects of Chinese, Arabic, Farsi, and Urdu.
People to help us write and translate documentation.
Homepage (website coming soon)
Download sites
CODA:
You are probably wondering what, if any relevance this has to Eclipse Phase. One of the biggest inspirations for Project Byzantium was the Mesh of Eclipse Phase, and it is likely that, had a few of us not fallen in love with the RPG we would never have remembered learning about mobile IP or mesh routing protocols in undergraduate network programming class. So, we thank everyone who worked on Eclipse Phase for all of your hard work.
__________________
I am everywhere.
Sun, 2012-01-15 00:50
#2
Re: Byzantium v0.1a (Scarab) Released!
This is an awesome idea, and one I absolutely hope you guys can get off the ground. I haven't done any OS coding before, but if there's anything I might be able to do to help, I'd like to.
If you are knowledgable in Python, Erlang, PHP, or shell scripting, we could definitely use your help. We also need help with writing documentation and fine-tuning the quickstart guide so that it make sense.
On a secondary note, I have a rather Extropian suggestion for this OS; you might want to make this capable of secondary anonymous internet protocols such as i2p, Tor, Freenet, and others that I can't remember; after all, if you are trying to make a mesh system that is more durable than currently existing wireless topologies, you might as well go the extra mile and make it feasible for users to be more trace resistant as well (one way to take down a network is to find its users).
We do have such plans in mind, though they are likely going to wait until the beta releases start (probably >= v0.3). We plan to make it possible for network gateways to route traffic over the Tor network, and we are evaluating a number of other darknets for usability and feasibility (as well as VPNs). Keep in mind that most of our use cases involve not having net.access (or at least, reliable net.access), so we aim to replicate a subset of that functionality in the applications that Byzantium nodes provide.
A mesh's users being found are a concern of ours. Our threat model was developed in collaboration with activist groups around the world, and it involves not users being tracked down but nodes/access points being tracked down (which happened rather a lot in 2011 in Syria), hence, designing for mobility, long distance links and rapid shutdown if need be.
__________________
I am everywhere.
Sun, 2012-01-15 08:26
#3
Re: Byzantium v0.1a (Scarab) Released!
If you are knowledgable in Python, Erlang, PHP, or shell scripting, we could definitely use your help. We also need help with writing documentation and fine-tuning the quickstart guide so that it make sense.
Unfortunately, most of my coding skills are in the C languages, MySQL and Javascript, though I am learning Python and am at least nominally skilled at shell script. I might be more useful in documentation for the time being.
We do have such plans in mind, though they are likely going to wait until the beta releases start (probably >= v0.3). We plan to make it possible for network gateways to route traffic over the Tor network, and we are evaluating a number of other darknets for usability and feasibility (as well as VPNs). Keep in mind that most of our use cases involve not having net.access (or at least, reliable net.access), so we aim to replicate a subset of that functionality in the applications that Byzantium nodes provide.
Agreed. Some means of maintaining decentralized networks, with every Byzantium node being capable of acting as a server would be an interesting way to maintain communication when the network is cut off from the greater internet. So users might be able to use such programs as IRC (which if memory serves is decentralized) or eMule to interlink with users on whatever size topology can be maintained.
It might also be wise to make Byzantium capable of caching parts of the internet, so that internet users can at least view a backup of websites while the network is cut off from the world. How you might design Byzantium to determine which parts of the internet to cache, I have no clue.
A mesh's users being found are a concern of ours. Our threat model was developed in collaboration with activist groups around the world, and it involves not users being tracked down but nodes/access points being tracked down (which happened rather a lot in 2011 in Syria), hence, designing for mobility, long distance links and rapid shutdown if need be.
For rapid shutdown, steps can be taken to ensure that the operating system's integrity can be maintained even with power being cut. For small hard drives, the current configuration works quite well. You might want to also make a stripped-down version of Byzantium down the line that is capable of being started via disk, then allowing that disk to be removed so that the entire OS is simply held on RAM until shutdown (of course there will have to be a minimum requirement, but I'm sure that with work you can get it below Windows XP requirement levels).
For larger hard drives and major nodes that such groups might set up, parity code combined with RAID support or even the capability for "false RAID" data storage (mirrored storage of data on a single hard drive; a friend once jokingly called it SLED, for Single Large Expensive Drive, but I don't think he invented that term) would do wonders for making quick shutdown an easy task. This support for large hard drives would also be very handy, should you implement the internet cache I was mentioning earlier.
__________________
"Question with boldness even the existence of a god; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear." - Thomas Jefferson, Letter to Peter Carr, 1787
"That sounds like heresy. We're going to wipe you from the history books for that crap!" - Texas Board of Education, Ruling on March 12th, 2010
Fri, 2012-01-20 17:03
#4
Re: Byzantium v0.1a (Scarab) Released!
Unfortunately, most of my coding skills are in the C languages, MySQL and Javascript, though I am learning Python and am at least nominally skilled at shell script. I might be more useful in documentation for the time being.
Help with documentation (in particular, The Book) would be great. Also, there are a couple of things that could use some automation, such as hardening and building the actual OS package. Are you on the mailing list?
Agreed. Some means of maintaining decentralized networks, with every Byzantium node being capable of acting as a server would be an interesting way to maintain communication when the network is cut off from the greater internet. So users might be able to use such programs as IRC (which if memory serves is decentralized) or eMule to interlink with users on whatever size topology can be maintained.
IRC is decentralized... sort of. Servers are capable of connecting to one another to relay traffic from node to node so that users can be spread across a large area of net.space without overloading any one server's socket capacity. The problem with most IRC servers is that they have to be specifically configured to federate with one another. The one we are using appears to do so automatically with mDNS but we have not tested it yet, and there are other options that we are going to investigate soon.
It might also be wise to make Byzantium capable of caching parts of the internet, so that internet users can at least view a backup of websites while the network is cut off from the world. How you might design Byzantium to determine which parts of the internet to cache, I have no clue.
We are toying with the idea of adding a caching transparent web proxy that can be turned on and off, but disk space and memory to contain the cache and indices is at a premium with a live OS.
You might want to also make a stripped-down version of Byzantium down the line that is capable of being started via disk, then allowing that disk to be removed so that the entire OS is simply held on RAM until shutdown (of course there will have to be a minimum requirement, but I'm sure that with work you can get it below Windows XP requirement levels).
That functionality already exists actually, we have just not exercised it strongly yet. The underlying distribution (Porteus Linux) includes a "RAM only" feature which does just that.
For larger hard drives and major nodes that such groups might set up, parity code combined with RAID support or even the capability for "false RAID" data storage (mirrored storage of data on a single hard drive; a friend once jokingly called it SLED, for Single Large Expensive Drive, but I don't think he invented that term) would do wonders for making quick shutdown an easy task. This support for large hard drives would also be very handy, should you implement the internet cache I was mentioning earlier.
Installing to a journalled file system (like EXT3 or EXT4) is definitely an option. I think we can do some experiments fairly soon to see how well this work. I even have a dataset in mind for them... __________________
I am everywhere.
Sat, 2012-01-21 23:20
#5
Re: Byzantium v0.1a (Scarab) Released!
Help with documentation (in particular, The Book) would be great. Also, there are a couple of things that could use some automation, such as hardening and building the actual OS package. Are you on the mailing list?
No, I can't say I am. I will probably join it soon.
IRC is decentralized... sort of. Servers are capable of connecting to one another to relay traffic from node to node so that users can be spread across a large area of net.space without overloading any one server's socket capacity. The problem with most IRC servers is that they have to be specifically configured to federate with one another. The one we are using appears to do so automatically with mDNS but we have not tested it yet, and there are other options that we are going to investigate soon.
If that's the case, this might call for some new chat protocol. This mesh network would provide an excellent testing ground for a truly decentralized chat network that has its backbone built entirely on these mesh servers (and anything else on the internet that is running the chat software).
We are toying with the idea of adding a caching transparent web proxy that can be turned on and off, but disk space and memory to contain the cache and indices is at a premium with a live OS.
I would recommend disabling that feature with a live install, and making it active only on an actual hard drive install. Web caching is very memory-intensive, and it could potentially act like a memory leak for a live install (as the caching rapidly eats up RAM without freeing it until shutdown or restart).
That functionality already exists actually, we have just not exercised it strongly yet. The underlying distribution (Porteus Linux) includes a "RAM only" feature which does just that.
Probably for the best. You might want to wait until beta before rolling out a feature like that.
Installing to a journalled file system (like EXT3 or EXT4) is definitely an option. I think we can do some experiments fairly soon to see how well this work. I even have a dataset in mind for them...
D'oh! I forgot about journaling file systems. EXT4 is probably the best course, at least so long as there are still plans to make it defragmentable while live (I don't think they've finish building that feature yet).
__________________
"Question with boldness even the existence of a god; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear." - Thomas Jefferson, Letter to Peter Carr, 1787
"That sounds like heresy. We're going to wipe you from the history books for that crap!" - Texas Board of Education, Ruling on March 12th, 2010
Tue, 2012-01-24 22:35
#6
Re: Byzantium v0.1a (Scarab) Released!
If that's the case, this might call for some new chat protocol. This mesh network would provide an excellent testing ground for a truly decentralized chat network that has its backbone built entirely on these mesh servers (and anything else on the internet that is running the chat software).
There are a few of them out there already, but the most mature of them is actually XMPP. We are considering using ejabberd for a number of functions, such as distributed realtime chat (that plug-in comes with the source tree), microblogging (same), and user-to-user instant messaging. I believe that ejabberd instances can be configured to automatically find one another, but if they cannot then we may have a little more code to write. Implementing a mobile-friendly front-end should not be difficult.
I would recommend disabling that feature with a live install, and making it active only on an actual hard drive install. Web caching is very memory-intensive, and it could potentially act like a memory leak for a live install (as the caching rapidly eats up RAM without freeing it until shutdown or restart).
Most of the services we have are off by default (right now, anyway), and have to be enabled by the administrator. We could add a few checks to determine how the node is running and disable that option or not.
D'oh! I forgot about journaling file systems. EXT4 is probably the best course, at least so long as there are still plans to make it defragmentable while live (I don't think they've finish building that feature yet).
I do not know. I need to do some more research on EXT4 (it is a little too close to the bleeding edge for my tastes at this moment). __________________
I am everywhere.
This is an awesome idea, and one I absolutely hope you guys can get off the ground. I haven't done any OS coding before, but if there's anything I might be able to do to help, I'd like to.
On a secondary note, I have a rather Extropian suggestion for this OS; you might want to make this capable of secondary anonymous internet protocols such as i2p, Tor, Freenet, and others that I can't remember; after all, if you are trying to make a mesh system that is more durable than currently existing wireless topologies, you might as well go the extra mile and make it feasible for users to be more trace resistant as well (one way to take down a network is to find its users).
"Question with boldness even the existence of a god; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear." - Thomas Jefferson, Letter to Peter Carr, 1787
"That sounds like heresy. We're going to wipe you from the history books for that crap!" - Texas Board of Education, Ruling on March 12th, 2010