If you expose 100 apps (whether it's the 100 best free software apps, 100 best non-free apps, or 100 apps written by a gradeschool programming class) on the default launch menu, your tech support will need to create support documentation (which is different from end-user documentation), train on the documentation and possibly the end-user documentation, and otherwise operationalize the documentation (internal/external KB, escalation criteria and procedures etc.) for those apps.
In some important senses, "to Photoshop" implies using a broader set of capabilities and a different context than "to retouch" since Photoshop allows the user to create, illustrate and transform images in ways not possible with an airbrush and a darkroom. "*To Adobe" would not have worked well in this case since Adobe is already known to be a building material/technique unrelated to images. "*To Gimp" wouldn't work in this case since it already means "to lose physical or mental capability or functionality" via (a backformation of?) the noun "gimp" which is a pejorative for "one with a disability". "*To Gimp" in the context of the software application and images could then be easily taken to mean "to break or harm the image using the Gimp software".
The transition from brand or product name to a verb seems weird because despite all of our advances in technology, it's still rare to develop new tools that provide fundamental new kinds of capabilities. "To laser", though not a trademark, has followed a similar path to "to Photoshop" in that the name of the tool becomes a verb for the application of the tool, regardless of the specific desired outcome or context (compare: "to hammer", "to pen", and "to root").
"To Google" is in the same area (starting as a brand for a single product, but grew to include related and unrelated products) in that we've had the verb "to search" for a long time, but not a verb for "to search on the Internet". Even though there are many search engines, "to Google" has a clear meaning about any of them since searching the web is qualitatively the same action on any search engine for most users and purposes. Near "to Google", the verb "to Fusker" has appeared in some circles to mean specifically "to search the web for images", via a perl script and (now defunct) website of the same name.
Prior to Google, "to gopher" had a similar meaning, roughly "to search for on-line content via the Gopher protocol". That verb sounded like "to go for" which resonated in context. It's unclear if "*to archie" (to search FTP archives using the Archie tool), "*to Jughead" (to Gopher via the Jughead tool), or "*to Veronica" (to Gpher via the Veronica tool) ever gained wide acceptance.
In other areas of the Internet, we have other formations such as "to IM" (or "to instant messenge" from "instant messenger") which seems to be being displaced by "to MSN", "to Digg", "to Facebook" etc. (although strangely not "*to MySpace" or "*to Friendster") which all mean to employ those websites/services for their intended functionality. I've also heard the imperative "*MSN me on Facebook!" which semantically distinguishes the applied roles and functions of those services.
That's what I thought. The browser==gasoline analogy keeps coming up in these discussions, but since I'm not a car enthusiast, I wasn't sure if I was missing something fundamental to the point as the monetary cost to the consumer of choosing any of the three major browsers is the same.
A "society" has other larger problems if the choice or lack of choice of web browser adversely affects how that society operates to the point of requiring government intervention.
easily configurable systems loaded to the gills with software
Support headache to create, train and operationalize documentation for each of those applications, especially when users either complain and/or call when they botch the configuration. This was learned from the first netbook experience, and is reflected in the OLPC-like initiatives.
As with all good design, less is more, and the project is done not when there is nothing more to add, but nothing more to take away.
Do not confuse innovation, the application of new ideas, with invention which is the creation of new ideas.
There will always be niche markets that are inaccessible to mass production, which cannot presently be served by "small start-ups" due to the cost of entry (patent licensing fees). Such heterogeneous niche markets would be viable and efficient at the small-scale local level but uninteresting to the MegaCorp patent holders who cannot efficiently regularize or monetize the niche markets. In the absence of patents, new ideas would find a larger variety of market-accessible uses.
just 'having' the features doesn't matter. The product is painfully hard to use because there's no order or organization. Just enough of the feature there to say that it has the feature too.
Just like the vast majority of published or released software titles worldwide which do not seek or use feedback from non-developers.
You miss the broader point. The data is only useful if it can be operationalised, that is, if it can be understood by the relevant systems as *more* than an ordered collection of bytes.
In response to your original question, that I can edit the byte stream of a GW-BASIC source file using vi on Fedora does not imply that the computer can operationalise an instance of the algorithm represented by the byte stream. Fedora is in no useful way compatible with the huge pile of GW-BASIC source code from merely 20-30 years ago. (Parallel issues of useful compatibility hold for the hole pattern of any punch card or the magnetic domains of any magnetic media, which are relatively easy to obtain.)
If you're handy with RPN, you could edit PDFs (which are plain text internally) using gedit. That does not imply that gedit is usefully compatible with PDFs in the same way that kpdf is compatible with PDFs. For similar reasons, gedit is not made compatible with English by virtue of being able to open books from PG.
So yes, my claim is that computers 100 years from now are unlikely to "understand" (able to compile or otherwise operationalise) the source code for OpenOffice etc. beyond being able to read/edit/write the byte stream as just a byte stream, without substantial effort.
I also have my doubts about representing hierarchical file/storage/inode systems being around efficiently for that long, which may be troublesome if the tarball wants to unroll directories of #includes onto some many-dimensional relational eigenspace (or however our datacubes will be organised).
Heck, paper punchcards are compatible with current computers to the extent that we can OCR and assign discreet known values to the holes and represent their information in a binary format. Do you have a programmable loom from the 1800s I could borrow?
There's more to compatibility than being able to read raw data. Otherwise, we could say that vi is compatible with JPEGs to the extent that you could manipulate the images' wavelets by altering single bytes at a time.
Five is a conservative number, as the issues with PS are well known.
If you're into it, try printing a moderately complex CSSed page in Firefox on Windows, any modern Linux and OS X. You'll experience up to three different printing engines and three different hardcopies. Bonus points if you use a font (or a part of a unicode font) that the browser supports, but the printing engine doesn't.
Also see what different programs (open source or not) do with/to multi-page TIFFs. Are the extra images layers, channels, appended, or nothing at all?
Reverse engineering a binary format from a decade and a half ago is harder than converting old source code into new source code.
That's often a safe assumption, given certain constraints on code quality. But see Quark and Adobe and the choices they made about using legacy code vs. starting over from scratch on apps to read/write their own file formats after periods of cycling entire developer teams every 12-24 months for a couple of years. See my previous point about TIFF/PS/HTML (globally, those are among the most common file formats in current use [faxes, PDFs/printers, internets] and yet we have not achieved consistency in interpreting/writing those formats, despite the fact that they are open in both format and software tools).
Do you really think C will be gone in a couple decades?;)
C as a language won't go away (nor would most programming languages ever become extinct), but don't count on the dozens of libraries, headers, templates and such that a typical program uses to be maintained into the future. Even now, configure on any moderately sophisticated program or framework (take OpenOffice) can require dozens of minutes to run, and potentially several hours to compile, because of all the version/architecture/configuration/etc interdependencies that need to be resolved, and we have access today to the sourcecodes for every relevant version of the subsystems. Are you confident that you could compile the relevant parts of OpenOffice 1.1.3 to recover some of the swriter table layout details that versions 2 and above handle differently now? From a pair of.ODx files, will a historian 100 years from now be able to figure out which two of the 3800 envelopes were not printed from the congresscritter's mail merge from an early and slightly buggy OpenOffice 2? (These problems are not exclusive to open source, nor are they solved by it.)
From an end-user perspective, I know that there are hundreds of millions of non-PCs out there (cell phones/PDAs, multi-function copiers/printers, digital projectors, etc.) that will successfully open (if not exactly) my Word 95 document, along with dozens (hundreds?) of computer programs on a variety of platforms that do not share a single point of control or failure. I don't know that any one (nor which one) of the current other open or proprietary formats will necessarily gain that much resiliency through massive redundancy that my document will open in 50 years.
TCO includes not having to retrain noobs from the street or the IT/HR department on the newfangled interface which has slightly different looking UI elements. Remember that employees and intended users may have knowledge ranging from wanting to load paper into the LCD through to what we know here. At present, part of IT's costs are hidden by the practice of power users (anyone under 30) in local offices performing (passable) first tier helpdesk functions for most of their common end-user applications (Windows, Office, web browser, printing). With any new system (MS upgrade or Linux), there's a relearning cost, which shows up as $ on someone's budget. In a typical bureaucracy or large organisation, IT (as with all other departments) would naturally prefer for someone else to bear that cost.
Learning a slightly different interface should be the same level of difficulty, given comparable new interfaces, regardless of the brand of the new interface but it isn't. There is a psychological factor, which some programmers are too quick to discount, arising from the reputation of the previous product. MS whatever may crash/break all the time, but at least the user already knows the ways in which it breaks and how to avoid those situations. There's less reliability about known faults for a new product from the same vendor, than for a new product from a new vendor which may contain a whole new set of faults to learn.
When you can't open documents from a decade and a half ago, because they were stored in some incompatible proprietary format, you just get some enterprising novice coder to create a plugin to load it. This is a solution for accessing any legacy soft and hard format, given sufficient resources.
(Contemplate what happens when current source code formats become incompatible...)
Also, neither having the source code, nor saving files in an open or documented format is a guarantee that they will remain accessible. There's a good chance today that if you open a postscript (or derivatives) or TIFF created a decade ago with three different renderers based on different sourcecode than which created them, you'll get five different renderings.
There's a good chance today that if you open a rich DHTML file using three different renderers based on different sourcecode than which created them, you'll get five different renderings...
(No, I'm not scarred by having to convert.GEM files into a modern format.)
Yeah, because freeing memory and CPU from not having to run the Teletubbies UI from XP, and being able to quota and throttle processes and services really deprives the game of the resources it needs to run.
If you spend 10 minutes Googling intelligently, DX and video drivers work fine in 2K3 for gaming as long as you didn't cheap out on some B-grade Super Wonder Color Over 9000 OEM card from the bottom of the clearance bin at Wal-Mart.
I hope their in house Photoshop skills are better than those demonstrated in the screenshots of the template page in Wired's article. Someone should inform TuneCore that reflections do not make the objects being reflected translucent, and that design notes ("Black") in the default font should be deleted from the final image.
A single component or step substitution on a single production line can expose unintended capabilities when supplies are commodities only to an extent. Recall the interesting modifications enabled by a single line of graphite.
No, just treat it as GPL always. You're waiting for the developer to die so you can use the code without GPL restrictions? Really?
The ability to determine whether a work is or is not in the public domain mas more significant consequences beyond simple code reuse. It can be difficult now to track down the rights holders for even single author works older than a couple decades, which stifles legal reuse in whole or in part. GPLed works have the potential to include contributions from thousands of authors whose individual contributions to the whole are both distinct but very difficult to attribute in most cases.
This will become a sustainability issue in the circumstance that millions of instances of some (hardware or software) device, whose manufacturer no longer exists/supports it, have been deployed containing GPL-licensed code needing a critical fix, but which was authored by some combination of living and dead authors who are unable to be contacted, nor are able implement the fix. There would obviously be room for some smart third-party consultants to spend some resources to learn how to fix the code, and then to offer to fix each instance of it, but there would be little to no commercial incentive to do so since the ability to exclusively charge for the fix (beyond the first instance) cannot be assured. Potential instances of this problem include OpenSSH embedded in routers, web browsers embedded in appliances, kernels in controllers, drivers for wireless chipsets etc. In future we might want also to emulate the hardware/software in use today but which is no longer easily accessible. In these cases, the GPLed source code would be available but would also be encumbered for legitimate proprietary reuse due to ambiguity over copyright holders. (If submarine patents are a problem for innovation now where the timeframe is limited to around two decades, the number of potential claimants is small, and potential issues are available in a public database, consider the potential of a 99 year timeframe with thousands of potential claimants who can't be settled as a class, where there is no database of potential issues.) Imagine writing the holo-book "100 Years of the Linux Kernel" and needing to interactively demonstrate system calls to see how it would be legally easier to decompile/copy a 10 GHz AMD processor that would be out of copyright than to figure out if you could include a particular version of GPL-licensed VirtualBox.
Thus, if we speak of broad freedom to advance the useful arts and sciences, the kind of de facto perpetual copyright by obscurity obtained through the use of GPL is no better than the almost perpetual copyright extensions we loathe Disney and Co. for seeking. If we speak of narrow freedom to lord over particular files containing particular implementations, GPL probably enhances the freedom of those who wish to perpetuate the GPL.
No, but I don't think the BSD or MIT license prevents that either, does it?
After attempting to exhaust other candidates for the kinds of freedoms GPL tries to enhance, my point was that GPL does not appear to do anything useful for consumer protection, not to bash BSD or MIT licenses. In the absence of GPL, responsible copyright holders will ensure that they do not license their work to malevolent distributors and have some reasonable tools to attempt to prevent the malevolents from distributing unauthorised modified binaries without detection. Such avenues are explicitly made unavailable in the GPL. I would argue that the developer whose work has been hijacked for malevolent purposes has more freedom to fix the problem under any number of generic proprietary software licenses than under GPL. (An alternative interpretation is that GPLed works have some extra kind of as yet unexplained privilege above other copyrighted works, such as software and books, that excludes or immunizes GPLed works from first sale doctrine. In that case, GPL would be no better or worse for this kind of consumer protection, and a number of current business models would be non-viable.)
In the last 10,000 years, science and engineering have done pretty well for enhancing themselves and have let anyone else do the same by not encumbering their algorithms in legal protections. Even with modern patents, the maximum duration of exclusivity over an algorithm is less than 20 years, after which anyone can muck around as they please for fun and profit.
Algorithms such as cola recipes do not need to be protected in the first place (our society demonstrates this by the fact that anyone can implement and sell a liquid with the same formula as the one that Coke sells, they just can't call it Coke for very good consumer protection and trademark reasons). However, it's a very good thing to be able to protect exclusivity over specific implementations since there are valuable social and monetary assets tied to particular meatspace implementations of algorithms, just as there should be the ability to protect exclusivity over particular non-meatspace implementations of algorithms. When I purchase a DVD labeled Apple OS X 10.5, I do not want something containing a QNX installer.
But that's not the kind of protection GPL adds for the producer or consumer. GPL for software tries to prevent particular implementations of algorithms (products) from being used in unauthorized ways, and does not claim to protect any particular algorithms (otherwise it would have the same conceptual failings as business process patents). So clearly, GPL is not intended to protect algorithms, but possibly to protect particular implementations or rights of their implementers.
GPL's restrictions on how an implementation may be redistributed (must include a link/copy of the GPL and distribute code if redistributing) would be analogous to Coke prohibiting the redistribution of remixed products such as cola-battered chocolate crumbles unless each cola-battered chocolate crumbles comes with a copy of the recipe, no matter how the redistributor of the instance of Coke used came to acquire that instance of the Coke, even if the chocolate crumbles are not advertised as being a Coke-containing product. If the waste products from the production of cola-battered chocolate crumbles ends up being sold in commercial compost, a copy of the recipe for the compost would then have to accompany each bag of compost, even if the compost is not advertised as being a Coke-containing product. Ad nauseum. In this simple instance, GPL would add nothing to actively protect a particular implementation or its implementer, so the kinds of things it protects are not analogous to tangible goods, nor are the freedoms it enhances related to those tangible goods.
So what does it protect and what freedoms does it enhance? Copyrights perhaps? If we consider software to be like books or artwork, where each licensed copy is protected, a number of issues arise: 1) If copyright terms remain related to the life of the creator, at what point should a particular version of GPL-licensed software fall into the public domain? If GPL requires tracking the providence of each contributor to a work to determine length of copyright before I can use a work which falls into the public domain, GPL-licensed code has the effect of being more difficult to re-use than code protected under copyright alone, or code in the public domain. 2) If GPL claims to be an enhanced copyright protection, the doctrine of first sale says I can buy a copy of a book, make a derivative work by pasting/cutting from it, and then resell that copy without restriction as long as I'm not representing the altered work as an original. Does GPL permit me to obtain one copy of GPL-licensed source code, modify it, and then install that instance to a router to be distributed without a copy of the modified source code? If not, GPL has the effect of being less free than code protected by copyright alone, or code in the public domain. 3) If GPL claims to be an enhanced product labeling or consumer protection, it does no better than existing consumer protection legislation in terms of disclo
First, if 100% effectiveness is the test a protective device must pass before we enable an activity with that device, we wouldn't have the use of electricity, motor vehicles, food, or most tools or resources.
Second, there exist a sufficient number of empirical tests for the qualifications of birth control operators and hence a potential avenue to regulate, just as there are a number of empirical tests for the qualifications of vehicle operators FROM WHOM WE TACITLY ACCEPT A SLIGHT RISK AND RATE OF FAILURE AS ROUTINE.
Slashdot Mirror
I was apparently unclear.
If you expose 100 apps (whether it's the 100 best free software apps, 100 best non-free apps, or 100 apps written by a gradeschool programming class) on the default launch menu, your tech support will need to create support documentation (which is different from end-user documentation), train on the documentation and possibly the end-user documentation, and otherwise operationalize the documentation (internal/external KB, escalation criteria and procedures etc.) for those apps.
In some important senses, "to Photoshop" implies using a broader set of capabilities and a different context than "to retouch" since Photoshop allows the user to create, illustrate and transform images in ways not possible with an airbrush and a darkroom. "*To Adobe" would not have worked well in this case since Adobe is already known to be a building material/technique unrelated to images. "*To Gimp" wouldn't work in this case since it already means "to lose physical or mental capability or functionality" via (a backformation of?) the noun "gimp" which is a pejorative for "one with a disability". "*To Gimp" in the context of the software application and images could then be easily taken to mean "to break or harm the image using the Gimp software".
Adobe rants about use of "Photoshop" as a verb and as a noun here: http://www.adobe.com/misc/trade.html
The transition from brand or product name to a verb seems weird because despite all of our advances in technology, it's still rare to develop new tools that provide fundamental new kinds of capabilities. "To laser", though not a trademark, has followed a similar path to "to Photoshop" in that the name of the tool becomes a verb for the application of the tool, regardless of the specific desired outcome or context (compare: "to hammer", "to pen", and "to root").
"To Google" is in the same area (starting as a brand for a single product, but grew to include related and unrelated products) in that we've had the verb "to search" for a long time, but not a verb for "to search on the Internet". Even though there are many search engines, "to Google" has a clear meaning about any of them since searching the web is qualitatively the same action on any search engine for most users and purposes. Near "to Google", the verb "to Fusker" has appeared in some circles to mean specifically "to search the web for images", via a perl script and (now defunct) website of the same name.
Prior to Google, "to gopher" had a similar meaning, roughly "to search for on-line content via the Gopher protocol". That verb sounded like "to go for" which resonated in context. It's unclear if "*to archie" (to search FTP archives using the Archie tool), "*to Jughead" (to Gopher via the Jughead tool), or "*to Veronica" (to Gpher via the Veronica tool) ever gained wide acceptance.
In other areas of the Internet, we have other formations such as "to IM" (or "to instant messenge" from "instant messenger") which seems to be being displaced by "to MSN", "to Digg", "to Facebook" etc. (although strangely not "*to MySpace" or "*to Friendster") which all mean to employ those websites/services for their intended functionality. I've also heard the imperative "*MSN me on Facebook!" which semantically distinguishes the applied roles and functions of those services.
$151 for Windows is still $1 more for the vendors. Even though it's poor business sense, they can make it up in volume.
That's what I thought. The browser==gasoline analogy keeps coming up in these discussions, but since I'm not a car enthusiast, I wasn't sure if I was missing something fundamental to the point as the monetary cost to the consumer of choosing any of the three major browsers is the same.
What's the cost difference to the consumer between the brands of gasoline?
A "society" has other larger problems if the choice or lack of choice of web browser adversely affects how that society operates to the point of requiring government intervention.
There's a project that already does most of that:
http://sam.zoy.org/lmos/
although be sure to change the default included placeholder media.
Photoshop, like Google, is well on its way to becoming a common verb. One should be able to photoshop with any competent raster image editing program.
easily configurable systems loaded to the gills with software
Support headache to create, train and operationalize documentation for each of those applications, especially when users either complain and/or call when they botch the configuration. This was learned from the first netbook experience, and is reflected in the OLPC-like initiatives.
As with all good design, less is more, and the project is done not when there is nothing more to add, but nothing more to take away.
You're doing it wrong if the typical user encounters cause to realize the name of the OS they're using.
Yes, but the fact that one language can't fit even the toy benchmark into a small space, while another can, is also telling.
Do not confuse innovation, the application of new ideas, with invention which is the creation of new ideas.
There will always be niche markets that are inaccessible to mass production, which cannot presently be served by "small start-ups" due to the cost of entry (patent licensing fees). Such heterogeneous niche markets would be viable and efficient at the small-scale local level but uninteresting to the MegaCorp patent holders who cannot efficiently regularize or monetize the niche markets. In the absence of patents, new ideas would find a larger variety of market-accessible uses.
just 'having' the features doesn't matter. The product is painfully hard to use because there's no order or organization. Just enough of the feature there to say that it has the feature too.
Just like the vast majority of published or released software titles worldwide which do not seek or use feedback from non-developers.
You miss the broader point. The data is only useful if it can be operationalised, that is, if it can be understood by the relevant systems as *more* than an ordered collection of bytes.
In response to your original question, that I can edit the byte stream of a GW-BASIC source file using vi on Fedora does not imply that the computer can operationalise an instance of the algorithm represented by the byte stream. Fedora is in no useful way compatible with the huge pile of GW-BASIC source code from merely 20-30 years ago. (Parallel issues of useful compatibility hold for the hole pattern of any punch card or the magnetic domains of any magnetic media, which are relatively easy to obtain.)
If you're handy with RPN, you could edit PDFs (which are plain text internally) using gedit. That does not imply that gedit is usefully compatible with PDFs in the same way that kpdf is compatible with PDFs. For similar reasons, gedit is not made compatible with English by virtue of being able to open books from PG.
So yes, my claim is that computers 100 years from now are unlikely to "understand" (able to compile or otherwise operationalise) the source code for OpenOffice etc. beyond being able to read/edit/write the byte stream as just a byte stream, without substantial effort.
I also have my doubts about representing hierarchical file/storage/inode systems being around efficiently for that long, which may be troublesome if the tarball wants to unroll directories of #includes onto some many-dimensional relational eigenspace (or however our datacubes will be organised).
We can pull fields off magnetic tapes from the 60s with fairly generic kit, but can we interpret them? http://www.theregister.co.uk/2008/11/11/vintage_ibm_tape_drive_moon_dust_data/
Heck, paper punchcards are compatible with current computers to the extent that we can OCR and assign discreet known values to the holes and represent their information in a binary format. Do you have a programmable loom from the 1800s I could borrow?
There's more to compatibility than being able to read raw data. Otherwise, we could say that vi is compatible with JPEGs to the extent that you could manipulate the images' wavelets by altering single bytes at a time.
Five is a conservative number, as the issues with PS are well known.
If you're into it, try printing a moderately complex CSSed page in Firefox on Windows, any modern Linux and OS X. You'll experience up to three different printing engines and three different hardcopies. Bonus points if you use a font (or a part of a unicode font) that the browser supports, but the printing engine doesn't.
Also see what different programs (open source or not) do with/to multi-page TIFFs. Are the extra images layers, channels, appended, or nothing at all?
Reverse engineering a binary format from a decade and a half ago is harder than converting old source code into new source code.
That's often a safe assumption, given certain constraints on code quality. But see Quark and Adobe and the choices they made about using legacy code vs. starting over from scratch on apps to read/write their own file formats after periods of cycling entire developer teams every 12-24 months for a couple of years. See my previous point about TIFF/PS/HTML (globally, those are among the most common file formats in current use [faxes, PDFs/printers, internets] and yet we have not achieved consistency in interpreting/writing those formats, despite the fact that they are open in both format and software tools).
Do you really think C will be gone in a couple decades? ;)
C as a language won't go away (nor would most programming languages ever become extinct), but don't count on the dozens of libraries, headers, templates and such that a typical program uses to be maintained into the future. Even now, configure on any moderately sophisticated program or framework (take OpenOffice) can require dozens of minutes to run, and potentially several hours to compile, because of all the version/architecture/configuration/etc interdependencies that need to be resolved, and we have access today to the sourcecodes for every relevant version of the subsystems. Are you confident that you could compile the relevant parts of OpenOffice 1.1.3 to recover some of the swriter table layout details that versions 2 and above handle differently now? From a pair of .ODx files, will a historian 100 years from now be able to figure out which two of the 3800 envelopes were not printed from the congresscritter's mail merge from an early and slightly buggy OpenOffice 2? (These problems are not exclusive to open source, nor are they solved by it.)
From an end-user perspective, I know that there are hundreds of millions of non-PCs out there (cell phones/PDAs, multi-function copiers/printers, digital projectors, etc.) that will successfully open (if not exactly) my Word 95 document, along with dozens (hundreds?) of computer programs on a variety of platforms that do not share a single point of control or failure. I don't know that any one (nor which one) of the current other open or proprietary formats will necessarily gain that much resiliency through massive redundancy that my document will open in 50 years.
TCO includes not having to retrain noobs from the street or the IT/HR department on the newfangled interface which has slightly different looking UI elements. Remember that employees and intended users may have knowledge ranging from wanting to load paper into the LCD through to what we know here. At present, part of IT's costs are hidden by the practice of power users (anyone under 30) in local offices performing (passable) first tier helpdesk functions for most of their common end-user applications (Windows, Office, web browser, printing). With any new system (MS upgrade or Linux), there's a relearning cost, which shows up as $ on someone's budget. In a typical bureaucracy or large organisation, IT (as with all other departments) would naturally prefer for someone else to bear that cost.
Learning a slightly different interface should be the same level of difficulty, given comparable new interfaces, regardless of the brand of the new interface but it isn't. There is a psychological factor, which some programmers are too quick to discount, arising from the reputation of the previous product. MS whatever may crash/break all the time, but at least the user already knows the ways in which it breaks and how to avoid those situations. There's less reliability about known faults for a new product from the same vendor, than for a new product from a new vendor which may contain a whole new set of faults to learn.
When you can't open documents from a decade and a half ago, because they were stored in some incompatible proprietary format, you just get some enterprising novice coder to create a plugin to load it. This is a solution for accessing any legacy soft and hard format, given sufficient resources.
(Contemplate what happens when current source code formats become incompatible...)
Also, neither having the source code, nor saving files in an open or documented format is a guarantee that they will remain accessible. There's a good chance today that if you open a postscript (or derivatives) or TIFF created a decade ago with three different renderers based on different sourcecode than which created them, you'll get five different renderings.
There's a good chance today that if you open a rich DHTML file using three different renderers based on different sourcecode than which created them, you'll get five different renderings...
(No, I'm not scarred by having to convert .GEM files into a modern format.)
Yeah, because freeing memory and CPU from not having to run the Teletubbies UI from XP, and being able to quota and throttle processes and services really deprives the game of the resources it needs to run.
If you spend 10 minutes Googling intelligently, DX and video drivers work fine in 2K3 for gaming as long as you didn't cheap out on some B-grade Super Wonder Color Over 9000 OEM card from the bottom of the clearance bin at Wal-Mart.
I hope their in house Photoshop skills are better than those demonstrated in the screenshots of the template page in Wired's article. Someone should inform TuneCore that reflections do not make the objects being reflected translucent, and that design notes ("Black") in the default font should be deleted from the final image.
A single component or step substitution on a single production line can expose unintended capabilities when supplies are commodities only to an extent. Recall the interesting modifications enabled by a single line of graphite.
No, just treat it as GPL always. You're waiting for the developer to die so you can use the code without GPL restrictions? Really?
The ability to determine whether a work is or is not in the public domain mas more significant consequences beyond simple code reuse. It can be difficult now to track down the rights holders for even single author works older than a couple decades, which stifles legal reuse in whole or in part. GPLed works have the potential to include contributions from thousands of authors whose individual contributions to the whole are both distinct but very difficult to attribute in most cases.
This will become a sustainability issue in the circumstance that millions of instances of some (hardware or software) device, whose manufacturer no longer exists/supports it, have been deployed containing GPL-licensed code needing a critical fix, but which was authored by some combination of living and dead authors who are unable to be contacted, nor are able implement the fix. There would obviously be room for some smart third-party consultants to spend some resources to learn how to fix the code, and then to offer to fix each instance of it, but there would be little to no commercial incentive to do so since the ability to exclusively charge for the fix (beyond the first instance) cannot be assured. Potential instances of this problem include OpenSSH embedded in routers, web browsers embedded in appliances, kernels in controllers, drivers for wireless chipsets etc. In future we might want also to emulate the hardware/software in use today but which is no longer easily accessible. In these cases, the GPLed source code would be available but would also be encumbered for legitimate proprietary reuse due to ambiguity over copyright holders. (If submarine patents are a problem for innovation now where the timeframe is limited to around two decades, the number of potential claimants is small, and potential issues are available in a public database, consider the potential of a 99 year timeframe with thousands of potential claimants who can't be settled as a class, where there is no database of potential issues.) Imagine writing the holo-book "100 Years of the Linux Kernel" and needing to interactively demonstrate system calls to see how it would be legally easier to decompile/copy a 10 GHz AMD processor that would be out of copyright than to figure out if you could include a particular version of GPL-licensed VirtualBox.
Thus, if we speak of broad freedom to advance the useful arts and sciences, the kind of de facto perpetual copyright by obscurity obtained through the use of GPL is no better than the almost perpetual copyright extensions we loathe Disney and Co. for seeking. If we speak of narrow freedom to lord over particular files containing particular implementations, GPL probably enhances the freedom of those who wish to perpetuate the GPL.
No, but I don't think the BSD or MIT license prevents that either, does it?
After attempting to exhaust other candidates for the kinds of freedoms GPL tries to enhance, my point was that GPL does not appear to do anything useful for consumer protection, not to bash BSD or MIT licenses. In the absence of GPL, responsible copyright holders will ensure that they do not license their work to malevolent distributors and have some reasonable tools to attempt to prevent the malevolents from distributing unauthorised modified binaries without detection. Such avenues are explicitly made unavailable in the GPL. I would argue that the developer whose work has been hijacked for malevolent purposes has more freedom to fix the problem under any number of generic proprietary software licenses than under GPL. (An alternative interpretation is that GPLed works have some extra kind of as yet unexplained privilege above other copyrighted works, such as software and books, that excludes or immunizes GPLed works from first sale doctrine. In that case, GPL would be no better or worse for this kind of consumer protection, and a number of current business models would be non-viable.)
In the last 10,000 years, science and engineering have done pretty well for enhancing themselves and have let anyone else do the same by not encumbering their algorithms in legal protections. Even with modern patents, the maximum duration of exclusivity over an algorithm is less than 20 years, after which anyone can muck around as they please for fun and profit.
Algorithms such as cola recipes do not need to be protected in the first place (our society demonstrates this by the fact that anyone can implement and sell a liquid with the same formula as the one that Coke sells, they just can't call it Coke for very good consumer protection and trademark reasons). However, it's a very good thing to be able to protect exclusivity over specific implementations since there are valuable social and monetary assets tied to particular meatspace implementations of algorithms, just as there should be the ability to protect exclusivity over particular non-meatspace implementations of algorithms. When I purchase a DVD labeled Apple OS X 10.5, I do not want something containing a QNX installer.
But that's not the kind of protection GPL adds for the producer or consumer. GPL for software tries to prevent particular implementations of algorithms (products) from being used in unauthorized ways, and does not claim to protect any particular algorithms (otherwise it would have the same conceptual failings as business process patents). So clearly, GPL is not intended to protect algorithms, but possibly to protect particular implementations or rights of their implementers.
GPL's restrictions on how an implementation may be redistributed (must include a link/copy of the GPL and distribute code if redistributing) would be analogous to Coke prohibiting the redistribution of remixed products such as cola-battered chocolate crumbles unless each cola-battered chocolate crumbles comes with a copy of the recipe, no matter how the redistributor of the instance of Coke used came to acquire that instance of the Coke, even if the chocolate crumbles are not advertised as being a Coke-containing product. If the waste products from the production of cola-battered chocolate crumbles ends up being sold in commercial compost, a copy of the recipe for the compost would then have to accompany each bag of compost, even if the compost is not advertised as being a Coke-containing product. Ad nauseum. In this simple instance, GPL would add nothing to actively protect a particular implementation or its implementer, so the kinds of things it protects are not analogous to tangible goods, nor are the freedoms it enhances related to those tangible goods.
So what does it protect and what freedoms does it enhance? Copyrights perhaps? If we consider software to be like books or artwork, where each licensed copy is protected, a number of issues arise:
1) If copyright terms remain related to the life of the creator, at what point should a particular version of GPL-licensed software fall into the public domain? If GPL requires tracking the providence of each contributor to a work to determine length of copyright before I can use a work which falls into the public domain, GPL-licensed code has the effect of being more difficult to re-use than code protected under copyright alone, or code in the public domain.
2) If GPL claims to be an enhanced copyright protection, the doctrine of first sale says I can buy a copy of a book, make a derivative work by pasting/cutting from it, and then resell that copy without restriction as long as I'm not representing the altered work as an original. Does GPL permit me to obtain one copy of GPL-licensed source code, modify it, and then install that instance to a router to be distributed without a copy of the modified source code? If not, GPL has the effect of being less free than code protected by copyright alone, or code in the public domain.
3) If GPL claims to be an enhanced product labeling or consumer protection, it does no better than existing consumer protection legislation in terms of disclo
First, if 100% effectiveness is the test a protective device must pass before we enable an activity with that device, we wouldn't have the use of electricity, motor vehicles, food, or most tools or resources.
Second, there exist a sufficient number of empirical tests for the qualifications of birth control operators and hence a potential avenue to regulate, just as there are a number of empirical tests for the qualifications of vehicle operators FROM WHOM WE TACITLY ACCEPT A SLIGHT RISK AND RATE OF FAILURE AS ROUTINE.