:Stalin disliked intellectuals, hence the Doctor's "plot" in 1953 [cyberussr.com], and killing off the officer corps [trussel.com] which almost led to the defeat of the Russian Army in the Winter War against Finland [winterwar.com].
From where I come from, it is now commonly believed that the officer corps extermination was a result of German intelligence operation executed to weaken Soviet Army command. As the most capable officers came from military dynasties, they had no problem labeling them as hidden enemies of the soviet regime and thus exploiting general Stalin's dislike towards intellectuals you referred to.
I believe these books may have some details on the subejct; however they are considered highly contraversial by many, so be warned:)
"What is the directive that throttles the number of Apache processes."
Oh, this is classics. The better question would've been "There is a directive throttling the number of Apache processes - true/false".
The answer for the original question is "I'm not interested in working for your company as you expect me remember some junk, which I would normally look up on as-needed basis". Duh.
How would this be different from hiring Kevin Mitnick to handle security issues?
Very different. Hacking and security is all about an *expertise*, which ultimately defines the quality of the work at the end of the day. In the privacy domain though the foundation is different - it's all about a *position*, the position of unconditional respect for individual privacy.
I seriously doubt one can suddenly develop such a respect if she was knowingly affiliated with doubleclick in the past. Too bad.
(For those who don't know applied number theory, when factoring a number you first try the small primes, then assuming two large factors of the form (p-n)(p+n) = p^2-n^2.)
For those who don't know applied number theory, here is somewhat better look at existing factoring algotirthms.
> 2 - XML is bloated, I can send binary much cheaper/easier
DUH. If your application is fine using binary data transfer, then USE it. HOWEVER, many applications that either have to A) communicate with other applications or B) have to deal with varying data sets benefit greatly from using XML. Anyone who has been programming for any length of time knows that while binary is more compact, it is less flexible and potentially more error prone.
I havn't read the article yet, but XML does NOT suck because: 1. the data and/or fields added at anytime WITHOUT breaking anything
not-XML specific
2. the data is in a heiracherical format, reducing data replication and allowing for a more sophisticated data structure.
not-XML specific.
3. the daya can be changed by a text editor.
One should agree that an ability to poke around what's essentially a *raw* data with a text editor is very very useful property. I simply cannot understand how we've managed to live with (gasp) binary data and (gasp gasp) even to modify it as needed...
4. and BECAUSE the data is text, it compresses REALLY well.
It compresses REALLY well, because it's freaking BLOATED in first place.
Who cares about 64 bits if the mainstream applications are written in a way that keeps wasting CPU power left and right without much care about peformance or efficient design ? Twice as large addressing space. Ok, so what ?
The one of the only few areas where 64 bits will make an actual tangible difference is a crypto and OS themselves, but these would not probably be a factor enough to speed the introduction of 64 bits CPU.
I mean if the money Intel spent on R&D would've gone on to the (re-)eduction of applicaiton designers, we would've still be doing just fine with old'n'trusty Pentiums. Slightly exagerrated, of course, but you got the point:)
IIRC, differential GPS is where you correct for clock error by using a fixed point with a very accurate latitude/longitude measurement as one of your "sattelites".
First of all, differential GPS operates with differences of a signal phases, not the timestamps.
Second, DGPS was the one and only high-precision ("tenths of millimeter") method available before Us army decided to remove all artificial noice from the signal in 2000. It is a static method though and requires two nodes to sit tight on their spots for at least few minutes to accumulate enough redundant data.
Thirdly, there is a kinetic methods that apply to a processing of noise GPS signals by moving objects. I dont remember all math behind it, but it works out into automatic cancellation of phase measurements error and gives a decent location and speed accuracy even with S/A on. Not suitable for high speed objects (such as missles), but more than enough for driving around.
> However, the article identifies a clear gap in the tooling and that gap needs to be addressed for XML to become a widespread success, instead of another buzzword hype.
It takes more than a set of good tools for a technology to become 'a widespread success'. A clear justification why XML is better than existing standard marshalling techniques would be a good starting point. ASN.1 DER, simple container LSB serialization and others.
I'm probably beating the dead horse here but XML has at least two properties rendering it useless for any performance-aware application:
(a) unlike, say, TLV it does not allow effeciently skipping parts of the data you dont need or aware of. I.e. in order to skip the section, you need to read and parse it first.
(b) XML's is a lazy man ASN.1 DER. It's all there in much more compact and elegant form. The only 'drawback' in the eyes of XML crowd is that it's binary. Sure, everyone knows that encoding numbers as strings is a definite way to improve upon the performance and scalability of everything from network protocols (SOAP, BXXP, UPNP) to a basic document processing. Right on.
The bottom line is that XML has probably reached its acceptance limits. Whoever accepted XML for granted or stuck with it or is not willing to learn about alternatives will keep on whining about tools being sucky. That's life, but OTOH it's only the small part of it.
In general, since X-boxes do not have the private key, the private key cannot be found given unrestricted access to X-boxes unless RSA is broken.
Sure it can, but not with a timing attack of course. Just nit picking.
Public key is essentially a pair of e and (p*q), where e - some number, p and q - primes. And the private key is an inverse of e by modulo (p-1)*(q-1). Thus factoring public key gives you private one.
.. that the logs on the target machines neither exist nor ever audited. And as with any probing method, the vulnerbility can very simply be fighted by rating incoming connections. Let the OpenSSL do its job efficiently, and guard against logistics of the vulnerability instead.
I have few years of commercial Windows coding experience and probably half as much of *nix one and I've gotta tell you that different APIs is not the biggest obstacle (and IDEs certainly are even the lesser one). It's more of the general practices issue. On Windows due to its closedness and incomplete documentation, the developer is haunted by a constant feeling of uncertainty. From simple things like an API call suddenly falling on patched version of WinNT to a methods declared as BOOL something() returing anything but 0 and 1.
Dont get me wrong - it's perfectly fine to have bugs in any code, including the OS, but the inability to fully investigate the problem forces developer to stay as independent from the system API as possible and be constantly ready for the weirdest induced f*ckups possible. Sure, there are tons of people who write the code tightly coupled with Windows, but with this often means creating a lot of work for support and deployment departments.
My general impression is that a good (as in "geeky professional") windows developer does not have much trouble moving to the *nix, while the move in the opposite direction is quite likely to be painful. Scroll the this very thread and see what I'm talking about - *nixoids complaining about Windows, and not the other way around:)
Few minor differences exists though (no poll(), limit on number of selectors(), AF_INET instead of PF_INET, etc), but these do not prevent many people (including myself) from writing clean networking code, which is portable between *nix/win32.
:Some very smart people have suggested this before, but this seems like the first real implementation.
One dont need to be smart to proclaim the benefits of using idle PC time for the distributed computing. Quitea fewcompanies are already doing just that.
It's now purely the issue of effective marketing and sales, not the technology. And grabbing CPU cycles to compensate musicians is just another business plan, certainly neat in idea, but not exactly novel.
Slashdot Mirror
:Stalin disliked intellectuals, hence the Doctor's "plot" in 1953 [cyberussr.com], and killing off the officer corps [trussel.com] which almost led to the defeat of the Russian Army in the Winter War against Finland [winterwar.com].
:)
From where I come from, it is now commonly believed that the officer corps extermination was a result of German intelligence operation executed to weaken Soviet Army command. As the most capable officers came from military dynasties, they had no problem labeling them as hidden enemies of the soviet regime and thus exploiting general Stalin's dislike towards intellectuals you referred to.
I believe these books may have some details on the subejct; however they are considered highly contraversial by many, so be warned
An unemployed OS developer is very different from unemployed VB scriptologist. Nothing personal though, good luck with the job search.
"What is the directive that throttles the number of Apache processes."
Oh, this is classics. The better question would've been "There is a directive throttling the number of Apache processes - true/false".
The answer for the original question is "I'm not interested in working for your company as you expect me remember some junk, which I would normally look up on as-needed basis". Duh.
> Jakb sdf aksvbmk aklsdfj alksjd SjkczLzeq adjskf sdkimz zoikjp ead!
Jakbs dfaks vbmka klsdf jalks jdSjk czLze qadjs kfsdk imzzo ikjpe adxxx
How would this be different from hiring Kevin Mitnick to handle security issues?
Very different. Hacking and security is all about an *expertise*, which ultimately defines the quality of the work at the end of the day. In the privacy domain though the foundation is different - it's all about a *position*, the position of unconditional respect for individual privacy.
I seriously doubt one can suddenly develop such a respect if she was knowingly affiliated with doubleclick in the past. Too bad.
It does not even qualify for a Flamebait.
It's 25k for just pointing them into the right direction.
I say, if they pay for an idea, there is a chance they will take it seriously this time...
No, I dont have an article unfortunately. I asked for the same thing though when I first saw these images :)
> Finding this in DNA insures that the organism is PURE EVIL.
Another detection method is to check E bit in the header if there is one.
Which one is the original - this or this.
The consensus on the BBS I found these at was that both are touched. Go figure.
Here
Also note that it's actually based on the ideas initially developed by HTCPCP protocol, which just turned 5 years.
(For those who don't know applied number theory, when factoring a number you first try the small primes, then assuming two large factors of the form (p-n)(p+n) = p^2-n^2.)
For those who don't know applied number theory, here is somewhat better look at existing factoring algotirthms.
> 2 - XML is bloated, I can send binary much cheaper/easier
DUH. If your application is fine using binary data transfer, then USE it. HOWEVER, many applications that either have to A) communicate with other applications or B) have to deal with varying data sets benefit greatly from using XML. Anyone who has been programming for any length of time knows that while binary is more compact, it is less flexible and potentially more error prone.
Repeat after me - ASN.1 ASN.1 ASN.1
I havn't read the article yet, but XML does NOT suck because:
...
1. the data and/or fields added at anytime WITHOUT breaking anything
not-XML specific
2. the data is in a heiracherical format, reducing data replication and allowing for a more sophisticated data structure.
not-XML specific.
3. the daya can be changed by a text editor.
One should agree that an ability to poke around what's essentially a *raw* data with a text editor is very very useful property. I simply cannot understand how we've managed to live with (gasp) binary data and (gasp gasp) even to modify it as needed
4. and BECAUSE the data is text, it compresses REALLY well.
It compresses REALLY well, because it's freaking BLOATED in first place.
Who cares about 64 bits if the mainstream applications are written in a way that keeps wasting CPU power left and right without much care about peformance or efficient design ? Twice as large addressing space. Ok, so what ?
:)
The one of the only few areas where 64 bits will make an actual tangible difference is a crypto and OS themselves, but these would not probably be a factor enough to speed the introduction of 64 bits CPU.
I mean if the money Intel spent on R&D would've gone on to the (re-)eduction of applicaiton designers, we would've still be doing just fine with old'n'trusty Pentiums. Slightly exagerrated, of course, but you got the point
If you run a company and have a choice between hiring two PhDs for the price of one BSc and select latter, you failed as a manager. As simple as that.
IIRC, differential GPS is where you correct for clock error by using a fixed point with a very accurate latitude/longitude measurement as one of your "sattelites".
First of all, differential GPS operates with differences of a signal phases, not the timestamps.
Second, DGPS was the one and only high-precision ("tenths of millimeter") method available before Us army decided to remove all artificial noice from the signal in 2000. It is a static method though and requires two nodes to sit tight on their spots for at least few minutes to accumulate enough redundant data.
Thirdly, there is a kinetic methods that apply to a processing of noise GPS signals by moving objects. I dont remember all math behind it, but it works out into automatic cancellation of phase measurements error and gives a decent location and speed accuracy even with S/A on. Not suitable for high speed objects (such as missles), but more than enough for driving around.
> However, the article identifies a clear gap in the tooling and that gap needs to be addressed for XML to become a widespread success, instead of another buzzword hype.
It takes more than a set of good tools for a technology to become 'a widespread success'. A clear justification why XML is better than existing standard marshalling techniques would be a good starting point. ASN.1 DER, simple container LSB serialization and others.
I'm probably beating the dead horse here but XML has at least two properties rendering it useless for any performance-aware application:
(a) unlike, say, TLV it does not allow effeciently skipping parts of the data you dont need or aware of. I.e. in order to skip the section, you need to read and parse it first.
(b) XML's is a lazy man ASN.1 DER. It's all there in much more compact and elegant form. The only 'drawback' in the eyes of XML crowd is that it's binary. Sure, everyone knows that encoding numbers as strings is a definite way to improve upon the performance and scalability of everything from network protocols (SOAP, BXXP, UPNP) to a basic document processing. Right on.
The bottom line is that XML has probably reached its acceptance limits. Whoever accepted XML for granted or stuck with it or is not willing to learn about alternatives will keep on whining about tools being sucky. That's life, but OTOH it's only the small part of it.
Forgot to read the context of the thread as usual :)
In general, since X-boxes do not have the private key, the private key cannot be found given unrestricted access to X-boxes unless RSA is broken.
Sure it can, but not with a timing attack of course. Just nit picking.
Public key is essentially a pair of e and (p*q), where e - some number, p and q - primes. And the private key is an inverse of e by modulo (p-1)*(q-1). Thus factoring public key gives you private one.
.. that the logs on the target machines neither exist nor ever audited. And as with any probing method, the vulnerbility can very simply be fighted by rating incoming connections. Let the OpenSSL do its job efficiently, and guard against logistics of the vulnerability instead.
I have few years of commercial Windows coding experience and probably half as much of *nix one and I've gotta tell you that different APIs is not the biggest obstacle (and IDEs certainly are even the lesser one). It's more of the general practices issue. On Windows due to its closedness and incomplete documentation, the developer is haunted by a constant feeling of uncertainty. From simple things like an API call suddenly falling on patched version of WinNT to a methods declared as BOOL something() returing anything but 0 and 1.
:)
Dont get me wrong - it's perfectly fine to have bugs in any code, including the OS, but the inability to fully investigate the problem forces developer to stay as independent from the system API as possible and be constantly ready for the weirdest induced f*ckups possible. Sure, there are tons of people who write the code tightly coupled with Windows, but with this often means creating a lot of work for support and deployment departments.
My general impression is that a good (as in "geeky professional") windows developer does not have much trouble moving to the *nix, while the move in the opposite direction is quite likely to be painful. Scroll the this very thread and see what I'm talking about - *nixoids complaining about Windows, and not the other way around
Few minor differences exists though (no poll(), limit on number of selectors(), AF_INET instead of PF_INET, etc), but these do not prevent many people (including myself) from writing clean networking code, which is portable between *nix/win32.
:Some very smart people have suggested this before, but this seems like the first real implementation.
One dont need to be smart to proclaim the benefits of using idle PC time for the distributed computing. Quite a few companies are already doing just that.
It's now purely the issue of effective marketing and sales, not the technology. And grabbing CPU cycles to compensate musicians is just another business plan, certainly neat in idea, but not exactly novel.
For some of us preferring trinary notation
Two Plus Two is Eleven !