I know everyone means well with their suggestions, but I've got over 300 DVDs in my collection. At least 60-70 of them have played just fine on the X-Box. They all play fine on the computers and Sony set-top.
My point is more that the "extras" on some disks already break some players. Additional DRM will further reduce playability, when most of the disks that use copy protection now are just mass-marketting media pulp from US conglomerates.
A good third of my anime disks have no copy protection, yet they don't seem to be suffering on sales. Maybe because most fans aren't the thieves US media thinks, but are just not willing to part with hard-earned dollars for crap that should be priced in the $10-20 range, not $35 and up.
Every other DVD, CD, and game plays fine on my X-Box. This one disk reports as being unrecognized, and my presumption is that it's detecting the autorun.inf that it can't handle.
I'd have suspected the DVD itself if it didn't play just fine in my computer, my friend's computer, and my Sony set-top player.
DVD's like the extended edition of "Fellowship of the Ring" already won't play on legal set-top hardware like the XBox because it doesn't get recognized as a DVD (while playing just fine in 3 other set-top units.)
As far as I'm concerned, the industry is already shipping pre-destructed material. Shoddy plotlines. Crappy acting, B-stories with A-budgets. "Adaptations" of classics. Bah.
And what do you think happens when you upgrade an RDBMS, but run the old clients? Or upgrade the file server? Or print server?
Upgrades and running with untested versions are what internal testing processes are for. Vendors will not and cannot be expected to test with every possible combination of tools and releases -- you need to verify your particular environment.
Or you can refuse to think about it and just use the JRE that came with the product.
It's a common practice to type in a key algorithm from a textbook or online source as comments to explain what not-so-obvious code is doing. I would not be at all surprised to find that the "identical" comments are the result of such practices, though it's far more likely the code came from BSD or other sources.
SCO doesn't just have to prove there is identical code -- they have to prove that their IP is the originator of that code. I find the chances of that pathetically slim.
I hate SCO for being such a shining example of everything wrong with US IP enforcement. I love SCO for being a shining example of why OSS licenses and standards are so important to industry and the general public.
Microsoft is another animal entirely. It is their blatant egomaniacal search for total control and domination of IT that is scary.
SCO is just a mosquito annoying the world, and about to be slapped into protein paste. Microsoft is the wolf pack that can actually do damage if they ever slip their loose leash.
Sun may require that you distribute an application in order to distribute a JRE, but I have yet to install a utility on Solaris, SuSE, RedHat, Mandrake, WinXP, Win2K, or WinNT that did not allow me to specify the location of my JRE.
The "recommended" JRE shipped by the application provider is simply the one that they've done their testing with.
The only exception I've found is for Java in RDBMS stored procs, which obviously have to run with the JRE that is bound in to the RDBMS.
The fact that most so-called sysadmins are afraid to select a configuration other than "default" says far more about the sysadmin's skill than the product or it's installer.
I got into computers because of video games and curiosity, not because I had access to some whiz-bang machine with high level languages.
Machine code was POKE'd into memory. No assembler. No compiler. BASIC at that point was little more than a CLI you booted into, not a real language.
You can't "make" someone interested in things, just encourage them when they show interest. Anyone looking for quick gratification is not going to stick with programming -- it just takes too much time and attention to detail for most people to tolerate.
With the still-ongoing cases over domain theft and fraud, is it at all surprising that it's also active in areas like IP block assignments?
I get SPAM with faked reply-to, sent-by, and domain names. Most hacks against my systems are from IP addresses that don't resolve back to a valid domain.
The only shock here is that someone was dumb enough to think they could get a/16 for only $500.
Open source and open standards save a lot of money for implementors. Even at $0.25 per sales unit, a moderately successful game selling 100,000 units would have to pay out $25,000 in license fees. Multiply that by a few "cheap" technologies, and you are soon into serious money that could pay for an extra developer-year or more. That can make a significant difference in the quality of the shipped game.
I grew up in the midwest. Any farmer has no problems buying fertilizer. Diesel is just an issue of finding a gas station. The fact that the two can combine to produce crude nitro explosives doesn't make either illegal.
Nor has that changed at all. Farmers already have corp paperwork, tax ids, etc. registered with their suppliers. The most they might have had to do is fill out one more form to provide legal confirmation that their farmers, just in case the people they've dealt with for the past 20 years forgot.
The RIAA cannot make tools like codec's illegal. It would be like outlawing screwdrivers because they might get used to hotwire a car. While technically true, there are far too many legitimate uses for the tool.
Ogg Vorbis is used in mainstream games like Unreal. There is no reason to expect the game industry wouldn't go with Ogg Theora for video as well. As long as it's stable and performs well, why would game developers opt for non-portable proprietary solutions?
Where and when did the author of the search engine sign a contract with the RIAA promising it would not index music files? Did he sign another with the MPAA promising it wouldn't index video files? Is there someone he should contract with to avoid indexing still images?
This is not a contract issue, but an issue of rights and freedoms. Search engines are just information filters. They don't provide the data, just a means of locating it. If someone is searching for illegal material, or making illegal material available, the resulting issues are their responsibility, not the search engine author's.
You are correct about this not being a freedom of speech issue, until you consider that the index of a hard-copy document (such as an encyclopedia) is the equivalent of a search engine for online material. Are you suggesting the RIAA should be able to block any document index from referencing MP3's or OggVorbis information because it can be used to perform an illegal act?
What's next -- the RIAA sues Google for allowing you to search for the pattern "MP3"? Perhaps they can go after Addison-Wesley and other book publishers next for providing guides and manuals that can be used to develop the next technology the RIAA is threatened by.
Clauses about owning what you do on your own time don't usually hold up in court, and I've yet to run into a client who wasn't willing to stroke that section out of the contract when I explain why it's an issue for me and my career.
The two places I've worked that leveraged OSS were good about posting their enhancements, one works directly with the developers for a key OSS product they use. (It's been a big benefit to both -- the OSS developer has been adding features they need, and they've been providing him a "real life" debug environment with a highly skilled team and solid feedback.)
I've always specifically steered clients away from GPL libraries, as their business IP isn't worth risking when there are LGPL (or equivalent) libraries that do the same job. Rah-rahs for the GPL and all that, but banks and financial companies aren't even going to consider putting their internal processing systems out as GPL software, and don't qualify for internal-use-only exceptions in most cases.
It sounds to me like this might not even be an investigation of IBM per se, but an investigation as to how a particular customer arranged payment for their orders. Maybe Enron or some such convinced IBM to take a stock swap for orders or some other trade intended to boost the customer's expenses without draining their cash reserve.
The comments by James Grant seem irrelevant, as there is no indication of exactly what is being investigated.
Maybe there is an accounting error somewhere at IBM, but it seems to me it's an investigation of a very specific set of transactions, not an investigation of overall practices ala Enron.
Reviewer chose not to migrate menus
on
Ximian's Back
·
· Score: 1
The reviewer comments on the first screenshot that it's what you'll see if you choose not to migrate your existing Gnome config. There is no mention of how well/if upgrading configs works, so I get the impression it wasn't tested by the reviewer.
Yes, GUI's are technically bloat to the techs. As I mentioned, their utility is in allowing people to accomplish the same tasks as techs without all the attention to detail and memorization of commands.
Playing audio in response to certian manipulations is something called feedback.
Oh really? You mean the fact that the window went away when I clicked the "close" button wasn't feedback enough -- I need to burn CPU cycles going "bing" and annoy the cubemates/roommates/family?
If you don't like it, then don't run it.
You miss my point. Anything which does not serve a purpose is bloat. Making things pretty and noisy makes for good eye candy to sell a system, but far too many app developers are spending all their time on skinning GUIs for apps that don't perform their basic function reliably or easily. The net is littered with tens of thousands of such projects, with barely usable non-intuitive interfaces that look really, really nice, and which let other people create equally unusable garish non-intuitive interfaces.
Eye candy is well and good for the masses, but let's make sure it works before making it pretty!
If it serves no utility other than "looking pretty" or "sounding good", it's bloat in a WM. Skinning. Translucent icons. Glowing/popping/spinning animted icons. Playing audio whenever you perform some particular manipulation.
All bloat. Very nice to look at, but it slows the system down and provides no functionality.
Technically the whole concept of a GUI is "bloat" to a purist, but I think there is too much ease-of-use utility to a GUI to slam the whole concept as bloat..
Actually your int version doesn't produce identical results.
In your prior example, each byte is calculated seperately, discarding any overflow bit. Changing to 4-byte integers means that the byte overflow bit is carried into the neighbouring byte by the integer math, producing different results.
Now if you want to get machine-specific, you could mess around with something like this:
char src[5];
char dst[5];
int * iSrc = &src[0];// compiler alias, no code
int * iDst = &dst[0];// compiler alias, no code
*dst = (*src << 1) & 0x01010101;
dst[5] = src[5] * 2;
Remember the int pointers are just compiler aliases, so the optimizer just ends up discarding the "variables" in favour of using the existing addresses provided by src and dst.
System licensing requires a seperate license for each machine.
User/Seat licensing requires a seperate license for each user, but not each machine.
Session licensing requires a license for each process, user, or device that is using the product, including those that access the product with sharing/concentrator products (e.g. the webserver only has 10 active database connections, but 300 users, so 300 session licenses are required.)
Corporate licensing is negotiated on a per-customer basis and sometimes includes the most "interesting" terms and conditions.
Microsoft is just conceding corporations the right to per-seat/user licensing, which is already one of the most common product licensing arrangements in the industry.
Don't underestimate the impact to Microsoft's bottom line. Under prior interpretations, Microsoft was requiring the corporations to pay for two licenses per telecommuting employee instead of one. They were also requiring extra licenses for failover systems which aren't intended to be used unless the primary fails!
In my (I admit not exactly exhaustive experience) the best value optmisations are those that are based upon things the programmer knows that are not expressed in the code and hence the compiler doesn't. Of course if you are using a shitty old compiler you also get the joys of doing by hand all the optimisations that have been automated for the last decade or two:)
Alas, it is the use of old broken compilers that usually has lead to the twisted code. Maybe you wouldn't be shocked at the number of sites out there that don't upgrade anything because they're horrified at the regression test expenses, but realize you can't update without testing.
Cool history on the coding. Cut my teeth on a TRS-80 Model I Level I myself, later banging away at C64, Amiga, and God knows how many variants on DOS, Windows, and *nix.
Any decent compiler would convert your array indexing to pointer code instead of recalculating the offset on each iteration.
Modern CPUs no longer have an effective performance difference between integer shifts and adds (reg-reg should be 1 internal CPU cycle, which is often a multiple of the external clock.)
So here is an "optimization" that might result from outdated processor/compiler assumptions. It would only work for positive integers on a "normal" processor (there used to be oddball CPUs that use 1's complement instead of 2's complement for signed integers):
Not only does the "tuned" version fail to improve performance, it loses the ability to deal with negatives. It's completely obfuscated the intent to fill dst with a doubling of src, has done nothing to improve performance, and thereby would deserve to be spanked.
Realistically, many CPUs could actually do the whole look as a single vector processing instruction -- a feature that has no explicit syntax, but can only be enabled by a good optimizing compiler or assembly inlines.
True, and the compiler should recognize that is what is happening, and tweak the output accordingly. That would make it real interesting for the decompiler to try to create code that even vaguely describes what is really going on!
You know, it's funny how you can take a common sample of performance tweaked code and turn it into a personal attack. Think I'll skip the many snarling replies that come to mind, and just remind myself you have no idea who I am or what my skills are.
Get out of the research labs and start creating and maintaining code that has to run on old hardware, old compilers, old third-party products, and has no upgrade budget. You go and explain to the management that performance tweaks would make the code "unmaintainable", and I'll stand by and have a chuckle while interviewing your replacement.
Real production code has tweaked segments. It's not "pretty", it's not as "readable" as some would like, but it is functionally equivalent. Odds are that if you're trying to reverse-engineer code, it's going to be old code that has been hacked and tweaked to keep it going after being rushed into production.
But hey, what do I know? I've only been programming for about 20 years, so obviously some prof saddled with the first year classes must have more insight. I humbly bow before the wisdom of one who preaches source code style while discussing decompilers...
A huge portion of the benefit of the "ugly" solution is that the overhead of invoking memcpy() as a function far exceeds the execution of the byte assignments. If your compiler is smart enough to unroll memcpy(), it would produce the output I described.
Slashdot Mirror
I know everyone means well with their suggestions, but I've got over 300 DVDs in my collection. At least 60-70 of them have played just fine on the X-Box. They all play fine on the computers and Sony set-top.
My point is more that the "extras" on some disks already break some players. Additional DRM will further reduce playability, when most of the disks that use copy protection now are just mass-marketting media pulp from US conglomerates.
A good third of my anime disks have no copy protection, yet they don't seem to be suffering on sales. Maybe because most fans aren't the thieves US media thinks, but are just not willing to part with hard-earned dollars for crap that should be priced in the $10-20 range, not $35 and up.
Every other DVD, CD, and game plays fine on my X-Box. This one disk reports as being unrecognized, and my presumption is that it's detecting the autorun.inf that it can't handle.
I'd have suspected the DVD itself if it didn't play just fine in my computer, my friend's computer, and my Sony set-top player.
DVD's like the extended edition of "Fellowship of the Ring" already won't play on legal set-top hardware like the XBox because it doesn't get recognized as a DVD (while playing just fine in 3 other set-top units.)
As far as I'm concerned, the industry is already shipping pre-destructed material. Shoddy plotlines. Crappy acting, B-stories with A-budgets. "Adaptations" of classics. Bah.
And what do you think happens when you upgrade an RDBMS, but run the old clients? Or upgrade the file server? Or print server?
Upgrades and running with untested versions are what internal testing processes are for. Vendors will not and cannot be expected to test with every possible combination of tools and releases -- you need to verify your particular environment.
Or you can refuse to think about it and just use the JRE that came with the product.
It's a common practice to type in a key algorithm from a textbook or online source as comments to explain what not-so-obvious code is doing. I would not be at all surprised to find that the "identical" comments are the result of such practices, though it's far more likely the code came from BSD or other sources.
SCO doesn't just have to prove there is identical code -- they have to prove that their IP is the originator of that code. I find the chances of that pathetically slim.
I hate SCO for being such a shining example of everything wrong with US IP enforcement. I love SCO for being a shining example of why OSS licenses and standards are so important to industry and the general public.
Microsoft is another animal entirely. It is their blatant egomaniacal search for total control and domination of IT that is scary.
SCO is just a mosquito annoying the world, and about to be slapped into protein paste. Microsoft is the wolf pack that can actually do damage if they ever slip their loose leash.
Sun may require that you distribute an application in order to distribute a JRE, but I have yet to install a utility on Solaris, SuSE, RedHat, Mandrake, WinXP, Win2K, or WinNT that did not allow me to specify the location of my JRE.
The "recommended" JRE shipped by the application provider is simply the one that they've done their testing with.
The only exception I've found is for Java in RDBMS stored procs, which obviously have to run with the JRE that is bound in to the RDBMS.
The fact that most so-called sysadmins are afraid to select a configuration other than "default" says far more about the sysadmin's skill than the product or it's installer.
I got into computers because of video games and curiosity, not because I had access to some whiz-bang machine with high level languages.
Machine code was POKE'd into memory. No assembler. No compiler. BASIC at that point was little more than a CLI you booted into, not a real language.
You can't "make" someone interested in things, just encourage them when they show interest. Anyone looking for quick gratification is not going to stick with programming -- it just takes too much time and attention to detail for most people to tolerate.
With the still-ongoing cases over domain theft and fraud, is it at all surprising that it's also active in areas like IP block assignments?
I get SPAM with faked reply-to, sent-by, and domain names. Most hacks against my systems are from IP addresses that don't resolve back to a valid domain.
The only shock here is that someone was dumb enough to think they could get a /16 for only $500.
Open source and open standards save a lot of money for implementors. Even at $0.25 per sales unit, a moderately successful game selling 100,000 units would have to pay out $25,000 in license fees. Multiply that by a few "cheap" technologies, and you are soon into serious money that could pay for an extra developer-year or more. That can make a significant difference in the quality of the shipped game.
I grew up in the midwest. Any farmer has no problems buying fertilizer. Diesel is just an issue of finding a gas station. The fact that the two can combine to produce crude nitro explosives doesn't make either illegal.
Nor has that changed at all. Farmers already have corp paperwork, tax ids, etc. registered with their suppliers. The most they might have had to do is fill out one more form to provide legal confirmation that their farmers, just in case the people they've dealt with for the past 20 years forgot.
The RIAA cannot make tools like codec's illegal. It would be like outlawing screwdrivers because they might get used to hotwire a car. While technically true, there are far too many legitimate uses for the tool.
Ogg Vorbis is used in mainstream games like Unreal. There is no reason to expect the game industry wouldn't go with Ogg Theora for video as well. As long as it's stable and performs well, why would game developers opt for non-portable proprietary solutions?
Where and when did the author of the search engine sign a contract with the RIAA promising it would not index music files? Did he sign another with the MPAA promising it wouldn't index video files? Is there someone he should contract with to avoid indexing still images?
This is not a contract issue, but an issue of rights and freedoms. Search engines are just information filters. They don't provide the data, just a means of locating it. If someone is searching for illegal material, or making illegal material available, the resulting issues are their responsibility, not the search engine author's.
You are correct about this not being a freedom of speech issue, until you consider that the index of a hard-copy document (such as an encyclopedia) is the equivalent of a search engine for online material. Are you suggesting the RIAA should be able to block any document index from referencing MP3's or OggVorbis information because it can be used to perform an illegal act?
What's next -- the RIAA sues Google for allowing you to search for the pattern "MP3"? Perhaps they can go after Addison-Wesley and other book publishers next for providing guides and manuals that can be used to develop the next technology the RIAA is threatened by.
Clauses about owning what you do on your own time don't usually hold up in court, and I've yet to run into a client who wasn't willing to stroke that section out of the contract when I explain why it's an issue for me and my career.
The two places I've worked that leveraged OSS were good about posting their enhancements, one works directly with the developers for a key OSS product they use. (It's been a big benefit to both -- the OSS developer has been adding features they need, and they've been providing him a "real life" debug environment with a highly skilled team and solid feedback.)
I've always specifically steered clients away from GPL libraries, as their business IP isn't worth risking when there are LGPL (or equivalent) libraries that do the same job. Rah-rahs for the GPL and all that, but banks and financial companies aren't even going to consider putting their internal processing systems out as GPL software, and don't qualify for internal-use-only exceptions in most cases.
It sounds to me like this might not even be an investigation of IBM per se, but an investigation as to how a particular customer arranged payment for their orders. Maybe Enron or some such convinced IBM to take a stock swap for orders or some other trade intended to boost the customer's expenses without draining their cash reserve.
The comments by James Grant seem irrelevant, as there is no indication of exactly what is being investigated.
Maybe there is an accounting error somewhere at IBM, but it seems to me it's an investigation of a very specific set of transactions, not an investigation of overall practices ala Enron.
The reviewer comments on the first screenshot that it's what you'll see if you choose not to migrate your existing Gnome config. There is no mention of how well/if upgrading configs works, so I get the impression it wasn't tested by the reviewer.
Yes, GUI's are technically bloat to the techs. As I mentioned, their utility is in allowing people to accomplish the same tasks as techs without all the attention to detail and memorization of commands.
Oh really? You mean the fact that the window went away when I clicked the "close" button wasn't feedback enough -- I need to burn CPU cycles going "bing" and annoy the cubemates/roommates/family?
You miss my point. Anything which does not serve a purpose is bloat. Making things pretty and noisy makes for good eye candy to sell a system, but far too many app developers are spending all their time on skinning GUIs for apps that don't perform their basic function reliably or easily. The net is littered with tens of thousands of such projects, with barely usable non-intuitive interfaces that look really, really nice, and which let other people create equally unusable garish non-intuitive interfaces.
Eye candy is well and good for the masses, but let's make sure it works before making it pretty!
If it serves no utility other than "looking pretty" or "sounding good", it's bloat in a WM. Skinning. Translucent icons. Glowing/popping/spinning animted icons. Playing audio whenever you perform some particular manipulation.
All bloat. Very nice to look at, but it slows the system down and provides no functionality.
Technically the whole concept of a GUI is "bloat" to a purist, but I think there is too much ease-of-use utility to a GUI to slam the whole concept as bloat..
Typo. Should by the iSrc/iDst in the shift/mask calc.
Actually your int version doesn't produce identical results.
In your prior example, each byte is calculated seperately, discarding any overflow bit. Changing to 4-byte integers means that the byte overflow bit is carried into the neighbouring byte by the integer math, producing different results.
Now if you want to get machine-specific, you could mess around with something like this:
Remember the int pointers are just compiler aliases, so the optimizer just ends up discarding the "variables" in favour of using the existing addresses provided by src and dst.
There are four common commercial licenses:
Microsoft is just conceding corporations the right to per-seat/user licensing, which is already one of the most common product licensing arrangements in the industry.
Don't underestimate the impact to Microsoft's bottom line. Under prior interpretations, Microsoft was requiring the corporations to pay for two licenses per telecommuting employee instead of one. They were also requiring extra licenses for failover systems which aren't intended to be used unless the primary fails!
Alas, it is the use of old broken compilers that usually has lead to the twisted code. Maybe you wouldn't be shocked at the number of sites out there that don't upgrade anything because they're horrified at the regression test expenses, but realize you can't update without testing.
Cool history on the coding. Cut my teeth on a TRS-80 Model I Level I myself, later banging away at C64, Amiga, and God knows how many variants on DOS, Windows, and *nix.
Any decent compiler would convert your array indexing to pointer code instead of recalculating the offset on each iteration.
Modern CPUs no longer have an effective performance difference between integer shifts and adds (reg-reg should be 1 internal CPU cycle, which is often a multiple of the external clock.)
So here is an "optimization" that might result from outdated processor/compiler assumptions. It would only work for positive integers on a "normal" processor (there used to be oddball CPUs that use 1's complement instead of 2's complement for signed integers):
Not only does the "tuned" version fail to improve performance, it loses the ability to deal with negatives. It's completely obfuscated the intent to fill dst with a doubling of src, has done nothing to improve performance, and thereby would deserve to be spanked.
Realistically, many CPUs could actually do the whole look as a single vector processing instruction -- a feature that has no explicit syntax, but can only be enabled by a good optimizing compiler or assembly inlines.
True, and the compiler should recognize that is what is happening, and tweak the output accordingly. That would make it real interesting for the decompiler to try to create code that even vaguely describes what is really going on!
You know, it's funny how you can take a common sample of performance tweaked code and turn it into a personal attack. Think I'll skip the many snarling replies that come to mind, and just remind myself you have no idea who I am or what my skills are.
Get out of the research labs and start creating and maintaining code that has to run on old hardware, old compilers, old third-party products, and has no upgrade budget. You go and explain to the management that performance tweaks would make the code "unmaintainable", and I'll stand by and have a chuckle while interviewing your replacement.
Real production code has tweaked segments. It's not "pretty", it's not as "readable" as some would like, but it is functionally equivalent. Odds are that if you're trying to reverse-engineer code, it's going to be old code that has been hacked and tweaked to keep it going after being rushed into production.
But hey, what do I know? I've only been programming for about 20 years, so obviously some prof saddled with the first year classes must have more insight. I humbly bow before the wisdom of one who preaches source code style while discussing decompilers...
A huge portion of the benefit of the "ugly" solution is that the overhead of invoking memcpy() as a function far exceeds the execution of the byte assignments. If your compiler is smart enough to unroll memcpy(), it would produce the output I described.