That said, delphi can be a little nutty for updating to new versions.
That was MUCH MUCH more the case for versions 1-4 of delphi than for 5-7. I recompiled quite a few complex Delphi 5 projects in Delphi 7 with 10 minutes worth of code tweaks.
They just use quantum cryptography to generate the keys
Quantum techniques are applied not to key generation, but key distribution. This is a crucial distinction. Also, if you think you can bruteforce AES in a useful amount of time, have a ball. The people spending this kind of money on a QKD system are likely going to be picking appropriatly large key sizes for their message traffic.
Oh, but I do. My time. All I want is for telemarketers to pay me to cover my lost time incurred answering their phone call. Heinlein had it right in Cat
I postulate that the never changing, perfect from version 1.0 API is a fantasy, or at least such a rarely achieved goal that it is not significant that vendors of complex software (including Sun, IBM, and Microsoft) do not achieve it. Or did you miss the whole Java evolution from 1.0 to 1.4.1.2.3.1.2 or whatever......;)
So are you FUDding or have you been affected by an API change? What API call was it that changed? They add new ones all the time, but "change" actually happens pretty gradually.
Take 50 engineers, and describe to them this scenario: A carpenter is in need of a device with which he may attach multiple layers of wood or other materials by driving a short, narrow shaft of stiff metal through them. The device should be simple, inexpensive, human powered, and capable of removing these shafts (lets call them nails).
You are going to get 50 different designs, and a lot of them are gonna look a lot like a hammer.
IMHO, its disengenuous to accuse.Net of being a copycat of J2EE. They both largely address the same problem space, and do so within the paradigm of OOP. I/O streams were around before Java(tm) was Oak. Does that negate the usefulness of Java(tm)? No. It enhances it, because it reuses a well-known, well-understood design pattern.
So, which is better? That question is usually answered elsewhere...ie by the time you are addressing the RMI implementation of a system, you have already committed to a language/platform. I would guess that there isn't much appreciable difference between.Net remoting using binary serialization and the TCP channel and Java(tm) RMI via TCP.
If performance on the one of the platforms.Net runs on is important to you, YOU would do well to properly test scenarios important to you on those platforms, in both Java and.Net. If portability to arbitrary platforms is important to you, then.Net is out of the picture. If you currently posses either.Net or Java expertise, you would likely be wise to leverage that expertise to craft more efficient designs than to rely on one rmi implementation vs another.
The data serialization format is pluggable. Out of the box, you may use the binary serializer, the xml serializer, or the soap xml serializer. Or you may write your own.
1. True, but remoting learns a lot from DCOM's mistakes. 2. Not entirely true, if you consider System.EnterpriseServices.ServicedComponent (aka COM+) or the BYOT option. 3. There is an http transport for DCOM. 4. If you stipulate #2, what missing features remain to be gained?
1. The wire protocol and the data serialization format are decoupled from the remoting mechanism - ie you can do remoting using the xml formatter over msmq, or the soap formatter over http, or you can use the binary formatter over tcp, or you can use [your custom formatter] over [your custom channel].
Part of most self-check systems is a large scale for the bag well (the place where the grocery bags are) and a connection to a database that correlates UPC/SKU to item weight. The self-check register keeps tabs on what the combined weight of the currently rung items should be, and makes sure that it matches within an error threshold what the scale is reporting.
Oh yeah, a lot of stores also have one cashier monitoring 4-8 self check lanes.
You should give more credit to the business people. They do actually think about this stuff. Retail is a pretty cutthroat business, and larger chains don't get that way without smart people.
Great stuff - it really resonates with my personal belief - I am not quite yet willing to state with any certainty that God does or does not exist, but I am damn sure he is NOT the irrational temper-tantrum prone child the bible makes him out to be.
Both are at an acute angle from the horizontal normal to my line of sight. The split is right of center, so that the primary (digital) display is dominant.
If you are concerned about neck strain, be sure the height is correct....
Slashdot Mirror
That said, delphi can be a little nutty for updating to new versions.
That was MUCH MUCH more the case for versions 1-4 of delphi than for 5-7. I recompiled quite a few complex Delphi 5 projects in Delphi 7 with 10 minutes worth of code tweaks.
They just use quantum cryptography to generate the keys
Quantum techniques are applied not to key generation, but key distribution. This is a crucial distinction.
Also, if you think you can bruteforce AES in a useful amount of time, have a ball. The people spending this kind of money on a QKD system are likely going to be picking appropriatly large key sizes for their message traffic.
Oh, but I do. My time. All I want is for telemarketers to pay me to cover my lost time incurred answering their phone call. Heinlein had it right in Cat
Saying KDE is more secure than Windows is like saying a Goodyear Eagle GT (tire) is faster than a Ford Mustang....
Did you mean to compare KDE to the Explorer shell + various native win32 widget APIs?
fprintf was in ntdll.dll long before C# was but a gleam in Anders Hejlsberg's eye.
We saw it here in Dublin too, but my Dublin is in Ohio....
I postulate that the never changing, perfect from version 1.0 API is a fantasy, or at least such a rarely achieved goal that it is not significant that vendors of complex software (including Sun, IBM, and Microsoft) do not achieve it. Or did you miss the whole Java evolution from 1.0 to 1.4.1.2.3.1.2 or whatever...... ;)
So are you FUDding or have you been affected by an API change? What API call was it that changed? They add new ones all the time, but "change" actually happens pretty gradually.
Obviously, the poster must be a personal friend of Carly's
Take 50 engineers, and describe to them this scenario:
.Net of being a copycat of J2EE. They both largely address the same problem space, and do so within the paradigm of OOP. I/O streams were around before Java(tm) was Oak. Does that negate the usefulness of Java(tm)? No. It enhances it, because it reuses a well-known, well-understood design pattern.
.Net remoting using binary serialization and the TCP channel and Java(tm) RMI via TCP.
A carpenter is in need of a device with which he may attach multiple layers of wood or other materials by driving a short, narrow shaft of stiff metal through them. The device should be simple, inexpensive, human powered, and capable of removing these shafts (lets call them nails).
You are going to get 50 different designs, and a lot of them are gonna look a lot like a hammer.
IMHO, its disengenuous to accuse
So, which is better? That question is usually answered elsewhere...ie by the time you are addressing the RMI implementation of a system, you have already committed to a language/platform. I would guess that there isn't much appreciable difference between
I wouldn't be too suprised if Ja.Net did something just like that.
Imagine a popular geek writer penning a novel about an era when nanotech is rampant and carbon crystals are ubiquitous.
Imagine reading that novel.
Imagine
If performance on the one of the platforms .Net runs on is important to you, YOU would do well to properly test scenarios important to you on those platforms, in both Java and .Net. If portability to arbitrary platforms is important to you, then .Net is out of the picture. If you currently posses either .Net or Java expertise, you would likely be wise to leverage that expertise to craft more efficient designs than to rely on one rmi implementation vs another.
Repeat after me: there is no silver bullet.
The data serialization format is pluggable. Out of the box, you may use the binary serializer, the xml serializer, or the soap xml serializer. Or you may write your own.
1. True, but remoting learns a lot from DCOM's mistakes.
2. Not entirely true, if you consider System.EnterpriseServices.ServicedComponent (aka COM+) or the BYOT option.
3. There is an http transport for DCOM.
4. If you stipulate #2, what missing features remain to be gained?
1. The wire protocol and the data serialization format are decoupled from the remoting mechanism - ie you can do remoting using the xml formatter over msmq, or the soap formatter over http, or you can use the binary formatter over tcp, or you can use [your custom formatter] over [your custom channel].
2. It can be DCOM, but it doesnt have to be.
Disclaimer - I am in retail, but not grocery.
Part of most self-check systems is a large scale for the bag well (the place where the grocery bags are) and a connection to a database that correlates UPC/SKU to item weight. The self-check register keeps tabs on what the combined weight of the currently rung items should be, and makes sure that it matches within an error threshold what the scale is reporting.
Oh yeah, a lot of stores also have one cashier monitoring 4-8 self check lanes.
You should give more credit to the business people. They do actually think about this stuff. Retail is a pretty cutthroat business, and larger chains don't get that way without smart people.
hmmmmm
Great stuff - it really resonates with my personal belief - I am not quite yet willing to state with any certainty that God does or does not exist, but I am damn sure he is NOT the irrational temper-tantrum prone child the bible makes him out to be.
God didn't respond to the prayers so as to test peoples' faith.
</sarcasm>
Tell it brother!
AND GO HOGS!!! Woooo pig! Soooooeee!
True, and, IMO, pedanticly so. Retail stores prosecute the very same shoplifters who shop their stores.
I bet that shoplifters pay for things sometimes too.
2 18.1 LCDs (Viewsonic. 1 digital, 1 analog) ;)
nVidia Quadro NVS AGP
lucky me
Both are at an acute angle from the horizontal normal to my line of sight. The split is right of center, so that the primary (digital) display is dominant.
If you are concerned about neck strain, be sure the height is correct....
We don' need no steeeking laches!