The cp command doesn't allow for the arbitrary point-and-shoot selection of files to copy, and it also doesn't have some of the more useful related functionality (e.g., directory comparison) that I use all the time in mc.
It's an *addition* to the standard admin toolset, not a replacement. IMO.
Midnight Commander is one of the tools that I could live without, but I sure wouldn't want to. I use it all over the place... on the Solaris servers and my Windows XP workstation here at work, on my Linux, OS/2, and Windows boxes at home, on my Nokia 770 tablet, etc.
It makes it easier to delete files and directory trees with certainty (and accuracy!), the built-in editor is good enough for modifying shell scripts and even making moderate code changes to more involved programs, its built-in FTP capability is invaluable when one has to flip a lot of files or directories between hosts, and its customizable menus and panelization capabilities can add some fairly powerful capabilities to even the most dedicated command-line user.
Don't know how it works at the there companies mentioned in the header, but it's been my experience that layoffs at many companies are based on seniority, not job performance. The jumior people tend to get the axe.
Sometimes those people are the weakest link, but sometimes they aren't.
I've been subjected to Windows and its idiosyncrasies for over 20 years now (started with Windows/286 2.1 back in 1988), and much of my opinion of Windows has been colored by its inability to keep up with its current competition, be it PC/GEOS, MacOS, OS/2, or Linux.
If Microsoft wants to gain respect in certain circles, it needs to write good code.
While it's true that the US's energy consumption per capita is through the roof, keep in mind that much of the US lives in an environment where a certain amount of energy consumption is almost a hard requirement in order to live with any semblance of comfort, at least in wintertime. The alternative to electricity/oil/gas would be wood or coal.
Folks living near the equator (which is a LOT of the world's population) don't generally have that requirement.
Even here in the Atlanta area, we'll be seeing temperatures in the teens Fahrenheit this week.:-)
Waterfall can work fairly well in a large software development environment with strictly defined and relatively lengthy release cycles. We used it when I worked at the Unisys Airline Development/Support Center for the large USAS products sold to airlines (development cycle roughly 12-18 months between versions), and it worked just fine.
The end result was a good software application with a fairly low number of defects, and this with a customer base that was willing to pay enough for their own copies of the source code. If there were major issues, they would have found them!
However, I think shorter cycles and a different mindset are required if you have to write software in-house and deal with the real-world requirements of end users. Sometimes shifts in functionality or project requirements are driven by factors outside of both you and your end users (changing federal regulations, changes in another system you interface with, etc.), and that requires a flexible mindset not usually found in a pure waterfall environment. And sometimes large changes have to be designed, implemented, and tested very quickly.
I've see it done well. It requires skilled and experienced people, usually.
Heck, C wasn't even taught when I was in college (1981-1987) because we used PCs, UNIVAC 1100's, and VAXen in school rather than UNIX boxes, and I'd written code in several BASIC variants, several assemblers, Pascal, PL/1, FORTRAN, COBOL, SNOBOL, SSG, and Forth before I ever saw a line of C code.:-)
If you perform certain types of validation on a routine basis, write a set of common routines to do the work, and reuse them over and over again. Standardize your code. Define standard buffer names, sizes and buffer attributes, and make sure that anyone working on that code is acutely aware of the standards which are already in place.
Reject code that doesn't follow the standard. Even if it works otherwise.
Modular coding isn't rocket science, and one can be very structured and modular in any language. No OO needed. We had an extensive library of common routines, common buffers, etc. back when I wrote Fortran 66 and 77 code at my last major place of employment, and we have the exact same thing here on both the C and Fortran sides of life.
Microsoft's monolithic products (and its traditionally slow production cycles and bug response times) don't seem to reflect the same types of results that are seen from the use of "agile" practices used in other commercial software operations and in various open source projects.
My own guess is that it isn't the fault of the developers, but rather lengthy processes at both ends which at least partially remove some of the advantages of agile development.
It's too bad that those with a clue in your company don't have more say into the design, marketing, and maintaining of the products bearing your company's label.
The steps of analyzing, planning, coding, testing, and maintaining are used in all types of software development, not just those using formalized waterfall methodologies. You just do it in smaller steps if you're using a more agile development methodology in an in-house development environment.
Agile developers aren't idiots. They just tend to release finished software on the module level rather than as an entire cohesive product.
Interviewers are relatively easy to deal with -- it's been my experience, however, that the hard part is getting to the point where you're actually talking to a person (HR, interviewer, whatever) in the first place.
Many companies receive hundreds if not thousands of applications for each position, and the filtering that is done in front of the interview process is not always predictable by those on the outside.
If you can tailor your resume to pass those filters, however, that will go a long way to help you get to the "interview" part of the process.
Seriously. People will tend to respond a lot better to you if they feel that they have legitimate input into the process, and many of those folks might be able to provide ideas and experience that you can benefit directly from.
Of course, I'm speaking as a 46-year-old programmer who's been doing software design/development for 20 years, so my bias is from the other side. Then again, most of the folks I tend to deal with are at my experience level or higher so in many cases *I* tend to be the youngster with the radical ideas. But I've learned to defer to my elders in many cases even tho I disagree. Sometimes they actually turn out to be right!;-)
I agree about modern RTS's, which I can't even play online. I prefer playing them offline where I can play at my own pace.
That's why I love playing Spring -- you can pause a single-player game against AIs in midstream, spend several minutes scanning the map from all angles and queueing up orders, and then let it fly again.
Not only does it slow the pace down, but it helps to negate some of the reaction speed advantage that the AI players have. You can stop at any point and analyze the situation in great detail.:-)
Both Spring (and the game which inspired it, Total Annihilation) allow for enough automation and order queueing even in real-time to remove some of the micromanagement from the game. Makes the game a lot less hectic to run than most RTS games I've played -- it's nice to have units which already have orders to patrol a certain route, attack anything within range, and repair themselves automagically w/o my intervention, and they can be set up to do all of the above as part of a repeating build queue.
What does a BSCS have to do with managing people? That's a social skill, not a technical one.
CompSci programs vary greatly from school to school, and have also varied quite a bit over time.
When I got my BSCS in the mid 1980's, the program I was in at Mankato State University covered a few high-level languages plus an assembler, hardware logic, structured programming, data structures, programming language theory, compiler design, language interfaces, operating system design, system analysis and design, team programming (we did a team project in four-person teams), and a few other things. A lot of it was introductory material, not terribly in-depth, but enough to cover the basics in case someone had an interest in going further.
Any process which gets the job done so the software runs well and the defects which impact the end user experience are minimized is a good process. Sometimes that process is highly formalized, sometimes not. Sometimes the process is something which an organization simply made up from common sense and experience. It doesn't matter.
Programmers shouldn't have to worry about special keywords... let the compilers worry about that stuff.:-)
Of course, many techniques which have been around for the past 40 years are also obvious to anyone skilled in the art of programming, and the patent office has fallen down so many times on that count that I'm not sure publishing means all that much either...
It's obviously possible. Linus does this with the Linux trademark, and there don't seem to be any downstream limitations. There are all sorts of free and non-free entities... including Debian... that are able to use the Linux trademark without legal repercussions.
So, to ask the obvious question... Why doesn't the Mozilla group handle the Mozilla trademark in the same way that Linus does with the Linux trademark?
I've had access to millions of LOC over the years that I couldn't legally release as proof of prior art without getting corporate legal involved, and that's usually not a trivial undertaking.
I'm not sure $50k is worth potentially trashing a career.
There are hundreds if not thousands of companies out there that have written software in-house for decades, and I'm guessing most are in the same boat.
given that high school drop-outs are about 50/50 male and female... why are SO many of the minimum wage jobs staffed by women, and the male drop outs move up the ladder to better paying jobs (or start out in better paying jobs right off the bat).
I suspect many of the male drop-outs are actually in prison, at least in the US.
If I, as a developer, spend several years developing WidgetDesigner, and then I sell a copy of WidgetDesigner to you for $50, is it fair to me if you go and give every other person in the world a copy of my software at no charge?
That question cannot be answered without more information.
Under which license did you release the software?
If you released it under the GPL, then the above action would be reasonable... and expected.
If you released it under some other license, then the above may or may not be reasonable depending on the terms of that license. There isn't enough information in your comment to make that determination.:-)
Regardless, I'm assuming that you're smart enough to not release your software under a license that you don't actually agree with. If you aren't, perhaps you shouldn't be trying to make a living writing and selling software...
I can't sell any other copies, because everyone already has a free copy - I will have then earned $50 for several man-years of work.
The problem with the situation you describe isn't the license involved, the problem is your choice in using an inappropriate license for your software.
If you want to restrict the distribution of your software, use a license which restricts its distribution.
Seems like a simple solution to me.
Whining about a license that you HAVE TO CHOOSE TO USE as a developer seems like a pointless exercise to me.
Slashdot Mirror
The cp command doesn't allow for the arbitrary point-and-shoot selection of files to copy, and it also doesn't have some of the more useful related functionality (e.g., directory comparison) that I use all the time in mc.
It's an *addition* to the standard admin toolset, not a replacement. IMO.
Midnight Commander is one of the tools that I could live without, but I sure wouldn't want to. I use it all over the place ... on the Solaris servers and my Windows XP workstation here at work, on my Linux, OS/2, and Windows boxes at home, on my Nokia 770 tablet, etc.
It makes it easier to delete files and directory trees with certainty (and accuracy!), the built-in editor is good enough for modifying shell scripts and even making moderate code changes to more involved programs, its built-in FTP capability is invaluable when one has to flip a lot of files or directories between hosts, and its customizable menus and panelization capabilities can add some fairly powerful capabilities to even the most dedicated command-line user.
I love my Midnight Commander! :-)
Don't know how it works at the there companies mentioned in the header, but it's been my experience that layoffs at many companies are based on seniority, not job performance. The jumior people tend to get the axe.
Sometimes those people are the weakest link, but sometimes they aren't.
I've been subjected to Windows and its idiosyncrasies for over 20 years now (started with Windows/286 2.1 back in 1988), and much of my opinion of Windows has been colored by its inability to keep up with its current competition, be it PC/GEOS, MacOS, OS/2, or Linux.
If Microsoft wants to gain respect in certain circles, it needs to write good code.
It's that simple.
While it's true that the US's energy consumption per capita is through the roof, keep in mind that much of the US lives in an environment where a certain amount of energy consumption is almost a hard requirement in order to live with any semblance of comfort, at least in wintertime. The alternative to electricity/oil/gas would be wood or coal.
Folks living near the equator (which is a LOT of the world's population) don't generally have that requirement.
Even here in the Atlanta area, we'll be seeing temperatures in the teens Fahrenheit this week. :-)
Waterfall can work fairly well in a large software development environment with strictly defined and relatively lengthy release cycles. We used it when I worked at the Unisys Airline Development/Support Center for the large USAS products sold to airlines (development cycle roughly 12-18 months between versions), and it worked just fine.
The end result was a good software application with a fairly low number of defects, and this with a customer base that was willing to pay enough for their own copies of the source code. If there were major issues, they would have found them!
However, I think shorter cycles and a different mindset are required if you have to write software in-house and deal with the real-world requirements of end users. Sometimes shifts in functionality or project requirements are driven by factors outside of both you and your end users (changing federal regulations, changes in another system you interface with, etc.), and that requires a flexible mindset not usually found in a pure waterfall environment. And sometimes large changes have to be designed, implemented, and tested very quickly.
I've see it done well. It requires skilled and experienced people, usually.
Heck, C wasn't even taught when I was in college (1981-1987) because we used PCs, UNIVAC 1100's, and VAXen in school rather than UNIX boxes, and I'd written code in several BASIC variants, several assemblers, Pascal, PL/1, FORTRAN, COBOL, SNOBOL, SSG, and Forth before I ever saw a line of C code. :-)
If you perform certain types of validation on a routine basis, write a set of common routines to do the work, and reuse them over and over again. Standardize your code. Define standard buffer names, sizes and buffer attributes, and make sure that anyone working on that code is acutely aware of the standards which are already in place.
Reject code that doesn't follow the standard. Even if it works otherwise.
Modular coding isn't rocket science, and one can be very structured and modular in any language. No OO needed. We had an extensive library of common routines, common buffers, etc. back when I wrote Fortran 66 and 77 code at my last major place of employment, and we have the exact same thing here on both the C and Fortran sides of life.
Microsoft's monolithic products (and its traditionally slow production cycles and bug response times) don't seem to reflect the same types of results that are seen from the use of "agile" practices used in other commercial software operations and in various open source projects.
My own guess is that it isn't the fault of the developers, but rather lengthy processes at both ends which at least partially remove some of the advantages of agile development.
It's too bad that those with a clue in your company don't have more say into the design, marketing, and maintaining of the products bearing your company's label.
The steps of analyzing, planning, coding, testing, and maintaining are used in all types of software development, not just those using formalized waterfall methodologies. You just do it in smaller steps if you're using a more agile development methodology in an in-house development environment.
Agile developers aren't idiots. They just tend to release finished software on the module level rather than as an entire cohesive product.
Interviewers are relatively easy to deal with -- it's been my experience, however, that the hard part is getting to the point where you're actually talking to a person (HR, interviewer, whatever) in the first place.
Many companies receive hundreds if not thousands of applications for each position, and the filtering that is done in front of the interview process is not always predictable by those on the outside.
If you can tailor your resume to pass those filters, however, that will go a long way to help you get to the "interview" part of the process.
Last time I was driving in England/Scotland/Wales, *ALL* of the road signs were show distances and speed limits in miles and MPH.
Web sites like these seem to indicate that nothing has changed in that regard.
In other words, the UK is hardly a good example of a country which has converted to metric measures. Perhaps Canada would be a better choice?
Not if those CD-R blanks are explicitly labeled for Music use.
In that case, part of the profits *does* in fact go to the music industry.
Seriously. People will tend to respond a lot better to you if they feel that they have legitimate input into the process, and many of those folks might be able to provide ideas and experience that you can benefit directly from.
Of course, I'm speaking as a 46-year-old programmer who's been doing software design/development for 20 years, so my bias is from the other side. Then again, most of the folks I tend to deal with are at my experience level or higher so in many cases *I* tend to be the youngster with the radical ideas. But I've learned to defer to my elders in many cases even tho I disagree. Sometimes they actually turn out to be right! ;-)
That's why I love playing Spring -- you can pause a single-player game against AIs in midstream, spend several minutes scanning the map from all angles and queueing up orders, and then let it fly again.
Not only does it slow the pace down, but it helps to negate some of the reaction speed advantage that the AI players have. You can stop at any point and analyze the situation in great detail. :-)
Both Spring (and the game which inspired it, Total Annihilation) allow for enough automation and order queueing even in real-time to remove some of the micromanagement from the game. Makes the game a lot less hectic to run than most RTS games I've played -- it's nice to have units which already have orders to patrol a certain route, attack anything within range, and repair themselves automagically w/o my intervention, and they can be set up to do all of the above as part of a repeating build queue.
Quiz is here...
What does a BSCS have to do with managing people? That's a social skill, not a technical one.
CompSci programs vary greatly from school to school, and have also varied quite a bit over time.
When I got my BSCS in the mid 1980's, the program I was in at Mankato State University covered a few high-level languages plus an assembler, hardware logic, structured programming, data structures, programming language theory, compiler design, language interfaces, operating system design, system analysis and design, team programming (we did a team project in four-person teams), and a few other things. A lot of it was introductory material, not terribly in-depth, but enough to cover the basics in case someone had an interest in going further.
Waterfall, agile, who cares?
Any process which gets the job done so the software runs well and the defects which impact the end user experience are minimized is a good process. Sometimes that process is highly formalized, sometimes not. Sometimes the process is something which an organization simply made up from common sense and experience. It doesn't matter.
Programmers shouldn't have to worry about special keywords ... let the compilers worry about that stuff. :-)
I had a really nice Ferarri in NFS3. Does that count? :-)
Yes, I did forget that bit.
Of course, many techniques which have been around for the past 40 years are also obvious to anyone skilled in the art of programming, and the patent office has fallen down so many times on that count that I'm not sure publishing means all that much either...
It's obviously possible. Linus does this with the Linux trademark, and there don't seem to be any downstream limitations. There are all sorts of free and non-free entities ... including Debian ... that are able to use the Linux trademark without legal repercussions.
So, to ask the obvious question... Why doesn't the Mozilla group handle the Mozilla trademark in the same way that Linus does with the Linux trademark?
I've had access to millions of LOC over the years that I couldn't legally release as proof of prior art without getting corporate legal involved, and that's usually not a trivial undertaking.
I'm not sure $50k is worth potentially trashing a career.
There are hundreds if not thousands of companies out there that have written software in-house for decades, and I'm guessing most are in the same boat.
I suspect many of the male drop-outs are actually in prison, at least in the US.
That question cannot be answered without more information.
Under which license did you release the software?
If you released it under the GPL, then the above action would be reasonable ... and expected.
If you released it under some other license, then the above may or may not be reasonable depending on the terms of that license. There isn't enough information in your comment to make that determination. :-)
Regardless, I'm assuming that you're smart enough to not release your software under a license that you don't actually agree with. If you aren't, perhaps you shouldn't be trying to make a living writing and selling software...
The problem with the situation you describe isn't the license involved, the problem is your choice in using an inappropriate license for your software.
If you want to restrict the distribution of your software, use a license which restricts its distribution.
Seems like a simple solution to me.
Whining about a license that you HAVE TO CHOOSE TO USE as a developer seems like a pointless exercise to me.
They could easily have allowed Debian to distribute the code with the trademark. Or was that solution unacceptable to Debian?