After seeing the interest in for example the RC5-56 challenge and others, it is a fact that there is a huge amount of people interested in participating in things like this. Maybe a distributed computing project, willing and open to take any (non criminal) tasks would not be that bad idea afterall. If there would be volunteers for building the crunching code using API provided, it would be possible to run projects with quite short lifecycle. I don't see SETI and RC5-56 and similar projects very interesting anymore. The task should be clear, reasonable and the estimated brute forcing time should be reasonable (like in 3 months maximum.) A dozen of little tasks per year, might prove more interesting.
Anyway, in this particular case, and 99% of others, the password is "IAmGod":) and in this case probably no distributed brute forcing is needed - just the plain old crackerjack should do.:) .
Some clips:
- " The simple fact is that the killer application for electronic cinema is advertising."
- "As low-cost electronic projectors land firmly in place for advertising, other types of content will gravitate to the theatre. Typically called alternative content, this could include independent films, Broadway plays, sporting events, pop concerts, or interactive games designed for cinema."
- "Rather than charge into digital cinema head-on while trying to figure out the business plan, it's far more likely that exhibitors will back into digital cinema by first implementing all other forms of electronically projected entertainment."
I believe the man behind this article has a good point, it's not that bad for the Cinemas, it will open a lot of new possibilities as well.
Re:Apparently, by cutting your own throat you get
on
What Free Cable?
·
· Score: 2
> Thank you Mr. "Holier-Than-Thou".
O:)
Apparently, by cutting your own throat you get
on
What Free Cable?
·
· Score: 2
You can break the law, and do all kinds of stupid things that seem fun for a second. But then you realize, or someone else makes you realize, that there was a reason why it is not wanted behaviour. Stealing is stealing, even if you steal bytes or a free porn channel.
>What you said, essentially means:
>I don't hate the dark skin, I think it's just a skin color. But sometimes I just cannot resist
> throwing baits at the Nigger lovers, who don't seem to think it is just that - skin color.
Exactly. Hardware is hardware, skin is skin, language is just a language. If you loose your control because of flamebait, then your opinion is vague. And yeah, us white people have no penis, finns are finished and truly.
Often, a flamebait leads to good discussion on the subject, but only if you are not too tied into your own opinion.
You can find this also here:
Following Text authored by Albert Langer not me, posted to ZCommerce mailing list on Fri 09, Jun 2000 . Still very valid:
<clip>
Warning: Following ideas are "off the top of my head". Not verified.
Q. "Where do I store the decryption key so that the cracker who
snarfs the database file can't get it (just in memory somewhere?),
and yet have the system be able to boot itself, including having
the key, without human intervention?"
A. "Using a 'one time' fast key in a client cookie".
Details:
1. Generate single Public/Private key pair off site. (Slow but only done
once). 2. Store only the Public key on web server. 3A. Store Private key very securely on internal site with controlled and
audited access etc. 3B. Or better still, immediately destroy it. Losing only the functionality
marked * below.
(Above are common to several previous responses. Following are new.) 4. Compress each CC card as received to shorter equivalent bit string (eg
convert the parts that are card type to enum, remove checksum, convert
remaining ascii digits to large binary integer and concatenate with the
enum. This makes the cookie below smaller, also removes some redundancy. 5. Use public key to generate and store encrypted copy of compressed CC
number on web server. (Fast). Do NOT store or transmit to internal site,
except on specific secure request with audit records maintained at web
server as well as internal site. Use same precautions as would be used for
storing plaintext CC numbers or private keys. 6. Generate XOR of encrypted copy and plaintext on server. (Very Fast). 7. Store the XOR in long term client cookie (expiry no later than CC expiry
date, or add expiry). 8. Destroy plaintext of CC AND the XOR on webserver. 9. Steps 4, 5 and 6 MUST be carefully designed to leave no trace of
plaintext or XOR on web server, eg in virtual memory paged to disk etc etc. 10. Step 7 MUST be designed so web server cannot store cookie in client
unless transmission protected by secure transport (https). 11. Step 7 SHOULD be designed so client cannot transmit cookie to anybody
other than the same server and with the same secure transport (possibly
impossible and a key flaw).
<clip>
See the link provided above for benefits of this approach, this post is already too long:)
I really hope they (and some others) can make the breakthrough, the processor market really needs some fresh new competition. Even though AMD and Intel are "battling", the fight is still, despite of the press - done in Intel's universe. See this article from turn of 2001.
But, when we see real pressure from multiple directions, we might see these companies develop something truly revolutionary, currently they don't have to - they just don't. A market situation in which Intel would have only around 40% slice, would nurture much more speedy development.
> It's already old news that there's a love-hate relation with the new iMac
I don't hate the iMac, I think it's just a piece of hardware. But sometimes I just cannot resist throwing baits at the mac lovers, who don't seem to think it is just that - hardware.:))
> use the money you saved to buy a few dozen of those hello-kitty dildos/vibrators instead
So, you thereby state the hello-kitty vibrator is a good substitute for this product? Personally, I don't use those. But hey, maybe I should give it a try!:)
From" It's clear that the new iMac is several leaps ahead of any other computer out there. Just like its predecessor."
It's easy to be several leaps ahead, when no-one else is on the same track. I sure hope it will stay such. When I am buying a computer, I am buying a computer and not a football with a LCD display sticked into it using a dildo. I also want to be able to go to the nearest shop and buy some accessory for the computer, instead of ordering it from outer space, which seems to be the origin of this design and the only authorized dealer.
I was interested to find out how much Linus has contributed to the dev. kernel during last month, I might as well post it here. Based on this he has followed the work multiple times a week during last month. And as I also see a couple of sunpoints, this means....ermm.... nothing.
Yes, but, it has not been utterly convincing before as it has had "experimental" status until the development version 2.5.14 which was released 05-May-2002. That's why I believe 2.6 will be what really makes the difference. Bluetooth has worked quite well for quite some time in Linux, but if you are making a decision for using that in a embedded device, you are likely to avoid anything "experimental" as the development project probably is an experiment already by itself:)
<clip>
in 2.5.14 Bluetooth support (no longer experimental!) (Maxim Krasnyansky, Bluetooth team)
<clip>
As it now seems that bluetooth kernel support will make it to 2.6, we will see Linux crawling through new paths to embedded devices. The floodgates are now really open, since this has been a true barrier for many companies forcing them to select something else which is otherwise inferior.
WLAN is a short-range solution, GPRS is long (or mid)-range. WLAN provides (if available) relatively high band-width for limited amount of users. GPRS provides more trustable relatively low-bit rate for more users. WLAN is governed by laws of a jungle. GPRS is strictly governed. I quess these are the main differences that the user will see, in addition that the standards are very different.
Nokia sells a card with support for both WiFi 802.11b and GPRS, maybe because the two things are different.
What you might see is automagic switch to 802.11b network when it's scanned to provide better and trustable bit-rate, and switch back to GPRS when the WLAN network fails.
In my definition, a true 1024 bit processor would be a 1024 bit chip optimized for 1024 bit code, must have address size of 1024 bits and 1024 bit databus, natural word size must be 1024 bits.
> Or in other words, will we see microprocessors
> with giga-bit (or even exa-bit) path ?
Using current technologies (DNA&Quantums excluded) the main problem will become the size. At some point, the barrier will be hit - there is a limit for the number of transistors you can fit in certain size
My quess is, however, that we will see a true 1024 bit processor by year 2008. I also quess that at this point we have seen the best the current technology can offer, and we will start shifting away from transistors. Majority of our computers will be based on these alternative technologies by year 2015.
"We developed an experimental prototype of a VLIW processor, capable of performing multiway branching and conditional execution, which is currently operational. The prototype has helped us investigate some of the hardware constraints in building VLIWs.
This processor executes tree-instructions within a ``classical'' VLIW architecture, that is, fixed-length VLIWs with preassigned slots for the different operations. The register state consists of 64 32-bit general purpose registers, 8 single-bit condition code registers, 4 memory address registers, program status word register, and some special registers. Each Very Long Instruction Word is 759 bits, which include..."
Now, when we know the relationship between IBM and Transmeta, can you combine the results of these two 'projects'.:)
A programmer with $8 000 monthly salary killed a spammer, resulting in a 50 year penalty.
Penalized programmer seeks compensation for $4 800 000 lost income (programmer has so vague understanding of money, that he forgets that this does not represent the correct value after 50 years;)
So, how actually does this differ from this spammer's case?
Slashdot Mirror
After seeing the interest in for example the RC5-56 challenge and others, it is a fact that there is a huge amount of people interested in participating in things like this. Maybe a distributed computing project, willing and open to take any (non criminal) tasks would not be that bad idea afterall. If there would be volunteers for building the crunching code using API provided, it would be possible to run projects with quite short lifecycle. I don't see SETI and RC5-56 and similar projects very interesting anymore. The task should be clear, reasonable and the estimated brute forcing time should be reasonable (like in 3 months maximum.) A dozen of little tasks per year, might prove more interesting.
:) and in this case probably no distributed brute forcing is needed - just the plain old crackerjack should do. :) .
Anyway, in this particular case, and 99% of others, the password is "IAmGod"
- SMPTE DC28 Technology Committee for Digital Cinema
- European Digital Cinema Forum (EDCF)
Article Backing into Digital Cinema.
Some clips:
- " The simple fact is that the killer application for electronic cinema is advertising."
- "As low-cost electronic projectors land firmly in place for advertising, other types of content will gravitate to the theatre. Typically called alternative content, this could include independent films, Broadway plays, sporting events, pop concerts, or interactive games designed for cinema."
- "Rather than charge into digital cinema head-on while trying to figure out the business plan, it's far more likely that exhibitors will back into digital cinema by first implementing all other forms of electronically projected entertainment."
I believe the man behind this article has a good point, it's not that bad for the Cinemas, it will open a lot of new possibilities as well.
> Thank you Mr. "Holier-Than-Thou".
O:)
free ingredients for blood sausages.
You can break the law, and do all kinds of stupid things that seem fun for a second. But then you realize, or someone else makes you realize, that there was a reason why it is not wanted behaviour. Stealing is stealing, even if you steal bytes or a free porn channel.
>What you said, essentially means: >I don't hate the dark skin, I think it's just a skin color. But sometimes I just cannot resist
.
> throwing baits at the Nigger lovers, who don't seem to think it is just that - skin color.
Exactly. Hardware is hardware, skin is skin, language is just a language. If you loose your control because of flamebait, then your opinion is vague. And yeah, us white people have no penis, finns are finished and truly
Often, a flamebait leads to good discussion on the subject, but only if you are not too tied into your own opinion.
You can find this also here:
:)
Following Text authored by Albert Langer not me, posted to ZCommerce mailing list on Fri 09, Jun 2000 . Still very valid:
<clip>
Warning: Following ideas are "off the top of my head". Not verified.
Q. "Where do I store the decryption key so that the cracker who snarfs the database file can't get it (just in memory somewhere?), and yet have the system be able to boot itself, including having the key, without human intervention?"
A. "Using a 'one time' fast key in a client cookie".
Details:
1. Generate single Public/Private key pair off site. (Slow but only done once).
2. Store only the Public key on web server.
3A. Store Private key very securely on internal site with controlled and audited access etc.
3B. Or better still, immediately destroy it. Losing only the functionality marked * below.
(Above are common to several previous responses. Following are new.)
4. Compress each CC card as received to shorter equivalent bit string (eg convert the parts that are card type to enum, remove checksum, convert remaining ascii digits to large binary integer and concatenate with the enum. This makes the cookie below smaller, also removes some redundancy.
5. Use public key to generate and store encrypted copy of compressed CC number on web server. (Fast). Do NOT store or transmit to internal site, except on specific secure request with audit records maintained at web server as well as internal site. Use same precautions as would be used for storing plaintext CC numbers or private keys.
6. Generate XOR of encrypted copy and plaintext on server. (Very Fast).
7. Store the XOR in long term client cookie (expiry no later than CC expiry date, or add expiry).
8. Destroy plaintext of CC AND the XOR on webserver.
9. Steps 4, 5 and 6 MUST be carefully designed to leave no trace of plaintext or XOR on web server, eg in virtual memory paged to disk etc etc.
10. Step 7 MUST be designed so web server cannot store cookie in client unless transmission protected by secure transport (https).
11. Step 7 SHOULD be designed so client cannot transmit cookie to anybody other than the same server and with the same secure transport (possibly impossible and a key flaw).
<clip>
See the link provided above for benefits of this approach, this post is already too long
I really hope they (and some others) can make the breakthrough, the processor market really needs some fresh new competition. Even though AMD and Intel are "battling", the fight is still, despite of the press - done in Intel's universe. See this article from turn of 2001.
But, when we see real pressure from multiple directions, we might see these companies develop something truly revolutionary, currently they don't have to - they just don't. A market situation in which Intel would have only around 40% slice, would nurture much more speedy development.
> Then there is the "13373r 7h4n y00" market segment ...(that would be you)
:)))
Woo-haa! Good bait, two fishes already. Reel'em in!
> It's already old news that there's a love-hate relation with the new iMac
:))
:)
I don't hate the iMac, I think it's just a piece of hardware. But sometimes I just cannot resist throwing baits at the mac lovers, who don't seem to think it is just that - hardware.
> use the money you saved to buy a few dozen of those hello-kitty dildos/vibrators instead
So, you thereby state the hello-kitty vibrator is a good substitute for this product? Personally, I don't use those. But hey, maybe I should give it a try!
From" It's clear that the new iMac is several leaps ahead of any other computer out there. Just like its predecessor."
It's easy to be several leaps ahead, when no-one else is on the same track. I sure hope it will stay such. When I am buying a computer, I am buying a computer and not a football with a LCD display sticked into it using a dildo. I also want to be able to go to the nearest shop and buy some accessory for the computer, instead of ordering it from outer space, which seems to be the origin of this design and the only authorized dealer.
> He owes us nothing, we have no right to demand anything or criticise.
;) against *bonk* jokes *bonk*.
*bonk* wake up *bonk* it is not necessary to defend your friend (I know everyone knows Linus
Yea right.If this is aesthetically pleasing, then see the Solar Sail, that one I could actually think of planting in my garden.
I was interested to find out how much Linus has contributed to the dev. kernel during last month, I might as well post it here. Based on this he has followed the work multiple times a week during last month. And as I also see a couple of sunpoints, this means....ermm.... nothing.
(29-May-2002)
version: changelog entries
2.5.19 : 7
2.5.18 : 10
2.5.17: 6
2.5.16: 8
2.5.15: 4
2.5.14 : 2
2.5.13: 3
2.5.12: 5
2.5.11: 5
2.5.10: 10
(24-Apr-2002)
Yes, but, it has not been utterly convincing before as it has had "experimental" status until the development version 2.5.14 which was released 05-May-2002. That's why I believe 2.6 will be what really makes the difference. Bluetooth has worked quite well for quite some time in Linux, but if you are making a decision for using that in a embedded device, you are likely to avoid anything "experimental" as the development project probably is an experiment already by itself :)
<clip> in 2.5.14 Bluetooth support (no longer experimental!) (Maxim Krasnyansky, Bluetooth team) <clip>
As it now seems that bluetooth kernel support will make it to 2.6, we will see Linux crawling through new paths to embedded devices. The floodgates are now really open, since this has been a true barrier for many companies forcing them to select something else which is otherwise inferior.
WLAN is a short-range solution, GPRS is long (or mid)-range. WLAN provides (if available) relatively high band-width for limited amount of users. GPRS provides more trustable relatively low-bit rate for more users. WLAN is governed by laws of a jungle. GPRS is strictly governed. I quess these are the main differences that the user will see, in addition that the standards are very different.
Nokia sells a card with support for both WiFi 802.11b and GPRS, maybe because the two things are different.
What you might see is automagic switch to 802.11b network when it's scanned to provide better and trustable bit-rate, and switch back to GPRS when the WLAN network fails.
therefor, the message content is: void.
In my definition, a true 1024 bit processor would be a 1024 bit chip optimized for 1024 bit code, must have address size of 1024 bits and 1024 bit databus, natural word size must be 1024 bits.
:)
correctify my mistakes
> Or in other words, will we see microprocessors
:)
> with giga-bit (or even exa-bit) path ?
Using current technologies (DNA&Quantums excluded) the main problem will become the size. At some point, the barrier will be hit - there is a limit for the number of transistors you can fit in certain size
My quess is, however, that we will see a true 1024 bit processor by year 2008. I also quess that at this point we have seen the best the current technology can offer, and we will start shifting away from transistors. Majority of our computers will be based on these alternative technologies by year 2015.
Save this for future reference.
See IBM's research on the VLIW subject.
:)
"We developed an experimental prototype of a VLIW processor, capable of performing multiway branching and conditional execution, which is currently operational. The prototype has helped us investigate some of the hardware constraints in building VLIWs.
This processor executes tree-instructions within a ``classical'' VLIW architecture, that is, fixed-length VLIWs with preassigned slots for the different operations. The register state consists of 64 32-bit general purpose registers, 8 single-bit condition code registers, 4 memory address registers, program status word register, and some special registers. Each Very Long Instruction Word is 759 bits, which include..."
Now, when we know the relationship between IBM and Transmeta, can you combine the results of these two 'projects'.
partly covering the subject, is here.
A programmer with $8 000 monthly salary killed a spammer, resulting in a 50 year penalty.
;)
Penalized programmer seeks compensation for $4 800 000 lost income (programmer has so vague understanding of money, that he forgets that this does not represent the correct value after 50 years
So, how actually does this differ from this spammer's case?
posting idiotic comments is free. I see two of them while typing this.
0 1
1 0
0 1