Forbidding encryption wouldn't help any
on
Blaming Encryption
·
· Score: 1
...against terrorism. The technology is out of the bottle and the "bad guys" will now have it forever. Banning computers (from *everywhere*) and telecommunications would help.
And of course airplanes.
And postal service.
And other vehicles.
And electricity.
Books, pencils and paper.
And all the technology that's been invented in past 10000 years.
And by banning all personal freedom. No, banning encryption is clearly giving in for the terrorists. Their goal is to restrict our choices and our freedom. Ban encryption and they have attained part of their goals.
It's very simple and clear that terrorists can do the same as intelligence services have been doing forever: using totally unbreakable one time pads, such as carefully selected phrases that sound totally innocent, but which have secretly agreed other meaning.
WTC accident is *NOT* encryption's or Phil Zimmermann's fault.
I was modded as a troll? Hopefully this will clarify my point.
When talking about video formats, PLEASE don't confuse following concepts: Application, transport layer/file format and CODEC.
CODEC is a collection of algorithms that CODes and EnCodes a (video) signal. Examples, MPEG-1, MPEG-4, Sorenson, FLI, even GIF can be considered as a CODEC.
Transport layer (or file format) contains the data stream for CODEC. There reasons transport layers are used such as streaming (multiplexing different streams in one stream) and enabling editability. Examples of a transport layer: AVI, QuickTime file format, ASF, GIF, FLI.
In some cases, such as FLI and GIF, the transport layer is not seperated from the CODEC. FLI and GIF files can only contain one kind of data.
In this context, the application is a piece of software that encodes, displays (decodes) or otherwise processes the transport layer stream.
Applications, like Windows Media Player, QuickTime Player and Real can all handle different transport layers that are encoded using many different CODECS. Gimmicks like Auto-upgradeability must be handled at the application level.
Auto upgradeable? Excuse me, do you have a method to auto update hardware now? If I'm not totally misguided, I understand for example cell phones will have hardware decoder.
A specific MPEG4 implementation might be auto-upgradeable, but only to the extent *any* other application/codec. For example, such as GIF, FLI, IFF/ANIM, Cinepac or Sorenson.
I finally have to open my mouth on a topic that's been annoying me for a long time in slashdot -- unit correctness or more like lack of it.
Please *please* remember 'K' stands for kelvin and 'k' for kilo. Also that 'M' is for mega and 'm' for milli.
Also, stop talking about file sizes / transfer speeds that are sized in millibits (mb) or kelvinbits (Kb). That's just plain wrong! 'B' usually stands for byte and 'b' for bit. A byte is 8 bits. Please remember this, because 8-fold error is quite bad.
Ye olde 8086 is much like the cannonical 1 cycle = 1 instruction CPU that you described. Since the minimum number of trasistors needed to execute an instruction is pretty much fixed (but occaisionally somebody somewhere figures out a way to reduce the number by a few), and the amount of time it takes for the signals to pass through a sequence of transistors is basically fixed (although better materials and smaller transistors can improve this), a 1 cycle = 1 instruction really just isn't capable of running at a high clock speed (Mhz).
8086 is *far* from being clock cycle per instruction design. The fastest instructions in it take 3 cycles (like NOP or register to register ADD). Instructions with complex effective address calculations take even longer. For example MOV (MOV = load/store instruction in x86 'architecture') immediate (immediate = the data is supplied in the instruction) to memory with base + index + displacement addressing takes massive *22* clock cycles. For comparison, in more modern architectures (anything since 486), it often takes just 1 or 2 effective clock cycles in ideal conditions.
Combine this with blinding laser weapons...
on
The Sound of Safety?
·
· Score: 1
Hear "chussh chussh chussh", turn around and you're blind.
More information about these cruel weapons here. --
Oh yes, most of the IE is loaded at startup time as the main user interface (DLLs or ActiveX controls). When you start IE on a PC, it only needs to load a relatively light "container". IE itself is basically just a huge ActiveX control. --
"The first invention is a method of compressing text stored in binary form, which expresses information as a series of noughts and ones, by comparing each word with its predecessor and recording only the differences between words. This compresses the data to an eighth of its normal size. "
While the information density in english text is about 0.6 - 1.3 bits per word, actually compressing data to that extent is not really possible. And even if it were and worked perfectly on english text, it wouldn't help you much - the majority of your data would be binary anyways (thus this algorithm wouldn't work). 8-fold compression is certainly not achievable in general case in practise. Most of the data volume (music & graphics files, like JPEG, MP3s and your 1337 p1r473 divxs) is already in acompressed form and you can only get a few percent off of it in the best case. So for the most of the data volume, their method would do nothing anyways. --
"The first invention is a method of compressing text stored in binary form, which expresses information as a series of noughts and ones, by comparing each word with its predecessor and recording only the differences between words. This compresses the data to an eighth of its normal size. "
While the information density in english text is about 0.6 - 1.3 bits per word, actually compressing data to that extent is not really possible. And even if it were and worked perfectly on english text, it wouldn't help you much - the majority of your data would be binary anyways (thus this algorithm wouldn't work). 8-fold compression is certainly not achievable in general case in practise. Most of the data volume (music & graphics files, like JPEG, MP3s and your 1337 p1r473 divxs) is already in acompressed form and you can only get a few percent off of it in the best case. So for the most of the data volume, their method would do nothing anyways. --
No, that's wrong. The chip is organized *internally* in a 16-kbit-by-16 array. The reason for that is you usually don't want to read one bit at a time, but at least something like 4, 8 or 16. Implementing 32-bit memory using 1-bit chips would take 32 chips and a hefty amount of control logic in the memory controller, unless you had serialized access, which in turn would be very slow. So putting things internally in an array is a standard practise for almost any kind of memory technology.
I agree with your comment about saving the core kernel state, but honestly, you wouldn't notice any much difference between storing it on a hard disk or to MRAM. If the state would be like 4 MB, seek and transfer combined would probably be less than 0.5 seconds.
I think the most interesting use for this chip at this point (if it was available) would be as a transaction log buffer for databases, journaling filesystems and such. --
Unavailable? For all I know, finnish computer magazines were full of those reviews (and ads) for games (Mikrobitti, PRINTTI, etc...). So that couldn't be the problem.:)
Hmm... lets see. Comparison of Z80 and P3 at 1 MHz.
P3 has two 32-bit wide ALUs (arithmetic-logical units) and one floating point unit. Each one of them can do one operation in one clock cycle (excluding multiply, divide, legacy instructions and branches), therefore in theory being able to execute 2 instructions per clock (in perfect conditions, perfect pipelining (no mem/reg dependencies) and no cache misses, page faults or interrupts).
Z80 has just one 8-bit wide ALU and no floating point OR multiply/divide instruction (and yes, it has two 16 bit registers too, but still it's an 8-bit system internally). Z80 is not pipelined, so it has to spend one (two?) complete cycles just for memory access and then two cycles for execution (minimum cycle time being 4 cycles).
Even in basic situations, at 1MHz, P3 would win Z80 by 800%. But in general each P3 instruction does a *lot* more useful work than a Z80 instruction. If you code multiply routine in Z80, it probably needs at least C+N*8 to C+N*16 cycles (C = some initialization N=number of bits), probably more. Original Pentium needs 9 or 11 cycles for multiply (AMD K5, K6 and K7 have troughput of one cycle per multiply IIRC). N being usually at least 16 and C maybe 32, Z80 would probably be able to do one 16-bit multiply in 200-400 cycles, all modern processors would be a *lot* ahead in this case. Even in case of general code, 1MHz P3 would probably come ahead some 2000%, at least 1000% faster, than 1 MHz Z80.
But I wouldn't be surprised if Z80 performance per transistor per MHz would be faster than P3's counterpart, though...
Lets see, Finland for example. Mobile phone adoption is at 70.1% last time I checked. Land lines were digitalized 10-20 years ago (meaning phoneline modem CONNECTs at 46000-54000bps). ISDN is available everywhere. Italy is another example, their mobile phone penetration is 50-60% nowadays. I don't believe their land line phones are crappy, either.
On the other hand, in USA, many local phone companies don't care much about landline infrastructure quality because local phone calls are free and only revenue comes from subscription fee and long distance. They've even been cheating by "splitting the line", halving bandwidth leading to dramatically lower quality.
Just 153kbit/s, what's the big deal? GPRS (GSM) *already* delivers 144kbit/s (can be more or less depending on bandwidth allocation, over 170kbit/s is possible in GPRS, right?) and UMTS will give 2Mbit/s next year.
Why bother, because you can already get 144kbit/s with GPRS, using just one GSM phone... Or at least in Finland, that is. I believe they've launched/launching GPRS already/shortly.
Treehuggers? That is hardly about hugging trees or anything like that, but trying to save our own collective ass! If I were you, I'd be a little bit more concerned about environmental issues than that! Why don't you buy cars that consume less or reduce car usage altogether? Or move closer to work / school / whatever? Considering environmental damage, maybe 10 bucks per gallon would be closer to reality... By the way, eventually we're going to run out of gas anyways, and expect gas to cost that $10 after some 15 years anyways, without tax! Sorry for being incoherant, it's 2:30 AM:)
AmigaOS, or should I say Kickstart, partially implemented recovering memory state after reboot (yeah, and this was done way back in 1985.) After rebooting, it wouldn't erase memory, but the OS would look for some system vector tables and do some basic sanity checks to see if the tables are corrupted. Some nice uses were for example a RAM-disk that could survive rebooting.
Sometimes the system hanged in repeating crashes and reboots, though. Then your only option was to really erase memory, for example by toggling The Most Significant Bit (ie. power switch).
Other bad point was that also viruses liked to hook themselves to those vectors, enabling them to survive reboots.
For the rest of the state, maybe you could log some state changes to for example display adapter, network card and etc. Or maybe your devices would have to expose their internal state in some compact structure you could just copy to log areas periodically (when the system would be in special recoverable state.)
Slashdot Mirror
And of course airplanes.
And postal service.
And other vehicles.
And electricity.
Books, pencils and paper.
And all the technology that's been invented in past 10000 years.
And by banning all personal freedom. No, banning encryption is clearly giving in for the terrorists. Their goal is to restrict our choices and our freedom. Ban encryption and they have attained part of their goals.
It's very simple and clear that terrorists can do the same as intelligence services have been doing forever: using totally unbreakable one time pads, such as carefully selected phrases that sound totally innocent, but which have secretly agreed other meaning.
WTC accident is *NOT* encryption's or Phil Zimmermann's fault.
Slight correction - in the parent, I was talking about MPEG-4, the CODEC, not MPEG-4 the standard.
I was modded as a troll? Hopefully this will clarify my point.
When talking about video formats, PLEASE don't confuse following concepts: Application, transport layer/file format and CODEC.
CODEC is a collection of algorithms that CODes and EnCodes a (video) signal. Examples, MPEG-1, MPEG-4, Sorenson, FLI, even GIF can be considered as a CODEC.
Transport layer (or file format) contains the data stream for CODEC. There reasons transport layers are used such as streaming (multiplexing different streams in one stream) and enabling editability. Examples of a transport layer: AVI, QuickTime file format, ASF, GIF, FLI.
In some cases, such as FLI and GIF, the transport layer is not seperated from the CODEC. FLI and GIF files can only contain one kind of data.
In this context, the application is a piece of software that encodes, displays (decodes) or otherwise processes the transport layer stream.
Applications, like Windows Media Player, QuickTime Player and Real can all handle different transport layers that are encoded using many different CODECS. Gimmicks like Auto-upgradeability must be handled at the application level.
A specific MPEG4 implementation might be auto-upgradeable, but only to the extent *any* other application/codec. For example, such as GIF, FLI, IFF/ANIM, Cinepac or Sorenson.
At least it very accurately describes the way actual customers behave like in software industry.
I finally have to open my mouth on a topic that's been annoying me for a long time in slashdot -- unit correctness or more like lack of it.
Please *please* remember 'K' stands for kelvin and 'k' for kilo. Also that 'M' is for mega and 'm' for milli.
Also, stop talking about file sizes / transfer speeds that are sized in millibits (mb) or kelvinbits (Kb). That's just plain wrong! 'B' usually stands for byte and 'b' for bit. A byte is 8 bits. Please remember this, because 8-fold error is quite bad.
That's all. Thanks for listening.
Ye olde 8086 is much like the cannonical 1 cycle = 1 instruction CPU that you described. Since the minimum number of trasistors needed to execute an instruction is pretty much fixed (but occaisionally somebody somewhere figures out a way to reduce the number by a few), and the amount of time it takes for the signals to pass through a sequence of transistors is basically fixed (although better materials and smaller transistors can improve this), a 1 cycle = 1 instruction really just isn't capable of running at a high clock speed (Mhz).
8086 is *far* from being clock cycle per instruction design. The fastest instructions in it take 3 cycles (like NOP or register to register ADD). Instructions with complex effective address calculations take even longer. For example MOV (MOV = load/store instruction in x86 'architecture') immediate (immediate = the data is supplied in the instruction) to memory with base + index + displacement addressing takes massive *22* clock cycles. For comparison, in more modern architectures (anything since 486), it often takes just 1 or 2 effective clock cycles in ideal conditions.
Hear "chussh chussh chussh", turn around and you're blind. More information about these cruel weapons here.
--
Oh yes, most of the IE is loaded at startup time as the main user interface (DLLs or ActiveX controls). When you start IE on a PC, it only needs to load a relatively light "container". IE itself is basically just a huge ActiveX control.
--
Um, you never clean the screen in the scanline based methods... :)
--
While the information density in english text is about 0.6 - 1.3 bits per word, actually compressing data to that extent is not really possible. And even if it were and worked perfectly on english text, it wouldn't help you much - the majority of your data would be binary anyways (thus this algorithm wouldn't work). 8-fold compression is certainly not achievable in general case in practise. Most of the data volume (music & graphics files, like JPEG, MP3s and your 1337 p1r473 divxs) is already in acompressed form and you can only get a few percent off of it in the best case. So for the most of the data volume, their method would do nothing anyways.
--
Ooops, sorry, wrong article! :)
--
"The first invention is a method of compressing text stored in binary form, which expresses information as a series of noughts and ones, by comparing each word with its predecessor and recording only the differences between words. This compresses the data to an eighth of its normal size. "
While the information density in english text is about 0.6 - 1.3 bits per word, actually compressing data to that extent is not really possible. And even if it were and worked perfectly on english text, it wouldn't help you much - the majority of your data would be binary anyways (thus this algorithm wouldn't work). 8-fold compression is certainly not achievable in general case in practise. Most of the data volume (music & graphics files, like JPEG, MP3s and your 1337 p1r473 divxs) is already in acompressed form and you can only get a few percent off of it in the best case. So for the most of the data volume, their method would do nothing anyways.
--
You need 32 of these in order to get just 1 megabyte (256kb x 32 = 8192 kb = 1024 kB). For 8 MB, you need 256 (8192 * 8 / 256kb) of these.
--
No, that's wrong. The chip is organized *internally* in a 16-kbit-by-16 array. The reason for that is you usually don't want to read one bit at a time, but at least something like 4, 8 or 16. Implementing 32-bit memory using 1-bit chips would take 32 chips and a hefty amount of control logic in the memory controller, unless you had serialized access, which in turn would be very slow. So putting things internally in an array is a standard practise for almost any kind of memory technology.
I agree with your comment about saving the core kernel state, but honestly, you wouldn't notice any much difference between storing it on a hard disk or to MRAM. If the state would be like 4 MB, seek and transfer combined would probably be less than 0.5 seconds.
I think the most interesting use for this chip at this point (if it was available) would be as a transaction log buffer for databases, journaling filesystems and such.
--
Since when inviduals are banned from investing in the stock market in Europe? I live in Europe and can indeed invest as much as I want to.
--
Unavailable? For all I know, finnish computer magazines were full of those reviews (and ads) for games (Mikrobitti, PRINTTI, etc...). So that couldn't be the problem. :)
Hmm... lets see. Comparison of Z80 and P3 at 1 MHz.
P3 has two 32-bit wide ALUs (arithmetic-logical units) and one floating point unit. Each one of them can do one operation in one clock cycle (excluding multiply, divide, legacy instructions and branches), therefore in theory being able to execute 2 instructions per clock (in perfect conditions, perfect pipelining (no mem/reg dependencies) and no cache misses, page faults or interrupts).
Z80 has just one 8-bit wide ALU and no floating point OR multiply/divide instruction (and yes, it has two 16 bit registers too, but still it's an 8-bit system internally). Z80 is not pipelined, so it has to spend one (two?) complete cycles just for memory access and then two cycles for execution (minimum cycle time being 4 cycles).
Even in basic situations, at 1MHz, P3 would win Z80 by 800%. But in general each P3 instruction does a *lot* more useful work than a Z80 instruction. If you code multiply routine in Z80, it probably needs at least C+N*8 to C+N*16 cycles (C = some initialization N=number of bits), probably more. Original Pentium needs 9 or 11 cycles for multiply (AMD K5, K6 and K7 have troughput of one cycle per multiply IIRC). N being usually at least 16 and C maybe 32, Z80 would probably be able to do one 16-bit multiply in 200-400 cycles, all modern processors would be a *lot* ahead in this case. Even in case of general code, 1MHz P3 would probably come ahead some 2000%, at least 1000% faster, than 1 MHz Z80.
But I wouldn't be surprised if Z80 performance per transistor per MHz would be faster than P3's counterpart, though...
Lets see, Finland for example. Mobile phone adoption is at 70.1% last time I checked. Land lines were digitalized 10-20 years ago (meaning phoneline modem CONNECTs at 46000-54000bps). ISDN is available everywhere. Italy is another example, their mobile phone penetration is 50-60% nowadays. I don't believe their land line phones are crappy, either.
On the other hand, in USA, many local phone companies don't care much about landline infrastructure quality because local phone calls are free and only revenue comes from subscription fee and long distance. They've even been cheating by "splitting the line", halving bandwidth leading to dramatically lower quality.
Just 153kbit/s, what's the big deal? GPRS (GSM) *already* delivers 144kbit/s (can be more or less depending on bandwidth allocation, over 170kbit/s is possible in GPRS, right?) and UMTS will give 2Mbit/s next year.
is a protocol Microsoft intends to get rich with. :)
Content means MSN.
that Microsoft has everything to lose in this issue. If WAP gets foothold, they won't be able to get their system (SOAP or whatever) through.
This is about Microsoft's life and death, once again. They don't want to give markets to mobile phone giants (Nokia, Ericcson and Motorola).
If I remember correctly, estimated 1 billion people will use mobile phones by 2010.
Why bother, because you can already get 144kbit/s with GPRS, using just one GSM phone... Or at least in Finland, that is. I believe they've launched/launching GPRS already/shortly.
Treehuggers? That is hardly about hugging trees or anything like that, but trying to save our own collective ass! If I were you, I'd be a little bit more concerned about environmental issues than that! Why don't you buy cars that consume less or reduce car usage altogether? Or move closer to work / school / whatever? Considering environmental damage, maybe 10 bucks per gallon would be closer to reality... By the way, eventually we're going to run out of gas anyways, and expect gas to cost that $10 after some 15 years anyways, without tax! Sorry for being incoherant, it's 2:30 AM :)
AmigaOS, or should I say Kickstart, partially implemented recovering memory state after reboot (yeah, and this was done way back in 1985.) After rebooting, it wouldn't erase memory, but the OS would look for some system vector tables and do some basic sanity checks to see if the tables are corrupted. Some nice uses were for example a RAM-disk that could survive rebooting.
Sometimes the system hanged in repeating crashes and reboots, though. Then your only option was to really erase memory, for example by toggling The Most Significant Bit (ie. power switch).
Other bad point was that also viruses liked to hook themselves to those vectors, enabling them to survive reboots.
For the rest of the state, maybe you could log some state changes to for example display adapter, network card and etc. Or maybe your devices would have to expose their internal state in some compact structure you could just copy to log areas periodically (when the system would be in special recoverable state.)
I don't know. :)