We have the power in our wallets. If we, collectively, avoid copy protected products like the plague, the message will get across to the powers that be - they can not make us buy what we don't want to buy, after all.
If they do not change, it will be their ruin.
Sadly, most people will not follow this path, as they are satisfied to let the corporate moguls dictate what they can and can't do in the confines of their home.
So, every VHS video tape I have recorded and subsequently skipped over the commercials was a DRM violation?
Horse puckey!
When something enters the walls of my home (my castle, if you will), it is in my domain - and, as long as I do not rebroadcast it, or charge money to bring in people off the street to view it, I should be free to do what I want with it. This is the concept behind 'fair use' in copyrighted material.
Furthermore, I will not buy any product that attempts to usurp that sovereign power within my own walls.
ummmm - you can version directory structures under CVS - as well as any file types you care to think of (binary).
Additionally, define what you mean by 'atomic commit'. If that means you can commit the changes of just one file in the set - then CVS handles that too.
I will have to agree - moving files is a pain in CVS. However, such a major change to your directory structures would probably warrant a new top level anyway...
The issue is you are misrepresenting that people 'want' something of their own free will, when, in fact, many of the decisions to use a particular product come about due to coersion. Coersion as a result of dirty business deals and coersion as a result of monopolistic 'standards' manipulation.
Generating wealth as the result of manipulating a marketplace to corner the market does not enrich people's lives - and is not "moral goodness", no matter how you try to spin it. Even if the majority of people "equate the ability to generate wealth with a type of moral goodness" - that would not make unethical behavior any less wrong for its being accepted by the majority. To fight against something wrong by boycotting it is not 'sophistry', as you imply.
If you can't see that, you are either lying to yourself, or ignorant of the ethical concepts of responsibility, honor and common decency.
The easy way you brush ethical considerations under the rug is disgusting. I can not fathom how anyone can think or act like this, and look themselves in the eye in the mirror each morning. I can only surmise you are an Enron executive.
The executive summary: diversify your skill base, and become a jack of all trades; coupled with that, look at other means to increase your ability to satisfy your user community better and faster than the competition.
This is a moral consideration, as I'm sure other people will point out. - lostguy
What you are saying is tautological. Yes, my statement dealt with a moral consideration; that is the point. Microsoft is not interested in doing the right thing - they are more interested in the almighty dollar. You can not discount ethical considerations when approaching technology. In the case of some technology, such as the A-Bomb project, especially so.
For example, the current companies that benefit from the Chinese government contracts to provide network firewall and filtering are morally reprehensible. Would I buy a product from them, even though it may be 'best in class'? No, because I believe we have a responsibility to do the right thing in all cases - particularly where our actions can effect thousands of people, and even if it does not benefit our stockholders (if I were to own a company and make such decisions); we have a responsibility to be good stewards when we wield grave power. We should also not support those who show poor stewardship in such situations.
You can not divorce yourself from the ethics of a situation simply because you are discussing a technical subject. This seems to be a key difference between those who espouse the Microsoft way, and those who tread the *nix path - a recurring theme that goes through the discourse in this forum.
I went out and downloaded Cygwin, and messed with it a little bit.
My major issue with it is it is really designed for porting existing applications into a Windows environment by using a system level DLL to map Unix system services to Windows system services. While that may be useful, it does not allow you to run native DOS and Windows applications from within Cygwin (I should be able to do anything on my machine from one interface - not have to jump around).
This does not address my goal - which is to build a transparent shell and utilities that run under native Windows-DOS/command.com, allow the execution of native DOS and Windows binaries inside the shell, while also providing emulation for the POSIX parts that Windows does not get 'right' out of the box - such as job control, regular expression pattern matching, interprocess communication etc...
My approach would allow me to install the windows versions of various tools (emacs, python, perl, java, etc...), and use these seamlessly within the shell - interacting with the overall file systems with the CP/Mish syntax as needed to differentiate multiple storage devices. Something not possible with Cygwin (from my poking around - unless you know some secret to using it that I am not privy to?).
Additionally, I want my tools to have a relatively small footprint - the basic package would consist of python, the bash clone, and the collection of basic CLI tools (grep, diff, patch, ps, ls, cat, etc...); that is all. The user could choose to load other Windows or legacy DOS applications as they desire (for example, I would load the windows builds of emacs and perl) - and it would all work together.
A *nix developer, like myself, could use such a tool to leverage existing skills no matter what machine you use with the added flexibility of being able to interact with the whole system. Additionally, I think my approach has a smaller footprint than the Cygwin solution - and thus would be a quicker and cleaner installation process - as well as a very clean de-installation (no DLLs to load and lose track of).
So - I think I will continue with my little experiment...:)
You are making the assumption that programming in a *nix culture mostly benefits the programmers in all cases. While we can say that some of the fringe applications may have such properties, your nuts and bolts - get the work done for our customers enterprise *nix developers have no such luxury.
Now, given that it is irresponsible to put mission critical applications on a windows machine, there is really only one other OS to develop to: *nix.
The issue is not 10% of the desktops - the real issue is building enterprise class applications that run on servers - and that is where *nix shines. Who the heck is building applications that run on a client's machine now anyway? Gamers, crackers, and anyone else tied to Microsoft at the hip - that is who. All of our new system development is going to the web (which might be why Microsoft is so focused on.NET - to play catch up with Java and the 4GL tools and frameworks that are out there).
Using agile development methods I can kick out a quick and workable python/Zope application over the web in no time. Depending on the scalability requirements and the size of the user community, that might be enough for production, as well. If not, then it can be easily ported to Jython with a storage array strapped on the side.
You windows-centric developers are living in the dark ages. It is the 21st century for crying out loud. Of course, if the vast majority of you don't change, then I can continue to get all the juicy contracts building the enterprise backbone, while you compete for the few 'desktop application' jobs out there with the other 100,000 Microserfs.
Continue doing what you are doing - I was wrong...
Windows has a _much_ more powerful API - ProtonMotiveForce
I can do more under Unix (up to and including rewriting the kernel) than you can do under Windows. You are constrained. Microsoft forces you to program a certain way - there are no alternatives. If that is your definition of 'more powerful', then I think you have something to learn about 'power' where a computer is concerned.
Windows has better threading support, a better asynchronous programming model, and a much more powerful network API
Threads have been shown to be more difficult to program, and thus more likely to have bugs than using interprocess communication. Unix's norm is to build many small tools that communicate in standard ways (piping standard output of one application to standard input of another, or via sockets across the network) and lash them up to get work done in ways the original developer may not have imagined. Our goal is usable applications for our users - not buggy code that makes the users pull out their hair.
Asynchronous progamming model; not something I have found in my research or experience. Perhaps that is another name for ?...? Is that really desireable? I ascribe to the spiral development model myself (or any of the variations attributable to agile software development - aka extreme programming). It works; you might try it sometime.
As for network APIs, how can you get more powerful than Expect? You simply instantiate an application (such as telnet, ftp, etc.) and use the reference returned to filter the resultant data stream from the remote application - and have your application respond as appropriate. I know of no Windows API that is as easy to use as that.
Here is what you should be doing if you develop under *nix:
1. Ask yourself if the application would be better served as a web based system. If so, use Zope, java or any number of other tools available for the task. This is the ultimate in portability because anyone with a browser will be able to use your application.
2. If your application absolutely has to run on the client machine, then use a 4GL as core language, such as Python, Perl, Java. Consider C as glue, and only use it sparingly. I would suggest standardizing on the TK gui tool kit - which is available for most languages including Python and Perl.
3. If your application has highspeed graphics or a realtime monitoring utility, then use accepted libraries, such as OpenGL etc, and program using the fastest language - C.
4. Forget all of that 'powerful API' BS the Microserfs keep yelling at you. Remember: the "highest priority is to satisfy the customer through early and continuous delivery of valuable software" - Agile Manifesto. Keeping your customers waiting because you spent fifteen days finding a bug in a Windows API is unacceptable. Similarly, wasting time trying to build something from scratch that you could have delivered in less time using existing standards, frameworks and 4GL languages is also unforgivable. Everything else is fluff.
Finally, you say that Microsoft has 'courted the developers' - I believe they have lead you down a narrow path by your nose. They have certainly not 'courted' me, as my standards for supplying my user base with working software is higher than any holy war.
The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")... - Joel Spolsky
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")... - Joel Spolsky
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
The only drawback with pure gui IDEs is my requirement to be able to do substantial work remotely.
While you can export an X window - the overhead across the network is unbearable. Again, this is where emacs shines; I like the flexibility of being able to make changes from anywhere at anytime - quickly without any hassles - and check in the changes on my remote server's CVS repository - without leaving the interface.
If I am WiFi'ing at the coffee shop, and I get a call from a client that needs some development work to fix a bug, it is real nice not to have to jump up and spill my latte in a mad dash to the office. I can calmly sip my beverage of choice while VPN'ing into my development network - do the job - test - and deploy the patches, all from the confort of my chair.
What IDE allows me to do that now? Emacs, for sure.
I intend on putting my stuff up on Freshmeat or equivalent sometime in the future.
I'm going to do a little research first, and see if there is already a project that is a going concern before I do - that way I don't duplicate efforts.
If you want to contact me regarding this, email me at this location and I will give you what I've got (grep.py atm).
The previous post said exactly what I would say regarding your assumption that I have only tried one thing. I can only add the following:
I have tried many different commercial IDEs, including Borland, Semantic, Microsoft, Sun, and I also used vi and a plethora of xterms before I delved into Emacs seriously. Emacs is the best of breed; it allows me to not only do development on my local machine, but also across the network - and it is fully extendable - so I can create and manage exactly the bells and whistles I want - not what some marketing department thinks I should have.
If something works best given the task, why change? By your assumption, when you get old we should just fire you and hire some new kid - because he is newer. Your assumption that each new IDE builds on, and is an improvement over previous IDEs is also illogical. Each tool provides certain capabilities - most of which are fluff put in to increase the feature count.
This is the primary problem in IT today - people who see the greatest new gee-wiz gadget and decide that is the way the whole operation needs to work (not taking into account individual preferences and modes of working). If something works for you - great! Just don't force the rest of us to use it, or assume we are all dismissing your great tool out of hand: we have good reasons for the choices we make.
Give me diff, patch, CVS or RCS, make and emacs and I am a happy camper.
Every year I have some yahoo come in and say how one IDE can do this, that, and the other thing - the best thing since sliced bread. Of course bells and whistles do not an IDE make (I would have said 'make an IDE', but, then I would be a liar on two counts).
Emacs is fully extensible, and interfaces with all of the tools above. Additionally, I can run it over a telnet/ssh connection with ease (I don't use the mouse very much for two reasons; 1, I keep the keystrokes in my head for when I do need to use a telnet session, and 2, I have gotten to the point where I can do things faster using the keyboard than a mouse and keyboard combo in emacs.
I even do my primary editing on my windoze box using emacs, and am in the process of writing python language equivalents to the most common unix command line utilities (already completed 'grep.py' - then want: make, diff, patch and other tools unavailable on the windows command line) as a learning process.
I guess real world government trumps virtual government.
Are we 'netizens' with any unalienable rights? Or, is this just a pipe dream?
Those of us who do not wish to descend into a vanilla world of producers and consumers, and controls on how we lash up our machines need to set up an 'Alternet' based on long distance WiFi and a broadband version of a mesh network.
Granted, the military could jam us off the air. I don't think we would be worrying about our network freedom as much as our physical freedom at that point anyway.
While this is probably paranoid drivel, it does concern me that someone in a room far away can decide how I can use a socket connection to my Dad's computer (halfway accross the continent) over the internet. Will the 'haves' decide that the 'have nots' are abusing the technology at the expense of their bottom lines, and butcher the net to create a new kind of 'television' - producer/consumer model? If so, what can we do about it?
When networks are outlawed, only outlaws will have networks.
Can't mod you up - so I'll just ditto what you said - VOIP customers will have broadband available to them which will obviate the need of a modem for internet access.
Forking is not bad, particularly if it allows features to see the light of day that might otherwise have been suppressed. In such an environment the largest group of people can be completely satisfied (both those who forked, and those who did not fork).
Open Source is about dynamism - the ebb and flow of designs through an ecosystem of software. Some die, some gain small niches where they live for many years, and some become 'killer apps' - used by all.
The key is for Businesses and Governments who are considering, or are in the process of moving to Open Source to engage integrators who will steer them through that ecosystem - to locate the tools they need to do the job, and more importantly, choose based on the level of risk they are willing to accept, given such considerations as disaster recovery, and in-house skill sets for maintaining and upgrading software that could be abandoned.
Of course, that is no different than what they have to deal with from proprietary vendors anyway (if Microsoft desides to end-of-life Windows NT, there is not much you can do about it - oh wait - they already did that. At least with Open Source you have the option of maintaining the software yourself if such a thing comes to pass [I haven't heard about Microsoft releasing NT sources yet...and I won't hold my breath]).
Slashdot Mirror
We have the power in our wallets. If we, collectively, avoid copy protected products like the plague, the message will get across to the powers that be - they can not make us buy what we don't want to buy, after all.
If they do not change, it will be their ruin.
Sadly, most people will not follow this path, as they are satisfied to let the corporate moguls dictate what they can and can't do in the confines of their home.
So, every VHS video tape I have recorded and subsequently skipped over the commercials was a DRM violation?
Horse puckey!
When something enters the walls of my home (my castle, if you will), it is in my domain - and, as long as I do not rebroadcast it, or charge money to bring in people off the street to view it, I should be free to do what I want with it. This is the concept behind 'fair use' in copyrighted material.
Furthermore, I will not buy any product that attempts to usurp that sovereign power within my own walls.
ummmm - you can version directory structures under CVS - as well as any file types you care to think of (binary).
Additionally, define what you mean by 'atomic commit'. If that means you can commit the changes of just one file in the set - then CVS handles that too.
I will have to agree - moving files is a pain in CVS. However, such a major change to your directory structures would probably warrant a new top level anyway...
The issue is you are misrepresenting that people 'want' something of their own free will, when, in fact, many of the decisions to use a particular product come about due to coersion. Coersion as a result of dirty business deals and coersion as a result of monopolistic 'standards' manipulation.
Generating wealth as the result of manipulating a marketplace to corner the market does not enrich people's lives - and is not "moral goodness", no matter how you try to spin it. Even if the majority of people "equate the ability to generate wealth with a type of moral goodness" - that would not make unethical behavior any less wrong for its being accepted by the majority. To fight against something wrong by boycotting it is not 'sophistry', as you imply.
If you can't see that, you are either lying to yourself, or ignorant of the ethical concepts of responsibility, honor and common decency.
The easy way you brush ethical considerations under the rug is disgusting. I can not fathom how anyone can think or act like this, and look themselves in the eye in the mirror each morning. I can only surmise you are an Enron executive.
I am not a security geek - so can not comment on the issue of having a security audit cost me my job.
On the other hand, I do have some thoughts on increasing your likelyhood of finding or keeping a job in this tough IT marketplace, that can be found here...
The executive summary: diversify your skill base, and become a jack of all trades; coupled with that, look at other means to increase your ability to satisfy your user community better and faster than the competition.
This is a moral consideration, as I'm sure other people will point out. - lostguy
What you are saying is tautological. Yes, my statement dealt with a moral consideration; that is the point. Microsoft is not interested in doing the right thing - they are more interested in the almighty dollar. You can not discount ethical considerations when approaching technology. In the case of some technology, such as the A-Bomb project, especially so.
For example, the current companies that benefit from the Chinese government contracts to provide network firewall and filtering are morally reprehensible. Would I buy a product from them, even though it may be 'best in class'? No, because I believe we have a responsibility to do the right thing in all cases - particularly where our actions can effect thousands of people, and even if it does not benefit our stockholders (if I were to own a company and make such decisions); we have a responsibility to be good stewards when we wield grave power. We should also not support those who show poor stewardship in such situations.
You can not divorce yourself from the ethics of a situation simply because you are discussing a technical subject. This seems to be a key difference between those who espouse the Microsoft way, and those who tread the *nix path - a recurring theme that goes through the discourse in this forum.
I went out and downloaded Cygwin, and messed with it a little bit.
:)
My major issue with it is it is really designed for porting existing applications into a Windows environment by using a system level DLL to map Unix system services to Windows system services. While that may be useful, it does not allow you to run native DOS and Windows applications from within Cygwin (I should be able to do anything on my machine from one interface - not have to jump around).
This does not address my goal - which is to build a transparent shell and utilities that run under native Windows-DOS/command.com, allow the execution of native DOS and Windows binaries inside the shell, while also providing emulation for the POSIX parts that Windows does not get 'right' out of the box - such as job control, regular expression pattern matching, interprocess communication etc...
My approach would allow me to install the windows versions of various tools (emacs, python, perl, java, etc...), and use these seamlessly within the shell - interacting with the overall file systems with the CP/Mish syntax as needed to differentiate multiple storage devices. Something not possible with Cygwin (from my poking around - unless you know some secret to using it that I am not privy to?).
Additionally, I want my tools to have a relatively small footprint - the basic package would consist of python, the bash clone, and the collection of basic CLI tools (grep, diff, patch, ps, ls, cat, etc...); that is all. The user could choose to load other Windows or legacy DOS applications as they desire (for example, I would load the windows builds of emacs and perl) - and it would all work together.
A *nix developer, like myself, could use such a tool to leverage existing skills no matter what machine you use with the added flexibility of being able to interact with the whole system. Additionally, I think my approach has a smaller footprint than the Cygwin solution - and thus would be a quicker and cleaner installation process - as well as a very clean de-installation (no DLLs to load and lose track of).
So - I think I will continue with my little experiment...
You are making the assumption that programming in a *nix culture mostly benefits the programmers in all cases. While we can say that some of the fringe applications may have such properties, your nuts and bolts - get the work done for our customers enterprise *nix developers have no such luxury.
.NET - to play catch up with Java and the 4GL tools and frameworks that are out there).
Now, given that it is irresponsible to put mission critical applications on a windows machine, there is really only one other OS to develop to: *nix.
The issue is not 10% of the desktops - the real issue is building enterprise class applications that run on servers - and that is where *nix shines. Who the heck is building applications that run on a client's machine now anyway? Gamers, crackers, and anyone else tied to Microsoft at the hip - that is who. All of our new system development is going to the web (which might be why Microsoft is so focused on
Using agile development methods I can kick out a quick and workable python/Zope application over the web in no time. Depending on the scalability requirements and the size of the user community, that might be enough for production, as well. If not, then it can be easily ported to Jython with a storage array strapped on the side.
You windows-centric developers are living in the dark ages. It is the 21st century for crying out loud. Of course, if the vast majority of you don't change, then I can continue to get all the juicy contracts building the enterprise backbone, while you compete for the few 'desktop application' jobs out there with the other 100,000 Microserfs.
Continue doing what you are doing - I was wrong...
Windows has a _much_ more powerful API - ProtonMotiveForce
I can do more under Unix (up to and including rewriting the kernel) than you can do under Windows. You are constrained. Microsoft forces you to program a certain way - there are no alternatives. If that is your definition of 'more powerful', then I think you have something to learn about 'power' where a computer is concerned.
Windows has better threading support, a better asynchronous programming model, and a much more powerful network API
Threads have been shown to be more difficult to program, and thus more likely to have bugs than using interprocess communication. Unix's norm is to build many small tools that communicate in standard ways (piping standard output of one application to standard input of another, or via sockets across the network) and lash them up to get work done in ways the original developer may not have imagined. Our goal is usable applications for our users - not buggy code that makes the users pull out their hair.
Asynchronous progamming model; not something I have found in my research or experience. Perhaps that is another name for ?...? Is that really desireable? I ascribe to the spiral development model myself (or any of the variations attributable to agile software development - aka extreme programming). It works; you might try it sometime.
As for network APIs, how can you get more powerful than Expect? You simply instantiate an application (such as telnet, ftp, etc.) and use the reference returned to filter the resultant data stream from the remote application - and have your application respond as appropriate. I know of no Windows API that is as easy to use as that.
Here is what you should be doing if you develop under *nix:
1. Ask yourself if the application would be better served as a web based system. If so, use Zope, java or any number of other tools available for the task. This is the ultimate in portability because anyone with a browser will be able to use your application.
2. If your application absolutely has to run on the client machine, then use a 4GL as core language, such as Python, Perl, Java. Consider C as glue, and only use it sparingly. I would suggest standardizing on the TK gui tool kit - which is available for most languages including Python and Perl.
3. If your application has highspeed graphics or a realtime monitoring utility, then use accepted libraries, such as OpenGL etc, and program using the fastest language - C.
4. Forget all of that 'powerful API' BS the Microserfs keep yelling at you. Remember: the "highest priority is to satisfy the customer through early and continuous delivery of valuable software" - Agile Manifesto. Keeping your customers waiting because you spent fifteen days finding a bug in a Windows API is unacceptable. Similarly, wasting time trying to build something from scratch that you could have delivered in less time using existing standards, frameworks and 4GL languages is also unforgivable. Everything else is fluff.
Finally, you say that Microsoft has 'courted the developers' - I believe they have lead you down a narrow path by your nose. They have certainly not 'courted' me, as my standards for supplying my user base with working software is higher than any holy war.
Support and configuration are two different animals.
Linux supports all that you say; is it configured out of the box in all distros - probably not.
The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")... - Joel Spolsky
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
$p = get/process FileName
$p[5].ToString()
foreach ($p) { $p.ToString() }
This is from the 'monad' page listed in the parent post.
That looks alot like csh. There is a reason why no one writes csh scripts anymore...
The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")... - Joel Spolsky
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
Why not have a script do it for you - no monitor, or pesky terminal window needed.
I have been meaning to take Eclipse for a spin.
The only drawback with pure gui IDEs is my requirement to be able to do substantial work remotely.
While you can export an X window - the overhead across the network is unbearable. Again, this is where emacs shines; I like the flexibility of being able to make changes from anywhere at anytime - quickly without any hassles - and check in the changes on my remote server's CVS repository - without leaving the interface.
If I am WiFi'ing at the coffee shop, and I get a call from a client that needs some development work to fix a bug, it is real nice not to have to jump up and spill my latte in a mad dash to the office. I can calmly sip my beverage of choice while VPN'ing into my development network - do the job - test - and deploy the patches, all from the confort of my chair.
What IDE allows me to do that now? Emacs, for sure.
I intend on putting my stuff up on Freshmeat or equivalent sometime in the future.
I'm going to do a little research first, and see if there is already a project that is a going concern before I do - that way I don't duplicate efforts.
If you want to contact me regarding this, email me at this location and I will give you what I've got (grep.py atm).
The previous post said exactly what I would say regarding your assumption that I have only tried one thing. I can only add the following:
I have tried many different commercial IDEs, including Borland, Semantic, Microsoft, Sun, and I also used vi and a plethora of xterms before I delved into Emacs seriously. Emacs is the best of breed; it allows me to not only do development on my local machine, but also across the network - and it is fully extendable - so I can create and manage exactly the bells and whistles I want - not what some marketing department thinks I should have.
If something works best given the task, why change? By your assumption, when you get old we should just fire you and hire some new kid - because he is newer. Your assumption that each new IDE builds on, and is an improvement over previous IDEs is also illogical. Each tool provides certain capabilities - most of which are fluff put in to increase the feature count.
This is the primary problem in IT today - people who see the greatest new gee-wiz gadget and decide that is the way the whole operation needs to work (not taking into account individual preferences and modes of working). If something works for you - great! Just don't force the rest of us to use it, or assume we are all dismissing your great tool out of hand: we have good reasons for the choices we make.
Cygwin - I will try that. I thought it was a commercial only product - I guess I was wrong (I was probably thinking about another product).
Now I have to think up a new project...
Give me diff, patch, CVS or RCS, make and emacs and I am a happy camper.
Every year I have some yahoo come in and say how one IDE can do this, that, and the other thing - the best thing since sliced bread. Of course bells and whistles do not an IDE make (I would have said 'make an IDE', but, then I would be a liar on two counts).
Emacs is fully extensible, and interfaces with all of the tools above. Additionally, I can run it over a telnet/ssh connection with ease (I don't use the mouse very much for two reasons; 1, I keep the keystrokes in my head for when I do need to use a telnet session, and 2, I have gotten to the point where I can do things faster using the keyboard than a mouse and keyboard combo in emacs.
I even do my primary editing on my windoze box using emacs, and am in the process of writing python language equivalents to the most common unix command line utilities (already completed 'grep.py' - then want: make, diff, patch and other tools unavailable on the windows command line) as a learning process.
What I find interesting is that the guy slashdotted himself...one way to work out your firewall and web server, I suppose.
I guess real world government trumps virtual government.
Are we 'netizens' with any unalienable rights? Or, is this just a pipe dream?
Those of us who do not wish to descend into a vanilla world of producers and consumers, and controls on how we lash up our machines need to set up an 'Alternet' based on long distance WiFi and a broadband version of a mesh network.
Granted, the military could jam us off the air. I don't think we would be worrying about our network freedom as much as our physical freedom at that point anyway.
While this is probably paranoid drivel, it does concern me that someone in a room far away can decide how I can use a socket connection to my Dad's computer (halfway accross the continent) over the internet. Will the 'haves' decide that the 'have nots' are abusing the technology at the expense of their bottom lines, and butcher the net to create a new kind of 'television' - producer/consumer model? If so, what can we do about it?
When networks are outlawed, only outlaws will have networks.
Can't mod you up - so I'll just ditto what you said - VOIP customers will have broadband available to them which will obviate the need of a modem for internet access.
Great, one more thing to make the government even more paranoid than it already is...
What's next, abolition of the internet and reinstatement of the tickertape machine?
Of course, their paranoia could be feeding my own paranoia - or it might be the other way around.
That is not correct - at least where I live (not Qwest land).
Forking is not bad, particularly if it allows features to see the light of day that might otherwise have been suppressed. In such an environment the largest group of people can be completely satisfied (both those who forked, and those who did not fork).
Open Source is about dynamism - the ebb and flow of designs through an ecosystem of software. Some die, some gain small niches where they live for many years, and some become 'killer apps' - used by all.
The key is for Businesses and Governments who are considering, or are in the process of moving to Open Source to engage integrators who will steer them through that ecosystem - to locate the tools they need to do the job, and more importantly, choose based on the level of risk they are willing to accept, given such considerations as disaster recovery, and in-house skill sets for maintaining and upgrading software that could be abandoned.
Of course, that is no different than what they have to deal with from proprietary vendors anyway (if Microsoft desides to end-of-life Windows NT, there is not much you can do about it - oh wait - they already did that. At least with Open Source you have the option of maintaining the software yourself if such a thing comes to pass [I haven't heard about Microsoft releasing NT sources yet...and I won't hold my breath]).