So again - somebody please explain what is the problem here? Is GPL version change really such a disaster? What should I care as Linux user?
As a Linux user, your main cause for concern is the possibility that some programs that you use today or interesting programs that have yet to be written will suffer as a result of the GPL version change. This possibility is due to the incompatibility of the GPL v2 and v3 licenses. We have already seen that a number of kernel developers are opposed to the new version of the license. It can also be assumed that some current major corporate contributors to GPL v2 projects would also be opposed to the new tivoization and patent clauses. If a number of important components or libraries shift to GPL v3, then these are likely to be abandoned or forked by developers that want their projects to stick with GPL v2.
I know that forking is nothing new, but it seems fairly arrogant of the FSF to intentionally create a schism within the ranks of developers that support the GPL by creating a new and incompatible license that they *know* many of them will be vehemently against.
There are still some sporadic reports at forum.parallels.com that people are still having difficulty getting Parallels to recognize and use the VT-x instructions on their Minis, but the problems seemed to have largely been resolved by the latest Apple firmware updates.
Even if you did have a chip that is somehow lacking the VT-x instructions, you could still run Parallels just fine - albeit not at its full potential speed. This has been true since the first beta of Parallels and is true of virtualization products on other platforms. The OP probably didn't think to mention it because it is a non-issue.
Hmm...you must have skimmed through the tutorial without reading closely, since it *specifically* tells you that the Currency Converter is overdesigned to introduce the MVC concept:
"This design for Currency Converter is intended to illustrate a few points, and so may be overly designed for something so simple. It is quite possible to have the application's controller class, ConverterController, perform the computation and do without the Converter class. By adhering to the MVC paradigm in this tutorial, however, you will learn the fundamentals of good Cocoa design which will assist you greatly as you begin to work on more advanced projects."
Of course, a full justification of the MVC approach is beyond the scope of this reply!
This might be a valid concern if Microsoft ever actually officially supported WTL, but they didn't and they don't.
As others have pointed out, WTL is a pet project of a single Microsoft employee and always has been. At one time, it may have been briefly proposed as an officially supported alternative to MFC for C++ Win32 development, but they probably felt there was no point in confusing the issue with another C++ library since the future development focus was to be shifted to.NET rather than COM/Win32.
By hosting the code on SourceForge, I personally believe the point *is* to accept user contributions to the source. Because Microsoft never really invested any resources in WTL, there is little harm in allowing the community to take over the project. The community for WTL has never been large, but there are a number of dedicated users who prefer the "lightweight" C++ template programming model over the "heavyweight" C++ inheritance model provided by MFC and ilk (wxWindows and OWL).
I would imagine the decision to release WTL on SourceForge went something like this:
WTL Author: "Hey Mr. Manager, this WTL thing that I've been working on in my free time for the last several years still has a small but dedicated set of users. It's getting to be a pain for me to maintain, however, so do you mind if I put it up on SourceForge so they can help me keep it alive?"
Mr. Manager: "Hmm...okay. Use the CPL like that installer thing."
This has been my experience as well. I've worked as a software developer on dozens of consulting projects in North America and Western Europe, and the US managers prefer to work from "intuition" and "feel" rather than the rigorously specified requirements and design that the Europeans insist upon.
I personally believe that there are merits and drawbacks to both approaches and that the ideal is somewhere between formal and informal approaches.
The informal, intuitive approach can result in a deliverable that is a much closer fit to the actual needs of the client - not just what they think they want or what they can express in words. A good informal manager circulates through the entire target organization from management, to accounting, to the IT department, to the users, and sometimes even to the client's own customers. Through a process of information osmosis, the manager constructs a feel of what the deliverable really needs to be and directs the team accordingly. Obviously, this approach works best when the project manager is damn good (sharp *and* experienced) and the development team is small and works well together. The main drawback, of course, is a tendency to chaotic development as things are written and rewritten to hit a moving target.
The formal approach is reliable, predicatable, and safe. Maybe what you deliver will not be a perfect match for the unspoken requirements that inevitably surface during the project lifecycle, but at least you have a better chance of delivering *something*.
I wonder, however, with the growing pool of cheap outsourced labor, if the paint-by-numbers formal software approach is really the best answer for the US going forward. If a project is specified in sufficient detail, then anyone can do the development. Perhaps the intuitive, informal approach is the only competitive advantage a US team can offer going forward - a dream team of software magicians rather than a clockwork team of software engineers.
I always thought an interesting application for "modern" interactive fiction would be to apply the technologies of voice recognition and speech synthesis to IF. The structure of the IF game itself would remain the same - only all of the interaction is through listening/speaking rather than reading/typing.
So on your next long drive to nowhere in particular, you could play an IF game on your car's computer instead of listening to a non-interactive audio book or some tunes on the CD player/radio.
Obviously, this kind of thing might also be fun for the visually-impaired gamer.
Any idea if anyone has ever done this?
Integrating Finder with Terminal
on
A Better Finder?
·
· Score: 2, Interesting
One of my half-baked ideas for a Finder enhancement (that may or may not be able to survive the transition to fully baked), would be to somehow integrate the Finder and Terminal applications into a single user interface.
When accomplishing a task, it is sometimes more convenient to use the Finder's graphical user interface. Other, generally more complicated, tasks require the use of the Terminal's CLI. To perfrom a sequence of tasks, I often find myself switching back and forth between one or more Finder and Terminal instances to get the job done. If the two applications were combined into one, the transition between GUI-oriented work and CLI-oriented work would not be as mentally disconcerting. In addition, the strengths of both approaches could be combined to offset their weaknesses.
The Terminal would be embedded in the Finder as a splitter pane above or below the graphical view of the file system (according to user preference). The working directory of the Terminal could either be linked to automatically update during point-and-click navigation through folders or decoupled with a sync-to-current location button provided to update the Terminal's working directory. Special "pipeable" objects would be provided to redirect the results of Terminal commands to the current GUI view.
Here is a simple example to illustrate this: 1.) The user opens a new Finder window and navigates to a folder using the GUI. 2.) The user types a command in the embedded Terminal: ls *.log | FinderView. 3.) The results of the command are piped to the Finder's current view and presented graphically.
Obviously, there are many issues that would have to be resolved to make all of this work properly, but I think it would be worth the effort to create a hybrid CLI/GUI Finder-like application.
The number of Linux kernel developers you presented isn't particularly impressive, since there are about 5000 developers working on the latest version of Windows Server 2003 (source: Mark Lucovsky, Microsoft). There really isn't any way to prove that the best and the brightest at Microsoft are any better or worse than the best and the brightest on the Linux kernel team. The proof is in the pudding (or the kernel) so to speak, but even still there is room for debate and contention.
It could be argued that Microsoft's greatest development advantage is the opportunity for superior efficiency through centralized control and more structured communication. This advantage may turn out to be a weakness, however. Linux, with its looser organization and higher degree of redundant effort, may not be as efficient but this parallelism creates an almost Darwinian environment that weeds out the weakest solutions in favor of the strong. Which model is the most effective for software?
To me it seems unlikely that the two camps will stay locked in this struggle forever. It will likely end much like the Cold War between the Soviet Union and the United States. Both sides will stay locked in an uneasy equilibrium for many years with each claiming a periodic advantage. Eventually one side will come to the realization that it has fallen far enough behind that it's no longer possible to catch up.
To continue with the analogy, however, it's still the 1950's. It will be many years before a final, decisive victory is reached by either philosophy. (Or maybe the UFOs will finally land and we'll just use AlienOS Earth Edition).
If you've ever purchased a home, you've probably experienced an extreme deluge of telemarketing. New homeowner lists are generated and sent out to what must be every home-related business on the planet: pest control, security systems, lawn care, water treatment, housecleaning, long distance, insurance, etc.
About a week after I moved into my new house, the barrage started. At its peak, the calls would start at around 7:30am and continue until about 8:00pm. I think the one day record was about 30 calls.
It's tapered off now, but there is still a fairly steady stream of calls. In fact, while writing this post I received two telemarketing calls. The first was just a dead line (Hello?... Hello?... Hello?... click) and the second cutoff before I had a chance to tell the guy to put me on the DNC list.
This may not constitute harassment on the part of any individual company (except for the ones that continue to call after I told them not to), but surely it's a conspiracy to commit harassment by the industry itself. Please make it stop!!!!
Regarding the legislation, I don't want to get any calls from surveys, charities, or politicians either. In my opinion, the legislation doesn't go far enough.
As opposed to open source software where the wheel is reinvented again and again just for the hell of it? Where perfectly useable commercial products are cloned feature-by-feature and even screen-by-screen because it's an offense against nature to just pay for and use the existing product. Where the spit and polish of a commercial product is deemed unnecessary since you can just "look at the code" if you don't understand it. Where the most common response to a user feature request is "it's open source, so you can add it yourself".
I don't want to sound too negative, since open source has been irrefutably proven to work for the difficult and technical: protocol stacks, OS kernels, web servers, compilers, etc. Commercial software, however, still has the edge in creating attractive and useable human computer interfaces. Why? Because it's not about "learning" and "sharing" and "culture" - it's about grabbing people by the balls and making them want to use the product.
This is true of nearly every product in our wonderfully chaotic system of global capitalism. Why should software be any different?
Jaron's concepts are vaguely stated but still interesting. If you imagine a computer having a central intelligence that is modeled after human intelligence with a certain amount of pattern recognition and iterative learning behavior, there are some potential immediate applications of this.
A simple example would be the computer's parsing of HTML (or any other grammar/vocabulary-based file format) as compared to a human's parsing of the written word. The human mind has a certain amount of fault-tolerance for ambiguities and grammar-deviations which allows it to make some sense of all but the most mutated input. An example of this would be your own ability to grok most Slashdot posts, however rife with gramer, spelin, and logik errors they may be.
The computer could also potentially do this to less than perfect input - smooth over the "errors" and try to extract as much meaning as possible using its own knowledge of patterns. It could make corrections to input such as transforming a STRUNG tag to STRONG, since this is probably what was intended and is the closest match to existing grammar.
Obviously this is a very simple example, but I think this kind of approach could lead to new ways of solving problems and increasing the overall reliability of computer systems.
Slashdot Mirror
As a Linux user, your main cause for concern is the possibility that some programs that you use today or interesting programs that have yet to be written will suffer as a result of the GPL version change. This possibility is due to the incompatibility of the GPL v2 and v3 licenses. We have already seen that a number of kernel developers are opposed to the new version of the license. It can also be assumed that some current major corporate contributors to GPL v2 projects would also be opposed to the new tivoization and patent clauses. If a number of important components or libraries shift to GPL v3, then these are likely to be abandoned or forked by developers that want their projects to stick with GPL v2.
I know that forking is nothing new, but it seems fairly arrogant of the FSF to intentionally create a schism within the ranks of developers that support the GPL by creating a new and incompatible license that they *know* many of them will be vehemently against.
There are still some sporadic reports at forum.parallels.com that people are still having difficulty getting Parallels to recognize and use the VT-x instructions on their Minis, but the problems seemed to have largely been resolved by the latest Apple firmware updates.
Even if you did have a chip that is somehow lacking the VT-x instructions, you could still run Parallels just fine - albeit not at its full potential speed. This has been true since the first beta of Parallels and is true of virtualization products on other platforms. The OP probably didn't think to mention it because it is a non-issue.
Fortunately, FLAC is "BSDed" not "GPLed" so it has a much better shot at widespread adoption - i.e. in commercial hardware and software products.
Myabe when you're thirty-one, you'll *really* be able to tell the difference.
Hmm...you must have skimmed through the tutorial without reading closely, since it *specifically* tells you that the Currency Converter is overdesigned to introduce the MVC concept:
"This design for Currency Converter is intended to illustrate a few points, and so may be overly designed for something so simple. It is quite possible to have the application's controller class, ConverterController, perform the computation and do without the Converter class. By adhering to the MVC paradigm in this tutorial, however, you will learn the fundamentals of good Cocoa design which will assist you greatly as you begin to work on more advanced projects."
Of course, a full justification of the MVC approach is beyond the scope of this reply!
This might be a valid concern if Microsoft ever actually officially supported WTL, but they didn't and they don't.
.NET rather than COM/Win32.
As others have pointed out, WTL is a pet project of a single Microsoft employee and always has been. At one time, it may have been briefly proposed as an officially supported alternative to MFC for C++ Win32 development, but they probably felt there was no point in confusing the issue with another C++ library since the future development focus was to be shifted to
By hosting the code on SourceForge, I personally believe the point *is* to accept user contributions to the source. Because Microsoft never really invested any resources in WTL, there is little harm in allowing the community to take over the project. The community for WTL has never been large, but there are a number of dedicated users who prefer the "lightweight" C++ template programming model over the "heavyweight" C++ inheritance model provided by MFC and ilk (wxWindows and OWL).
I would imagine the decision to release WTL on SourceForge went something like this:
WTL Author:
"Hey Mr. Manager, this WTL thing that I've been working on in my free time for the last several years still has a small but dedicated set of users. It's getting to be a pain for me to maintain, however, so do you mind if I put it up on SourceForge so they can help me keep it alive?"
Mr. Manager:
"Hmm...okay. Use the CPL like that installer thing."
WTL Author:
"Thanks!"
This has been my experience as well. I've worked as a software developer on dozens of consulting projects in North America and Western Europe, and the US managers prefer to work from "intuition" and "feel" rather than the rigorously specified requirements and design that the Europeans insist upon.
I personally believe that there are merits and drawbacks to both approaches and that the ideal is somewhere between formal and informal approaches.
The informal, intuitive approach can result in a deliverable that is a much closer fit to the actual needs of the client - not just what they think they want or what they can express in words. A good informal manager circulates through the entire target organization from management, to accounting, to the IT department, to the users, and sometimes even to the client's own customers. Through a process of information osmosis, the manager constructs a feel of what the deliverable really needs to be and directs the team accordingly. Obviously, this approach works best when the project manager is damn good (sharp *and* experienced) and the development team is small and works well together. The main drawback, of course, is a tendency to chaotic development as things are written and rewritten to hit a moving target.
The formal approach is reliable, predicatable, and safe. Maybe what you deliver will not be a perfect match for the unspoken requirements that inevitably surface during the project lifecycle, but at least you have a better chance of delivering *something*.
I wonder, however, with the growing pool of cheap outsourced labor, if the paint-by-numbers formal software approach is really the best answer for the US going forward. If a project is specified in sufficient detail, then anyone can do the development. Perhaps the intuitive, informal approach is the only competitive advantage a US team can offer going forward - a dream team of software magicians rather than a clockwork team of software engineers.
Actually, it sounds to me more like a high-budget episode of MythBusters (http://dsc.discovery.com/fansites/mythbusters/myt hbusters.html).
Since when did Jamie and Adam become astronauts?
I always thought an interesting application for "modern" interactive fiction would be to apply the technologies of voice recognition and speech synthesis to IF. The structure of the IF game itself would remain the same - only all of the interaction is through listening/speaking rather than reading/typing.
So on your next long drive to nowhere in particular, you could play an IF game on your car's computer instead of listening to a non-interactive audio book or some tunes on the CD player/radio.
Obviously, this kind of thing might also be fun for the visually-impaired gamer.
Any idea if anyone has ever done this?
One of my half-baked ideas for a Finder enhancement (that may or may not be able to survive the transition to fully baked), would be to somehow integrate the Finder and Terminal applications into a single user interface.
When accomplishing a task, it is sometimes more convenient to use the Finder's graphical user interface. Other, generally more complicated, tasks require the use of the Terminal's CLI. To perfrom a sequence of tasks, I often find myself switching back and forth between one or more Finder and Terminal instances to get the job done. If the two applications were combined into one, the transition between GUI-oriented work and CLI-oriented work would not be as mentally disconcerting. In addition, the strengths of both approaches could be combined to offset their weaknesses.
The Terminal would be embedded in the Finder as a splitter pane above or below the graphical view of the file system (according to user preference). The working directory of the Terminal could either be linked to automatically update during point-and-click navigation through folders or decoupled with a sync-to-current location button provided to update the Terminal's working directory. Special "pipeable" objects would be provided to redirect the results of Terminal commands to the current GUI view.
Here is a simple example to illustrate this:
1.) The user opens a new Finder window and navigates to a folder using the GUI.
2.) The user types a command in the embedded Terminal: ls *.log | FinderView.
3.) The results of the command are piped to the Finder's current view and presented graphically.
Obviously, there are many issues that would have to be resolved to make all of this work properly, but I think it would be worth the effort to create a hybrid CLI/GUI Finder-like application.
The number of Linux kernel developers you presented isn't particularly impressive, since there are about 5000 developers working on the latest version of Windows Server 2003 (source: Mark Lucovsky, Microsoft). There really isn't any way to prove that the best and the brightest at Microsoft are any better or worse than the best and the brightest on the Linux kernel team. The proof is in the pudding (or the kernel) so to speak, but even still there is room for debate and contention.
It could be argued that Microsoft's greatest development advantage is the opportunity for superior efficiency through centralized control and more structured communication. This advantage may turn out to be a weakness, however. Linux, with its looser organization and higher degree of redundant effort, may not be as efficient but this parallelism creates an almost Darwinian environment that weeds out the weakest solutions in favor of the strong. Which model is the most effective for software?
To me it seems unlikely that the two camps will stay locked in this struggle forever. It will likely end much like the Cold War between the Soviet Union and the United States. Both sides will stay locked in an uneasy equilibrium for many years with each claiming a periodic advantage. Eventually one side will come to the realization that it has fallen far enough behind that it's no longer possible to catch up.
To continue with the analogy, however, it's still the 1950's. It will be many years before a final, decisive victory is reached by either philosophy. (Or maybe the UFOs will finally land and we'll just use AlienOS Earth Edition).
If you've ever purchased a home, you've probably experienced an extreme deluge of telemarketing. New homeowner lists are generated and sent out to what must be every home-related business on the planet: pest control, security systems, lawn care, water treatment, housecleaning, long distance, insurance, etc.
... Hello? ... Hello? ... click) and the second cutoff before I had a chance to tell the guy to put me on the DNC list.
About a week after I moved into my new house, the barrage started. At its peak, the calls would start at around 7:30am and continue until about 8:00pm. I think the one day record was about 30 calls.
It's tapered off now, but there is still a fairly steady stream of calls. In fact, while writing this post I received two telemarketing calls. The first was just a dead line (Hello?
This may not constitute harassment on the part of any individual company (except for the ones that continue to call after I told them not to), but surely it's a conspiracy to commit harassment by the industry itself. Please make it stop!!!!
Regarding the legislation, I don't want to get any calls from surveys, charities, or politicians either. In my opinion, the legislation doesn't go far enough.
As opposed to open source software where the wheel is reinvented again and again just for the hell of it? Where perfectly useable commercial products are cloned feature-by-feature and even screen-by-screen because it's an offense against nature to just pay for and use the existing product. Where the spit and polish of a commercial product is deemed unnecessary since you can just "look at the code" if you don't understand it. Where the most common response to a user feature request is "it's open source, so you can add it yourself".
I don't want to sound too negative, since open source has been irrefutably proven to work for the difficult and technical: protocol stacks, OS kernels, web servers, compilers, etc. Commercial software, however, still has the edge in creating attractive and useable human computer interfaces. Why? Because it's not about "learning" and "sharing" and "culture" - it's about grabbing people by the balls and making them want to use the product.
This is true of nearly every product in our wonderfully chaotic system of global capitalism. Why should software be any different?
Jaron's concepts are vaguely stated but still interesting. If you imagine a computer having a central intelligence that is modeled after human intelligence with a certain amount of pattern recognition and iterative learning behavior, there are some potential immediate applications of this.
A simple example would be the computer's parsing of HTML (or any other grammar/vocabulary-based file format) as compared to a human's parsing of the written word. The human mind has a certain amount of fault-tolerance for ambiguities and grammar-deviations which allows it to make some sense of all but the most mutated input. An example of this would be your own ability to grok most Slashdot posts, however rife with gramer, spelin, and logik errors they may be.
The computer could also potentially do this to less than perfect input - smooth over the "errors" and try to extract as much meaning as possible using its own knowledge of patterns. It could make corrections to input such as transforming a STRUNG tag to STRONG, since this is probably what was intended and is the closest match to existing grammar.
Obviously this is a very simple example, but I think this kind of approach could lead to new ways of solving problems and increasing the overall reliability of computer systems.