I agree. Linux makes a very nice "we-also-run" for Solaris/Oracle shops. Develop with Linux on the desktop, put Linux on continuous/automated build servers, use Linux for smoke and unit testing. Then deploy to test and production Solaris servers running Oracle.
This combination is effective because it allows a development team to explore, and even break stuff, on low-cost but highly capable systems. These systems don't need the "grooming-the-queen" approach of mainframe administration, or the "you-can't-handle-the-root" management of Solaris system administration. Most of the well paid Solaris sysadmins I've encountered have proven to be well worth their pay. That makes it even more important that we concentrate their effort on optimizing and maintaining production systems (storage management, fail-over, system security, OS patches... etc.).
Let the developers worry about bouncing an application server or web server to test a change. Let the developers worry about scripting and scheduling builds. Let the developers figure out how to configure the application and try several different ways of doing it. Let the developers do all of this on Linux.
Sorry for the rant... I'm out of breath now.
The opinions expressed in this post are my own, and not necessarily the opinions of my employer.
American's don't mind if foreign people are arrested...
I'm an American. It bothered me.
If you mean that the media didn't give it the coverage it deserved, I'd agree with that. It's likely, however, that the stories they were allowed to cover did not include ones that weren't in the interests of the parent companies (AOL Time Warner for example).
--
The opinions expressed in this post are my own and not necessarily those of my employer.
A database might help solve some of the technical problems, but in the U.S., at least, the political problems would pose a significantly different challenge.
I'd venture that there are many, many individuals whose interests would not be served by improving the patent system. If I recall correctly, there was a previous post on a similar thread (months ago here on/.) asserting that the patent office was one of the few departments of government (in the U.S.) that regularly turns a profit.
--
The opinions expressed in this posting are my own and do not necessarily reflect the stance or opinions of my employer.
AOL Instant Messenger has fallen prey to the Microsoft-style feature-bloat problem. The client attempts to be a file transfer system, an advertising console... etc. The result is that users are left open to virus attacks. Do you remember a little while back the AIM vulnerability that allowed attackers to execute arbitrary code on the user's PC?
I don't know about you, but I find that ridiculous. All I want out of an IM client is IM and IM chat, not ads, scripting, file transfer and other "features" that open up my system over yet another protocol.
Writing software is not difficult. Writing high-quality software _is_ difficult
and requires experienced craftsmen (infer journalistic gender-neutrality, please).
So how then, can you get high-quality software quickly? Two ways:
Hire experienced experts. Experienced experts produce high-quality work
quickly. They write code
generators to do tedious work for them. They classify problems and hunt
down and implement reusable solutions.
Keep giving them raises and interesting problems. Granted, defects in the
software will be of the extremely intractable variety (very subtle design
flaws or bad/wrong requirements)
Reuse experienced expert knowledge and technique in the form of pattern-driven
code generating tools. Hire journeyman developers to adapt the code the
tool burps out and get on with life. Keep an expert or two around to extend
or correct the patterns the tool uses for generation. You'll get applications
that are far less pretty than the hand-crafted variety. On the other hand,
the defects are known and predicatable. Tools
(apologies for the shameles plug) for this sort
of development are just now becoming available and practical. Granted,
when handed a powerful implement fools often find a way to hurt themselves (thus instantiating the 8th corollary to Murphy's Law).
Either method has drawbacks. #1 produces the best software, #2 produces
the cheapest software. #1 makes the "Agile" crowd happy while #2 is
the sermon of "Software Engineers."
Why single-out developers for defective code? Because developers write defective
code. No, all developers aren't clods with text editors. Developers who do write
buggy code may even care about their craft (Pragmatic Programmer tip #1). But
developers themselves are to blame for the defects in their work, even though
outside factors contribute to problems. We must take responsibilty for our bugs,
move on and fix them. Then find new ways
of working that make it more difficult for software defects to make it into
production evironments.
We cannot fix imperfect programmers. We can only mitigate
the effects of their imperfection through mentoring, certification, education,
and proper management. In other words, treat software development as a craft,
a talent to be polished and perfected.
Writing software well means communicating well with a computer. Artful written
communication is very difficult to reduce to an engineering discipline, yet the skill can be taught and practiced.
Right, we all know how effective parental warning labels are on music, or how effective the Surgeon General's warnings are on cigarettes.
You're right that they shouldn't be allowed to use the CD-quality label, but they should also pay damages to consumers who bought damaged goods. Don't accept a simple hand-slap and a promise from them that they'll be good from now on. These organizations are all about their bottom line. Affect it, and they'll listen.
Relatively current records
show a trend of rising carbon dioxide levels. Geological trends
paint a more worrisome picture. Going back several hundred thousand years, periods
of major glaciation (that's an ice age to you ACs out there) were preceded by
measureable increases in atmospheric carbon dioxide.
It turns out the Earth reacts to high levels of CO2 in the atmosphere first
by heating up (the so-called greenhouse effect). Higher air temperatures aren't
interesting, what's interesting is what happens when higher water temperatures
alter the flow of the oceans' currents. You see, the oceans have an enormous
mechanism for exchanging carbon dioxide for oxygen. Ocean currents flow away
from the equator, warm water on the surface. As the water nears cooler climates
near the poles, it cools and surface content sinks, including carbon dioxide
in solution. That carbon dioxide becomes rich food for underwater vegetation,
which of course produce oxygen. The water heats up (due to thermal vents in
the ocean floor, for example) and rises, releasing oxygen.
Things get nasty when this falls out of balance, however. When water is warmer,
it stays on the surface longer, traveling further north, or further south, encroaching
on the poles. Eventually, this warm surface water starts to melt off ice at
the poles. Not all of the ice melts, some of it begins to migrate. This starts
to happen at an increasing rate. Now colder and colder water (and thus colder
air temps. and precipitation) make their way toward the poles. Major glaciation,
or, an ice age.
OK, that's nice, you say. But so what, there've been ice ages before. Pollution
being a factor in this vast mechanism is all B.S. right?
Well... If you follow that second link, you'll see that studies, right here
on Earth, show that atmospheric carbon dioxide levels are significantly higher
than they've been in the last 420,000 years. Do a Google search and you'll find
studies showing that this peak begins it's upward curve beyond the median back
in the 1700s.
I used Macs throughout high school. I would've bought one for myself, even, but I ended up with an IBM XT clone for a very simple reason: back then, Macs cost too freaking much.
Linux doesn't face that same problem. It's essentially free and runs on cheap hardware. When they grow up, they'll be able to pay for a bundled distribution...
They could even make a college preparatory class out of the experience: Installing Debian 201...
While I tend to agree with your conclusion that actual Web Services (in their current formulation) are mostly a fad, I disagree with your suggestion that standardization yields weak security.
Obscure security can only secure the trivial. Lots of eyeballs checking and auditing the code, beating on it ruthlessly, does work. (That's a slight misquote Linus' Law of Debugging from "The Cathedral and the Bazaar") Witness Linux or *BSD.
Message-driven, discovery-based APIs for applications will be a good thing. For one thing, the actual APIs would fall more in line with O-O practice, where you classify objects by the messages they respond to (and not, instead, by the attributes they have). For another, you'd have a framework for service design-by-contract. But port 80 HTTP requests seem to be a lousy way to do this.
Think Panama Canal, Hoover Dam, the Great Pyramids, walking on the Moon, the tower of Babel... Throughout history, humans in large groups who come together, find a way to work toward a common goal, and actually work without a what's-in-it-for-me attitude accomplish wonders.
OK, yes, many of the accomplishments I mentioned had paid workers, but in most cases there was a cause (racing to the Moon out of patriotism, avoiding a death sentence from Pharaoh... etc.)
In all of these efforts, the sense of being part of something greater was there.
Just as termites can rally around a queen and build giant mounds complete with air conditioning (really, Google-search it), humans in large numbers have altered the Earth's geography and climate. It's only natural that humans in large numbers working toward a common goal (be it a sense of belonging, or just to beat MS) could successfully put together something as complex and large-scale as an OS.
... Not that I'd categorize Linux as a wonder of the world.:)
You dutifully explained to this person that a ping is an active sonar pulse used to detect submarines and that it had something to do with tunneling protocols in World War II... right?
Open Source is not a business model. It is, rather, a style of software distribution
and licensing intended to improve the lives of programmers. Given this assertion,
companies intending to make money using Open Source software have a few choices.
Develop a professional services business model, implementing solutions with
Open Source, sell support for Open Source software, or depend on the the programmers
whose lives, or livelihoods they've improved.
I think you can reasonably apply the label Shareware to the concept of asking
those who appreciate the software for monetary expressions of that appreciation.
While I'm not asserting that MandrakeSoft is going to become the id Software
of the Linux world, I would suggest that you ought to follow the Shareware ethic
and contribute, or, as the typical Shareware ideal would recommend, stop using
the software.
Yes, I know there is no such license for Mandrake's Linux saying "you
can try it but you must pay us to continue using it." But taking the attitude
that "they're stupid for offering it for free in the first place... haha..."
seems selfish to me. And given the three alternatives I mentioned for sustaining
a business using Open Source, I would prefer depending upon community appreciation
(a gratifying validation of one's work) even when it means less money.
-----
Disclaimer: The opinions expressed here are my own and do not reflect opinions
or stances of my employer.
I wish Windows did the job well. For all my preaching, the application I currently work on has pieces that run in Solaris on a Sun UE10K, OS/390 on an IBM mainframe, OpenVMS on a DEC Alpha, and various pitiful, troublesome versions of Windows (file serving and the client GUI).
Our development work is done on Windows because, yep, it came with the PCs we bought from Dell. Our company is taking a real hard look at Linux for the desktop, though. MS wants to switch our licensing and have us pay them an additional 20-some million dollars in additional fees. We politely said "No."
...the telephone system was just so wonderful and cheap when a single, large monopoly ran it, right?
The monopoly was bad, but deregulation is proving to be a bigger disaster. Any extreme is bad, including extreme capitalism or the lack thereof. Why do you think Mr. Greenspan recommends normalizing influences in the form of interest rate adjustments?
...there are some inefficiencies associated with that, but nothing compared to the inefficiencies of having a single, centrally planned operating system everywhere...
Isn't Linux a centrally planned OS (Linus)? Maybe we clone Mr. Knuth and have
him manage that fictional OS (everybody would use because it'd be that good).
Your choice of languages would be MMIX, C, C++ and Java (those supported by
CWEB ). Who said anything about
a crushing bureaucracy planning the OS? I think a form of community process,
similar to the one Java goes through, would actually be a good thing. I think
a centrally planned OS doesn't necessarily go hand in hand with a monopoly.
I lean more toward Neal Stephenson's point of view, that OSes probably shouldn't
be products. (Please note that I'd distinguish a distribution, with bells and
whistles, as distinct from the core OS; the kernel, and standard IO services)
We need a diversity of operating systems, and that's what remedies should be aimed at.
I have to disagree with this sentiment. First, if there were a common operating system that most people in the world used, writing software would become much easier for programmers. No more portability headaches. You'd have a set of guaranteed APIs that just work, you don't have to spend time angsting (forgive the verbing) about conversion, or VM differences, or ASCII to EBCDIC sorting issues... etc.
Instead we concern ourselves with usability and usefulness, correctness, robustness, extensibility, maintainability... you know, quality. You don't worry about product availability matrices, you peruse feature lists. Programmers and sysadmins who have skills on this OS (let's name it UbiquitIX) can take those skills and transfer them anywhere.
The problem in the case of Windows is not its popularity. The problem is that its design is driven not by the goals of quality, but by profit. This causes Microsoft to damage the 'product' on purpose. Take SmartTags in IE 6 for XP. How much time do you think developers spent on that feature, the primary purpose of which was to direct traffic to MSN and Microsoft's partners? What if they had spent that time on making it secure instead?
Our UbiquitIX OS must also be an open standard, lest a company like Microsoft use it in a "fire and motion" technique: keep changing the standard, keep the API documentation one release behind, and competitors spend all their time catching up.
What we see in Microsoft is the near extreme success of a capitalist notion. I'm not suggesting capatilism is bad, (I like not standing in bread lines, thank you) but that, taken to an extreme, capitalism values money more than people.
Remember, 1 Timothy 6:10 says that love of money, not money itself, is the root of all sorts of evil.
So your boss chooses a tool because he's buddies with the guy who made
the sale... ahem... sorry, 'partnership' arrangement: If it's a language,
the techniques and recommendations Mr. Bloch makes become that much more important.
Why? Because, in your spare time, you accidentally replace that Visual Cobol
(eccchhh) component with Java or Python or.... "It was purely by accident,
boss, honest... but look how much more/better it does!" Separation of
concerns allows you to upgrade components of the application as you go (granted
this is significantly more difficult in a product offering than a business
application). Separation of concerns also means easier debugging so you have
less work to do in substandard tools. If it's not a language, no problem,
tell your boss that you're using the Linux emulator that came with Windows...
"Mr. Application Builder, sir, we've changed our business, effective
yesterday. You can make the app. do that today, right?" Flexible, extensible,
composable code shortens time-to-market. You spend less time debugging (as
referenced above), less time writing code (after the first time, admittedly),
and when the business changes you don't have to worry about brittle or tangled
code breaking when you extend it.
"Diverse skills" huh? Do you mean the people on your team have
MS Word on their résumés? If you're in charge, you need to teach
them. Start by learning and understanding design and analysis patterns.
Embed these in your code, point them out to your team members. Communicate
in models (UML), and walk your team through the process you use to create
them. Do code reviews. It doesn't have to be a review of every line in the
application. Pick some code you think is high quality, examine it with the
team and show them why you think so. Pick some code you know is low quality,
point out the reasons why, have the team suggest ways to improve it and then
have them fix it.
Creating code that can't be reused in similar contexts is like filing down
a block of metal every time you need a screwdriver. It's silly. Good code is
like a craftsman's favorite set of tools, it can be used in many ways to make
customers happy. The recommendations of Mr. Bloch expose how experts in the
craft of software construction think about and do their work.
I understand what you mean about most code generators. All of them require
you to accept what the designers decided, or code it yourself. I think this
will change, though, as a greater understanding of the UML, and more importantly,
patterns, comes to the industry.
One of the three amigos (Jacobson, I think) gave a speech describing what he
called "UML all the way down." Basically, he meant that most (if not
all) coding would be done at the UML level. I see a handful of tools moving
in that direction already. Rose is one, Together is another, although OptimalJ
(shameless plug on my part, I'm employed by Compuware) is the only one I've
seen that generates a complete J2EE application from a diagram (deployment descriptors,
JSP UI and all).
I'm also with you on the coding becoming the easy part of the process. I've
found it to be a challenge explaining to management why we spend so much time
in analysis and design. I have to say, though, that it's gotten easier now that
we've been through the process a few times, and produced good software and happy
users, on time.
In previous cycles, we've tended to do what diagramming needed to be done;
just enough to communicate the design idea to the entire team. From there we
went on to contract specification in comment headers, then to code. This has
been very effective, as the end result of the design phase is to have the programmers
just itching to fill out those signatures and contracts with implementations.
The diagrams got us to the point of understanding the final solution well enough
to visualize it in our mind. The other upside was that the bulk of the non-pictorial
documentation lives with the code.
The only reason we haven't used code generation so far, is that we've not been
working in a language supported by Rose, and OptimalJ has just come on the scene
(we intend to use it internally).
All of that said, there will always be the Steve Gibson's of the world who
eschew abstraction and write tight, small, effective assembler... for one platform...
and only they can maintain it...
Security concerns regarding XP aren't holding us back from adopting XP. My company (a large software/services company) is not adopting XP for a handful of other reasons
We can't get upgrade pricing for all of our machines that run Win95 and XP licensing is expensive in general
We haven't tested all of our internal web applications against IE6 to find out what, if anything, MS broke
We haven't tested all of our internal GUI applications to see which ones XP breaks
Many (thousands) of corporate users don't have the PC hardware to run it
In general, our OS is installed by our PC vendor and the currently prescribed corporate configurations still include Win98 or NT4
We'd likely have to upgrade all of our MS Office Suites (Office 97 is the 'approved' version), which again, is very expensive (5000 users at HQ alone, don't mention the international offices)--we also don't know how MS Office will break some of our internal apps that integrate with it yet
Some corporate users still run 16-bit terminal emulators to use applications running on our trusty old OS/390 mainframe
I don't doubt that we'll eventually adopt Windows 2000 as the desktop standard (although marketing will still use their beloved Macs). It will require a lot of testing, a lot of planning and a lot of money to accomplish the upgrade. On the other hand, the benefits of XP are slight, whereas the costs and effort involved in upgrading would be significant.
Besides, there are still those of us here suggesting Mandrake Linux on the servers and desktops. [mandatory comment]
legalese n. Dense, pedantic verbiage in a language
description, product specification, or interface standard; text that
seems designed to obfuscate and requires a language lawyer to
parse it. Though hackers are not afraid of high information
density and complexity in language (indeed, they rather enjoy both),
they share a deep and abiding loathing for legalese; they associate
it with deception, suits, and situations in which hackers
generally get the short end of the stick.
Having taught the UML to my development team, I've found it to be more effective
to begin with the class diagram. There are several reasons for this.
The class diagram drives object-orientation home more quickly as you immediately
encounter encapsulation and inheritance on this diagram. Class diagrams (interpreted
strictly) show what combinations of messages are possible with the current system
through dependencies and associations. The OCL enhances the vocabulary of the
class diagram to allow business constraints to be modeled as well.
Learning the class diagram first becomes even more effective when you're teaching
the UML in the context of a process or method. For example, I taught my team
a hybrid of the RUP and ICONIX processes, which we then used immediately (this
is also key). In both those processes (although more so in the RUP) you use
sequence diagrams to help find the classes, and to help flesh them out (if you
can send it a message you've got a dependency at least...).
You make a good point about sequence diagrams being more like code (the UML
itself is designed to be executable), but most code generators work from the
class diagram (again making it more important in fact if not in theory). To
represent code you'd often have to create a myriad of sequence diagrams to express
all possible combinations of the interactions between a particular set of classes.
Sequence diagrams are more useful within the scope of a use case than within
the scope of a single class operation.
Many free software / open source / pseudo-free 'light edition' UML modeling
tools sometimes don't even include sequence diagrams, although I'd argue that
they are the second most important diagram after the class diagram.
OTOH, sequence diagrams more effectively convey the intended impact of polymorphism
to those less experienced in O-O.
As to your business analyst woes, I sympathize. I suggest you buy them (or
better, have your company expense a copy) of Alistair Cockburn's Writing
Effective Use Cases. Good use cases become critical especially if you base
the rest of you SDLC from them, as in Use Case Driven Object Modeling with
UML by Doug Rosenberg.
Slashdot Mirror
Shouldn't it be a cartoon left foot, disembodied just above the ankle? You know like that one in the... Oh... Never mind.
I agree. Linux makes a very nice "we-also-run" for Solaris/Oracle shops. Develop with Linux on the desktop, put Linux on continuous/automated build servers, use Linux for smoke and unit testing. Then deploy to test and production Solaris servers running Oracle.
This combination is effective because it allows a development team to explore, and even break stuff, on low-cost but highly capable systems. These systems don't need the "grooming-the-queen" approach of mainframe administration, or the "you-can't-handle-the-root" management of Solaris system administration. Most of the well paid Solaris sysadmins I've encountered have proven to be well worth their pay. That makes it even more important that we concentrate their effort on optimizing and maintaining production systems (storage management, fail-over, system security, OS patches... etc.).
Let the developers worry about bouncing an application server or web server to test a change. Let the developers worry about scripting and scheduling builds. Let the developers figure out how to configure the application and try several different ways of doing it. Let the developers do all of this on Linux.
Sorry for the rant... I'm out of breath now.
The opinions expressed in this post are my own, and not necessarily the opinions of my employer.
Yeah!!
All those people ought to be using Microsoft Word to edit their posts so it puts that little green squiggley underline thingy...
Oh... Never mind.
Uhhh... You mean geekspacetime right?
I'm an American. It bothered me.
If you mean that the media didn't give it the coverage it deserved, I'd agree with that. It's likely, however, that the stories they were allowed to cover did not include ones that weren't in the interests of the parent companies (AOL Time Warner for example).
--
The opinions expressed in this post are my own and not necessarily those of my employer.
A database might help solve some of the technical problems, but in the U.S., at least, the political problems would pose a significantly different challenge.
I'd venture that there are many, many individuals whose interests would not be served by improving the patent system. If I recall correctly, there was a previous post on a similar thread (months ago here on /.) asserting that the patent office was one of the few departments of government (in the U.S.) that regularly turns a profit.
--
The opinions expressed in this posting are my own and do not necessarily reflect the stance or opinions of my employer.
Ahh... an easy question to answer.
AOL Instant Messenger has fallen prey to the Microsoft-style feature-bloat problem. The client attempts to be a file transfer system, an advertising console... etc. The result is that users are left open to virus attacks. Do you remember a little while back the AIM vulnerability that allowed attackers to execute arbitrary code on the user's PC?
I don't know about you, but I find that ridiculous. All I want out of an IM client is IM and IM chat, not ads, scripting, file transfer and other "features" that open up my system over yet another protocol.
Regards,
Murph
Comcast is the only available broadband provider in my neighborhood. I guess I'll have to wait for powerline broadband.
I'll just have to figure out how to cover the meter outside my house that guages how many pictures I've downloaded...
Writing software is not difficult. Writing high-quality software _is_ difficult and requires experienced craftsmen (infer journalistic gender-neutrality, please).
So how then, can you get high-quality software quickly? Two ways:
Either method has drawbacks. #1 produces the best software, #2 produces the cheapest software. #1 makes the "Agile" crowd happy while #2 is the sermon of "Software Engineers."
Why single-out developers for defective code? Because developers write defective code. No, all developers aren't clods with text editors. Developers who do write buggy code may even care about their craft (Pragmatic Programmer tip #1). But developers themselves are to blame for the defects in their work, even though outside factors contribute to problems. We must take responsibilty for our bugs, move on and fix them. Then find new ways of working that make it more difficult for software defects to make it into production evironments.
We cannot fix imperfect programmers. We can only mitigate the effects of their imperfection through mentoring, certification, education, and proper management. In other words, treat software development as a craft, a talent to be polished and perfected.
Writing software well means communicating well with a computer. Artful written communication is very difficult to reduce to an engineering discipline, yet the skill can be taught and practiced.
Right, we all know how effective parental warning labels are on music, or how effective the Surgeon General's warnings are on cigarettes.
You're right that they shouldn't be allowed to use the CD-quality label, but they should also pay damages to consumers who bought damaged goods. Don't accept a simple hand-slap and a promise from them that they'll be good from now on. These organizations are all about their bottom line. Affect it, and they'll listen.
I'll bite on this troll.
Relatively current records show a trend of rising carbon dioxide levels. Geological trends paint a more worrisome picture. Going back several hundred thousand years, periods of major glaciation (that's an ice age to you ACs out there) were preceded by measureable increases in atmospheric carbon dioxide.
It turns out the Earth reacts to high levels of CO2 in the atmosphere first by heating up (the so-called greenhouse effect). Higher air temperatures aren't interesting, what's interesting is what happens when higher water temperatures alter the flow of the oceans' currents. You see, the oceans have an enormous mechanism for exchanging carbon dioxide for oxygen. Ocean currents flow away from the equator, warm water on the surface. As the water nears cooler climates near the poles, it cools and surface content sinks, including carbon dioxide in solution. That carbon dioxide becomes rich food for underwater vegetation, which of course produce oxygen. The water heats up (due to thermal vents in the ocean floor, for example) and rises, releasing oxygen.
Things get nasty when this falls out of balance, however. When water is warmer, it stays on the surface longer, traveling further north, or further south, encroaching on the poles. Eventually, this warm surface water starts to melt off ice at the poles. Not all of the ice melts, some of it begins to migrate. This starts to happen at an increasing rate. Now colder and colder water (and thus colder air temps. and precipitation) make their way toward the poles. Major glaciation, or, an ice age.
OK, that's nice, you say. But so what, there've been ice ages before. Pollution being a factor in this vast mechanism is all B.S. right?
Well... If you follow that second link, you'll see that studies, right here on Earth, show that atmospheric carbon dioxide levels are significantly higher than they've been in the last 420,000 years. Do a Google search and you'll find studies showing that this peak begins it's upward curve beyond the median back in the 1700s.
Humans affect the environment. Period.
I used Macs throughout high school. I would've bought one for myself, even, but I ended up with an IBM XT clone for a very simple reason: back then, Macs cost too freaking much.
Linux doesn't face that same problem. It's essentially free and runs on cheap hardware. When they grow up, they'll be able to pay for a bundled distribution...
They could even make a college preparatory class out of the experience: Installing Debian 201...
While I tend to agree with your conclusion that actual Web Services (in their current formulation) are mostly a fad, I disagree with your suggestion that standardization yields weak security.
Obscure security can only secure the trivial. Lots of eyeballs checking and auditing the code, beating on it ruthlessly, does work. (That's a slight misquote Linus' Law of Debugging from "The Cathedral and the Bazaar") Witness Linux or *BSD.
Message-driven, discovery-based APIs for applications will be a good thing. For one thing, the actual APIs would fall more in line with O-O practice, where you classify objects by the messages they respond to (and not, instead, by the attributes they have). For another, you'd have a framework for service design-by-contract. But port 80 HTTP requests seem to be a lousy way to do this.
I'll take a shot...
Think Panama Canal, Hoover Dam, the Great Pyramids, walking on the Moon, the tower of Babel... Throughout history, humans in large groups who come together, find a way to work toward a common goal, and actually work without a what's-in-it-for-me attitude accomplish wonders.
OK, yes, many of the accomplishments I mentioned had paid workers, but in most cases there was a cause (racing to the Moon out of patriotism, avoiding a death sentence from Pharaoh... etc.)
In all of these efforts, the sense of being part of something greater was there.
Just as termites can rally around a queen and build giant mounds complete with air conditioning (really, Google-search it), humans in large numbers have altered the Earth's geography and climate. It's only natural that humans in large numbers working toward a common goal (be it a sense of belonging, or just to beat MS) could successfully put together something as complex and large-scale as an OS.
... Not that I'd categorize Linux as a wonder of the world. :)
ESR took a better shot at explaining it in his book, The Cathedral and the Bazaar.
/
.
/
.
The views expressed in this post are my own and aren't connected to the views and opinions of my employers.
LOL... That's what you get when you let the Atari generation name military technology.
You dutifully explained to this person that a ping is an active sonar pulse used to detect submarines and that it had something to do with tunneling protocols in World War II... right?
Open Source is not a business model. It is, rather, a style of software distribution and licensing intended to improve the lives of programmers. Given this assertion, companies intending to make money using Open Source software have a few choices. Develop a professional services business model, implementing solutions with Open Source, sell support for Open Source software, or depend on the the programmers whose lives, or livelihoods they've improved.
I think you can reasonably apply the label Shareware to the concept of asking those who appreciate the software for monetary expressions of that appreciation. While I'm not asserting that MandrakeSoft is going to become the id Software of the Linux world, I would suggest that you ought to follow the Shareware ethic and contribute, or, as the typical Shareware ideal would recommend, stop using the software.
Yes, I know there is no such license for Mandrake's Linux saying "you can try it but you must pay us to continue using it." But taking the attitude that "they're stupid for offering it for free in the first place... haha..." seems selfish to me. And given the three alternatives I mentioned for sustaining a business using Open Source, I would prefer depending upon community appreciation (a gratifying validation of one's work) even when it means less money.
-----
Disclaimer: The opinions expressed here are my own and do not reflect opinions or stances of my employer.
I wish Windows did the job well. For all my preaching, the application I currently work on has pieces that run in Solaris on a Sun UE10K, OS/390 on an IBM mainframe, OpenVMS on a DEC Alpha, and various pitiful, troublesome versions of Windows (file serving and the client GUI).
Our development work is done on Windows because, yep, it came with the PCs we bought from Dell. Our company is taking a real hard look at Linux for the desktop, though. MS wants to switch our licensing and have us pay them an additional 20-some million dollars in additional fees. We politely said "No."
The monopoly was bad, but deregulation is proving to be a bigger disaster. Any extreme is bad, including extreme capitalism or the lack thereof. Why do you think Mr. Greenspan recommends normalizing influences in the form of interest rate adjustments?
Isn't Linux a centrally planned OS (Linus)? Maybe we clone Mr. Knuth and have him manage that fictional OS (everybody would use because it'd be that good). Your choice of languages would be MMIX, C, C++ and Java (those supported by CWEB ). Who said anything about a crushing bureaucracy planning the OS? I think a form of community process, similar to the one Java goes through, would actually be a good thing. I think a centrally planned OS doesn't necessarily go hand in hand with a monopoly. I lean more toward Neal Stephenson's point of view, that OSes probably shouldn't be products. (Please note that I'd distinguish a distribution, with bells and whistles, as distinct from the core OS; the kernel, and standard IO services)
C-x C-c
I have to disagree with this sentiment. First, if there were a common operating system that most people in the world used, writing software would become much easier for programmers. No more portability headaches. You'd have a set of guaranteed APIs that just work, you don't have to spend time angsting (forgive the verbing) about conversion, or VM differences, or ASCII to EBCDIC sorting issues... etc.
Instead we concern ourselves with usability and usefulness, correctness, robustness, extensibility, maintainability... you know, quality. You don't worry about product availability matrices, you peruse feature lists. Programmers and sysadmins who have skills on this OS (let's name it UbiquitIX) can take those skills and transfer them anywhere.
The problem in the case of Windows is not its popularity. The problem is that its design is driven not by the goals of quality, but by profit. This causes Microsoft to damage the 'product' on purpose. Take SmartTags in IE 6 for XP. How much time do you think developers spent on that feature, the primary purpose of which was to direct traffic to MSN and Microsoft's partners? What if they had spent that time on making it secure instead?
Our UbiquitIX OS must also be an open standard, lest a company like Microsoft use it in a "fire and motion" technique: keep changing the standard, keep the API documentation one release behind, and competitors spend all their time catching up.
What we see in Microsoft is the near extreme success of a capitalist notion. I'm not suggesting capatilism is bad, (I like not standing in bread lines, thank you) but that, taken to an extreme, capitalism values money more than people.
Remember, 1 Timothy 6:10 says that love of money, not money itself, is the root of all sorts of evil.
OK, in order:
Creating code that can't be reused in similar contexts is like filing down a block of metal every time you need a screwdriver. It's silly. Good code is like a craftsman's favorite set of tools, it can be used in many ways to make customers happy. The recommendations of Mr. Bloch expose how experts in the craft of software construction think about and do their work.
I understand what you mean about most code generators. All of them require you to accept what the designers decided, or code it yourself. I think this will change, though, as a greater understanding of the UML, and more importantly, patterns, comes to the industry.
One of the three amigos (Jacobson, I think) gave a speech describing what he called "UML all the way down." Basically, he meant that most (if not all) coding would be done at the UML level. I see a handful of tools moving in that direction already. Rose is one, Together is another, although OptimalJ (shameless plug on my part, I'm employed by Compuware) is the only one I've seen that generates a complete J2EE application from a diagram (deployment descriptors, JSP UI and all).
I'm also with you on the coding becoming the easy part of the process. I've found it to be a challenge explaining to management why we spend so much time in analysis and design. I have to say, though, that it's gotten easier now that we've been through the process a few times, and produced good software and happy users, on time.
In previous cycles, we've tended to do what diagramming needed to be done; just enough to communicate the design idea to the entire team. From there we went on to contract specification in comment headers, then to code. This has been very effective, as the end result of the design phase is to have the programmers just itching to fill out those signatures and contracts with implementations. The diagrams got us to the point of understanding the final solution well enough to visualize it in our mind. The other upside was that the bulk of the non-pictorial documentation lives with the code.
The only reason we haven't used code generation so far, is that we've not been working in a language supported by Rose, and OptimalJ has just come on the scene (we intend to use it internally).
All of that said, there will always be the Steve Gibson's of the world who eschew abstraction and write tight, small, effective assembler... for one platform... and only they can maintain it...
Anyway, happy coding.
Security concerns regarding XP aren't holding us back from adopting XP. My company (a large software/services company) is not adopting XP for a handful of other reasons
We can't get upgrade pricing for all of our machines that run Win95 and XP licensing is expensive in general
We haven't tested all of our internal web applications against IE6 to find out what, if anything, MS broke
We haven't tested all of our internal GUI applications to see which ones XP breaks
Many (thousands) of corporate users don't have the PC hardware to run it
In general, our OS is installed by our PC vendor and the currently prescribed corporate configurations still include Win98 or NT4
We'd likely have to upgrade all of our MS Office Suites (Office 97 is the 'approved' version), which again, is very expensive (5000 users at HQ alone, don't mention the international offices)--we also don't know how MS Office will break some of our internal apps that integrate with it yet
Some corporate users still run 16-bit terminal emulators to use applications running on our trusty old OS/390 mainframe
I don't doubt that we'll eventually adopt Windows 2000 as the desktop standard (although marketing will still use their beloved Macs). It will require a lot of testing, a lot of planning and a lot of money to accomplish the upgrade. On the other hand, the benefits of XP are slight, whereas the costs and effort involved in upgrading would be significant.
Besides, there are still those of us here suggesting Mandrake Linux on the servers and desktops. [mandatory comment]
Tivo capability, hmmmm....
"Aww crap.... I just taped over all my MS-Game 2.0 save games with an episode of Meet The Press..."
From The Jargon File via the UMEC's Jargon Server:
Having taught the UML to my development team, I've found it to be more effective to begin with the class diagram. There are several reasons for this.
The class diagram drives object-orientation home more quickly as you immediately encounter encapsulation and inheritance on this diagram. Class diagrams (interpreted strictly) show what combinations of messages are possible with the current system through dependencies and associations. The OCL enhances the vocabulary of the class diagram to allow business constraints to be modeled as well.
Learning the class diagram first becomes even more effective when you're teaching the UML in the context of a process or method. For example, I taught my team a hybrid of the RUP and ICONIX processes, which we then used immediately (this is also key). In both those processes (although more so in the RUP) you use sequence diagrams to help find the classes, and to help flesh them out (if you can send it a message you've got a dependency at least...).
You make a good point about sequence diagrams being more like code (the UML itself is designed to be executable), but most code generators work from the class diagram (again making it more important in fact if not in theory). To represent code you'd often have to create a myriad of sequence diagrams to express all possible combinations of the interactions between a particular set of classes. Sequence diagrams are more useful within the scope of a use case than within the scope of a single class operation.
Many free software / open source / pseudo-free 'light edition' UML modeling tools sometimes don't even include sequence diagrams, although I'd argue that they are the second most important diagram after the class diagram.
OTOH, sequence diagrams more effectively convey the intended impact of polymorphism to those less experienced in O-O.
As to your business analyst woes, I sympathize. I suggest you buy them (or better, have your company expense a copy) of Alistair Cockburn's Writing Effective Use Cases. Good use cases become critical especially if you base the rest of you SDLC from them, as in Use Case Driven Object Modeling with UML by Doug Rosenberg.