It seems you are to dumb to understand that this still does not mean that
this is a law like you told. It might be a demand of your customers if they
don't want red LEDs on the front, it is NO law, because their is no such law.
And this is my point which you fail to understand.
It was told to you from more than one german person that there is no such
law. So when will you start to accept that fact? It is a childish behaviour
to insist that there must be some because you had to get rid of the red LEDs.
Why can't you just admit that you was wrong in your statement that there
is a law? Because you WERE wrong.
But i even don't believe that there is a requirement on no red LEDs specially
on telco equipment. We have some equipment supplied by the telcos and all of
these equipment IS fitted with red LEDs on the front. Maybe the hardware you
produced were real special, but their is no general forbid of red LEDs. And
no law.
you ARE a troll, because you don't stop telling your lies. There is NO law forbidding red LEDs. Maybe the customers of your company asked to avoid red LEDs, but it is absolutely no rule or law! I work for an ISP an all of our rackmount PCs, backup devices, telco devices etc. HAVE red LEDs on the FRONT.
NEVER USE A MAGNET! Besides the data tracking informations are written on most hard disks. You will destroy this essential data with a magnet and render the harddrive unusable!
Hehe, but in fact eastern germany _was_ equipped with fiber in large areas after the fall of the wall. Which nowadays leads to problems as DSL is not available to these people.
Deutsche Telekom AG has announced that they are working on a solution for fiber but nothing yet.
The FAQ states that the files are stored encrypted, but the link from above (http://www.nokia.com/phones/5510/spotlight_music. html) shows an example of copying the music from one 5510 to another. So how should this work if the music is encrypted? Only idea is that the music is encrypted with a common key, but it should be not so difficult to rip out the key from the pc based conversion software (same way, DVD was hacked).
United States GSM-Systems are on 1900 MHz not on 900 or 1800 like the european ones (900+1800 were already used in the united states). So you need a GSM phone which can work on 1900 MHz or a triple-band which can work 900/1800/1900. This phone is only 900/1800.
Just as a addition before people scream "Nonsense". It seems that it doesn't store MP3 but AAC. However: Still a cool transportable device which can record music, copy it to a computer etc.
And the webpage gives an example of copying the music to friends, so very likely the recorded music is not encrypted but plain AAC. There are freeware AAC decoders (and encoders) out there, so this is as usable as a mp3 encoder (you can convert it to mp3 later if you must) and it is said that AAC had better audio than mp3.
Easy. The big mobile phone manufacturers (Nokia, Ericcson, Siemens) are all based in Europe where we have GSM-Nets. Surely they will first produce a phone which can work in there home countries. And GSM won't work very well in the USA (except the few GSM1900 nets).
Face it: The USA had the first mobile phone networks but this is also the reason why you are using long outdated technology. Sometimes its better to be late but get good new technology:-) This will change with the emerge of UMTS however.
Did you missed the fact that it is much more battery effective to play MP3 using a special decoding chipset? I'm sure this phone includes one, otherwise it will probably be usable as a portable heater, too.
So why do you say this is a software thingie? It sure is a hardware thing as what you are asking for.
Did you read before posting? We are not talking about an phone with a mp3 player (i grant this is old) but about an phone which can RECORD mp3-files. Surely new technology. We are currently seeing the first portable mp3 recorders and here we have it included into a phone! Impressive technology and you say "no new features"?
Yepp, the vertical mistaken as a dipole was the first thing i was to wonder about too. Doesn't gives that much impression about the accuracy of the rest of the article.
Yep, it's out there. Run, jump, dance in the streets. Drink and be merry.
Thank you that you took Caution and haven't asked for wild sex in the streets. You know, geeks and sex? This could have caused serious depression on the readership of slashdot...
Ok, found it. It was published in c't November 1999, unfortunately this article is not online. Maybe you can find someone which owns the c't ROM 1999 (which contains the Articles on CD).
Windows can boot from CD. It just needs it registry (and afair some other files) writeable. You can place them on a Ramdisk.
German magazine c't had an article about doing this. They made Windows boot from CD flawless. I'm currently looking if i can locate this article, but i fear it isn't online.
Instead of getting nasty to some slashdot moderators, reread my original posting. It was not crap, but fully true.
At no point i talked about any other URIs than these in namespace. These URIs do not contain DTDs or anything useful else.
Yes, the DOCTYPE declaration indeed points to an DTD which should be existant. But these URLs still can change, and so you might have to change your DOCTYPE declarations once in a while. Shouldn't be a big hassle. Even a script can do this.
Good parsers should work with a local copy anyway, to take load from the network (its silly to fetch the DTD from an external source every time). Not so good parsers may depend on the external DTD, but this is in my eyes an concept flaw.
For production use you will likely turn of validation anyway to speed the things up.
So my point still holds true: While it is nasty that Netscape removed the DTD, this does not need to break things by concept. Its worse that all the information disappeared too.
So go out, let a script change your DOCTYPE declarations, and you will have valid documents once again. No big deal. You might want to exchange the URL to a local DTD when you use a dumb parser which does not allow to override the source of an DTD.
So, Mr. I'm So Important Because I Helped With An Oreilly Book: While your points hold true, my message is valid as well. The disappearing of the DTD is a hassle, but its one you can overcome easily. And that is the point in this discussion. Some think the declaration of an DTD ressource is an design flaw in XML. I don't think so. There is no scheme for storing DTDs which can and will last for ever.
Its only a flaw in parsers which aren't prepared to that this URL can (and will) break. So if this debacle shows us one thing it is that some parsers need to get smarter. This won't be the last DTD to disappear from there old location.
You were true, and so where me. But at least i did not do such arrogant postings with references to the great things i have done like you did. You should probably change your attitude.
So you see. There are only xml-namespace URIs there. Nothing which a validation parser can / or should use to get the DTD. Parsers which uses such URIs to obtain a DTD are broken, and won't even be able to parse XSL(T), because the W3C _has_ _no_ DTD at the URIs given.
So to parse the slashdot.rdf it does not make any difference if the DTD is there, or not, because it does not contain any reference to the DTD. How you get the DTD and how to supply it to your XML-Parser is up to you and your parser. But don't use URIs supplied in the document for things they aren't intended to. This can and will break.
Once again: To use a validating parser you need the DTD, of course. But the W3C makes no provision where to get this DTD! The Declaration inside a RDF-File for example is containing a xmlns-Attribute. That is XML-_N_ame_s_pace. Nothing more. See for example the declaration in http://slashdot.org/slashdot.rdf:
You can not run a validating parser solely on this. Because the URIs given above are in fact (what you appearently do not want to understand) only Namespace, and not a reference to the DTD.
There is no defined way to automatically determine where to get the DTD. You need to get it yourself and supply it to your validating Parser.
I've given the XSL(T)-Example. The XSL(T)-Declaration contains a URI as well. But the DTD is not there, only a information by the W3C, that this is the XSL(T)-Namespace. After all you may imagine that the W3C knows what it does. A valid XSL(T)-Document does not contain any reference about where to get the DTD. This was specifically intended so, as the Locations of DTD can change, as the example here shows us.
So you are still wrong. Having the DTD disappeared from Netscapes site DOES NOT make problems to validating parsers by default. Just obtain the DTD elsewhere and feed it into your parser.
Of course it is a mess that the DTD disappeared from Netscapes Site, as it makes it more difficult to find it anywhere in the net. And whats more annoying is that Netscape copyrighted the DTD and you may not be allowed to host this DTD anywhere.
But this IS NOT A PROBLEM BY CONCEPT. The W3C recognized that it can be virtually impossible to maintain a ever lasting repository for a DTD, and therefore does not urge you to make any links to your DTD. The URI in the Declaration is only Namespace, and you don't even need to put a Webpage there. The W3C itself had not webpages at there URIs at the beginning. Only after having too much people who do not understand (like you) complaing the added this short text. You can use mailto:bla@fasel or gopher:.. or telnet: or anyother unique URI you might imagine. Just make it unique for a given DTD.
There is nothing really wrong with Netscape removing the DTD from the "URL" which is declared in a RSS-Document.
By Specification this URI does not need to contain a valid URL, its just a Namespace to have a unique unifier for this specific DTD.
For example take a look at the URL supplied with XSL(T)-Stylesheets: http://www.w3.org/1999/XSL/Transform. This won't give you the DTD for XSL(T)-Documents. All you get is a webpage which simply states 'This is the XSLT namespace'. And even W3C put this webpage there only after having to much people complain that this URL was in the first place 404 (not existant).
You even do not need to use a HTTP-URI for the namespace. You are perfectly legal to use a (unique!) email address or something else.
So no validating parser should do anything with this Namespace URI. At least not try to obtain the DTD from there (imagine a validating parser sending you an email asking for the DTD...). If the DTD is needed, it has to be supplied and associated by other means. Not by the URI.
So there is nothing really wrong with netscape to remove the DTD. There are copies of it floating arround the net, and they can be used for validating parsers. And for simply _using_ RSS you won't even need the DTD. Validation costs time and in most real, life application you want to turn it off anyway (if implemented at all).
To clarify this: Yes, there are UPS out there, which are not designed for computer or electronics usage. Watch out!
A nonsense quote like 'waveform doesn't matter' won't give you a false feeling that you can buy anything which is sold.
Get a UPS with sine-wave or near sine-wave (sometimes called pseudo sine-wave), get one which is sold for computer usage. Get some brand name device. It might be more expensive, but do you want to sue a noname taiwan manufacturer because his bad designed UPS has fried your electronics?
You may restate it as long as you like, but it will never became the truth.
None-Sine Wave Forms can cause heavy spikes into switching power supplies effectively harming or destroying them.
If you don't respond to things like this, than don't do it. But don't tell the people nonsense which can destroy their equipment.
Fact is, that UPS mostly does nice enough waveforms which will not destroy your equipment. Of course because of this they can give you an warranty.
But you said that the waveform in general does not do any difference and that is dumb shit! No UPS designed for computers or electronics will output for example square wave or similar bad waveforms because this WILL destroy the equipment.
So, yes, you can use almost any UPS which is out there, which is sold for computer usage. And, no, it is not irrelevant which wave form a generator does output.
This is utter nonsense. I personally won't attach electronic devices to anything other than sine wave or nearly sine wave. All other wave forms can destroy electronic equipment!
The power supply of a computer for example works with a switching power supply which transforms the voltage via a very high frequency intermediate signal. The best thing to transform into high frequency is - a sinus wave. All other wave forms aren't really standalone waves, they are mixtures of different sine waves with different frequencies. For example a square wave consist of infinite sine waves. Now image what might happen if you transform such a bad signal.
Don't do it. Don't attach expensive electronic equipment to a sheap USV. The person who wrote this is _completely_ wrong, even with his motor hints. A motor is generally no problem, regardless of the wave form. I would put a motor, a light bulb or a electric shaver (which is little more than a motor) onto a odd shaped current, but never ever electronic equipment.
Remember: You won't be able to sue this guy for destroying your electronic equipment by his bad advice.
Slashdot Mirror
It seems you are to dumb to understand that this still does not mean that this is a law like you told. It might be a demand of your customers if they don't want red LEDs on the front, it is NO law, because their is no such law. And this is my point which you fail to understand.
It was told to you from more than one german person that there is no such law. So when will you start to accept that fact? It is a childish behaviour to insist that there must be some because you had to get rid of the red LEDs. Why can't you just admit that you was wrong in your statement that there is a law? Because you WERE wrong.
But i even don't believe that there is a requirement on no red LEDs specially on telco equipment. We have some equipment supplied by the telcos and all of these equipment IS fitted with red LEDs on the front. Maybe the hardware you produced were real special, but their is no general forbid of red LEDs. And no law.
you ARE a troll, because you don't stop telling your lies. There is NO law forbidding red LEDs. Maybe the customers of your company asked to avoid red LEDs, but it is absolutely no rule or law! I work for an ISP an all of our rackmount PCs, backup devices, telco devices etc. HAVE red LEDs on the FRONT.
NEVER USE A MAGNET! Besides the data tracking informations are written on most hard disks. You will destroy this essential data with a magnet and render the harddrive unusable!
Hehe, but in fact eastern germany _was_ equipped with fiber in large areas after the fall of the wall. Which nowadays leads to problems as DSL is not available to these people.
Deutsche Telekom AG has announced that they are working on a solution for fiber but nothing yet.
The FAQ states that the files are stored encrypted, but the link from above (http://www.nokia.com/phones/5510/spotlight_music. html) shows an example of copying the music from one 5510 to another. So how should this work if the music is encrypted? Only idea is that the music is encrypted with a common key, but it should be not so difficult to rip out the key from the pc based conversion software (same way, DVD was hacked).
United States GSM-Systems are on 1900 MHz not on 900 or 1800 like the european ones (900+1800 were already used in the united states). So you need a GSM phone which can work on 1900 MHz or a triple-band which can work 900/1800/1900. This phone is only 900/1800.
Just as a addition before people scream "Nonsense". It seems that it doesn't store MP3 but AAC. However: Still a cool transportable device which can record music, copy it to a computer etc.
And the webpage gives an example of copying the music to friends, so very likely the recorded music is not encrypted but plain AAC. There are freeware AAC decoders (and encoders) out there, so this is as usable as a mp3 encoder (you can convert it to mp3 later if you must) and it is said that AAC had better audio than mp3.
Easy. The big mobile phone manufacturers (Nokia, Ericcson, Siemens) are all based in Europe where we have GSM-Nets. Surely they will first produce a phone which can work in there home countries. And GSM won't work very well in the USA (except the few GSM1900 nets).
:-) This will change with the emerge of UMTS however.
Face it: The USA had the first mobile phone networks but this is also the reason why you are using long outdated technology. Sometimes its better to be late but get good new technology
Did you missed the fact that it is much more battery effective to play MP3 using a special decoding chipset? I'm sure this phone includes one, otherwise it will probably be usable as a portable heater, too.
So why do you say this is a software thingie? It sure is a hardware thing as what you are asking for.
Did you read before posting? We are not talking about an phone with a mp3 player (i grant this is old) but about an phone which can RECORD mp3-files. Surely new technology. We are currently seeing the first portable mp3 recorders and here we have it included into a phone! Impressive technology and you say "no new features"?
ke5fx de do1kju / kg6icx... :-)
Yepp, the vertical mistaken as a dipole was the first thing i was to wonder about too. Doesn't gives that much impression about the accuracy of the rest of the article.
Yep, it's out there. Run, jump, dance in the streets. Drink and be merry.
Thank you that you took Caution and haven't asked for wild sex in the streets. You know, geeks and sex? This could have caused serious depression on the readership of slashdot...
Nice. Is this available for download somewhere?
You can buy an archive version of the article from the c't for Euro 0,60, see: http://www.heise.de/kiosk/archiv/ct/99/11/206/
But be warned, the article is in german, so you will need babelfish or better knowledge of german.
HTH.
Ok, found it. It was published in c't November 1999, unfortunately this article is not online. Maybe you can find someone which owns the c't ROM 1999 (which contains the Articles on CD).
Windows can boot from CD. It just needs it registry (and afair some other files) writeable. You can place them on a Ramdisk.
German magazine c't had an article about doing this. They made Windows boot from CD flawless. I'm currently looking if i can locate this article, but i fear it isn't online.
Instead of getting nasty to some slashdot moderators, reread my original posting. It was not crap, but fully true.
At no point i talked about any other URIs than these in namespace. These URIs do not contain DTDs or anything useful else.
Yes, the DOCTYPE declaration indeed points to an DTD which should be existant. But these URLs still can change, and so you might have to change your DOCTYPE declarations once in a while. Shouldn't be a big hassle. Even a script can do this.
Good parsers should work with a local copy anyway, to take load from the network (its silly to fetch the DTD from an external source every time). Not so good parsers may depend on the external DTD, but this is in my eyes an concept flaw.
For production use you will likely turn of validation anyway to speed the things up.
So my point still holds true: While it is nasty that Netscape removed the DTD, this does not need to break things by concept. Its worse that all the information disappeared too.
So go out, let a script change your DOCTYPE declarations, and you will have valid documents once again. No big deal. You might want to exchange the URL to a local DTD when you use a dumb parser which does not allow to override the source of an DTD.
So, Mr. I'm So Important Because I Helped With An Oreilly Book: While your points hold true, my message is valid as well. The disappearing of the DTD is a hassle, but its one you can overcome easily. And that is the point in this discussion. Some think the declaration of an DTD ressource is an design flaw in XML. I don't think so. There is no scheme for storing DTDs which can and will last for ever.
Its only a flaw in parsers which aren't prepared to that this URL can (and will) break. So if this debacle shows us one thing it is that some parsers need to get smarter. This won't be the last DTD to disappear from there old location.
You were true, and so where me. But at least i did not do such arrogant postings with references to the great things i have done like you did. You should probably change your attitude.
Seems, Slashdot has tilted my examples. So, here we go. This is the RDF-Declaration from slashdot:
t ax -ns#"
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syn
xmlns="http://my.netscape.com/rdf/simple/0.9/">
So you see. There are only xml-namespace URIs there. Nothing which a validation parser can / or should use to get the DTD. Parsers which uses such URIs to obtain a DTD are broken, and won't even be able to parse XSL(T), because the W3C _has_ _no_ DTD at the URIs given.
So to parse the slashdot.rdf it does not make any difference if the DTD is there, or not, because it does not contain any reference to the DTD. How you get the DTD and how to supply it to your XML-Parser is up to you and your parser. But don't use URIs supplied in the document for things they aren't intended to. This can and will break.
Once again: To use a validating parser you need the DTD, of course. But the W3C makes no provision where to get this DTD! The Declaration inside a RDF-File for example is containing a xmlns-Attribute. That is XML-_N_ame_s_pace. Nothing more. See for example the declaration in http://slashdot.org/slashdot.rdf:
You can not run a validating parser solely on this. Because the URIs given above are in fact (what you appearently do not want to understand) only Namespace, and not a reference to the DTD.
There is no defined way to automatically determine where to get the DTD. You need to get it yourself and supply it to your validating Parser.
I've given the XSL(T)-Example. The XSL(T)-Declaration contains a URI as well. But the DTD is not there, only a information by the W3C, that this is the XSL(T)-Namespace. After all you may imagine that the W3C knows what it does. A valid XSL(T)-Document does not contain any reference about where to get the DTD. This was specifically intended so, as the Locations of DTD can change, as the example here shows us.
So you are still wrong. Having the DTD disappeared from Netscapes site DOES NOT make problems to validating parsers by default. Just obtain the DTD elsewhere and feed it into your parser.
Of course it is a mess that the DTD disappeared from Netscapes Site, as it makes it more difficult to find it anywhere in the net. And whats more annoying is that Netscape copyrighted the DTD and you may not be allowed to host this DTD anywhere.
But this IS NOT A PROBLEM BY CONCEPT. The W3C recognized that it can be virtually impossible to maintain a ever lasting repository for a DTD, and therefore does not urge you to make any links to your DTD. The URI in the Declaration is only Namespace, and you don't even need to put a Webpage there. The W3C itself had not webpages at there URIs at the beginning. Only after having too much people who do not understand (like you) complaing the added this short text. You can use mailto:bla@fasel or gopher:.. or telnet: or anyother unique URI you might imagine. Just make it unique for a given DTD.
There is nothing really wrong with Netscape removing the DTD from the "URL" which is declared in a RSS-Document.
By Specification this URI does not need to contain a valid URL, its just a Namespace to have a unique unifier for this specific DTD.
For example take a look at the URL supplied with XSL(T)-Stylesheets: http://www.w3.org/1999/XSL/Transform. This won't give you the DTD for XSL(T)-Documents. All you get is a webpage which simply states 'This is the XSLT namespace'. And even W3C put this webpage there only after having to much people complain that this URL was in the first place 404 (not existant).
You even do not need to use a HTTP-URI for the namespace. You are perfectly legal to use a (unique!) email address or something else.
So no validating parser should do anything with this Namespace URI. At least not try to obtain the DTD from there (imagine a validating parser sending you an email asking for the DTD...). If the DTD is needed, it has to be supplied and associated by other means. Not by the URI.
So there is nothing really wrong with netscape to remove the DTD. There are copies of it floating arround the net, and they can be used for validating parsers. And for simply _using_ RSS you won't even need the DTD. Validation costs time and in most real, life application you want to turn it off anyway (if implemented at all).
To clarify this: Yes, there are UPS out there, which are not designed for computer or electronics usage. Watch out!
A nonsense quote like 'waveform doesn't matter' won't give you a false feeling that you can buy anything which is sold.
Get a UPS with sine-wave or near sine-wave (sometimes called pseudo sine-wave), get one which is sold for computer usage. Get some brand name device. It might be more expensive, but do you want to sue a noname taiwan manufacturer because his bad designed UPS has fried your electronics?
You may restate it as long as you like, but it will never became the truth.
None-Sine Wave Forms can cause heavy spikes into switching power supplies effectively harming or destroying them.
If you don't respond to things like this, than don't do it. But don't tell the people nonsense which can destroy their equipment.
Fact is, that UPS mostly does nice enough waveforms which will not destroy your equipment. Of course because of this they can give you an warranty.
But you said that the waveform in general does not do any difference and that is dumb shit! No UPS designed for computers or electronics will output for example square wave or similar bad waveforms because this WILL destroy the equipment.
So, yes, you can use almost any UPS which is out there, which is sold for computer usage. And, no, it is not irrelevant which wave form a generator does output.
If you can't get this straight, don't post.
For 10.* this is irrelevant anyway. This are _private_ addresses which can not advertise outside of your network. So the size simply doesn't matter.
This is utter nonsense. I personally won't attach electronic devices to anything other than sine wave or nearly sine wave. All other wave forms can destroy electronic equipment!
The power supply of a computer for example works with a switching power supply which transforms the voltage via a very high frequency intermediate signal. The best thing to transform into high frequency is - a sinus wave. All other wave forms aren't really standalone waves, they are mixtures of different sine waves with different frequencies. For example a square wave consist of infinite sine waves. Now image what might happen if you transform such a bad signal.
Don't do it. Don't attach expensive electronic equipment to a sheap USV. The person who wrote this is _completely_ wrong, even with his motor hints. A motor is generally no problem, regardless of the wave form. I would put a motor, a light bulb or a electric shaver (which is little more than a motor) onto a odd shaped current, but never ever electronic equipment.
Remember: You won't be able to sue this guy for destroying your electronic equipment by his bad advice.
> Now if you are a nice person any girl that
> really gets to know you and has had some
> experience with a*holes should be a target.
> Unfortunatly not all girls have that experience.
Sorry, but what kind of asshole are you? I hope that _no_ girl has to made experience with assholes just for my own success with her.
So: _Fortunately_ not all girls have (to make) that experience.