Yes, there was recently a paper presented that "broke" SHA1, but the result is 2**69 operations instead of 2**80 to find a SHA1 collision. 2**69 is still a very large number of operations... a lot less than a full 2**80, but still a prohibitively large number (more costly than the actual realized losses the entertainment industry is suffering).
In this particular case, the person who was "loaned" the car (with the implication it would not be taken away) was very famous and many others started to purchase that same model of car, because of his well spoken preference for the superiority of that particular car.
After the cars were selling very well, and the needs of paying customer diverged from those who'd been given free models, the company decides it's no longer worth the promotional value to keep providing free ones.
What consequences? Having the kernel be way better than it would have been if Linus had listened to you people and not used BitKeeper?
The pace of kernel development did improve. Some may have been BK's superior performance, but much was attributed to the increased delegation of responsibility (eg, RTFA)
The "consequence" is that now, this improved speed can not continue much longer, until some other replacement is developed.
Sure, BitKeeper might be going away--but the things Linus accomplished while it was here will NOT go way.
But the improved speed may go away.
Worse yet, the pace of kernel development might even slow for some time, as developers all migrate to another tool. Consider that changeset data is locked in a proprietary format that needs to be reverse engineered.
Bloor's opinions are just another well worn paradigm: the more deeply entrenched it has become, the more novel licensing is evaluated in a myopic/short-sighted view of traditional software purchasing, the more it plays back into the hands of the traditional behemoths that dominate the industry.
so many people are moving from professional browsers to more amature ones... whose maintainers and coders are just "hackers" or college kids... not real software engineers.
Yeah, everyone's gonna be a lot safer staying with IE, right? Certainly the track record on critical vulnerabilities should be a strong indication.
Well Microsoft is free to couple their word processor with their media player, I guess.
No, No, NO. You guessed wrong.
They most certainly are NOT free to do any such thing.
They command a monopoly power, and it is clearly illegal to tie products together so as to leverage a monopoly in one product to effectively shut out competitors for your other product.
I feel much the same... Real's past abuses have destroyed all trust.
But, there is at least some length they could go to to restore my trust in them. They've supposedly "embraced open source", whatever that means. But if their player is ever accepted into Debian unstable or Debian testing... then that will be the tipping point where I know I can trust it!
It'll probably be a cold day in hell, but hey, if they ever do truely reform and offer a truely free, truely open source player that passes all the Debian guidelines, I'd say it's time to trust them again.
According to Robin (my partner and accountant, who is a CPA), the merchant account for our little website has two different "discount" rates (the portion of the sale that the bank takes).
One rate is for phone or internet orders, and the other is for in-person (cardholder present) sales. Sales without the cardholder present are a higher risk, and the bank charges the merchant (or at least in our case) a higher fee per transaction. I really don't pay attention to what the fees are anymore... there is little we can do about it, so time and energy is better spent trying to increase sales rather than worry about small, unavoidable fees.
Again, according to Robin, the card swipe through the terminal proves that the physical card was present, and the signature proves that the customer was present, saw and accepted the goods. These are factors that, on average over the sum of all transactions, significantly reduce risk. That is why they are important. It is this overall trend that matters to banks and the credit card processing clearinghouses.
Now, in the IT/computer security world, there's a tendancy to think of potential weaknesses, how to exploit them, and how to design countermeasures... roughly in that order, and in this case the first two. Valuable as this is, the constructive approach is to apply creative throught towards improvement, rather than cynical dismissal (common of slashdot comment posters) of the importance of a signature because most clerks don't check.
In fact, the truth is that on average, in-person transactions with a card swipe and signature carry a lower risk of fraud. Perhaps that risk would be even lower if most clerks checked the signature more closely, but even with the reality of today's environment, the card swipe and signature do indeed result in lower risk of fraud, which is passed on to the merchant as a lower fee.
Those for whom this library is relevant should afford to pay their IEEE membership costs
To give you one tiny example, several months ago I was working on a rewrite of the floating point library for the
SDCC C Complier. Yeah, I'm a small-time free software developer, and in that project you can find code I've contributed (mostly in the libraries).
I started working on the trig functions. There's a method called CORDIC (the alternate approach is polynomial approximation). Sine, Cosine and Arctangent are pretty documented for the CORDIC method. For Arcsine and Arccosine, not so easy. The widely published methods work, but they're not very accurate over the whole range needed.
Turns out, there's one paper in an old IEEE journal with a modification to the standard CORDIC algorithm which makes it accurate for these functions over the entire 0 to 1 input range. I searched for days, and found lots of brief mentions of this paper, and lots and lots of descriptions of only sine, cosine and arctangent with only brief hints that it's possible to apply CORDIC to the others.
I wasn't willing to pay about $80 to download the paper, and not $250... this was just a little side project to improve the float library for that compiler for a particular architecture (coding it in assembly).
Fortunately, one of the other developers was an IEEE member and had access to the paper. After a couple days of fiddling, I figured out the matrix multiply embedded in the equation (funny how those papers hide the messy details like that), and I wrote some C code as a prototype for the algorithm.
I did end up committing lots and lots of float library code to the project.... assembly optimized versions of all the basic operations, conversions and comparisons, and natual log and e^x. Someday I'll probably get back into those trig functions... but the CORDIC code isn't a big win anymore, now that the basic operations and heavily optimized and are used by the old polynomial approx code.
So, in this one little case, there was no way I was going to shell out lots of real dollars for access to an old IEEE published paper for that algorithm. It was old, published many years ago. Having it on-line for free download probably wouldn't cost IEEE anything in lost sales of recently journals.
But not having access to the information would have cost me and the SDCC project access to the algorithm, which someday (when I get the time to get back into the project) may get coded nicely into the library and benefit all sorts of people who may use the compiler and need those two trig functions. Especially on such small chips, assembly optimized libraries are a big deal and end up saving precious bytes of ram and code space. CPU speed is also improved... but not a giant win over the polynomial approach built on top of assembly optimized basic functions.
Sorry, but campaigns claiming that windows is cheaper than linux, based on MS-sponsored biased reports, are indeed FUD.
No. They're somewhere between "biased" to "lies".
FUD is when you conveniently ignore reality and depend on gullibility and marketing instead.
No. FUD is Fear, Uncertainty and Doubt.
FUD is claims like "They probably won't be around to support it", "How are you going to explain to your boss you risked everything on the newcomer", or "There's no 3-year roadmap, so nobody is in control of where it'll be in a few years". It's fear, uncertainty and doubt about the product. Not hard facts (such as cost comparisons).
Claiming that a product has overall lower cost, and backing it up with a factual study (even a biased one) is not FUD. It may be dishonest if the study is biased or applies to a different scenario, but FUD it is not.
Really, we could write articles about how MS should sell its software as a superiour product
Actally, this does seem to be what Microsoft is trying to do. They're telling people Windows is better.
Hmm... I wouldn't call myself a "website developer", but I do have a multi-hundred page website that I just started working on again, after mostly neglecting it for a year.
Stop sitting there with your arms crossed and insisting on making sites that aren't in compliance with public standards.
First and foremost, I'm concerned about providing the best experience for anyone who visits my little site.
I wouldn't say I'm resisting standard ("sitting there with your arms cross..."). Standards make sense where they help. But if there's a choice between following a standard or making the site work properly for all users, guess which one I'm going to take?
CSS is an excellent example. Yeah, I'm using some style elements, but as nearly as I can tell, Microsoft's browser still has many horrible bugs on lots of CSS beyond just the basics. You're not going to see me making extensive use of CSS until 99.9% of all browsers in use fully support it without bugs. Things are getting better, but there's still a lot of people using windows 98 and IE 5.
it removes the power from proprietary software --- and that the mindset of "well it's just one cool non-standard feature" is exactly the mindset that got us in this mess!
Maybe that's your issue, but not mine. Over here, I'm worrying about how to make a good website.... not Microsoft's stranglehold on the PC industry. I want my site to work nicely for everyone who comes to visit.
What got us all into this "mess" is that, even now, a bunch of this "standard" stuff just doesn't work. Or more specifically, browsers that don't fully or correctly support it.
So don't blame me. Don't put this on web site developers. It's the fault of buggy browsers. Anyone making a website is at the mercy of poorly written broswers, and it going to do anything they can to give their users the experience they should get using the most reliable methods they can. Those broswers bugs hurt for a long time, because even if only a small fraction of the population does not upgrade, those bugs stay with us. Even then, many sites don't rework all their pages every month or year.
It's only been fairly recently that almost all browsers have really started supporting the standards, and some, like a certain one that has 90% of the market, still doesn't support them very well.
inside RH engineering we find it very bizarre that people consider RH Linux and Fedora to be different.
Well, Seth, let me explain it to you in 3 words: Red Hat Network. Or 3 other words: End Of Life.
Many of us used RHL for years and when Redhat offered the $60/year subscription, many of us who'd followed the security advisories or regularly checked the errata web page for new RPMs decided to sign up. Yeah, it seemed kinda weird paying $60 for something that has previously been available for free download or cheap on Infomagic cdroms. But Redhat had displaced Slackware and became a pillar of the community and had seemed worthy... paying the $60/machine seemed like a nice way to give back to Redhat.
All that changed. Redhat abruptly announced end of life on all 7.x and 8.x, which were at the time the bulk of all installed linux machines. 9.x end of life was also announced... not even 12 months out (long enough for all paid subscribers to complete their service). These are simple facts. You can endlessly argue subjective opinions about the public statements Redhat made. Maybe I took it all the wrong way and heard "We don't give a shit about you hobbist and small business types, so use this unsupported, short-life, beta-quality fedora and stop freeloading". But the undeniable FACT is that only about 1-2 years prior, Redhat got most of its most loyal supporters to sign up for RHN for $60/machine, with vauge promises of long-term paid "support" (basically, automatic notifications and updates). We all paid our $60/machine, trusting Redhat that we could depend on them. That trust was betrayed.
Many people went to Fedora. Many of us did not. I kept using RH9 for some time, and eventually switched to Debian. I'm really happy with Debian and apt-get. Why Debian?
I'm a small-time open-source developer. Aside from stuff on my own website, the one "real" open-source project I'm involved in is SDCC. Most of the developers on the project, long ago, used either Redhat or Debian. I was one of the Redhat guys. Most of the end users run it on Windows. Back then, SDCC went though bug after bug after bug, all revolving around not deleting temp files, finding library paths, and sometimes excessive memory allocation. Of course, most of the problems were on the windows port. At the time, some builds were cross compiled, others were native using borland or msvc. Endless back-and-forth consisted of "Well, I'm using Redhat, and it does ABC", "On Debian, it does XYZ", can anyone on windows even tell what it really does? Eventually, those cross platform issues got worked out, and I was left with a lasting impression that most end users run on windows, and developers write on Debian and Redhat.
When the RHN end of life and bad PR... which sounded a lot like "we only care about enterprise customers... the rest of you are only good for beta testing"... came out, I decided it was time to make a switch. I resisted for some time, letting my RH9 system and an old RH7.2 system get out of date. FC2 came out, and people seemed to like it. That would have been the path of least resistance. But I remembered well that many of the other developers, at least in the one many-developer project I'm on, were using Debian. If I had to switch to something new and reinstall, why not go with Debian.
I've been using Debian ever since. I switched to "unstable", and despite the scary name, it's really great. I love apt-get.
Vorbis actually requires more RAM. A lot more. The spec also calls for a lot of 64 bit math.
In MP3, frames are always 1152 samples. Frames have a maximum size, and the amount of previous data they can depend upon is limited to a fixed amount. Some other buffering is needed to extract the compressed data into the uncompressed spectra, and then the MDCT and polyphase filter turns it into time domain. Half the previous frame's decoded data is needed to overlap with the next. RAM required is minimal (buffer input, hold one 1152 sample frame, store 1/2 of last one).
In Vorbis, frames can range from 64 to 8192 bytes (only two sizes are actually used in any particular vorbis stream, but a compliant decoded needs to be able to hanle 8192 byte frames if the stream is encoded with them). Vorbis frames don't depend on previous frame data (though the audio samples from the last 1/2 frame overlap, similar to mp3's iMDCT overlap), but frame size is unlimited in vorbis. So basic decoding needs up to a 8192 sample buffer, plus storing 1/2 the previous, and a potentially large compressed frame input buffer. So far, similar to mp3 if the encoder only outputs reasonable frames, only about 7x more due to the 8192 sample frame maximum.
If that were the whole story, it wouldn't be so bad. Saddly, it isn't.
Where other codecs use lots of fixed tables (called codebooks in the vorbis spec), vorbis uses no hard-coded tables. They're all provided in a header at the beginning of the stream. Vorbis places no upper limit on the size of this header, but the spec strongly suggests the compressed size be kept around 4k or less. That's with compression... not gzip-like compression, mind you. When expanded to a useful table in memory, these are quite large.
Similar tables exist in MP3, but because they are fixed and not included in the bitstream, they can be encoded into ROM, which is cheap. For Vorbis, they need to be in RAM. With lots of RAM, it's no problem. Just expand them all and use them. With limited RAM, the (hopefully) 4k header is kept and a lot of work is done to compress them on demand.
The other vorbis issue is the need for 64 bit math. At least to be fully compliant with the spec (using only 32 bits may lose quality). Vorbis frames, once unpacked, basically consist of two vectors... with you can think of as representing the spectrum of that frame's audio in course and fine resolution. You compute the dot product of these vectors to get the spectrum, and the spec says to use 64 bit precision. Then you do an inverse DCT (using 64 bit math) to get the time domain audio. At this point, you can go back to normal integers, apply the windows and overlapping (with the previous 1/2 frame) and output the audio samples. The kicker is doing that inverse DCT with 64 bit numbers. If you have a 32x32->64 multiply, that's 4X the number of multiplies, plus a bunch of adds and extra housekeeping.
I suspect that some embedded devices with vorbis support probably truncate to 32 bits after the dot product of those vectors and do the inverse DCT with only 32 bit precision. Apparantly this works most of the time, but loses some quality and won't necessarily be fully compliant with future improvements in vorbis encoding.
From an embedded developer perspective, vorbis requires much more RAM to decode than MP3. More than is included on-chip with common low-cost and low-power DSPs or microcontrollers with lightweight DSP capability.
Sure, including ALL the codebooks in the header makes the format highly flexible and adaptable in the future. But is make vorbis rather difficult in a DSP that can implment MP3.
The next hundred years is going to be a fight for technology
Please, try to keep some historical perspective.
It didn't take 100 years for the battle against recordable audio tape to diminish, and the RIAA members trippled their revenue after embracing the format.
The battle against VCRs didn't last 100 years, after which the MPAA members doubled their revenue.
Likewise, free radio broadcast of music wasn't fought that long by recording artists who ultimately used radio for marketing to increase their sales, rather than decrease them.
Photocopiers weren't fought for 100 years by publishers, whose immediate demise was also predicted.
If you look over at yahoo news, you'll see a front page story today proclaiming that on-line music sales last year became a substantial portion of the record industries revenue.
If history repeats itself, and it certain appears on-track, all this silly war against piracy will die down soon, and the RIAA/MPAA will be making more money than ever.
Sure, they'll always gripe and bitch about file sharing... just like they still don't like VHS and audio cassette tapes, but the point is they're already starting on the trend of exploiting the new market to make even more money (despite their best efforts to kill it).
The old saying, "the more things change, the more they stay the same" applies here. These new technology vs old busniess model struggles are nothing new. They play out over 5-15 years... not 100 years, and this one is already entering the phase where the old gaurd starts making even more money and wakes up to the fact that the new technology is a new, profitable market.
But Harrington said the CAN-SPAM Act, which took force last January, makes
all firms that engage in affiliate marketing liable for the actions of their sub-contractors.
"There's a message here for anybody running an affiliate program; you need to monitor what the third parties are doing," she said. "If you are using a business model that recruits others, you are strictly liable for the practices of those third parties. It's not just the people who push the button. It's the business that provides the financial incentive. The law is clear and strict."
And quoting from the CNN Money article:
A federal judge has issued a temporary restraining order against the defendants that prohibits them from sending similar e-mails and
freezes their assets, pending a preliminary hearing.
Now if all the companies and people involved are outside the US, or they keep all their money stuffed in their mattresses and pay cash for everything, maybe they can just run away.
But if they've done any banking within the US, they probably stand to lose all their money if they don't show up in court. (now if only groklaw would cover these cases....)
Just to keep things in perspective, here's a repost of a rather insightful look an some of these "bugs" by BruceRamsay in a comment over on LWN:
I'm sure there are valuable fixes in these patches. I look forward to their inclusion in a future kernel. However, it is good to keep things in perspective. The world did not collapse without these patches.
After a quick look at the bugs listed I have a few questions about some of the analysis. For example:
>> if(len > sizeof(moxaBuff)) > ^ signed int has only upper-bound checked >> return -EINVAL;
On all systems I know of, sizeof() produces an unsigned number. In C, comparisons between unsigned numbers and signed numbers are done as unsigned comparisons. In fact, -1 > sizeof(moxaBuff) is true. Therefore the comment "signed int has only upper-bound checked" is incorrect. After the test we are guaranteed that 0 <= len <= sizeof(moxaBuff). (I am speaking about real world C implementations and not theoretically possible C compilers.)
A quick look at Linux source code shows me that, at least on some architectures, PAGE_SIZE is an unsigned number. So tests like "len < PAGE_SIZE" also check for negative values of len.
It is hard to put a high priority on something which also includes incorrect analysis.
Still, I applaud the use automatic code analysis for producing clean and correct code. The more bugs removed the better.
If they make the crypto so good that difficult recapture techniques are needed... then doing so and offering the highest quality capture will become a challenge.
Much like the challenge today of posting the highest quality captures of currently running movies, whomever has the best rig and knows an insider to grab a copy of the disc shortly before release will go to extrordinary lengths. Like today, and as it's been in "warez" since the 80's Apple ][ and C64 games on BBSs, they'll get to promote their silly handle/name/slogan. Their group gets a few minutes of underground fame for having an elite, pristine copy early. Of course, in a matter of days, lots and lots of these second tier folks without the fancy gear get their few minutes of fame, being part of such an elite group... by impressing their friends with high quality copies of the new flick. Soon it's on p2p networks and mundane.
But there's always some new, shiney thing to pirate.... some new thing, that if obtained at the highest quality during that brief, fleeting period of newness, is cool. It's fun. If copied in their tiny window of time, it's elite. It's a powerful motivation to a class of very talented folks who, saddly, don't want to or have the opportunity to direct their energy to more worthy goals.
Once these discs are out, and before the crypto is really broken (took 3 years before anyone hacked css), these HD discs will provide that hacker motivation. Most likely, they'll be recaptured and turned into 4.5 gig mpeg4 avi files suitable for burning to a dvdrw.... with a few minutes of fame for the elite hackers with HD capable recapture and early access, followed by lesser but still very enjoyable minutes of fame for armies of trickle down until they hit the p2p networks.
The more things change, the more they stay the same (but substitute ftp sites, websites, usenet binaries groups, or even BBSs for "p2p networks").
Honestly - I work in the industry, and I'm still amazed at the lengths content providers will go to to try to prevent a single D-to-A, A-to-D conversion.
And exactly what length is that?
Last I heard, the royalty for macrovision is about 5 cents per disc.
It was news (here on slashdot some time ago) when the 2nd Happry Potter disc was released without macrovision enabled (just a single flag on the disc) to save the royalty cost. Many, many millions of copies sold within the opening days. That was the exception.
Just keep the "lengths the content providers [are] will to go" into perspective. It's several pennies per disc that retails for about $25 (US), and sometimes discounts to about half that.
Those pennies add up quickly, and there are plenty of folks who'd love to "tap that market" by offering DRM to the content providers. But ultimately, it's all about money. Studio execs aren't sitting around thinking about crypto. It's just a product they buy.
Second, when playing the "terrorist card" as a tactic against some person or group, the 2 worst things you could do are to phrase it in the form of a question and invite rational thought/analysis.
Slashdot Mirror
The Bittorrent protocol uses SHA1 hashing.
Yes, there was recently a paper presented that "broke" SHA1, but the result is 2**69 operations instead of 2**80 to find a SHA1 collision. 2**69 is still a very large number of operations... a lot less than a full 2**80, but still a prohibitively large number (more costly than the actual realized losses the entertainment industry is suffering).
In this particular case, the person who was "loaned" the car (with the implication it would not be taken away) was very famous and many others started to purchase that same model of car, because of his well spoken preference for the superiority of that particular car. After the cars were selling very well, and the needs of paying customer diverged from those who'd been given free models, the company decides it's no longer worth the promotional value to keep providing free ones.
What consequences? Having the kernel be way better than it would have been if Linus had listened to you people and not used BitKeeper?
The pace of kernel development did improve. Some may have been BK's superior performance, but much was attributed to the increased delegation of responsibility (eg, RTFA)
The "consequence" is that now, this improved speed can not continue much longer, until some other replacement is developed.
Sure, BitKeeper might be going away--but the things Linus accomplished while it was here will NOT go way.
But the improved speed may go away.
Worse yet, the pace of kernel development might even slow for some time, as developers all migrate to another tool. Consider that changeset data is locked in a proprietary format that needs to be reverse engineered.
Bloor's opinions are just another well worn paradigm: the more deeply entrenched it has become, the more novel licensing is evaluated in a myopic/short-sighted view of traditional software purchasing, the more it plays back into the hands of the traditional behemoths that dominate the industry.
so many people are moving from professional browsers to more amature ones ... whose maintainers and coders are just "hackers" or college kids ... not real software engineers.
Yeah, everyone's gonna be a lot safer staying with IE, right? Certainly the track record on critical vulnerabilities should be a strong indication.
No, No, NO. You guessed wrong.
They most certainly are NOT free to do any such thing.
They command a monopoly power, and it is clearly illegal to tie products together so as to leverage a monopoly in one product to effectively shut out competitors for your other product.
But, there is at least some length they could go to to restore my trust in them. They've supposedly "embraced open source", whatever that means. But if their player is ever accepted into Debian unstable or Debian testing... then that will be the tipping point where I know I can trust it!
It'll probably be a cold day in hell, but hey, if they ever do truely reform and offer a truely free, truely open source player that passes all the Debian guidelines, I'd say it's time to trust them again.
One rate is for phone or internet orders, and the other is for in-person (cardholder present) sales. Sales without the cardholder present are a higher risk, and the bank charges the merchant (or at least in our case) a higher fee per transaction. I really don't pay attention to what the fees are anymore... there is little we can do about it, so time and energy is better spent trying to increase sales rather than worry about small, unavoidable fees.
Again, according to Robin, the card swipe through the terminal proves that the physical card was present, and the signature proves that the customer was present, saw and accepted the goods. These are factors that, on average over the sum of all transactions, significantly reduce risk. That is why they are important. It is this overall trend that matters to banks and the credit card processing clearinghouses.
Now, in the IT/computer security world, there's a tendancy to think of potential weaknesses, how to exploit them, and how to design countermeasures... roughly in that order, and in this case the first two. Valuable as this is, the constructive approach is to apply creative throught towards improvement, rather than cynical dismissal (common of slashdot comment posters) of the importance of a signature because most clerks don't check.
In fact, the truth is that on average, in-person transactions with a card swipe and signature carry a lower risk of fraud. Perhaps that risk would be even lower if most clerks checked the signature more closely, but even with the reality of today's environment, the card swipe and signature do indeed result in lower risk of fraud, which is passed on to the merchant as a lower fee.
To give you one tiny example, several months ago I was working on a rewrite of the floating point library for the SDCC C Complier. Yeah, I'm a small-time free software developer, and in that project you can find code I've contributed (mostly in the libraries).
I started working on the trig functions. There's a method called CORDIC (the alternate approach is polynomial approximation). Sine, Cosine and Arctangent are pretty documented for the CORDIC method. For Arcsine and Arccosine, not so easy. The widely published methods work, but they're not very accurate over the whole range needed.
Turns out, there's one paper in an old IEEE journal with a modification to the standard CORDIC algorithm which makes it accurate for these functions over the entire 0 to 1 input range. I searched for days, and found lots of brief mentions of this paper, and lots and lots of descriptions of only sine, cosine and arctangent with only brief hints that it's possible to apply CORDIC to the others.
I wasn't willing to pay about $80 to download the paper, and not $250... this was just a little side project to improve the float library for that compiler for a particular architecture (coding it in assembly).
Fortunately, one of the other developers was an IEEE member and had access to the paper. After a couple days of fiddling, I figured out the matrix multiply embedded in the equation (funny how those papers hide the messy details like that), and I wrote some C code as a prototype for the algorithm.
I did end up committing lots and lots of float library code to the project.... assembly optimized versions of all the basic operations, conversions and comparisons, and natual log and e^x. Someday I'll probably get back into those trig functions... but the CORDIC code isn't a big win anymore, now that the basic operations and heavily optimized and are used by the old polynomial approx code.
So, in this one little case, there was no way I was going to shell out lots of real dollars for access to an old IEEE published paper for that algorithm. It was old, published many years ago. Having it on-line for free download probably wouldn't cost IEEE anything in lost sales of recently journals.
But not having access to the information would have cost me and the SDCC project access to the algorithm, which someday (when I get the time to get back into the project) may get coded nicely into the library and benefit all sorts of people who may use the compiler and need those two trig functions. Especially on such small chips, assembly optimized libraries are a big deal and end up saving precious bytes of ram and code space. CPU speed is also improved... but not a giant win over the polynomial approach built on top of assembly optimized basic functions.
Obviously, your benchmarks aren't anything like the tests in this thread, where rxvt-unicode is MANY times faster than gnome terminal.
No. They're somewhere between "biased" to "lies".
FUD is when you conveniently ignore reality and depend on gullibility and marketing instead.
No. FUD is Fear, Uncertainty and Doubt.
FUD is claims like "They probably won't be around to support it", "How are you going to explain to your boss you risked everything on the newcomer", or "There's no 3-year roadmap, so nobody is in control of where it'll be in a few years". It's fear, uncertainty and doubt about the product. Not hard facts (such as cost comparisons).
Claiming that a product has overall lower cost, and backing it up with a factual study (even a biased one) is not FUD. It may be dishonest if the study is biased or applies to a different scenario, but FUD it is not.
Really, we could write articles about how MS should sell its software as a superiour product
Actally, this does seem to be what Microsoft is trying to do. They're telling people Windows is better.
Especially when the customer pays for the CPU.
In the embedded world, where the CPU and code are both part of the same product, the design philisophy is quite different.
Yeah, that explains why 20-some million people are using Firefox to websites, access 60-some percent of which are running on Apache.
Hmm... I wouldn't call myself a "website developer", but I do have a multi-hundred page website that I just started working on again, after mostly neglecting it for a year.
Stop sitting there with your arms crossed and insisting on making sites that aren't in compliance with public standards.
First and foremost, I'm concerned about providing the best experience for anyone who visits my little site.
I wouldn't say I'm resisting standard ("sitting there with your arms cross..."). Standards make sense where they help. But if there's a choice between following a standard or making the site work properly for all users, guess which one I'm going to take?
CSS is an excellent example. Yeah, I'm using some style elements, but as nearly as I can tell, Microsoft's browser still has many horrible bugs on lots of CSS beyond just the basics. You're not going to see me making extensive use of CSS until 99.9% of all browsers in use fully support it without bugs. Things are getting better, but there's still a lot of people using windows 98 and IE 5.
it removes the power from proprietary software --- and that the mindset of "well it's just one cool non-standard feature" is exactly the mindset that got us in this mess!
Maybe that's your issue, but not mine. Over here, I'm worrying about how to make a good website.... not Microsoft's stranglehold on the PC industry. I want my site to work nicely for everyone who comes to visit.
What got us all into this "mess" is that, even now, a bunch of this "standard" stuff just doesn't work. Or more specifically, browsers that don't fully or correctly support it.
So don't blame me. Don't put this on web site developers. It's the fault of buggy browsers. Anyone making a website is at the mercy of poorly written broswers, and it going to do anything they can to give their users the experience they should get using the most reliable methods they can. Those broswers bugs hurt for a long time, because even if only a small fraction of the population does not upgrade, those bugs stay with us. Even then, many sites don't rework all their pages every month or year.
It's only been fairly recently that almost all browsers have really started supporting the standards, and some, like a certain one that has 90% of the market, still doesn't support them very well.
Well, Seth, let me explain it to you in 3 words: Red Hat Network. Or 3 other words: End Of Life.
Many of us used RHL for years and when Redhat offered the $60/year subscription, many of us who'd followed the security advisories or regularly checked the errata web page for new RPMs decided to sign up. Yeah, it seemed kinda weird paying $60 for something that has previously been available for free download or cheap on Infomagic cdroms. But Redhat had displaced Slackware and became a pillar of the community and had seemed worthy... paying the $60/machine seemed like a nice way to give back to Redhat.
All that changed. Redhat abruptly announced end of life on all 7.x and 8.x, which were at the time the bulk of all installed linux machines. 9.x end of life was also announced... not even 12 months out (long enough for all paid subscribers to complete their service). These are simple facts. You can endlessly argue subjective opinions about the public statements Redhat made. Maybe I took it all the wrong way and heard "We don't give a shit about you hobbist and small business types, so use this unsupported, short-life, beta-quality fedora and stop freeloading". But the undeniable FACT is that only about 1-2 years prior, Redhat got most of its most loyal supporters to sign up for RHN for $60/machine, with vauge promises of long-term paid "support" (basically, automatic notifications and updates). We all paid our $60/machine, trusting Redhat that we could depend on them. That trust was betrayed.
Many people went to Fedora. Many of us did not. I kept using RH9 for some time, and eventually switched to Debian. I'm really happy with Debian and apt-get. Why Debian?
I'm a small-time open-source developer. Aside from stuff on my own website, the one "real" open-source project I'm involved in is SDCC. Most of the developers on the project, long ago, used either Redhat or Debian. I was one of the Redhat guys. Most of the end users run it on Windows. Back then, SDCC went though bug after bug after bug, all revolving around not deleting temp files, finding library paths, and sometimes excessive memory allocation. Of course, most of the problems were on the windows port. At the time, some builds were cross compiled, others were native using borland or msvc. Endless back-and-forth consisted of "Well, I'm using Redhat, and it does ABC", "On Debian, it does XYZ", can anyone on windows even tell what it really does? Eventually, those cross platform issues got worked out, and I was left with a lasting impression that most end users run on windows, and developers write on Debian and Redhat.
When the RHN end of life and bad PR... which sounded a lot like "we only care about enterprise customers... the rest of you are only good for beta testing"... came out, I decided it was time to make a switch. I resisted for some time, letting my RH9 system and an old RH7.2 system get out of date. FC2 came out, and people seemed to like it. That would have been the path of least resistance. But I remembered well that many of the other developers, at least in the one many-developer project I'm on, were using Debian. If I had to switch to something new and reinstall, why not go with Debian.
I've been using Debian ever since. I switched to "unstable", and despite the scary name, it's really great. I love apt-get.
And I'm still a little bitter about Redhat.
If you buy the retail version (higher price), you can move it to different machines.
A year ago, we decided to "get legal" and purchased the retail boxes for Win 2000 (no activation).
In MP3, frames are always 1152 samples. Frames have a maximum size, and the amount of previous data they can depend upon is limited to a fixed amount. Some other buffering is needed to extract the compressed data into the uncompressed spectra, and then the MDCT and polyphase filter turns it into time domain. Half the previous frame's decoded data is needed to overlap with the next. RAM required is minimal (buffer input, hold one 1152 sample frame, store 1/2 of last one).
In Vorbis, frames can range from 64 to 8192 bytes (only two sizes are actually used in any particular vorbis stream, but a compliant decoded needs to be able to hanle 8192 byte frames if the stream is encoded with them). Vorbis frames don't depend on previous frame data (though the audio samples from the last 1/2 frame overlap, similar to mp3's iMDCT overlap), but frame size is unlimited in vorbis. So basic decoding needs up to a 8192 sample buffer, plus storing 1/2 the previous, and a potentially large compressed frame input buffer. So far, similar to mp3 if the encoder only outputs reasonable frames, only about 7x more due to the 8192 sample frame maximum.
If that were the whole story, it wouldn't be so bad. Saddly, it isn't.
Where other codecs use lots of fixed tables (called codebooks in the vorbis spec), vorbis uses no hard-coded tables. They're all provided in a header at the beginning of the stream. Vorbis places no upper limit on the size of this header, but the spec strongly suggests the compressed size be kept around 4k or less. That's with compression... not gzip-like compression, mind you. When expanded to a useful table in memory, these are quite large.
Similar tables exist in MP3, but because they are fixed and not included in the bitstream, they can be encoded into ROM, which is cheap. For Vorbis, they need to be in RAM. With lots of RAM, it's no problem. Just expand them all and use them. With limited RAM, the (hopefully) 4k header is kept and a lot of work is done to compress them on demand.
The other vorbis issue is the need for 64 bit math. At least to be fully compliant with the spec (using only 32 bits may lose quality). Vorbis frames, once unpacked, basically consist of two vectors... with you can think of as representing the spectrum of that frame's audio in course and fine resolution. You compute the dot product of these vectors to get the spectrum, and the spec says to use 64 bit precision. Then you do an inverse DCT (using 64 bit math) to get the time domain audio. At this point, you can go back to normal integers, apply the windows and overlapping (with the previous 1/2 frame) and output the audio samples. The kicker is doing that inverse DCT with 64 bit numbers. If you have a 32x32->64 multiply, that's 4X the number of multiplies, plus a bunch of adds and extra housekeeping.
I suspect that some embedded devices with vorbis support probably truncate to 32 bits after the dot product of those vectors and do the inverse DCT with only 32 bit precision. Apparantly this works most of the time, but loses some quality and won't necessarily be fully compliant with future improvements in vorbis encoding.
Sure, including ALL the codebooks in the header makes the format highly flexible and adaptable in the future. But is make vorbis rather difficult in a DSP that can implment MP3.
Please, try to keep some historical perspective.
It didn't take 100 years for the battle against recordable audio tape to diminish, and the RIAA members trippled their revenue after embracing the format.
The battle against VCRs didn't last 100 years, after which the MPAA members doubled their revenue.
Likewise, free radio broadcast of music wasn't fought that long by recording artists who ultimately used radio for marketing to increase their sales, rather than decrease them.
Photocopiers weren't fought for 100 years by publishers, whose immediate demise was also predicted.
If you look over at yahoo news, you'll see a front page story today proclaiming that on-line music sales last year became a substantial portion of the record industries revenue.
If history repeats itself, and it certain appears on-track, all this silly war against piracy will die down soon, and the RIAA/MPAA will be making more money than ever.
Sure, they'll always gripe and bitch about file sharing... just like they still don't like VHS and audio cassette tapes, but the point is they're already starting on the trend of exploiting the new market to make even more money (despite their best efforts to kill it).
The old saying, "the more things change, the more they stay the same" applies here. These new technology vs old busniess model struggles are nothing new. They play out over 5-15 years... not 100 years, and this one is already entering the phase where the old gaurd starts making even more money and wakes up to the fact that the new technology is a new, profitable market.
But if there was a mix-up, the innocent bystander could contact the FTC, petition the court, or show up to the hearing.
Well, from the MSNBC article:
And quoting from the CNN Money article:
Now if all the companies and people involved are outside the US, or they keep all their money stuffed in their mattresses and pay cash for everything, maybe they can just run away.
But if they've done any banking within the US, they probably stand to lose all their money if they don't show up in court. (now if only groklaw would cover these cases....)
Much like the challenge today of posting the highest quality captures of currently running movies, whomever has the best rig and knows an insider to grab a copy of the disc shortly before release will go to extrordinary lengths. Like today, and as it's been in "warez" since the 80's Apple ][ and C64 games on BBSs, they'll get to promote their silly handle/name/slogan. Their group gets a few minutes of underground fame for having an elite, pristine copy early. Of course, in a matter of days, lots and lots of these second tier folks without the fancy gear get their few minutes of fame, being part of such an elite group... by impressing their friends with high quality copies of the new flick. Soon it's on p2p networks and mundane.
But there's always some new, shiney thing to pirate.... some new thing, that if obtained at the highest quality during that brief, fleeting period of newness, is cool. It's fun. If copied in their tiny window of time, it's elite. It's a powerful motivation to a class of very talented folks who, saddly, don't want to or have the opportunity to direct their energy to more worthy goals.
Once these discs are out, and before the crypto is really broken (took 3 years before anyone hacked css), these HD discs will provide that hacker motivation. Most likely, they'll be recaptured and turned into 4.5 gig mpeg4 avi files suitable for burning to a dvdrw.... with a few minutes of fame for the elite hackers with HD capable recapture and early access, followed by lesser but still very enjoyable minutes of fame for armies of trickle down until they hit the p2p networks.
The more things change, the more they stay the same (but substitute ftp sites, websites, usenet binaries groups, or even BBSs for "p2p networks").
And exactly what length is that?
Last I heard, the royalty for macrovision is about 5 cents per disc.
It was news (here on slashdot some time ago) when the 2nd Happry Potter disc was released without macrovision enabled (just a single flag on the disc) to save the royalty cost. Many, many millions of copies sold within the opening days. That was the exception.
Just keep the "lengths the content providers [are] will to go" into perspective. It's several pennies per disc that retails for about $25 (US), and sometimes discounts to about half that.
Those pennies add up quickly, and there are plenty of folks who'd love to "tap that market" by offering DRM to the content providers. But ultimately, it's all about money. Studio execs aren't sitting around thinking about crypto. It's just a product they buy.
First, installing adware hardly meets the definition of violence.
Second, when playing the "terrorist card" as a tactic against some person or group, the 2 worst things you could do are to phrase it in the form of a question and invite rational thought/analysis.