How many americans who are pissed off about this would also (before today) have agreed with donating money to Sinn Feinn and the IRA cause? [Background info: these organisations are largely funded by americans of irish ancestry].
I'm genuinely interested - I think all terrorism is an evil. I just hope that what motivates people now is not "this is war" but actually "this and all things like it are disgusting - how do we get together and try to prevent all of them".
One man's freedom fighter is another man's terrorist.
Even taking your result as valid, the assumption you make is that the random numbers occur all over your possible inputs.
A previous poster gave a good counter example, but it is very easy to see that if, in base 10, your random numbers are generated by an algorithm which only ever produces digits in the 0-4 range, you can see that there is some scope for compression.
Perhaps it is more easily seen if in base 0xff, you only produce digits in the range 0x0 -> 0xf...so all your random numbers will be of the form:
0? 0? 0? 0?...
proof that this is compressible is left as an exercise:-)
I like the sound of so-called "BioDiesel". This is a combustible fuel produced from a crop (for example oilseed rape).
This would seem to be the perfect fuel, since it would have energy density comparable (more/less - don't know) to existing gasoline/diesel but the big advantage of zero overall carbon emissions.
But but but...burning it produces CO2.
Well yes, but at least that much carbon had to go into growing the plants in the first place. So the net carbon increase in the atmosphere is zero. Of course, you might still get nasty sooty particulates which mess up people's lungs, but we'll wait for "fuel cells driven by gasoline/diesel" to get a cleaner version.
Does anyone have more info about this kind of fuel? In particular any down-sides? (Other than the fact it doesn't seem to be popular at the moment?)
The article says that 'impedance mismatch' causes performance loss. I don't see this as necessrily true. If anything, I'd expect the additional features (listed at length in the article) to cost performance...are any numbers available?
If not (i.e. it is a collection of controls...) then I wonder if you could build/buy a prototype of what the people at the AT&T labs in cambridge use: a 'bat' which allows you to point and click anywhere.
OK, so you need some ultrasound receivers and some funky software, but you did ask slashdot, right?
Does the fact that this clearly demonstrates that such legalese goes unread even by the providers weaken the case of the 'shrink wrap' license agreements?
But if (following your decrytpion attempt) you can decompress...then you probably succeeded in the decryption - result!
Which gives us an interesting (practical) weakness in the question-asker's proposal. It is no good obfuscating your file format if it is then going to be wrapped in a standardised compression format by the (pre-processor to) the encryption algorithm.
OK - so there are difficulties involved in laser-through-air, but don't write the idea off because of that.
These problems (shimmer due to convection-induced air movement, beam occlusion due to raindrops, etc) can be addressed by future enhancements.
For example, off the top of my head, both the above problems could be addressed by using a simple transparent carrier medium for the laser. It doesn't have to be anything fancy to deflect convection current and water - heck, glass would do.
Granted glass would be brittle, so you might want to encase it in something else. You would also have the problem of suspending the carrier medium, so you might want to bury the result out of harm's way.
Well, XML can handle binary data encoded as base64 I believe.
The 'combination of the two' is what I was alluding to above. I guess that there should be an automatic way of taking an XML DTD and translating to an ASN.1 definition (and vice versa). This would then allow particular objects to be translated between XML and BER.
I believe that this seemingly-small point is a major reason why early IETF protocols were implemented more easily. It is just so easy to debug SMTP with telnet...debugging an X.400 connection is worlds more difficult.
However, I have been impressed by ASN.1 'pretty printing' tools which take some BER (and the definition of the ASN.1) and dump it out in a nice human-readable format. This takes away XML's main advantage I can see (apart from the fact that XML is popular and the way of the future that is:-)
Don't agree about the level. Have you seen X.400/X.500? (Last time I looked they weren't available on-line so it is reasonable if the answer is no:-)
ASN.1 can be (and is) used to represent some very complex objects (an email message with lots of different header type, complicated address, with fourteen different types of attachment, lots of which are themselves structured messages...you get the idea).
I may be missing something in XML but I don't see that it gives you anything except a "wire protocol" as well. It is a way to serialise an object into a platform-independent format.
The design choices for the format are different (wordy...good for humans, bad for network transmission) but that seems to be the only difference, technically speaking. [Apart from the (important) fact that an XML object self-describes its type...but this doesn't seem to be that useful in practice because of namespace issues. ASN.1 data types in a given protocol generally deal with this by including some data early on which identifies how to interpret the rest. e.g. an LDAP operation has a 'type').
I don't agree that they are totally different domains. Both are ways of encoding a 'useful' set of primitive data types structured and nested to arbitrary complexity.
Both can encode 'binary' data (is an integer binary? is a jpeg?), but with different levels of efficiency.
Simple tools exist to dump BER in a very xml-like human readable format *given the ASN.1 definition*. Granted they have been traditionally used for different purposes (XML more text oriented, ASN.1 more 'binary' oriented) but the featureset of the two encoding methods in very similar.
Re:Centralized ASN.1 vs. Decentralized XML Standar
on
Inside XML
·
· Score: 1
The bit-stealing line is good, but I'm not sure where you are coming from with the ambiguity comment. Given an encoded data stream and the ASN.1 to decode it you can get back your data structure. No problems. Of course you have (some) choice in how you represent the data when you encode, but that is common (and useful).
I don't think that the top-down/bottom-up thing is correct. In the case of both XML and ASN.1, certain 'tags' are set aside for unregistered use (PRIVATE tags in ASN.1) and if you use any such tags you need to agree with the person with whom you are exchanging data what format you are using. No difference I can see except the aforementioned 'religious' point of view with respect to the CCITT/ITU/ISO.
The only (programmatic) advantage I can see that XML could have is that the data describes its own type. BER-encoded data doesn't - you need to know what kind of object to expect.
However, this has been hobbled in XML by exactly the lack of central control of namespace you mention....I have no idea whose 'Invoice' DTD to use to interpret this object...so I don't see this as a practical advantage.
I don't know if it is just me, but does anyone else here deal with that "interesting" data represenation language "ASN.1" (Abstract Syntax Notation 1) with its associated binary representation BER (Basic Encoding Rules)?
ASN.1 defines a textual language for the representation of named primitive data types (strings, integers, real numbers, bitstrings, etc), structured ways of grouping them together (sequences, sets, etc).
BER provides a machine-independent way for these to be represented 'on-the-wire'. These representations are also abritrary-precision and have other cool features.
Fortunately or unfortunately (depending on your perspective and religion with respect to 'ISO/OSI' standards) ASN.1 never really caught on in the Internet world (SNMP and LDAP permitting).
However, I see it as playing a very similar role as XML. (Machine-independent representation of arbitrarily complex structured/nested data).
The main difference is that the BER represenation of ASN.1 is a (somewhat complex) binary format, whereas XML is text-based.
This is both an advantage and a disadvantage (more compact, harder for humans to read).
I'm wondering whether it is worth anyone's time writing up a BER XML translator to attack those 'but XML is too verbose' criticisms...
It might not work for your app, but I would recommend considering defining the operations you need to perform as a 'protocol'.
This protocol could be as simple as some XML/HTTP or whatever you like. You can then implement one server and whichever clients you like.
Once you have done this, you can develop a web client (which just translates web forms to and from your protocol) or a native UI.
If you DON'T do this and you go the web route, your web app will be a combination of the server+client components and it will be difficult to seperate them in the future.
Speaking from experience here...web interface not bad, but the fact it is co-located with the server encourages short-cuts best not taken.
Nice to see, especially the comments at the bottom about the road to widespread usage including not just open source release but also the standardisation of an API to allow compatible implementations.
Amusingly, the biggest-horsepower compute farm in the company is likely to be the collection of people using office apps. You can't easily buy processors below around 700Mhz these days and desktop apps do little but wait for keypresses.
The only real impact that people would notice would be in terms of memory footprint. Those high-res wallpapers and ten copies of Excel (or Staroffice, whatever) like to slurp the RAM and stay resident. So unfortunately, it is unlikely to be unnoticed by those donating their cycles...which is the real killer.
Bizarrely enough, a whole new filesystem doesn't count as 'infrastructure' in the sense of the kernel. If I've got the right end of the stick, each file system interfaces to the rest of the kernel through the VFS (well pretty much) so that no 'core' kernel changes when you add a new filesystem. (There are probably plenty of exceptions to this).
[This is one example of what people mean when they say that the kernel *is* object-oriented whenever people suggest coding it in C++.]
> This strikes me as a somewhat flawed design,
> because if laws apply, they should apply
> everywhere!
Well they do. It is just that the definition of 'everywhere' isn't as obvious as you might think.
Physical laws apply where they are supposed to, in space-time - all of it (which is my working definition of 'everywhere').
The only oddity is that it is possible for things to leave 'everywhere', which is, I admit, a fairly strange property.
Your reference to topology is the clue here. Lets drop back to the 2-d analogues for convenience of terminology.
People would be happy with an 'infinite plane' of spacetime. If you are used to that idea, then the fact the space-time might be bounded (like the 2-d surface of a sphere or even a torus) seems really odd, but with analogies like this one people can get their head round it.
(Although it is easy even then to get into mental traps. "What do you mean I can't go further North? I can just keep walking can't I? Thats not going to suddenly stop being North is it?")
But both of those (2-d) surface mentioned above lack 'holes'. But we only expect that because we aren't near one.
But if we lived in a chunk of flat space-time (i.e. no gravity) we would probably find the idea of curved space time prepostorous. ("What do you mean, things would just move 'on their own'? Yeah right").
Yes, its an idea which has merits in many areas. Basically installing from source is good when the compile-time dependencies are significant, when it doesn't add too much additional time to the install or if other constraints (e.g. political) prefer the use of source.
(It also must be a good idea, since Alan Cox has made comments suggesting this direction for kernel modules on linux-kernel a few times.:-)
> Unless the new location has a LOT of free
> energy, it will take too much
> effort/money/energy to make
> it habitable.
Which is one of the nice things about being on the moon of course, 50% (100%?) of the time you gets lots and lots of lovely bright sunlight. No atmosphere, no clouds, energy just pouring down at you.
Slashdot Mirror
You can take a look at http://www.runescape.com for a free-to-play MMORPG which is funded by banner ads in the client.
:-)
So you were right
Which is also flamebait.
How many americans who are pissed off about this would also (before today) have agreed with donating money to Sinn Feinn and the IRA cause? [Background info: these organisations are largely funded by americans of irish ancestry].
I'm genuinely interested - I think all terrorism is an evil. I just hope that what motivates people now is not "this is war" but actually "this and all things like it are disgusting - how do we get together and try to prevent all of them".
One man's freedom fighter is another man's terrorist.
Even taking your result as valid, the assumption you make is that the random numbers occur all over your possible inputs.
...
:-)
A previous poster gave a good counter example, but it is very easy to see that if, in base 10, your random numbers are generated by an algorithm which only ever produces digits in the 0-4 range, you can see that there is some scope for compression.
Perhaps it is more easily seen if in base 0xff, you only produce digits in the range 0x0 -> 0xf...so all your random numbers will be of the form:
0? 0? 0? 0?
proof that this is compressible is left as an exercise
I like the sound of so-called "BioDiesel". This is a combustible fuel produced from a crop (for example oilseed rape).
This would seem to be the perfect fuel, since it would have energy density comparable (more/less - don't know) to existing gasoline/diesel but the big advantage of zero overall carbon emissions.
But but but...burning it produces CO2.
Well yes, but at least that much carbon had to go into growing the plants in the first place. So the net carbon increase in the atmosphere is zero. Of course, you might still get nasty sooty particulates which mess up people's lungs, but we'll wait for "fuel cells driven by gasoline/diesel" to get a cleaner version.
Does anyone have more info about this kind of fuel? In particular any down-sides? (Other than the fact it doesn't seem to be popular at the moment?)
The article says that 'impedance mismatch' causes performance loss. I don't see this as necessrily true. If anything, I'd expect the additional features (listed at length in the article) to cost performance...are any numbers available?
If not (i.e. it is a collection of controls...) then I wonder if you could build/buy a prototype of what the people at the AT&T labs in cambridge use: a 'bat' which allows you to point and click anywhere.
OK, so you need some ultrasound receivers and some funky software, but you did ask slashdot, right?
I was going to ask "what is your favourite recipe for ketchup", but you beat me to it.
Does the fact that this clearly demonstrates that such legalese goes unread even by the providers weaken the case of the 'shrink wrap' license agreements?
Because you haven't shopped around?
.org.uk) now only £9.99 for 2 years .com,.net & .org from only £11.99 per year!"
.com costs so much more then registering a .co.uk?
http://www.freeparking.co.uk/
" Nominet Domains (.co.uk,
So how come registering a
But if (following your decrytpion attempt) you can decompress...then you probably succeeded in the decryption - result!
Which gives us an interesting (practical) weakness in the question-asker's proposal. It is no good obfuscating your file format if it is then going to be wrapped in a standardised compression format by the (pre-processor to) the encryption algorithm.
OK - so there are difficulties involved in laser-through-air, but don't write the idea off because of that.
These problems (shimmer due to convection-induced air movement, beam occlusion due to raindrops, etc) can be addressed by future enhancements.
For example, off the top of my head, both the above problems could be addressed by using a simple transparent carrier medium for the laser. It doesn't have to be anything fancy to deflect convection current and water - heck, glass would do.
Granted glass would be brittle, so you might want to encase it in something else. You would also have the problem of suspending the carrier medium, so you might want to bury the result out of harm's way.
Oh wait...
Well, XML can handle binary data encoded as base64 I believe.
The 'combination of the two' is what I was alluding to above. I guess that there should be an automatic way of taking an XML DTD and translating to an ASN.1 definition (and vice versa). This would then allow particular objects to be translated between XML and BER.
Would this be the best of all possible worlds?
I agree about the human readability.
:-)
I believe that this seemingly-small point is a major reason why early IETF protocols were implemented more easily. It is just so easy to debug SMTP with telnet...debugging an X.400 connection is worlds more difficult.
However, I have been impressed by ASN.1 'pretty printing' tools which take some BER (and the definition of the ASN.1) and dump it out in a nice human-readable format. This takes away XML's main advantage I can see (apart from the fact that XML is popular and the way of the future that is
Don't agree about the level. Have you seen X.400/X.500? (Last time I looked they weren't available on-line so it is reasonable if the answer is no :-)
ASN.1 can be (and is) used to represent some very complex objects (an email message with lots of different header type, complicated address, with fourteen different types of attachment, lots of which are themselves structured messages...you get the idea).
I may be missing something in XML but I don't see that it gives you anything except a "wire protocol" as well. It is a way to serialise an object into a platform-independent format.
The design choices for the format are different (wordy...good for humans, bad for network transmission) but that seems to be the only difference, technically speaking. [Apart from the (important) fact that an XML object self-describes its type...but this doesn't seem to be that useful in practice because of namespace issues. ASN.1 data types in a given protocol generally deal with this by including some data early on which identifies how to interpret the rest. e.g. an LDAP operation has a 'type').
I don't agree that they are totally different domains. Both are ways of encoding a 'useful' set of primitive data types structured and nested to arbitrary complexity.
Both can encode 'binary' data (is an integer binary? is a jpeg?), but with different levels of efficiency.
Simple tools exist to dump BER in a very xml-like human readable format *given the ASN.1 definition*. Granted they have been traditionally used for different purposes (XML more text oriented, ASN.1 more 'binary' oriented) but the featureset of the two encoding methods in very similar.
The bit-stealing line is good, but I'm not sure where you are coming from with the ambiguity comment. Given an encoded data stream and the ASN.1 to decode it you can get back your data structure. No problems. Of course you have (some) choice in how you represent the data when you encode, but that is common (and useful).
I don't think that the top-down/bottom-up thing is correct. In the case of both XML and ASN.1, certain 'tags' are set aside for unregistered use (PRIVATE tags in ASN.1) and if you use any such tags you need to agree with the person with whom you are exchanging data what format you are using. No difference I can see except the aforementioned 'religious' point of view with respect to the CCITT/ITU/ISO.
The only (programmatic) advantage I can see that XML could have is that the data describes its own type. BER-encoded data doesn't - you need to know what kind of object to expect.
However, this has been hobbled in XML by exactly the lack of central control of namespace you mention....I have no idea whose 'Invoice' DTD to use to interpret this object...so I don't see this as a practical advantage.
[This is on-topic, honest...]
I don't know if it is just me, but does anyone else here deal with that "interesting" data represenation language "ASN.1" (Abstract Syntax Notation 1) with its associated binary representation BER (Basic Encoding Rules)?
ASN.1 defines a textual language for the representation of named primitive data types (strings, integers, real numbers, bitstrings, etc), structured ways of grouping them together (sequences, sets, etc).
BER provides a machine-independent way for these to be represented 'on-the-wire'. These representations are also abritrary-precision and have other cool features.
Fortunately or unfortunately (depending on your perspective and religion with respect to 'ISO/OSI' standards) ASN.1 never really caught on in the Internet world (SNMP and LDAP permitting).
However, I see it as playing a very similar role as XML. (Machine-independent representation of arbitrarily complex structured/nested data).
The main difference is that the BER represenation of ASN.1 is a (somewhat complex) binary format, whereas XML is text-based.
This is both an advantage and a disadvantage (more compact, harder for humans to read).
I'm wondering whether it is worth anyone's time writing up a BER XML translator to attack those 'but XML is too verbose' criticisms...
It might not work for your app, but I would recommend considering defining the operations you need to perform as a 'protocol'.
This protocol could be as simple as some XML/HTTP or whatever you like. You can then implement one server and whichever clients you like.
Once you have done this, you can develop a web client (which just translates web forms to and from your protocol) or a native UI.
If you DON'T do this and you go the web route, your web app will be a combination of the server+client components and it will be difficult to seperate them in the future.
Speaking from experience here...web interface not bad, but the fact it is co-located with the server encourages short-cuts best not taken.
I don't know if your diskspace and bandwidth limits are met by them, but you can't beat the price.
http://www.workspot.com
They give VNC-accessible linux desktops. They allow you to install software locally too. Cool.
Amusingly enough this is a '4x2' in the UK. (Pronounced "Four be two" if you want to be taken seriously)
Nice to see, especially the comments at the bottom about the road to widespread usage including not just open source release but also the standardisation of an API to allow compatible implementations.
Amusingly, the biggest-horsepower compute farm in the company is likely to be the collection of people using office apps. You can't easily buy processors below around 700Mhz these days and desktop apps do little but wait for keypresses.
The only real impact that people would notice would be in terms of memory footprint. Those high-res wallpapers and ten copies of Excel (or Staroffice, whatever) like to slurp the RAM and stay resident. So unfortunately, it is unlikely to be unnoticed by those donating their cycles...which is the real killer.
Sort of.
Bizarrely enough, a whole new filesystem doesn't count as 'infrastructure' in the sense of the kernel. If I've got the right end of the stick, each file system interfaces to the rest of the kernel through the VFS (well pretty much) so that no 'core' kernel changes when you add a new filesystem. (There are probably plenty of exceptions to this).
[This is one example of what people mean when they say that the kernel *is* object-oriented whenever people suggest coding it in C++.]
> This strikes me as a somewhat flawed design,
> because if laws apply, they should apply
> everywhere!
Well they do. It is just that the definition of 'everywhere' isn't as obvious as you might think.
Physical laws apply where they are supposed to, in space-time - all of it (which is my working definition of 'everywhere').
The only oddity is that it is possible for things to leave 'everywhere', which is, I admit, a fairly strange property.
Your reference to topology is the clue here. Lets drop back to the 2-d analogues for convenience of terminology.
People would be happy with an 'infinite plane' of spacetime. If you are used to that idea, then the fact the space-time might be bounded (like the 2-d surface of a sphere or even a torus) seems really odd, but with analogies like this one people can get their head round it.
(Although it is easy even then to get into mental traps. "What do you mean I can't go further North? I can just keep walking can't I? Thats not going to suddenly stop being North is it?")
But both of those (2-d) surface mentioned above lack 'holes'. But we only expect that because we aren't near one.
But if we lived in a chunk of flat space-time (i.e. no gravity) we would probably find the idea of curved space time prepostorous. ("What do you mean, things would just move 'on their own'? Yeah right").
Yes, its an idea which has merits in many areas. Basically installing from source is good when the compile-time dependencies are significant, when it doesn't add too much additional time to the install or if other constraints (e.g. political) prefer the use of source.
:-)
(It also must be a good idea, since Alan Cox has made comments suggesting this direction for kernel modules on linux-kernel a few times.
> Unless the new location has a LOT of free
> energy, it will take too much
> effort/money/energy to make
> it habitable.
Which is one of the nice things about being on the moon of course, 50% (100%?) of the time you gets lots and lots of lovely bright sunlight. No atmosphere, no clouds, energy just pouring down at you.