While Kurzweil, in his Singularity is near, showed to some extend that nearly all information-related technology increases exponentially (via S-curve parts for each new major paradigm), opponents ridiculed that generalization of Moore's Law by arguing that razors' blades, modern razor designs made by computers, won't grow exponentially to thousands of blades by 2020.
IMO that's short sighted: even with razors it very well might (though far from as hard as Moore's Law growth and things depending on that): the paradigm of 'what constitutes a razor' just has to change. But why shouldn't it actually happen that way?
Ironically, We could see manual razors with nanowire/microcavity-like structures, or just shrinking, ever more precise razor blades with tiny strengthening parallel interconnections, or whatever, until we have razors that are simple Micromechanical Systems or nanorazors, with growing miniaturization technology this may be economical and possible as a trend.
First off, you don't have to get the treatment(s) if you'll really decide don't want to, whenever available. If you try to look at the arguments behind the links without bias, here is one thing, you might realize from it:
This IS also about improving quality of life along the way, by increasingly minimizing most serious degenerative diseases including heart disease/obesity at the cellular level (even without extremely healthy lifestyles), that are so much cause of suffering and inefficiencies in our society. So this definitely will do the public a lot of good. It's about indefinite postponement of morbidity from degenerative disease; I know one of the SENS researchers: many seriously ill, but not old, people (heart disease, cancer, autoimmune) are also waiting for very first successes of the studies. The MPrize goal of sustained life extension does inevitably include mitigation of degenerative diseases in the long-term.
Two more things I'd like to point out about the project.
It was clear to all the participants that a release which isn't open source right away would be seen by many people with doubts. I'd even have them myself, if I hadn't seen the source.:) We know and understand.
This is just an early release, where we wait for user feedback, optimize good parts of the code for extensibility and audits, and then, do such audits, then, it's a promise, you'll get the code, not GPL, but definitely open source. We expect quite some people to forget about this now and wait until then. However, if you don't code-review your other OSS, counting on peer review, you might as well use it now, as it _has_ even now already been peer reviewed by others.
About the license and being 'free' - this is a company, but as little as commercial as possible - the aim is really a community of enlightened crypto users. Ciphire will, always, stay FREE for end-users, and non-commercial institutions. We need to earn money to run servers and maintain code. We will charge from companies for company-editions eventually for that. We need a business license to be on the safe side for that, too, but there's nothing unusual about it.
Btw - we will not forever have or want to run these servers alone - while they're not fully decentralized, they are not centralized as well, they just need to sync so that certificate information is globally unique. Your public key on those servers can never be manipulated either, even if we wanted (see FAQ).
I'm not going into every detail or question here, but I'd like to point out that there are official Ciphire forums, where really everything asked is answered, fast:
Or what would speak against suspending the
process with kill -STOP and reviving
it later with kill -CONT ? You can
keep connections alive for ca. 360 seconds.
I think some *nix flavors will also have the kernel keep
the connection of suspended processes alive (right?).
A small caveat is that you need to keep the tty open or the standard input/output file descriptors will be lost.:( And you just can't reboot in between.. but hey it's unix, not windows, you don't have to:D
But it's the only solution that works
independently of kernel versions and patches.
It's annoying to depend on specific kernel versions,
or operating systems for that matter, to access your encrypted data.
CFS sucks though because it tends to give you
some errors with newer nfs packages, and because you
JUST CANT compile the official cfs sources.. they wont
compile on any decent Linux. The BSD port works though. So, here is my quasi-port that will compile on newer linux systems that I made.
Actually, today the NSA is being less involved in any
surveillance related to the internet. They no longer
maintain the echelon systems. Under the Clinton administration,
there was a new agency assigned for this task, the SCS.
I think many ex-NSA employees were just changing to the SCS. The reason for
doing so is that they can continue to deny the existance of their
primary surveillance agency that way.
While Kurzweil, in his Singularity is near, showed to some extend that nearly all information-related technology increases exponentially (via S-curve parts for each
new major paradigm), opponents ridiculed that generalization of Moore's Law by
arguing that razors' blades, modern razor designs made by computers, won't grow
exponentially to thousands of blades by 2020.
IMO that's short sighted: even with razors it very well might (though far from
as hard as Moore's Law growth and things depending on that): the paradigm of 'what
constitutes a razor' just has to change. But why shouldn't it actually happen that way?
Ironically, We could see manual razors with nanowire/microcavity-like structures,
or just shrinking, ever more precise razor blades with tiny strengthening parallel
interconnections, or whatever, until we have razors that are simple Micromechanical
Systems or nanorazors, with growing miniaturization technology this may be
economical and possible as a trend.
...and the related SENS effort, ideally _before_ ranting. :)
All here discussed counter-arguments and more, have been dealt with here:
http://www.sens.org/concerns.htm
(Well except for the non-infinite porn supply during eternity, perhaps.)
The -very interesting and diverse- reasons why both projects are carried out:
http://www.sens.org/ENSdef.htm
First off, you don't have to get the treatment(s) if you'll really decide
don't want to, whenever available. If you try to look at the arguments
behind the links without bias, here is one thing, you might realize from it:
This IS also about improving quality of life along the way, by increasingly
minimizing most serious degenerative diseases including heart disease/obesity
at the cellular level (even without extremely healthy lifestyles), that are
so much cause of suffering and inefficiencies in our society. So this definitely
will do the public a lot of good. It's about indefinite postponement of morbidity
from degenerative disease; I know one of the SENS researchers: many seriously ill,
but not old, people (heart disease, cancer, autoimmune) are also waiting for very
first successes of the studies. The MPrize goal of sustained life extension does
inevitably include mitigation of degenerative diseases in the long-term.
Two more things I'd like to point out about the project.
:) We know and understand.
It was clear to all the participants that a release which
isn't open source right away would be seen by many
people with doubts. I'd even have them myself, if I
hadn't seen the source.
This is just an early release, where we wait for user
feedback, optimize good parts of the code for
extensibility and audits, and then, do such audits,
then, it's a promise, you'll get the code, not GPL, but
definitely open source. We expect quite some people
to forget about this now and wait until then. However,
if you don't code-review your other OSS, counting on
peer review, you might as well use it now, as it _has_
even now already been peer reviewed by others.
About the license and being 'free' - this is a company,
but as little as commercial as possible - the aim is
really a community of enlightened crypto users.
Ciphire will, always, stay FREE for end-users, and
non-commercial institutions. We need to earn money
to run servers and maintain code. We will charge from
companies for company-editions eventually for that.
We need a business license to be on the safe side for
that, too, but there's nothing unusual about it.
Btw - we will not forever have or want to run these
servers alone - while they're not fully decentralized,
they are not centralized as well, they just need to sync
so that certificate information is globally unique. Your
public key on those servers can never be manipulated
either, even if we wanted (see FAQ).
I'm not going into every detail or question here, but I'd
like to point out that there are official Ciphire forums,
where really everything asked is answered, fast:
forum.ciphire.com
Thanks for your attention:)
for one, welcome our superior north korean hacker army overlords!
How progressive, going open source -- again. They really can't decide, what matters more, trying to look progressive or hiding bad code, can they?
Or what would speak against suspending the :( And you just can't reboot in between.. but hey it's unix, not windows, you don't have to :D
process with kill -STOP and reviving
it later with kill -CONT ? You can
keep connections alive for ca. 360 seconds.
I think some *nix flavors will also have the kernel keep
the connection of suspended processes alive (right?).
A small caveat is that you need to keep the tty open or the standard input/output file descriptors will be lost.
But it's the only solution that works independently of kernel versions and patches. It's annoying to depend on specific kernel versions, or operating systems for that matter, to access your encrypted data. CFS sucks though because it tends to give you some errors with newer nfs packages, and because you JUST CANT compile the official cfs sources.. they wont compile on any decent Linux. The BSD port works though. So, here is my quasi-port that will compile on newer linux systems that I made.
Actually, today the NSA is being less involved in any surveillance related to the internet. They no longer maintain the echelon systems. Under the Clinton administration, there was a new agency assigned for this task, the SCS. I think many ex-NSA employees were just changing to the SCS. The reason for doing so is that they can continue to deny the existance of their primary surveillance agency that way.
:)
Try this link for a lot more details..
Oh, and don't forget, Oct 21st, is this years "flood echelon" day...