This might help: the splitting Inheritance into its core aspects, and how those core aspects are implemented in Go and Rust:
https://lwn.net/Articles/54856...
There is a fundamental problem with planning innovation (doing something you or others did not do before):
Because you are doing something new, you cannot predict in front how much time you need as you don't know the problems you will encounter and the additional requirements/features that pop up during development (this always happens in software or system development).
PS. I am talking about real innovation. Most real innovations are build upon existing ones. So this holds only is you maximize sharing or re-use of existing systems, and not repeating your same trick over and over again. I will even go so far as saying: if you did a good planning your development is problably not very efficient.
Imitating voices is a whole other (interesting) problem. It might be possible that the computer of MIM can detect characteristics of Alice's voice so well that it can fool Bob (also take into account the amount of noise on mobile phone). That MIM only has to (manually) detect when Alice says the digits, and override it with its own computer-synthesized digits spoken to Bob. I think this is not far-fetched with the current state of voice technology.
Both the seed and the hash value must be shown on the display (concatenation of two digits each for example). Given that Bob uses the seed plus g^bd to calculate the last two digits and Alice uses the seed plus g^ac to generate the last two digits, the chance they are the same is very low. The random seed is, as mentioned in previous mail, generated after a,b,(plus c,d in case of MIM) are chosen.
If they arrive at different seed-hash values, and Alice or Bob says the number out loud (part of the protocol isn't it?), they would notice it, wouldn't they? (correct me if I'm wrong somewhere..)
I tried to write out what you are saying based on Diffie-Hellman using the Wikipedia page (correct me if I'm wrong). But then I encountered a possible solution (which might be already used):
Alice, MIM(man-in-middle), and Bob agree to use a prime number p=23 and base g=5. Alice chooses a secret integer a=6, then sends MIM (g^a mod p) MIM chooses a secret integer d=8, then sends Bob (g^d mod p) Bob chooses a secret integer b=15, then sends MIM (g^b mod p) MIM computes (g^b mod p)^d mod p = x, which gives hashf(x) = h MIM calculates integer c, such that hashf((g^a mod p)^c mod p) = hashf(y) = i, (which is 10000 combinations), then sends Alice (g^c mod p) Alice computes (g^c mod p)^a mod p = y
Then they all arrive at the same hash value, although different key-pairs are used.
BUT! What if the hash is calculated not only based on the function of both keys, but also by a random seed that is sent by Alice or Bob to the other side after the handshake procedure. Then it would be impossible to know 'c' such that the same hash value is found for Alice and Bob. The only thing left would be to generate 'c' such that x=y, but that is exactly the computation that is too expensive.
I agree with you that graph-based programming has the same complexity as text-bases programming. On the other side: a couple of years ago I used Labview, a 'graph'-based programming language/environment. It was incredible how fast I could implement something and debug it.
I still wonder why we still code in text files (as I do myself today). We invent dedicated databases for other to use, but we fail to use them ourselves for our main task. Would you go to a doctor if you knew doctors never go to doctors themselves?
In the meantime they invent these code generation tools, which are in my opinion the worst way to go because as soon as you have to edit the non-source code, you loose the connection with your 'graph'.
Therefore I stick to text as source, from which the objects, libraries and application are created in a consistent way.
If you are unwilling to understand that small improvements are better than no improvements, you might as well just kill yourself now, since the logical extension of your espoused philosophy would be that if your life is not perfect in every way, none of the good in it matters.
The problem with small improvements is that people think they did good and stop there. Sometimes things must get worse before there is momentum for change. In the end, we cannot predict if any of our actions are good or bad for the world in the long run. Also plain Chaos Theory will tell you that. For me, the best philosophy for life is still the Christian moral: Love God and not the material world, and secondly, love your fellow human beings, and do not judge.
> Please no. Wiki != CMS. I really hate the current trend of open source projects putting all their documentation in a wiki.
Why not? Wiki is the only tool that really allows multiple shared views on your (collaborative) information. Everyone can change and add his own view (page with tree of links for example).
Today, I put all my information at work in wiki pages, with the exception of passwords. The Wiki tool I use (and developed myself) has a flexible access rights system plus treats an attachment as a wiki-document as well. Unfortunately most open source wiki-tools are aimed at public websites and not corporate use where access rights are important, even in a closed intranet.
Another nice thing about Wiki tools is that it merges nicely with other tools (mail, etc.), as long as they have an HTTP interface (even Lotus Notes has that).
I dealt with J2EE only a little, but using Java for web development does not feel right. I just had to type, copy and &paste to much to get something working compared to languages Perl and PHP, and the final code does not look intuitive.
That brings me to this question: What happened to Java 1.5? Is it used anywhere? Can it be used with/in J2EE? Will J2EE be upgraded to something like J5EE?
Nowadays I just store information in Wiki's. A directory tree with documents is an outdated structure for storing (shared) knowledge. Because of Wiki's associative nature you can create multiple views of your information, and you can collaborate to very high degree.
BTW: The only formatting that is really relevant are headers, bullets, and simple tables.
I always found that these kind of pixel games, because they lack details, set our imagination to work, giving them a lot of 'atmosphere'.
--
I rest my case...
Also the base stations (GSM, UMTS) are reported (scientifically) to cause brain damage.
www.stopumts.nl is a good dutch site of one guy fighting against these types of radation, after noticing health problems himself.
Every programming language is already extensible. however, in the most popular languages (C en Java), the methods to compose elements are fixed (function decomposition, data structures, etc.).
The idea of this article is that you add more powerful macro-like methods but at the same time tell how the debugger how to interpret it. This seams quite a neat idea, however, It's not yet clear to me how this works in practice.
What I see in reactions like this is: Programmers develop complicated tools (databases, web interfaces, scripting languages, etc.) for others, but somehow, they don't want use their own tools themselves! Do you buy bread at a bakery when the baker does not want to eat its own bread?
If -say- 2 questions about the website's texts, ads or whatever, are put in the scrambled picture, you get a large number of possible answers for which the spammer cannot find out which two questions where asked in the first place!
A User Interface (for a browser) is effective if it connects to the workings of the brain, which works associatively: It associates concepts with a timeline (yesterday I visited a website about dogs), it associates causal relationships (after I found a dog I searched for dogfood) and it associates concepts with other concepts (the dogfood contained some fital vitamins which turned out to be important for dogs).
In our information jobs, we deal with different kinds of knowledge: code, documents, websites, personal information. For each type tools exists to browse, edit and query, but when it comes to information that overlaps different types of knowledge, we are stuck with manual labour and guessing.
Example: Who made requirements document X and which code implements this?
In the (I hope near) future, Operating systems are replaced by ontology editors, where instead of "files" we work with a network of accociated data, where ourselves, and agents, will navigate through, in a intuitive manner.
The operating system should continuously put the history of your document to disk: it should be a seamless versioning system. "publish"-points could be added if a user wants to.
Anyway, after a sleepness night, you start up your computer and "undo" some changes on the document you were working on last night.
Slashdot Mirror
This might help: the splitting Inheritance into its core aspects, and how those core aspects are implemented in Go and Rust: https://lwn.net/Articles/54856...
By saying that you "seek to be uncool", you prove that you DO care about the what world want/think.
I knew it, geeks are just wannabe nerds... You geeks are ruining our authenticity!
Everyone knows that the first thing to do, when creating acceleration software, is to test for race-conditions...
There is a fundamental problem with planning innovation (doing something you or others did not do before):
Because you are doing something new, you cannot predict in front how much time you need as you don't know the problems you will encounter and the additional requirements/features that pop up during development (this always happens in software or system development).
PS. I am talking about real innovation. Most real innovations are build upon existing ones. So this holds only is you maximize sharing or re-use of existing systems, and not repeating your same trick over and over again. I will even go so far as saying: if you did a good planning your development is problably not very efficient.
Imitating voices is a whole other (interesting) problem. It might be possible that the computer of MIM can detect characteristics of Alice's voice so well that it can fool Bob (also take into account the amount of noise on mobile phone). That MIM only has to (manually) detect when Alice says the digits, and override it with its own computer-synthesized digits spoken to Bob. I think this is not far-fetched with the current state of voice technology.
You are right, an adaptation is needed:
Both the seed and the hash value must be shown on the display (concatenation of two digits each for example). Given that Bob uses the seed plus g^bd to calculate the last two digits and Alice uses the seed plus g^ac to generate the last two digits, the chance they are the same is very low. The random seed is, as mentioned in previous mail, generated after a,b,(plus c,d in case of MIM) are chosen.
If they arrive at different seed-hash values, and Alice or Bob says the number out loud (part of the protocol isn't it?), they would notice it, wouldn't they? (correct me if I'm wrong somewhere..)
'i' must be 'h': hashf(y) = i -> hashf(y) = h
I tried to write out what you are saying based on Diffie-Hellman using the Wikipedia page (correct me if I'm wrong). But then I encountered a possible solution (which might be already used):
Alice, MIM(man-in-middle), and Bob agree to use a prime number p=23 and base g=5.
Alice chooses a secret integer a=6, then sends MIM (g^a mod p)
MIM chooses a secret integer d=8, then sends Bob (g^d mod p)
Bob chooses a secret integer b=15, then sends MIM (g^b mod p)
MIM computes (g^b mod p)^d mod p = x, which gives hashf(x) = h
MIM calculates integer c, such that hashf((g^a mod p)^c mod p) = hashf(y) = i, (which is 10000 combinations), then sends Alice (g^c mod p)
Alice computes (g^c mod p)^a mod p = y
Then they all arrive at the same hash value, although different key-pairs are used.
BUT!
What if the hash is calculated not only based on the function of both keys, but also by a random seed that is sent by Alice or Bob to the other side after the handshake procedure. Then it would be impossible to know 'c' such that the same hash value is found for Alice and Bob. The only thing left would be to generate 'c' such that x=y, but that is exactly the computation that is too expensive.
This guy claims the sun has a solid surface... Anyway, there are some nice pictures.
http://www.thesurfaceofthesun.com/
>There is no complex internal state to the system to (mis)understand.
:)
Unless you use Lotus Notes
I agree with you that graph-based programming has the same complexity as text-bases programming. On the other side: a couple of years ago I used Labview, a 'graph'-based programming language/environment. It was incredible how fast I could implement something and debug it.
I still wonder why we still code in text files (as I do myself today). We invent dedicated databases for other to use, but we fail to use them ourselves for our main task. Would you go to a doctor if you knew doctors never go to doctors themselves?
In the meantime they invent these code generation tools, which are in my opinion the worst way to go because as soon as you have to edit the non-source code, you loose the connection with your 'graph'.
Therefore I stick to text as source, from which the objects, libraries and application are created in a consistent way.
The problem with small improvements is that people think they did good and stop there. Sometimes things must get worse before there is momentum for change. In the end, we cannot predict if any of our actions are good or bad for the world in the long run. Also plain Chaos Theory will tell you that. For me, the best philosophy for life is still the Christian moral: Love God and not the material world, and secondly, love your fellow human beings, and do not judge.
> Please no. Wiki != CMS. I really hate the current trend of open source projects putting all their documentation in a wiki.
Why not? Wiki is the only tool that really allows multiple shared views on your (collaborative) information. Everyone can change and add his own view (page with tree of links for example).
Today, I put all my information at work in wiki pages, with the exception of passwords. The Wiki tool I use (and developed myself) has a flexible access rights system plus treats an attachment as a wiki-document as well. Unfortunately most open source wiki-tools are aimed at public websites and not corporate use where access rights are important, even in a closed intranet.
Another nice thing about Wiki tools is that it merges nicely with other tools (mail, etc.), as long as they have an HTTP interface (even Lotus Notes has that).
Nice, but this one look more high-tech to me:
http://www.turby.nl/
I dealt with J2EE only a little, but using Java for web development does not feel right. I just had to type, copy and &paste to much to get something working compared to languages Perl and PHP, and the final code does not look intuitive.
That brings me to this question:
What happened to Java 1.5? Is it used anywhere? Can it be used with/in J2EE? Will J2EE be upgraded to something like J5EE?
Nowadays I just store information in Wiki's. A directory tree with documents is an outdated structure for storing (shared) knowledge. Because of Wiki's associative nature you can create multiple views of your information, and you can collaborate to very high degree.
BTW: The only formatting that is really relevant are headers, bullets, and simple tables.
screenshots
I always found that these kind of pixel games, because they lack details, set our imagination to work, giving them a lot of 'atmosphere'. -- I rest my case...
ahref=http://news.com.com/Images+An+angry+Atari+pr incess%2C+bull+and+ninjas/2009-1043_3-5656760.html ?tag=st.prevhttp://news.com.com/Images+An+angry+At ari+princess%2C+bull+and+ninjas/2009-1043_3-565676 0.html?tag=st.prev>
I always found that these kind of pixel games, because they lack details, set our imagination to work, giving them a lot of 'atmosphere'.
Also the base stations (GSM, UMTS) are reported (scientifically) to cause brain damage.
www.stopumts.nl is a good dutch site of one guy fighting against these types of radation, after noticing health problems himself.
Every programming language is already extensible. however, in the most popular languages (C en Java), the methods to compose elements are fixed (function decomposition, data structures, etc.).
The idea of this article is that you add more powerful macro-like methods but at the same time tell how the debugger how to interpret it. This seams quite a neat idea, however, It's not yet clear to me how this works in practice.
What I see in reactions like this is: Programmers develop complicated tools (databases, web interfaces, scripting languages, etc.) for others, but somehow, they don't want use their own tools themselves! Do you buy bread at a bakery when the baker does not want to eat its own bread?
If -say- 2 questions about the website's texts, ads or whatever, are put in the scrambled picture,
you get a large number of possible answers for which the spammer cannot find out which two questions where asked in the first place!
Check this recent news story too:
c reature.reut/
http://www.cnn.com/2003/TECH/science/07/04/chile.
Anyone got a clue what this blob is supposed to be? Somebody's last supper?
A User Interface (for a browser) is effective if it connects to the workings of the brain, which works associatively: It associates concepts with a timeline (yesterday I visited a website about dogs), it associates causal relationships (after I found a dog I searched for dogfood) and it associates concepts with other concepts (the dogfood contained some fital vitamins which turned out to be important for dogs).
Example: Who made requirements document X and which code implements this?
In the (I hope near) future, Operating systems are replaced by ontology editors, where instead of "files" we work with a network of accociated data, where ourselves, and agents, will navigate through, in a intuitive manner.
Anyway, after a sleepness night, you start up your computer and "undo" some changes on the document you were working on last night.
That is what I am waiting for!