A pin code would work. But thumbprint authorization would be quicker and easier, its all just a number to the underlying hardware.
Really, all it does is authorize the transaction and generate an amount of virtual cash (a transaction counter on the card should be encrypted into the transaction also [I left that out of the parent post] and incremented after every transaction). You don't want to throw in merchant, or datestamp. Its not needed. The merchant does that. This should only take the place of a credit card number. The merchant can do whatever they want with it, but it will only yield that amount, and it authorizes making theft a very small issue. The point is to not just have some arbitrary number that will work for any transaction under the sun.
I've always wondered why they didn't make CCs like this: A credit card sized 10-key (with decimal point, enter, and clear) with small one line LCD (or equivalent device) at top, with a thumbprint authentication utility on the side, and a printed circuit on the back for generating flux to simulate a magnetic strip for use in standard CC readers and maybe for automated amount entry(a circuit tuned to the GPS frequencies of the area where the card is allowed to be used could be embedded to charge small capacitors for power, and also possibly for use in theft detection). Embedded in the card is:
1) Account Private Key (encrypted by a reversible crypto with the key being the output of a perceptron neural net trained to recognize all authorized users thumbprints [or other biometric authentication could and should be used as it becomes viable] with a constant result set [this is much simpler than you would think])
2) Account Public Key (signed by institution [aka VISA or Verisign whichever gets to this idea first])
The card has 4 states: Off, Amount query, thumbprint authorization, and encrypted transaction display and encrypted transaction activation of magnetic strip.
Essentially the card waits for an authorized thumbprint to activate the card going to the amount input, after the user enters the amount (or maybe the amount can automatically be transferred to the card using the strip or smart card interface or something), the transaction is signed by the private key, and then the signed transaction is made available on the LCD and the pseudo magnetic strip (which is cleared after swiping it or hitting the clear button). You get the point, its just like a remote cert mechanism for transactions. Just an idea.
Well, first of all Avalon is a framework for a server microkernel. It is a generalized framework for any kind of server not app servers in particular. The aforementioned enterpriseobjectbroker is the application server container.
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
It is in the works. Even jBoss started somewhere, but at least this project does not offer a facade of a free sofware project. Hiding their documentation from potential users who don't wish to spend money on the project. Soon, it will support hot deployment, as well as being cluster capable (depending on configuration, all this really requires are a few changes to the AltRMI library). Until then, well if you really require 24/7 uptime, don't use it. Its not ready for that, yet. It is still a relatively young product.
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'
I found transaction management to be a moot point. You can handle transactions using any kind of transaction manager you wish. As long as you are consistent across your system, then you should have no problems getting a suitable system in place, with as much transparency as EJB Entity beans provide, and possibly more.
My biggest gripe with J2EE is the fact that they have you implement often times unneeded code. Their system is very rigid. Their code looks unruly and is often times redundant. This framework uses logical interfaces which takes seperation of concerns to the next level, and it doesn't force you to implement anything. It gives you complete freedom in how you implement your systems, and it doesn't have the audacity to claim to know a kill all for data storage and retreival interfaces (aka EJB-QL and CMP). The framework doesn't look perfect, but at least you are not shunned for not using their provided interfaces. J2EE is a model where you are reuired to accept the entire "all encompassing" system. I don't believe Sun has all the answers. Avalon assumes a common server framework. I can build on that.
Oh yeah, and the avalon project also comes with a growing (and already available) supply of opensource reusable components for: pooling, thread management, etc. Pretty nice. I never gave j2ee another look after I found this project. Also, james, the apache java mail server, runs off the phoenix microkernel. So you know it has to be stable.
Free yourself from J2EE: Avalon Project: (a well thought out framework for server development) Phoenix Server Microkernel: (a very good implementation of the avalon framework) Enterprise Object Broker: (allows publication of any java class as a "bean" without having to conform to Enterprise Bean Spec, with hairthin differentiation between local and remote object invocation)
I myself have always believed that server software development has always been unnecessarily complex. If you like actually being able to simply, freely, quickly create a server app, then these products are for you.
The minute you do what you preach is the minute I wil listen to you. Take your dog off your leash, set your fish free, quit using glue, oh that oil is decomposed biomatter oh you evil murdering bastard. There are many animal based products that you are using no matter how hard you try not too. We are very codependant on the lives of animals, even if it is on the taking of those lives. Native Americans of the plains honored the buffalo, even though they killed it to eat it, clothe them, etc. There has to be a balance. In order for us to live our lives, they must support us in any way they can.
You know what? I'm sure that if scientists could advance the state of medical technology without possibly harming animals, they would. This is all just a transitional stage to the point where we can literally just grow organs, customized to the recipient to save lives of all types. Maybe someday even other animals. Sometimes you just have to step on an animal to get to the next step. And believe me, other animals do the same thing. We are not being predatory here. We are aiming to save lives. A goal which you are saying we should just ignore. Why don't you open your mind even more, and realize that people may "blown" their lives by eating greasy foods and not exercising, but are you saying we become prejudiced against them. They are predisposed to do what they do. We are all products of our environment and our genetic makeup. Nothing is our fault. We are in this world to live this one life. Period.
You know I used to read about how viruses would essentially change the DNA of a cell to make it into a virus factory, and that gene therapy would essentially use the same mechanism as a virus to alter the DNA in humans, eventually. Now, couldn't we graft this thing on to some host animal. Inject a viral type mechanism which changes the DNA to that of the intended recipient(human recipient), while using that mRNA targetting scheme(slashdot article about a month ago) to only effect the grafted heart? Just a thought.
You know when I first heard that another space shuttle exploded, I began to pray....that Lance Bass was on that friggin' thing. Why couldn't he have gone boom! Who needs 'em.
I said theoretically, and I was right. Assuming it does not get broken down into a bunch of RISC like microinstructions it may very well be possible for a CISC instruction to perform the same computation as several RISC instructions in fewer clock cycles. It all depends on the underlying hardware. But the whole premise behind CISC is to have the kitchen sink of instructions sets. So fewer instructions have to be fetched and decoded to do the same action. CISC has the potential to be faster thats why I said theoretically.
Itanium 2 is an Intel product correct? And when did I ever mention P4s. Just being nitpicky.
Re:You lost me on the incredible leap of logic...
on
XML and Perl
·
· Score: 1
Really I think the logical fallicy here is the fact that people think that PERL is good at processing text files. PERL is good at parsing text files which can be expressed by a regular language. That is about the scope of the effectiveness of the PERL pattern matching's usefulness.
MHz is not an absolute measure of processor power. This is exactly what I explained above. Secondly, MHz is much a comparative measure of CPU power as top speed is of performance of a car. If you want to know the knitty-gritty you gotta read some specs. Thirdly, I don't care how fast the PPC is per clock cycle, Intel chips with their extended instruction sets operate faster. Lastly, I am supplying some information to people who know very little on the subject. If you want to write up a CPU Design FAQ for dummies, have at it.
Slashdot Mirror
My only question is, since when does it cost $600 / station for WinXP upgrades?
A pin code would work. But thumbprint authorization would be quicker and easier, its all just a number to the underlying hardware. Really, all it does is authorize the transaction and generate an amount of virtual cash (a transaction counter on the card should be encrypted into the transaction also [I left that out of the parent post] and incremented after every transaction). You don't want to throw in merchant, or datestamp. Its not needed. The merchant does that. This should only take the place of a credit card number. The merchant can do whatever they want with it, but it will only yield that amount, and it authorizes making theft a very small issue. The point is to not just have some arbitrary number that will work for any transaction under the sun.
I've always wondered why they didn't make CCs like this:
A credit card sized 10-key (with decimal point, enter, and clear) with small one line LCD (or equivalent device) at top, with a thumbprint authentication utility on the side, and a printed circuit on the back for generating flux to simulate a magnetic strip for use in standard CC readers and maybe for automated amount entry(a circuit tuned to the GPS frequencies of the area where the card is allowed to be used could be embedded to charge small capacitors for power, and also possibly for use in theft detection). Embedded in the card is:
1) Account Private Key (encrypted by a reversible crypto with the key being the output of a perceptron neural net trained to recognize all authorized users thumbprints [or other biometric authentication could and should be used as it becomes viable] with a constant result set [this is much simpler than you would think])
2) Account Public Key (signed by institution [aka VISA or Verisign whichever gets to this idea first])
The card has 4 states:
Off, Amount query, thumbprint authorization, and encrypted transaction display and encrypted transaction activation of magnetic strip.
Essentially the card waits for an authorized thumbprint to activate the card going to the amount input, after the user enters the amount (or maybe the amount can automatically be transferred to the card using the strip or smart card interface or something), the transaction is signed by the private key, and then the signed transaction is made available on the LCD and the pseudo magnetic strip (which is cleared after swiping it or hitting the clear button). You get the point, its just like a remote cert mechanism for transactions. Just an idea.
Well, first of all Avalon is a framework for a server microkernel. It is a generalized framework for any kind of server not app servers in particular. The aforementioned enterpriseobjectbroker is the application server container.
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
It is in the works. Even jBoss started somewhere, but at least this project does not offer a facade of a free sofware project. Hiding their documentation from potential users who don't wish to spend money on the project. Soon, it will support hot deployment, as well as being cluster capable (depending on configuration, all this really requires are a few changes to the AltRMI library). Until then, well if you really require 24/7 uptime, don't use it. Its not ready for that, yet. It is still a relatively young product.
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'
I found transaction management to be a moot point. You can handle transactions using any kind of transaction manager you wish. As long as you are consistent across your system, then you should have no problems getting a suitable system in place, with as much transparency as EJB Entity beans provide, and possibly more.
My biggest gripe with J2EE is the fact that they have you implement often times unneeded code. Their system is very rigid. Their code looks unruly and is often times redundant. This framework uses logical interfaces which takes seperation of concerns to the next level, and it doesn't force you to implement anything. It gives you complete freedom in how you implement your systems, and it doesn't have the audacity to claim to know a kill all for data storage and retreival interfaces (aka EJB-QL and CMP). The framework doesn't look perfect, but at least you are not shunned for not using their provided interfaces. J2EE is a model where you are reuired to accept the entire "all encompassing" system. I don't believe Sun has all the answers. Avalon assumes a common server framework. I can build on that.
Oh yeah, and the avalon project also comes with a growing (and already available) supply of opensource reusable components for: pooling, thread management, etc. Pretty nice. I never gave j2ee another look after I found this project. Also, james, the apache java mail server, runs off the phoenix microkernel. So you know it has to be stable.
Free yourself from J2EE:
Avalon Project: (a well thought out framework for server development)
Phoenix Server Microkernel: (a very good implementation of the avalon framework)
Enterprise Object Broker: (allows publication of any java class as a "bean" without having to conform to Enterprise Bean Spec, with hairthin differentiation between local and remote object invocation)
I myself have always believed that server software development has always been unnecessarily complex. If you like actually being able to simply, freely, quickly create a server app, then these products are for you.
Chemical dependance like needing a specific chemical to live. Food does not count as it is so readily available in many forms.
The minute you do what you preach is the minute I wil listen to you. Take your dog off your leash, set your fish free, quit using glue, oh that oil is decomposed biomatter oh you evil murdering bastard. There are many animal based products that you are using no matter how hard you try not too. We are very codependant on the lives of animals, even if it is on the taking of those lives. Native Americans of the plains honored the buffalo, even though they killed it to eat it, clothe them, etc. There has to be a balance. In order for us to live our lives, they must support us in any way they can.
You know what? I'm sure that if scientists could advance the state of medical technology without possibly harming animals, they would. This is all just a transitional stage to the point where we can literally just grow organs, customized to the recipient to save lives of all types. Maybe someday even other animals. Sometimes you just have to step on an animal to get to the next step. And believe me, other animals do the same thing. We are not being predatory here. We are aiming to save lives. A goal which you are saying we should just ignore. Why don't you open your mind even more, and realize that people may "blown" their lives by eating greasy foods and not exercising, but are you saying we become prejudiced against them. They are predisposed to do what they do. We are all products of our environment and our genetic makeup. Nothing is our fault. We are in this world to live this one life. Period.
I only say this because chemical dependance for living is not a very viable mechanism, given that we are probably fixing to go to war.
You know I used to read about how viruses would essentially change the DNA of a cell to make it into a virus factory, and that gene therapy would essentially use the same mechanism as a virus to alter the DNA in humans, eventually. Now, couldn't we graft this thing on to some host animal. Inject a viral type mechanism which changes the DNA to that of the intended recipient(human recipient), while using that mRNA targetting scheme(slashdot article about a month ago) to only effect the grafted heart? Just a thought.
You know when I first heard that another space shuttle exploded, I began to pray....that Lance Bass was on that friggin' thing. Why couldn't he have gone boom! Who needs 'em.
Can't there be a box that maps between internal to random external IPIds, just on the other side of the NAT?
I said theoretically, and I was right. Assuming it does not get broken down into a bunch of RISC like microinstructions it may very well be possible for a CISC instruction to perform the same computation as several RISC instructions in fewer clock cycles. It all depends on the underlying hardware. But the whole premise behind CISC is to have the kitchen sink of instructions sets. So fewer instructions have to be fetched and decoded to do the same action. CISC has the potential to be faster thats why I said theoretically.
What we all need is a giant mashed potato battery!!!
When I stated:
Myth: RISC is better than CISC
I did not imply the converse. You assumed it.
Yes, because all your data obviously fits in 3Gig.
I'm sure the replicator will be all about DRM, and all modern information protection methods.
hee hee!
Itanium 2 is an Intel product correct? And when did I ever mention P4s. Just being nitpicky.
Really I think the logical fallicy here is the fact that people think that PERL is good at processing text files. PERL is good at parsing text files which can be expressed by a regular language. That is about the scope of the effectiveness of the PERL pattern matching's usefulness.
The real question here is what is the other machine he was connecting too. Man that sucker must be one bad ass mother.
Packet level filtering on a router would be a bad thing. Unless you just like very decreased bandwidth.
MHz is not an absolute measure of processor power. This is exactly what I explained above. Secondly, MHz is much a comparative measure of CPU power as top speed is of performance of a car. If you want to know the knitty-gritty you gotta read some specs. Thirdly, I don't care how fast the PPC is per clock cycle, Intel chips with their extended instruction sets operate faster. Lastly, I am supplying some information to people who know very little on the subject. If you want to write up a CPU Design FAQ for dummies, have at it.
I agree, because it is a reverse engineered mortar shell :-P.