I think your estimates of the life of burned CDs and DVDs are way overblown, BTW.
Not mine, so I can't comment. What I can do is to provide some sources for the estimates:
300 years citation - "MAM-A (Mitsui) claims a life of 300 years on their archival gold CD-R and 100 years for gold DVDs."
10 year estimate - "According to research conducted by J. Perdereau, CD-Rs are expected to have an average life expectancy of 10 years."
This doesn't sound a whole lot different than CDs or DVDs burned in factories. Those don't use a dye layer either, but pits etched into an (aluminum?) substrate. It sounds like this company has found a way to produce similar results at home -- but that doesn't mean the resulting discs will be any more durable or have longer life than your store-bought CDs/DVDs.
1. MAFIAA has little incentive to sell you discs that will last forever - I'd say, on the contrary. The fact they sell you pressed CD/DVD-es is rather related to the cost of producing them than it is with their concern on how long they'll last for you.
2. However, as a Write-Once-a-single-copy (backup, archiving purposes), I think this one will make a killing. The current life-span of recordable CD/DVD (not the pressed ones) vary between 10-300 years (subject to the quality and storage/use patterns).
more stuff created for war. These cameras instruments are not going to be sold to civilians, here is the purpose:
...
of-course outside of a war or a 'rescue operation' there may be not much use for these things, but it just adds to resources that are mis-allocated for wars instead of going towards normal consumer market. The only use for consumer market I can think of is war games unfortunately, like paintball.
Hmmm, paintball.... being hit by a solid grenade-like projectile of non-negligible mass... I think I'll pass.
The only advantage of this "grenade like" wireless camera: can reach close to the enemies position in a short time... I can't imagine during civilian operations this can be an advantage... Except, possibly, in building fires - in which an UAV mounted camera won't survive and the situation can evolve quite fast.
This has nothing to do with the issue at hand. A length-prefixed implementation also means that "strings are arrays". Just that, instead of having a NUL postfix, you have a length prefix.
Hmmmm.... is it? Let's try if the two are equivalent: in a length prefix implementation, how are you going to store/pass as param the "tail substring of a constant string" without copying the original string?
Example 1. Have you tried to use a std::vector (as a collection of constant strings)? Granted, you are able to switch to other constructs (like vector>), but... this is one example of the perils of "Pascal-strings" and one of the unintended consequence as an added complexity to deal with in the "language" if Pascal strings would be the only way to do it.
Example 2. Try boost::spirit. There are tricks to convince it NOT to use std::string as grammar attributes, but by default the "string by copy" is used.
My points:
1. sometimes you need to use a constructs (or libraries) that works "by copy"
2. if you have NUL-terminated strings as the "natural type" in the language, you can create your own constructs for Pascal-strings (length prefixed). If your one an only representation for the string is the P-string, you can't go and use the C-style string.
More than a lot of the/. postings, this one needs a suddenoutbreakofcommonsense tag. Let's hope U.S. courts eventually come to the same conclusion as their UK counterparts.
Given how rare this happens, I reckon the "random-outbreak-of-common-sense" tag makes... well... more sense.
And calling strcpy a bunch of times for the hell of it also does.
What sort of situations are you running into when you are passing a std::string by value and you don't need the copy for correctness (because you're going to modify one)?
If I need a copy, then (and only then) I need a copy and I'll be paying the price for a strcpy.
Other sites do the same more locally: in Alachua County, home to Gainesville and the University of Florida, the local newspaper runs a mugshot site at http://www.mugshotsgainesville.com/
From their site:
... Mug shots are presented chronologically, by booking time and date. Records will remain online for a maximum of 90 days.
I don't know if they collaborate with any sort of removeslander.com or removearrest.com sites, but I imagine the lucrative possibilities of collaboration might be tempting to a local news agency strapped for cash.
Somehow, I reckon they are not. Otherwise, why would they announce a 90 days maximum for public availability?
Desperate to get off the site, Cabibi quickly found an apparent ally: RemoveSlander.com. “You are not a criminal,” the website said reassuringly. “End this humiliating ordeal Bail out of Google. We can delete the mug-shot photo.”
Well, the best reaction would have been: contact the other mug-shots and start a " Block florida.arrests.org" campaign on Google. If there are enough of them, the florida.arrests.org will sunk into the oblivion.
Hey, should the/.-ers help? Like: log into your gmail account, do a search after "Florida mugshots" and use the "Block... " feature?
Aww... c'mon guys, let's see how fast we can pull the carpet under the feet of the computer-savvy Florida ex-con named Rob Wiggen. I just did it, also blocking from my results the www.mugshots.com, mugshotsusa.com and a bunch of others (we should stop only when the real public records will get onto the first page).
Assuming that the mug-shot disappears from florida.arrests.org, does it disappear from the public records?
If not, what stops another site to do the same?
Length: What's the size? What byte order? What bit size? How will this affect communications between platforms?
Adding: how do you pass to you the tail substring? (like: I parsed to here, take over from now on. Oh, yes, on top of the length, deal with another offset).
this could have been a perfectly typical and rational IT or CS decision, like the many similar decisions we all make every day
Actually the tradeoff may not have been rational.
Actually, the choice was rational (at least, on purpose) - you see, it's not about a single byte, it's about a new data type.
C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user.
And of course, in reality, where people aren't actually tested before providing bad code that performs these tasks poorly and has terrible effects on society at large, your attitude is approximately as useful as a purse to a fish.
Hmmm... let's not stop mid-way.
in reality, where people aren't actually tested before providing bad code that performs these tasks poorly and has terrible effects on society at large, you are approximately as useful as a purse to a fish.
FTFY: in a world who doesn't give a dam' about professionalism, being one is useless.
I'll argue that's the correct decision at a such low-level as C.
1. with NULL-terminated strings, there's no distinction (other than in the string.h and related library) between a char * and a other_type *. Inventing a "string" type in C (not C++) would have made the compiler more complex (see footnote **)
2. because char * is no different than other_type* , I can pass the address in the middle of the string char * for processing. Not so much for a std::string. How does it matter? Well, take parsing for example (the most trivial strtok) not only that one will need an extra string-len prefix, but you'll need to keep a separate "curr_pos".
If you have a NULL-terminated char* string, one can invent/use a std::string (or GString, or NSString, or Pascal-string). The reverse is not true: having the compiler accepting only Pascal-strings, it's not possible to start using the NULL-terminated convention.
many uses are much easier and faster when we know the length and for others few things beat a null-terminated string.
While in other cases (when you pass a std::string by-value and invoke the copy constructor, which tends to happen a lot), you have a hefty performance penalty.
Footnote ** - Dennis M. Ritchie on the C history.
C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type.
* Why is this not being addressed against Samsung within the United States where the patent was presumably granted?
It is. But with the Aussie dollar on the rise, Australia started to become an interesting market, so why not in Australia as well?
* Is this tied to the relatively recent free trade agreements between Australia and the United States? Is Korea not a partner?
Re. US - the agreement is not THAT recent (2004). Recent is only Australia as a patent battle ground.
Re. Korea: nope, in negotiation only – long after the FTA with US has been signed.
Slashdot Mirror
But of course, it's never been proven, because no single piece of this media has been around for 300 years.
:) Well, with the current crisis, what can we do better than to wait and see :)
I think your estimates of the life of burned CDs and DVDs are way overblown, BTW.
Not mine, so I can't comment. What I can do is to provide some sources for the estimates:
300 years citation - "MAM-A (Mitsui) claims a life of 300 years on their archival gold CD-R and 100 years for gold DVDs."
10 year estimate - "According to research conducted by J. Perdereau, CD-Rs are expected to have an average life expectancy of 10 years."
This doesn't sound a whole lot different than CDs or DVDs burned in factories. Those don't use a dye layer either, but pits etched into an (aluminum?) substrate. It sounds like this company has found a way to produce similar results at home -- but that doesn't mean the resulting discs will be any more durable or have longer life than your store-bought CDs/DVDs.
1. MAFIAA has little incentive to sell you discs that will last forever - I'd say, on the contrary. The fact they sell you pressed CD/DVD-es is rather related to the cost of producing them than it is with their concern on how long they'll last for you.
2. However, as a Write-Once-a-single-copy (backup, archiving purposes), I think this one will make a killing. The current life-span of recordable CD/DVD (not the pressed ones) vary between 10-300 years (subject to the quality and storage/use patterns).
more stuff created for war. These cameras instruments are not going to be sold to civilians, here is the purpose:
...
of-course outside of a war or a 'rescue operation' there may be not much use for these things, but it just adds to resources that are mis-allocated for wars instead of going towards normal consumer market. The only use for consumer market I can think of is war games unfortunately, like paintball.
Hmmm, paintball.... being hit by a solid grenade-like projectile of non-negligible mass... I think I'll pass.
The only advantage of this "grenade like" wireless camera: can reach close to the enemies position in a short time... I can't imagine during civilian operations this can be an advantage... Except, possibly, in building fires - in which an UAV mounted camera won't survive and the situation can evolve quite fast.
Why not use this design for consumer products? All the way around it's a better design. I'd cough up a few bucks more for this chip.
Consumer products needs holy smoke to operate (otherwise how would one tell the chip is broken?). This one... needs vacuum to operate.
For God's sake, we cannot let them do this. We're going for a triple-dip recession if we do.
That is: if we'll survive the second, isn't it?
Too bad you didn't have a computer to compose your essays, eh?
Wow, I can build a house faster with this hammer. Headline: Hammers Could Build Houses Faster Than Construction Workers (In Cyberspace)
On the same line: computers can write better essays than the students.
but it really needs to check for plagiarism.
If the computers will grade the essays, then it should be the computers to write it.
You mean: a Maxwell daemon or a brownian rachet? (note the links pointing to some interesting experiments).
This has nothing to do with the issue at hand. A length-prefixed implementation also means that "strings are arrays". Just that, instead of having a NUL postfix, you have a length prefix.
Hmmmm.... is it? Let's try if the two are equivalent: in a length prefix implementation, how are you going to store/pass as param the "tail substring of a constant string" without copying the original string?
Example 1. Have you tried to use a std::vector (as a collection of constant strings)? Granted, you are able to switch to other constructs (like vector>), but ... this is one example of the perils of "Pascal-strings" and one of the unintended consequence as an added complexity to deal with in the "language" if Pascal strings would be the only way to do it.
Example 2. Try boost::spirit. There are tricks to convince it NOT to use std::string as grammar attributes, but by default the "string by copy" is used.
My points:
1. sometimes you need to use a constructs (or libraries) that works "by copy"
2. if you have NUL-terminated strings as the "natural type" in the language, you can create your own constructs for Pascal-strings (length prefixed). If your one an only representation for the string is the P-string, you can't go and use the C-style string.
More than a lot of the /. postings, this one needs a suddenoutbreakofcommonsense tag. Let's hope U.S. courts eventually come to the same conclusion as their UK counterparts.
Given how rare this happens, I reckon the "random-outbreak-of-common-sense" tag makes... well... more sense.
And calling strcpy a bunch of times for the hell of it also does.
What sort of situations are you running into when you are passing a std::string by value and you don't need the copy for correctness (because you're going to modify one)?
If I need a copy, then (and only then) I need a copy and I'll be paying the price for a strcpy.
Other sites do the same more locally: in Alachua County, home to Gainesville and the University of Florida, the local newspaper runs a mugshot site at http://www.mugshotsgainesville.com/
From their site:
... Mug shots are presented chronologically, by booking time and date. Records will remain online for a maximum of 90 days.
I don't know if they collaborate with any sort of removeslander.com or removearrest.com sites, but I imagine the lucrative possibilities of collaboration might be tempting to a local news agency strapped for cash.
Somehow, I reckon they are not. Otherwise, why would they announce a 90 days maximum for public availability?
This stinks. I can't wait until the market for boilerplate makes these business models obsolete...
Until then, here's an idea of how you can help.
The point is these guys do all the SEO optimization they can, so when you do a search for your name, it comes up.
Being a SEO optimisation just for the purpose of blackmailing, here's an idea. I think it would be much cheaper for the blackmailed.
Desperate to get off the site, Cabibi quickly found an apparent ally: RemoveSlander.com. “You are not a criminal,” the website said reassuringly. “End this humiliating ordeal Bail out of Google. We can delete the mug-shot photo.”
Well, the best reaction would have been: contact the other mug-shots and start a " Block florida.arrests.org" campaign on Google. If there are enough of them, the florida.arrests.org will sunk into the oblivion.
Hey, should the /.-ers help? Like: log into your gmail account, do a search after "Florida mugshots" and use the "Block ... " feature?
Aww... c'mon guys, let's see how fast we can pull the carpet under the feet of the computer-savvy Florida ex-con named Rob Wiggen. I just did it, also blocking from my results the www.mugshots.com, mugshotsusa.com and a bunch of others (we should stop only when the real public records will get onto the first page).
Assuming that the mug-shot disappears from florida.arrests.org, does it disappear from the public records?
If not, what stops another site to do the same?
Length: What's the size? What byte order? What bit size? How will this affect communications between platforms?
Adding: how do you pass to you the tail substring? (like: I parsed to here, take over from now on. Oh, yes, on top of the length, deal with another offset).
this could have been a perfectly typical and rational IT or CS decision, like the many similar decisions we all make every day
Actually the tradeoff may not have been rational.
Actually, the choice was rational (at least, on purpose) - you see, it's not about a single byte, it's about a new data type.
C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user.
I guess my question would be: what if I want a string that contains NULs? (Yes, I've had this situation, before.)
Then you want a char array, not a string. How do you solve it when you need an int array?
And of course, in reality, where people aren't actually tested before providing bad code that performs these tasks poorly and has terrible effects on society at large, your attitude is approximately as useful as a purse to a fish.
Hmmm... let's not stop mid-way.
in reality, where people aren't actually tested before providing bad code that performs these tasks poorly and has terrible effects on society at large, you are approximately as useful as a purse to a fish.
FTFY: in a world who doesn't give a dam' about professionalism, being one is useless.
1. with NULL-terminated strings, there's no distinction (other than in the string.h and related library) between a char * and a other_type *. Inventing a "string" type in C (not C++) would have made the compiler more complex (see footnote **)
2. because char * is no different than other_type* , I can pass the address in the middle of the string char * for processing. Not so much for a std::string. How does it matter? Well, take parsing for example (the most trivial strtok) not only that one will need an extra string-len prefix, but you'll need to keep a separate "curr_pos".
If you have a NULL-terminated char* string, one can invent/use a std::string (or GString, or NSString, or Pascal-string). The reverse is not true: having the compiler accepting only Pascal-strings, it's not possible to start using the NULL-terminated convention.
many uses are much easier and faster when we know the length and for others few things beat a null-terminated string.
While in other cases (when you pass a std::string by-value and invoke the copy constructor, which tends to happen a lot), you have a hefty performance penalty.
Footnote ** - Dennis M. Ritchie on the C history.
C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type.
I'm presuming that the patents in question were granted within the United States of America.
A few questions are floating around my head: * How exactly does United States patent law apply to a Korean company selling products within Australia?
The answer.
* Why is this not being addressed against Samsung within the United States where the patent was presumably granted?
It is. But with the Aussie dollar on the rise, Australia started to become an interesting market, so why not in Australia as well?
* Is this tied to the relatively recent free trade agreements between Australia and the United States? Is Korea not a partner?
Re. US - the agreement is not THAT recent (2004). Recent is only Australia as a patent battle ground.
Re. Korea: nope, in negotiation only – long after the FTA with US has been signed.