Finding new hosting for our central "keymaster" is what the issue is. We have enough "fullsevers" for serving the computational data to clients (See http://n0cgi.distributed.net/rc5-proxyinfo.html).
FWIW, Our clients actually can speak a pure HTTP protocol for requesting data, allowing a simple/cgi-bin/rc5.cgi script handle direct serving, but the default communications mode is a more compact raw binary mode.
Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick
The "keymaster" (the machine that utilizes the ~3Mbit/sec) already distributes larger regions of uncomputed work to all of the "fullservers", which are the ones that in turn distribute the actual work to clients after splitting the blocks into sizes that correspond to what is needed by clients. You can see the list of all of the fullservers at http://n0cgi.distributed.net/rc5-proxyinfo.html
All of the chatty, multi-step network communications overhead with dealing directly with the clients is done at the fullserver level, including doing a windowed-history based coalescing on result submissions.
This is effectively what we already do with our keymaster, fullserver, personal proxy tiering. Personal proxies can be several layers deep if needed (many of our teams set up their own team servers using personal proxies).
Our network already uses a somewhat distributed model to spread out bandwidth demand as best as we can. You can see a bit of it if you look at our Proxy Status page at http://n0cgi.distributed.net/rc5-proxyinfo.html
Each of the servers listed are in in different DNS rotation grouped roughly by geographically named groups (that try to take in general network topology/connectivity). The servers listed there (known as "fullservers") handle all of the data communication needs requested by clients, and the fullservers in turn keep in contact with the "keymaster". The keymaster is the server responsible for the coordination of unique work between all of the fullservers and assigning out large regions of keyspace to the fullservers (which in turn split up the regions and redistribute to clients).
The hardware that we had hosted at Insync/TexasNet was actually 3 machines which together served several roles: our keymaster, one of our dns secondaries, our irc network hub, one of our three web content mirrors, and our ftp software distribution mirror (for actual client downloads).
It's unfortunate that the change in management at Insync/TexasNet caused them to want to re-evaluate all of the free-loading machines that were receiving donated services (there were apparently several others besides us) and cut off anyone who wasn't paying. Regardless, it's a touch economy and companies that want to survive have to look at where their costs are going and do their best to cut spending.
Many banks throughout the world continnue to use OS/2 for a lot of their systems. Just about the closest banks to Microsoft's main Redmond campus is a Washington Mutual branch, which happened to use OS/2 for their loan-clerks' desktop machines. I don't know if that is standard for all of their branches (or for their newly acquired branches). Incidentally, they use multiple information technology platforms, including IBM mainframe, AS400, UNIX variants, Windows NT, Novell, and OS/2 distributed environments.
Also, the vehicle title office for Austin, TX (in Georgetown) uses OS/2 for their license and vechicle database used behind the counter.
Check out http://www.distributed.net/source/ and read more about how to get the public source and what restrictions require that parts of it remain undisclosed.
Bringing the experience of greater platform support is one of many things that the distributed.net developers will immediately begin assisting United Devices with.
Windows is arguably a quite a bit more accessible via documented APIs than Linux is. Most of the "nifty" shareware utilities are just simple wrappers around a couple of core APIs. Whereas on Linux, many of the underlying configuration aspects need to be accessed by making a best-attempt at writing your own text parsing routines for the stuff under/proc, hoping that your parsing is robust enough to handle the variations that people with other configurations or other kernel versions. Windows unfortunately likes to reinvent new APIs to allow expanded access metaphors, such as WBEM/WMI, which has invented yet another way to access nearly every major configuration aspect that was previously available.
Cutting off access immediately when something suspicious is discovered doesn't allow you to continue to collect evidence against the people doing the hacking and wouldn't allow you to prosecute as effectively as you could if you have definite evidence of some theft occurring. Evidence of repeated access tracing back to the same party each time also allows you to establish intent. I'm sure there was also some delay involved in allowing the notified authorities to come in and also observe.
And remember that it is still a significant feat of backwards compatibility that many 16-bit DOS applications that were written in 1981 can still run under Windows 95/98/98SE/ME/NT/2k as a VDM application at all, without needing to boot to pure-mode DOS. That's arguably a considerable effort by itself and a tremendous amount of application compatibility development effort is involved in maintaining it to the level that it is at all.
You can still run DOS applications inside Windows ME (ie: as a window or full screen), but you just can't reboot the machine to a "pure" DOS prompt. If you have a boot floppy made with a previous version of DOS/Window9x, then you can get to a real DOS prompt that way.
Also keep in mind that your config.sys and autoexec.bat are not parsed anymore either. Windows ME still has the dependence on the DOS underlyings and DOS really have not been completely removed, but the ability to easily access real-mode DOS has simply been made difficult.
The primary purpose of doing this is to further enforce the movement of device drivers away from old style config.sys "DEVICE=" lines and various TSRs for supporting hardware and towards natively written 32-bit drivers. Such 32-bit drivers will generally be easier to port forward to future versions of Windows based on NT (Win2k and future) if those manufacturers don't already support NT.
A side benefit is that native 32-bit drivers in Windows ME will generally be easier for users to configure and adapt to hardware changes (such as power state or docking changes). For example, being able to use native 32-bit network drivers instead of 16-bit DOS IPXODI/VLM drivers generally will have a tremendous boost in performance and usability. Switching from a 16-bit DOS CDROM SYS driver with MSCDEX to a fully native will generally not only be faster, but will allow access to long filenames.
Although it is true that systems with older, no-longer supported hardware may still depend on DOS-mode TSRs or SYS drivers and may not be able to get updated drivers, Windows ME is not intended to be a general purpose upgrade for all older systems. Going forward, the next consumer OS after Windows ME will be based on NT and will have even more dramatic legacy hardware support issues, since many older manufacturers have neglected to support NT at all.
Yes, unfortunately it takes a few minutes to get pages and plans updated and things mailed out. The plan files of dbaker and nugget were updated at 07:17 UTC (2:17am ET). The changes to the front page to link to the announcement began at 07:00 UTC and were finally committed about 15 minutes later. The time up to that point was mostly spent preparing and sending out announcements to the mailing lists, and celebrating with those in #distributed on IRC.
Blocks that are requested but not returned are eventually recycled and redistributed to other clients. The percentage completion that is noted on the stats page is based off of the number of blocks that have been successfully credited to people. The extra "slack" between the actual keyspace completed and the old percentage displayed on the stats page came from two factors: blocks that had been completed by two distinct people because of re-verification, and blocks that had been invalid and had been redistributed to someone else for proper computation.
Duplicates are ignored and logged separately, that is how you were noticed. The purpose of the "cease and desist" email is to notify the person of a couple of things:
1) If you were trying to cheat, we've noticed you and your efforts are ineffectual.
2) If you somehow have a broken client, read-only disk, or have run out of disk space and are inadvertantly submitting duplicates, you might want to check on it. You might be wasting cpu or network bandwidth that you are not aware of.
The keymaster codebase is the same as the fullserver/personal proxy codebase, only compiled with different compilation directives to enable/disable different parts of the codebase. The only portions of the codebase that would not be necessarily restricted would be the low-level network socket wrappers that do nothing more than providing an abstraction around the platform-specific network i/o calls.
Unfortunately, we've reviewed the proxy codebase and there is very little useful code in it that can be usefully disseminated without weakening the [non]-security of our data protocol. These are the same problems that prevent us from releasing source to all parts of the client (we've released most all of the non-network parts of the client at source already).
Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such.
We understand the problems that are preventing us from becoming fully open source and are working to solve them. We have already done a lot of research work in this area and are working towards an eventual solution that can be fully open source. The data re-verification introduced in CSC is part of this! You can check out some of our work in this area at opcodeauth
The percentage reported by statsbox has always been a "rough" percentage that was computed from the sum(creditedblocks) for all users. (The total number of blocks was easilly assumed, based on the fact that it is a 56-bit contest).
That calculation was reasonable for contests where we did not have the potential of giving credit for a block more than once. However, with block re-verification (and now with the 25% of re-issued keyspace) there has been a lot of duplicate credit for the same blocks, so it's easy to see how the total number of credit blocks can exceed the number that were originally planned to be uniquely distributed.
We've attempted to scale back verification blocks slightly now, however to help ensure the validity of the network, we're continuing to do re-verification work as frequently as deemed necessary.
The invalid keyblocks have already begun redistribution, so yes they will be reprocessed (correctly this time). The person who correctly resubmits a validly re-computed version of that block will also receive credit. It's not possible for the old previously distributed version of the block to capture the second-pass credit for the block because the invalidly computed blocks are now being screened and discarded as they arrive at the keymaster.
Well, distributed.net participation should in theory be only idle cycles from machines that would normally be left on anyways, so the relative difference in power consumption between a running-but-idle machine and a computationally-intensive state should be relatively insignficant (much less significant than from a completely powered-off state).
Slashdot Mirror
FWIW, Our clients actually can speak a pure HTTP protocol for requesting data, allowing a simple /cgi-bin/rc5.cgi script handle direct serving, but the default communications mode is a more compact raw binary mode.
Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick
The "keymaster" (the machine that utilizes the ~3Mbit/sec) already distributes larger regions of uncomputed work to all of the "fullservers", which are the ones that in turn distribute the actual work to clients after splitting the blocks into sizes that correspond to what is needed by clients. You can see the list of all of the fullservers at http://n0cgi.distributed.net/rc5-proxyinfo.html
All of the chatty, multi-step network communications overhead with dealing directly with the clients is done at the fullserver level, including doing a windowed-history based coalescing on result submissions.
This is effectively what we already do with our keymaster, fullserver, personal proxy tiering. Personal proxies can be several layers deep if needed (many of our teams set up their own team servers using personal proxies).
Our network already uses a somewhat distributed model to spread out bandwidth demand as best as we can. You can see a bit of it if you look at our Proxy Status page at http://n0cgi.distributed.net/rc5-proxyinfo.html
Each of the servers listed are in in different DNS rotation grouped roughly by geographically named groups (that try to take in general network topology/connectivity). The servers listed there (known as "fullservers") handle all of the data communication needs requested by clients, and the fullservers in turn keep in contact with the "keymaster". The keymaster is the server responsible for the coordination of unique work between all of the fullservers and assigning out large regions of keyspace to the fullservers (which in turn split up the regions and redistribute to clients).
The hardware that we had hosted at Insync/TexasNet was actually 3 machines which together served several roles: our keymaster, one of our dns secondaries, our irc network hub, one of our three web content mirrors, and our ftp software distribution mirror (for actual client downloads).
It's unfortunate that the change in management at Insync/TexasNet caused them to want to re-evaluate all of the free-loading machines that were receiving donated services (there were apparently several others besides us) and cut off anyone who wasn't paying. Regardless, it's a touch economy and companies that want to survive have to look at where their costs are going and do their best to cut spending.
Many banks throughout the world continnue to use OS/2 for a lot of their systems. Just about the closest banks to Microsoft's main Redmond campus is a Washington Mutual branch, which happened to use OS/2 for their loan-clerks' desktop machines. I don't know if that is standard for all of their branches (or for their newly acquired branches). Incidentally, they use multiple information technology platforms, including IBM mainframe, AS400, UNIX variants, Windows NT, Novell, and OS/2 distributed environments.
Also, the vehicle title office for Austin, TX (in Georgetown) uses OS/2 for their license and vechicle database used behind the counter.
Check out http://www.distributed.net/source/ and read more about how to get the public source and what restrictions require that parts of it remain undisclosed.
Bringing the experience of greater platform support is one of many things that the distributed.net developers will immediately begin assisting United Devices with.
Windows is arguably a quite a bit more accessible via documented APIs than Linux is. Most of the "nifty" shareware utilities are just simple wrappers around a couple of core APIs. Whereas on Linux, many of the underlying configuration aspects need to be accessed by making a best-attempt at writing your own text parsing routines for the stuff under /proc, hoping that your parsing is robust enough to handle the variations that people with other configurations or other kernel versions. Windows unfortunately likes to reinvent new APIs to allow expanded access metaphors, such as WBEM/WMI, which has invented yet another way to access nearly every major configuration aspect that was previously available.
Of course, but it was probably just an attempt intended to infect all the existing GPL code projects with arcane Hungarian variable names.
Cutting off access immediately when something suspicious is discovered doesn't allow you to continue to collect evidence against the people doing the hacking and wouldn't allow you to prosecute as effectively as you could if you have definite evidence of some theft occurring. Evidence of repeated access tracing back to the same party each time also allows you to establish intent. I'm sure there was also some delay involved in allowing the notified authorities to come in and also observe.
Alpha was already announced to have been officially dropped as an Win2k+ platform nearly a year ago.
And remember that it is still a significant feat of backwards compatibility that many 16-bit DOS applications that were written in 1981 can still run under Windows 95/98/98SE/ME/NT/2k as a VDM application at all, without needing to boot to pure-mode DOS. That's arguably a considerable effort by itself and a tremendous amount of application compatibility development effort is involved in maintaining it to the level that it is at all.
You can still run DOS applications inside Windows ME (ie: as a window or full screen), but you just can't reboot the machine to a "pure" DOS prompt. If you have a boot floppy made with a previous version of DOS/Window9x, then you can get to a real DOS prompt that way. Also keep in mind that your config.sys and autoexec.bat are not parsed anymore either. Windows ME still has the dependence on the DOS underlyings and DOS really have not been completely removed, but the ability to easily access real-mode DOS has simply been made difficult. The primary purpose of doing this is to further enforce the movement of device drivers away from old style config.sys "DEVICE=" lines and various TSRs for supporting hardware and towards natively written 32-bit drivers. Such 32-bit drivers will generally be easier to port forward to future versions of Windows based on NT (Win2k and future) if those manufacturers don't already support NT. A side benefit is that native 32-bit drivers in Windows ME will generally be easier for users to configure and adapt to hardware changes (such as power state or docking changes). For example, being able to use native 32-bit network drivers instead of 16-bit DOS IPXODI/VLM drivers generally will have a tremendous boost in performance and usability. Switching from a 16-bit DOS CDROM SYS driver with MSCDEX to a fully native will generally not only be faster, but will allow access to long filenames. Although it is true that systems with older, no-longer supported hardware may still depend on DOS-mode TSRs or SYS drivers and may not be able to get updated drivers, Windows ME is not intended to be a general purpose upgrade for all older systems. Going forward, the next consumer OS after Windows ME will be based on NT and will have even more dramatic legacy hardware support issues, since many older manufacturers have neglected to support NT at all.
Yes, unfortunately it takes a few minutes to get pages and plans updated and things mailed out. The plan files of dbaker and nugget were updated at 07:17 UTC (2:17am ET). The changes to the front page to link to the announcement began at 07:00 UTC and were finally committed about 15 minutes later. The time up to that point was mostly spent preparing and sending out announcements to the mailing lists, and celebrating with those in #distributed on IRC.
cute, but we have only made clients available for processors with 32-bit registers, which means 386 and higher. :)
Blocks that are requested but not returned are eventually recycled and redistributed to other clients. The percentage completion that is noted on the stats page is based off of the number of blocks that have been successfully credited to people. The extra "slack" between the actual keyspace completed and the old percentage displayed on the stats page came from two factors: blocks that had been completed by two distinct people because of re-verification, and blocks that had been invalid and had been redistributed to someone else for proper computation.
1) If you were trying to cheat, we've noticed you and your efforts are ineffectual.
2) If you somehow have a broken client, read-only disk, or have run out of disk space and are inadvertantly submitting duplicates, you might want to check on it. You might be wasting cpu or network bandwidth that you are not aware of.
The keymaster codebase is the same as the fullserver/personal proxy codebase, only compiled with different compilation directives to enable/disable different parts of the codebase. The only portions of the codebase that would not be necessarily restricted would be the low-level network socket wrappers that do nothing more than providing an abstraction around the platform-specific network i/o calls.
Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such.
We understand the problems that are preventing us from becoming fully open source and are working to solve them. We have already done a lot of research work in this area and are working towards an eventual solution that can be fully open source. The data re-verification introduced in CSC is part of this! You can check out some of our work in this area at opcodeauth
The percentage reported by statsbox has always been a "rough" percentage that was computed from the sum(creditedblocks) for all users. (The total number of blocks was easilly assumed, based on the fact that it is a 56-bit contest).
That calculation was reasonable for contests where we did not have the potential of giving credit for a block more than once. However, with block re-verification (and now with the 25% of re-issued keyspace) there has been a lot of duplicate credit for the same blocks, so it's easy to see how the total number of credit blocks can exceed the number that were originally planned to be uniquely distributed.
We've attempted to scale back verification blocks slightly now, however to help ensure the validity of the network, we're continuing to do re-verification work as frequently as deemed necessary.
The invalid keyblocks have already begun redistribution, so yes they will be reprocessed (correctly this time). The person who correctly resubmits a validly re-computed version of that block will also receive credit. It's not possible for the old previously distributed version of the block to capture the second-pass credit for the block because the invalidly computed blocks are now being screened and discarded as they arrive at the keymaster.
Well, distributed.net participation should in theory be only idle cycles from machines that would normally be left on anyways, so the relative difference in power consumption between a running-but-idle machine and a computationally-intensive state should be relatively insignficant (much less significant than from a completely powered-off state).