I guess I should have been more specific about the games I play -- mostly FPS, MMOGS and Flight Simulations --- all of which are very configurable - and becoming more so as titles are upgraded, and new titles are released.
WWIIonline, (combination flight simulator and FPS) for example, allows all the controls to be remapped - mouse, joystick and keyboard. Most joysticks now come with software that not only allows remapping, but also macro development - for another layer of configurability.
World of Warcraft not only allows for control remapping and macros, but also has a rich interface for the development of 3rd party interfaces.
From my point of view, GUI usability must be tied to configurability for productivity software in a similar manner. We have only scratched the surface on what is possible, and the more possibilities are investigated by the end users, the better the results will be.
I see where you are coming from, but have two options that would solve that:
1. Infinite 'undo' and 'redo' functionality for the interface. The user could undo and/or redo until he finds where he made the mistake and go from there. If the configuration file was flat text (xml) it could even be saved in a version control system, so you could attach other meta-data to your versions (like 'version number', 'note', 'version name' etc...all nicely hidden from the user other than through the modification interface - unless he was geeky enough to mess with the file manually). With version control and 'releases' multiple configuration states could be maintained by name - and selected by the user with minimal issues.
2. A easily accessible 'default' button that puts everything back to the 'vanilla' version as found when first installed out-of-the-box (undoable, as in #1 above, of course).
Most users will have one or two interface 'states' that they like and use, while power users and geeks may have many. Again, everyone is happy who wants to be happy.
One perfect user interface paradigm is not achieveable(sic) because people are all different.
I see better user interfaces in pc games than I do in other software. This is primarily because game designers realized years ago that everyone has their own prefered way of interacting with the input interfaces. This led to the ability for the end user to modify the input options (such as a keyboard mapper and joystick macros).
A better approach for all software would be to build an infinitely modifiable interface - both for visualization and input. Tie the configurations to some standard, like XML. The company would have a 'standard' config file, and users and others would be able to create and share their own interpretations of what is 'best'. Everyone is (or I should say 'has the option of being') happy. If you are not an XML hack - a GUI could be easily built to make the modifications easier.
Most applications do not approach this level of configurability.
KDE is available under Solaris 10 -- you just have to enable a switch for it to show up as a choice in the X window login.
KDE beats the heck out of CDE...CDE, while functional, is not as snappy as KDE - nor does it have a plethora of open source apps (Kdevelop et al) that make KDE the premier development platform in comparison IMHO.
I think the point he is trying to make (after RTFL - the relevant link) is that while you can impliment equivalent functionality in any language, you will take a performance hit because other languages are not optimized to handle some of the items he mentions (class indexing etc...)
That is a tenuous argument at best; nonetheless without knowing the OpenStep standard there might be some validity to it - particularly if the standard specifies such functionality as is native to Objective-C.
Having never used Objective-C I am probably completely wrong about this - just making an observation based on what I read.
Aside from it being a vague idea (not withstanding his spirited defense of his name against his detractors) - he gives me nothing to illustrate how his 'documenation agenda' would be any better than what we currently have. Additionally, he is greatly ignorant of the realities of the systems necessary to make the automated aspects of his idea work - and distressingly it sounds alot like Microsoft's Palladium DRM.
I am all for a simplified documentation system that allows you to keep metadata regarding a document. XML and standards derived from it (Docbook, OpenDocument) fit the bill - and are about as uncomplicated as you can get while retaining that capability. The only thing simpler would be plain text. Of course you would lose any hyperlinking and metadata capability with that.
With XML we have the ability to extend the capabilities of our documents to imbed information - that is extensible for future improvements - and future proof because it is encoded in plain text.
Whatever we want to layer ontop of this is fine - and allows any expression you can think of.
The only part of that he mentioned that makes any sense at all was when he mentioned version control. We already have the tools for that - Subversion or CVS can be integrated in our documentation systems to handle real version control in XML documents.
The paper was not well thought out or delivered - particularly his reference to 'humanists good', 'technologists bad' -- what was that all about?
app space | we could insert something here to solve the problem instead! | desktop manager issue in here | | window manager and/or in here | | inserting somthing here won't solve that problem X
My basic idea was correct - but the details were flawed.
We could insert something between the applications and the window managers that could filter the API calls (a la WINE). While daunting, that bit of software would be no less daunting than trying to get everyone to use one unified window manager/desktop.
All you need is a layer between the X API and the applications. This layer would translate existing X calls to the 'user friendly' mode.
Developers would not have to learn any new tricks, and existing software would be immediately useful - and the tool would be more useful to the end user than trying to get the X window managers and desktops crowd to agree on anything.
Here is the secret to satisfying previous Windows users:
Make one of the installation questions, "Are you a previous MS Windows user?"
If they answer 'Yes' - then load FVWM'95 X window manager - and a set of GUI tools that mimic the underlying Windoze interface to various unix features.
If they answer 'No' - then load whatever X window manager the user wants (such as KDE, Gnome, Enlightenment etc...)
My question is, is this person doing it for that purpose (marketing), out of a misguided belief in what he is actually stating, or as some means to convince himself that he is a worthy human being after all?
I have parts for several 1+ GHZ machines that I am in the process of putting together. They will all run Linux (probably my own flavor of Linux From Scratch)
This leads into my next point: why spend money on a machine that will not provide exactly what you want? Several years ago I decided not to buy retail machines again, opting instead to build any new machine I needed. I put together a P4 2.4 GHZ Intel machine with 512mb Ram, Nvidia GeForce 5600 video with 256mb onboard ram using some existing drives (cdrom, HD) extracted from retired machines - for $550. It had exactly what I wanted and it screams. This motherboard is further upgradable - I can add more and faster RAM, video card, and serial ATA drives when bottlenecks become a problem. If I chose AMD instead, it would have saved even more money.
While doing it yourself might cost more in some respects (time, and sometimes money), if done correctly it extends the useful life of the PC as a front-line workstation or server beyond that of a retail machine, provides build quality you can trust (after all you should trust how you put the machine together), and does not include the Microsoft tax. If you are real frugal (buying used parts instead of the latest technology, for example) you can actually save money and get more machine for the same price.
My goal is a googleplex of processing power in my own beowulf cluster of machines that I have built myself.:)
I work in a cubicle. Nevertheless I love my job for several reasons:
1. I am not part of a software assembly line. I execute architecture, design and implimentation on various projects. I develop test plans and provide automated and manual testing for software I design.
2. I am part of a very small team - and each of us has strengths that compliment the other members, yet we have enough common knowledge not to lose touch with reality when projects get hairy.
3. I am trusted to make decisions regarding tools and training for the team. My advice is often required for projects outside of the scope of my current job because of my experience and knowledge.
How did I get here? The most important things that made a difference is I have never considered myself 'just a programmer'. I will get my hands dirty doing installation, system administration and network administration in a pinch. I also expanded my knowledge base away from just focusing on the programming task to include understanding how to integrate systems on hetrogenous networks. Finally, my work progression in the company took me through technical support, system administration, network engineering before arriving at my current spot; this experience rounded out my knowledge of the issues surrounding the operational side of things (which most developers have not a clue) making me an important asset to the overall organization.
Even before I worked in the field I was always curious about how to make the software development process better - and read everything I could get my hands on; I was an advocate for agile development before such a term existed, and I've built up a personal network in my home that not only serves my family's needs but provides a lab for my own ideas and projects in computer science. I looked at ways of improving efficiency through information technology in every job I've worked. This long love of the field has given me background I needed to accurately judge vendors and our internal IT 'vendor' efforts - to the benefit of the business.
I will admit that cubicles are not the environment most conducive to productivity. Nonetheless I have managed to make it workable by getting a good pair of headphones that allow me to mask the noise when I really need to concentrate. I have come to terms with cubicles because I have been allowed to maintain my employment for over 9 years now, when many others are out on the street looking for work. I would say surviving the dot-com bust is proof enough that my methods are working. Give me another 10 years and I'll tell you if that still holds true in the future.
Finding bugs in software and hardware can be likened to Scientific investigation - where the researcher controls the number and quantity of inputs so as to focus the results on meaningful data - which may or may not lead to a meaningful conclusion, leading the investigator to devine the meaning from incomplete data.
Creating and integrating multiple systems on a large network is also not clear cut, and many times unknowable interactions between various pieces of equipment on a hetrogenous network break calculations.
At a lower level the hardware itself can be used to postulate new techniques and validate the science surrounding semiconductors and other emerging technology involving the interactions of various materials and its application to computer technology.
So I think it is safe to say that, outside of some simple applications, computer science is indeed a science.
Nevertheless we continue to call this 'specification', which implies prior cognizance, when software 'documentation' or something else more descriptive would probably be a better term for what takes place during and after the fact.
The deep seated idea (and driver of software development processes) behind this comes out of early computer limitations. Everything was batch processed in the early days, and you submitted your application to the 'keepers of the beast' who would manage the care and feeding of the mainframe computer. Turn around times were enormous, so the idea of iterative development was not even considered as a possibility. This was the backdrop and driving force behind flowcharting, mathematical rigor in software, and the 'waterfall' lifecycle model that we live with to this day.
Today, with cpu cycles and hardware nearly free, developers can economically perform exploratory development - particularly useful in the case of cutting edge real-time applications - such as operating systems and embedded projects. Sadly, many developers are under the false apprehension that specs must be set in concrete before coding begins.
I think there is some confusion between the idea of 'software specifications' and 'standard interface specifications'. One may referenct the other, but they are not the same.
Software specifications define functional, design and sometimes implimentation details, and in my experience never survive implimentation simply because the developer can never anticipate every obstacle that reality throws at it. Thus the software specification quickly is changed, after the fact, to represent what was implimented. It lags behind reality and serves only to document what *was* done, rather than driving the development.
Standard interface specifications (APIs, and other standards such as POSIX) serve as agreements between many different players about how a particular interface should work to provide interoperability between all users of the standard. If you want to foster interoperability then you follow the standards that are widely accepted. Without standard compliance Linux would not be where it is today.
I read the article and it occurs to me that the confusion between them was at the heart this very issue. This confusion is sadly furthered by the use of the term 'specification' to represent both things - which are clearly different. Implimentation of emergent technology is different than established protocol agreements. Perhaps we should couch our language to make those differences clear when we speak about it.
The LFSS (Linux File System Standard) is the main standard I am really concerned about; if developers and OS distributions would stick to that it would solve a great deal of the problems I see when installing applications.
An ounce of ink is worth a pound of keystrokes. =)
I call shenanigans!! (Where is my broom?)
I'm a verbal person - so I will work out everything in the comments and then follow with a pass that encodes the idea if it is too complicated to work out as I go. I have enough experience to understand various algorithms and data structures - so I might put/* bubble sort */ - so I know I want a bubble sort at that location - perhaps give some more details about what the sort with be working on etc.:P
I've built enough applications that I generally know the basic outline of what I want for most projects before I even begin - in fact I might have some libraries of modules that do most of what I need already - so I would certainly include those items as required. Real programmers are lazy programmers...
So - ink is not required - nor killing large amounts of trees. Most development projects are variations on a theme not requiring you to reinvent the wheel.
Our lawyer prints everything - frigging books and reams of paper. Our damn printer has been rode hard and put up wet so many times it is starting to fail with paper jams more and more often. Build your ERDs, drawings, pseudocode and what have you on your computer instead. The rain forest, and your coworkers will appreciate it. (No self respecting hack would admit using so much paper, even if he did - I get the feeling you folks are all throwbacks to the card-walloper days and don't feel comfortable unless you have sawdust in your hair).:)
If money was not an option the following would be my dream set-up:
1. Office with a door. I don't know how many hours I have lost over the years through interruptions, and task switching - but it has to be a good 30% of my time. Designers should not be in cubes. Door should have a 'do not disturb' sign with a clock that says, 'available at:' --- might get fancy with it and provide an electronic digital display of the 'available at' time - coupled with electronic door locks that prevent opening it from the outside (maybe even from the inside too).
2. Small computer lab off of the office - containing racks:
a) Small Beowulf cluster for automated number crunching as needed (I have an idea about implimenting an optimizing C compiler via such a cluster for fast builds - among other uses). Ten nodes composed of fast 64 bit quad cpu machines - maxxed out on RAM, interconnected via fibre ring, running linux would suffice. b) Development Server (for web application development) fully loaded running linux, zope, apache, squid, etc... c) Examples of various client and server architectures (for testing client - server/web apps) - most of these would be 'average' machines, up to several years old so I can estimate what performance a typical customer can expect. I would have one set up as a remote RDBMS machine for testing that. d) Scratch Monkey (machine for doing initial system builds, OS level futzing, and anything else that could be dangerous - duplicate of the development server) e) CVS Server (Concurrent Version System server - or Subversion if that is your cup-o-tea) -- contains all previous and current software versions. This machine is backed-up off site for disaster recovery. f) Network connectivity - including examples of various network components I can expect my applications to have to deal with (firewalls, routers, switches etc). Ideally I would like to be able to duplicate any client's network set-up. Cisco 6500s on down should do... g) Large Pipe to the internet (Syncronous(sic) DSL - 1.4mb/sec both ways minimal - since money is not an issue, OC48 would do nicely). h) Power Supply(s) to provide power for all this (rectifier for DC power. backup generator - never know when you'll need to hack during a power outage, etc).
In office:
3. Top of the line AMD workstation with Gigs of Ram, the fastest processor they make, the best sound and graphics cards available, IBM Selectric style split keyboard (anti-carpel-tunnel), set of Bose computer speakers (two input, volume/mix controls). Depending on the software being developed I might want additional controllers - Saitek X45 joystick/throttle combo, robotics, etc... What type of development I am doing will determine additional requirements.
4. Panasonic Toughbook laptop running Linux for remote operations and monitoring. I would get the version with the handle and it would accompany me everywhere.
5. Very large HDTV/LCD screen - I need enough real estate to open up 10 letter size windows concurrently...or I am not happy. You don't want to see me unhappy.
6. Mobi KVM to provide console access to all of the above.
7. Kitchenette - small stove, microwave, sink, and Refrigerator for key beverages and snacks.
That would pretty much do it -- I could see the lab being shared with other developers...but ideally I would own my own development shop and employ a remote cadre of FOSS developers. I would upgrade/add equipment beyond what is listed here as needed to meet the needs of the projects.
My recollection is that we knew it would be polarized: either choice would have a large % of people that wanted us to go the other way. Some decisions are like that.
Why do these decisions have to be either, or?
Instead we should make them easily configurable by the user.
For extensions that are already well-established someone could write another extension to manage downloading and installing them as part of the options menu (if that is possible).
Slashdot Mirror
I guess I should have been more specific about the games I play -- mostly FPS, MMOGS and Flight Simulations --- all of which are very configurable - and becoming more so as titles are upgraded, and new titles are released.
WWIIonline, (combination flight simulator and FPS) for example, allows all the controls to be remapped - mouse, joystick and keyboard. Most joysticks now come with software that not only allows remapping, but also macro development - for another layer of configurability.
World of Warcraft not only allows for control remapping and macros, but also has a rich interface for the development of 3rd party interfaces.
From my point of view, GUI usability must be tied to configurability for productivity software in a similar manner. We have only scratched the surface on what is possible, and the more possibilities are investigated by the end users, the better the results will be.
I see where you are coming from, but have two options that would solve that:
1. Infinite 'undo' and 'redo' functionality for the interface. The user could undo and/or redo until he finds where he made the mistake and go from there. If the configuration file was flat text (xml) it could even be saved in a version control system, so you could attach other meta-data to your versions (like 'version number', 'note', 'version name' etc...all nicely hidden from the user other than through the modification interface - unless he was geeky enough to mess with the file manually). With version control and 'releases' multiple configuration states could be maintained by name - and selected by the user with minimal issues.
2. A easily accessible 'default' button that puts everything back to the 'vanilla' version as found when first installed out-of-the-box (undoable, as in #1 above, of course).
Most users will have one or two interface 'states' that they like and use, while power users and geeks may have many. Again, everyone is happy who wants to be happy.
One perfect user interface paradigm is not achieveable(sic) because people are all different.
I see better user interfaces in pc games than I do in other software. This is primarily because game designers realized years ago that everyone has their own prefered way of interacting with the input interfaces. This led to the ability for the end user to modify the input options (such as a keyboard mapper and joystick macros).
A better approach for all software would be to build an infinitely modifiable interface - both for visualization and input. Tie the configurations to some standard, like XML. The company would have a 'standard' config file, and users and others would be able to create and share their own interpretations of what is 'best'. Everyone is (or I should say 'has the option of being') happy. If you are not an XML hack - a GUI could be easily built to make the modifications easier.
Most applications do not approach this level of configurability.
KDE is available under Solaris 10 -- you just have to enable a switch for it to show up as a choice in the X window login.
KDE beats the heck out of CDE...CDE, while functional, is not as snappy as KDE - nor does it have a plethora of open source apps (Kdevelop et al) that make KDE the premier development platform in comparison IMHO.
I think the point he is trying to make (after RTFL - the relevant link) is that while you can impliment equivalent functionality in any language, you will take a performance hit because other languages are not optimized to handle some of the items he mentions (class indexing etc...)
That is a tenuous argument at best; nonetheless without knowing the OpenStep standard there might be some validity to it - particularly if the standard specifies such functionality as is native to Objective-C.
Having never used Objective-C I am probably completely wrong about this - just making an observation based on what I read.
Afterstep runs under Linux -- a cousin of OpenStep...
The W3C has already defined how to handle versioning (among other things) via OWL.
Future systems can be built using XML/OWL - in place of the plethora of proprietary systems currently in use.
Why are you waiting? Xanadu is here!
Aside from it being a vague idea (not withstanding his spirited defense of his name against his detractors) - he gives me nothing to illustrate how his 'documenation agenda' would be any better than what we currently have. Additionally, he is greatly ignorant of the realities of the systems necessary to make the automated aspects of his idea work - and distressingly it sounds alot like Microsoft's Palladium DRM.
I am all for a simplified documentation system that allows you to keep metadata regarding a document. XML and standards derived from it (Docbook, OpenDocument) fit the bill - and are about as uncomplicated as you can get while retaining that capability. The only thing simpler would be plain text. Of course you would lose any hyperlinking and metadata capability with that.
With XML we have the ability to extend the capabilities of our documents to imbed information - that is extensible for future improvements - and future proof because it is encoded in plain text.
Whatever we want to layer ontop of this is fine - and allows any expression you can think of.
The only part of that he mentioned that makes any sense at all was when he mentioned version control. We already have the tools for that - Subversion or CVS can be integrated in our documentation systems to handle real version control in XML documents.
The paper was not well thought out or delivered - particularly his reference to 'humanists good', 'technologists bad' -- what was that all about?
Correction: ...some logical flaws there:
app space
| we could insert something here to solve the problem instead!
|
desktop manager issue in here
|
|
window manager and/or in here
|
| inserting somthing here won't solve that problem
X
My basic idea was correct - but the details were flawed.
We could insert something between the applications and the window managers that could filter the API calls (a la WINE). While daunting, that bit of software would be no less daunting than trying to get everyone to use one unified window manager/desktop.
All you need is a layer between the X API and the applications. This layer would translate existing X calls to the 'user friendly' mode.
Developers would not have to learn any new tricks, and existing software would be immediately useful - and the tool would be more useful to the end user than trying to get the X window managers and desktops crowd to agree on anything.
Here is the secret to satisfying previous Windows users:
Make one of the installation questions, "Are you a previous MS Windows user?"
If they answer 'Yes' - then load FVWM'95 X window manager - and a set of GUI tools that mimic the underlying Windoze interface to various unix features.
If they answer 'No' - then load whatever X window manager the user wants (such as KDE, Gnome, Enlightenment etc...)
My question is, is this person doing it for that purpose (marketing), out of a misguided belief in what he is actually stating, or as some means to convince himself that he is a worthy human being after all?
I have parts for several 1+ GHZ machines that I am in the process of putting together. They will all run Linux (probably my own flavor of Linux From Scratch)
:)
This leads into my next point: why spend money on a machine that will not provide exactly what you want? Several years ago I decided not to buy retail machines again, opting instead to build any new machine I needed. I put together a P4 2.4 GHZ Intel machine with 512mb Ram, Nvidia GeForce 5600 video with 256mb onboard ram using some existing drives (cdrom, HD) extracted from retired machines - for $550. It had exactly what I wanted and it screams. This motherboard is further upgradable - I can add more and faster RAM, video card, and serial ATA drives when bottlenecks become a problem. If I chose AMD instead, it would have saved even more money.
While doing it yourself might cost more in some respects (time, and sometimes money), if done correctly it extends the useful life of the PC as a front-line workstation or server beyond that of a retail machine, provides build quality you can trust (after all you should trust how you put the machine together), and does not include the Microsoft tax. If you are real frugal (buying used parts instead of the latest technology, for example) you can actually save money and get more machine for the same price.
My goal is a googleplex of processing power in my own beowulf cluster of machines that I have built myself.
I work in a cubicle. Nevertheless I love my job for several reasons:
1. I am not part of a software assembly line. I execute architecture, design and implimentation on various projects. I develop test plans and provide automated and manual testing for software I design.
2. I am part of a very small team - and each of us has strengths that compliment the other members, yet we have enough common knowledge not to lose touch with reality when projects get hairy.
3. I am trusted to make decisions regarding tools and training for the team. My advice is often required for projects outside of the scope of my current job because of my experience and knowledge.
How did I get here? The most important things that made a difference is I have never considered myself 'just a programmer'. I will get my hands dirty doing installation, system administration and network administration in a pinch. I also expanded my knowledge base away from just focusing on the programming task to include understanding how to integrate systems on hetrogenous networks. Finally, my work progression in the company took me through technical support, system administration, network engineering before arriving at my current spot; this experience rounded out my knowledge of the issues surrounding the operational side of things (which most developers have not a clue) making me an important asset to the overall organization.
Even before I worked in the field I was always curious about how to make the software development process better - and read everything I could get my hands on; I was an advocate for agile development before such a term existed, and I've built up a personal network in my home that not only serves my family's needs but provides a lab for my own ideas and projects in computer science. I looked at ways of improving efficiency through information technology in every job I've worked. This long love of the field has given me background I needed to accurately judge vendors and our internal IT 'vendor' efforts - to the benefit of the business.
I will admit that cubicles are not the environment most conducive to productivity. Nonetheless I have managed to make it workable by getting a good pair of headphones that allow me to mask the noise when I really need to concentrate. I have come to terms with cubicles because I have been allowed to maintain my employment for over 9 years now, when many others are out on the street looking for work. I would say surviving the dot-com bust is proof enough that my methods are working. Give me another 10 years and I'll tell you if that still holds true in the future.
Obviously you have not worked with production computer arrays and software where 'deductive and rational' does not necessarily apply.
Finding bugs in software and hardware can be likened to Scientific investigation - where the researcher controls the number and quantity of inputs so as to focus the results on meaningful data - which may or may not lead to a meaningful conclusion, leading the investigator to devine the meaning from incomplete data.
Creating and integrating multiple systems on a large network is also not clear cut, and many times unknowable interactions between various pieces of equipment on a hetrogenous network break calculations.
At a lower level the hardware itself can be used to postulate new techniques and validate the science surrounding semiconductors and other emerging technology involving the interactions of various materials and its application to computer technology.
So I think it is safe to say that, outside of some simple applications, computer science is indeed a science.
In my experience, as well.
Nevertheless we continue to call this 'specification', which implies prior cognizance, when software 'documentation' or something else more descriptive would probably be a better term for what takes place during and after the fact.
The deep seated idea (and driver of software development processes) behind this comes out of early computer limitations. Everything was batch processed in the early days, and you submitted your application to the 'keepers of the beast' who would manage the care and feeding of the mainframe computer. Turn around times were enormous, so the idea of iterative development was not even considered as a possibility. This was the backdrop and driving force behind flowcharting, mathematical rigor in software, and the 'waterfall' lifecycle model that we live with to this day.
Today, with cpu cycles and hardware nearly free, developers can economically perform exploratory development - particularly useful in the case of cutting edge real-time applications - such as operating systems and embedded projects. Sadly, many developers are under the false apprehension that specs must be set in concrete before coding begins.
I think there is some confusion between the idea of 'software specifications' and 'standard interface specifications'. One may referenct the other, but they are not the same.
Software specifications define functional, design and sometimes implimentation details, and in my experience never survive implimentation simply because the developer can never anticipate every obstacle that reality throws at it. Thus the software specification quickly is changed, after the fact, to represent what was implimented. It lags behind reality and serves only to document what *was* done, rather than driving the development.
Standard interface specifications (APIs, and other standards such as POSIX) serve as agreements between many different players about how a particular interface should work to provide interoperability between all users of the standard. If you want to foster interoperability then you follow the standards that are widely accepted. Without standard compliance Linux would not be where it is today.
I read the article and it occurs to me that the confusion between them was at the heart this very issue. This confusion is sadly furthered by the use of the term 'specification' to represent both things - which are clearly different. Implimentation of emergent technology is different than established protocol agreements. Perhaps we should couch our language to make those differences clear when we speak about it.
Correction: "LFSS (Linux File System Standard)" should read: "FSH (File System Hierarchy)" - the same sentiments apply.
The LFSS (Linux File System Standard) is the main standard I am really concerned about; if developers and OS distributions would stick to that it would solve a great deal of the problems I see when installing applications.
The LSB is overrated imho.
An ounce of ink is worth a pound of keystrokes. =)
/* bubble sort */ - so I know I want a bubble sort at that location - perhaps give some more details about what the sort with be working on etc. :P
:)
I call shenanigans!! (Where is my broom?)
I'm a verbal person - so I will work out everything in the comments and then follow with a pass that encodes the idea if it is too complicated to work out as I go. I have enough experience to understand various algorithms and data structures - so I might put
I've built enough applications that I generally know the basic outline of what I want for most projects before I even begin - in fact I might have some libraries of modules that do most of what I need already - so I would certainly include those items as required. Real programmers are lazy programmers...
So - ink is not required - nor killing large amounts of trees. Most development projects are variations on a theme not requiring you to reinvent the wheel.
Our lawyer prints everything - frigging books and reams of paper. Our damn printer has been rode hard and put up wet so many times it is starting to fail with paper jams more and more often. Build your ERDs, drawings, pseudocode and what have you on your computer instead. The rain forest, and your coworkers will appreciate it. (No self respecting hack would admit using so much paper, even if he did - I get the feeling you folks are all throwbacks to the card-walloper days and don't feel comfortable unless you have sawdust in your hair).
If money was not an option the following would be my dream set-up:
1. Office with a door. I don't know how many hours I have lost over the years through interruptions, and task switching - but it has to be a good 30% of my time. Designers should not be in cubes. Door should have a 'do not disturb' sign with a clock that says, 'available at:' --- might get fancy with it and provide an electronic digital display of the 'available at' time - coupled with electronic door locks that prevent opening it from the outside (maybe even from the inside too).
2. Small computer lab off of the office - containing racks:
a) Small Beowulf cluster for automated number crunching as needed (I have an idea about implimenting an optimizing C compiler via such a cluster for fast builds - among other uses). Ten nodes composed of fast 64 bit quad cpu machines - maxxed out on RAM, interconnected via fibre ring, running linux would suffice.
b) Development Server (for web application development) fully loaded running linux, zope, apache, squid, etc...
c) Examples of various client and server architectures (for testing client - server/web apps) - most of these would be 'average' machines, up to several years old so I can estimate what performance a typical customer can expect. I would have one set up as a remote RDBMS machine for testing that.
d) Scratch Monkey (machine for doing initial system builds, OS level futzing, and anything else that could be dangerous - duplicate of the development server)
e) CVS Server (Concurrent Version System server - or Subversion if that is your cup-o-tea) -- contains all previous and current software versions. This machine is backed-up off site for disaster recovery.
f) Network connectivity - including examples of various network components I can expect my applications to have to deal with (firewalls, routers, switches etc). Ideally I would like to be able to duplicate any client's network set-up. Cisco 6500s on down should do...
g) Large Pipe to the internet (Syncronous(sic) DSL - 1.4mb/sec both ways minimal - since money is not an issue, OC48 would do nicely).
h) Power Supply(s) to provide power for all this (rectifier for DC power. backup generator - never know when you'll need to hack during a power outage, etc).
In office:
3. Top of the line AMD workstation with Gigs of Ram, the fastest processor they make, the best sound and graphics cards available, IBM Selectric style split keyboard (anti-carpel-tunnel), set of Bose computer speakers (two input, volume/mix controls). Depending on the software being developed I might want additional controllers - Saitek X45 joystick/throttle combo, robotics, etc... What type of development I am doing will determine additional requirements.
4. Panasonic Toughbook laptop running Linux for remote operations and monitoring. I would get the version with the handle and it would accompany me everywhere.
5. Very large HDTV/LCD screen - I need enough real estate to open up 10 letter size windows concurrently...or I am not happy. You don't want to see me unhappy.
6. Mobi KVM to provide console access to all of the above.
7. Kitchenette - small stove, microwave, sink, and Refrigerator for key beverages and snacks.
That would pretty much do it -- I could see the lab being shared with other developers...but ideally I would own my own development shop and employ a remote cadre of FOSS developers. I would upgrade/add equipment beyond what is listed here as needed to meet the needs of the projects.
Great point; have your cake and eat it too.
That is still not 'either, or' as the original author implied.
From the article:
My recollection is that we knew it would be polarized: either choice would have a large % of people that wanted us to go the other way. Some decisions are like that.
Why do these decisions have to be either, or?
Instead we should make them easily configurable by the user.
For extensions that are already well-established someone could write another extension to manage downloading and installing them as part of the options menu (if that is possible).
PurePwnage has a documentary of the new 'pro gamers' - pwning noobs, and getting headshots online near you....