Hopefully, there may be a change in mindset as a result. I know how hard it is to anticipate everything and think outside the box with pressures being what they are. And I understand some risk is unavoidable, and, as many experts have observed, the road through space will be paved, like any frontier, in blood.
It impressed me how it seems NASA has a launch-to-recovery mindset that may be hindering them. The riskiest parts of any Shuttle mission are launch and reentry. Any pilot puts their craft through a pre-flight check before heading out, including, with small aircraft, personally checking the engines, wings, control surfaces, and landing gear as well as avionics.
It seems to me prudent to do the same with the Shuttle before undertaking the riskiest parts of the mission. Maybe _all_ Shuttles should, as part of their mission, stop by the ISS for a look-over before starting reentry. Yes, I know that means a lot in terms of additional energy budget if the best orbit for the Shuttle mission is something rather different than ISS. (Maybe that can be helped using an external attachable booster, although I agree that might not improve the risks.) Doing that does have the advantage of offering a solution if something's found wrong with the Shuttle: Its crew can join the ISS until something is figured out.
The alternative, it seems to me, despite agency nay-saying, is to equip each Shuttle with an independently manuverable robot observer equipped with cameras which can be controlled from the flight deck. You'd obviously want a couple of 'em on hand for redundancy. And, whether you recover them for re-use or just de-orbit them (who needs more space junk) seems an unimportant matter. Then change the procedures to do a close inspection of the entire external surface.
And if something is found, keep the crew in orbit until an alternative means of return is available. Maybe that means finding a way of delivering additional consumables to them in a separate launch.
I think there may be a misunderstanding here. (AND, it was probably corrected below, but I haven't gotten there yet.)
The issue is over a new photo taken from New Mexico when Columbia was overhead prior to breakup. Unfortunately, the picture was hyped well beyond what it shows. It may show something, but it isn't obvious.
It seems to me the way to tell is not, as Ron Dittomore said at the last NASA briefing, to compare with pictures taken of other Shuttles landing from the same location. It seems to me that what you want are comparison images made to scale of a high resolution model of the Shuttle taken in profile, at the 3-space attitude the Shuttle was known to be at the time, and from the perspective of where the camera was. For that's what the image is: A black, low-resolution profile.
The late Richard Feynmann's report of the Challenger investigation had engineers coming up with failure rates of about one-in-a-hundred even at that time. In fact, being consistent with those.01 failure estimates was how Feynmann was able to ferret out engineers from suit types, the latter simply quoting the advertising that failure rates were one-in-a-hundred-thousand.
I think Smalltalk's biggest problem by far is that it's too insular. It's hard to talk with the rest of the world, or interact with what other programs are doing in other environments. That's the price of elegance, I suppose -- purity only comes when you won't sully yourself. But it's hard to work with.
Ian, you're kidding, right? I find Smalltalk much easier to work with than, e.g., Java when working with, say, relational databases because at some level in Smalltalk the cursor is just a pointer to a Collection of some kind. With Java, the writer of a query is obligated to decompose its result set rows down into Java
typed variables 1-1 with their SQL counterparts, whether the class doing the query really "cares" about that level of detail or not. For instance, blobs are really problematical. The corresponding Smalltalk interface might need to do some conversion of types to standard form, but that can be built into the database API.
The same is true regarding interactions with results gathered by code from other programming languages.
Ian, I'm not sure what you mean by The runtime environment is just too limiting (Smalltalk over FTP?). Do you mean what's come to be known as distributed Smalltalk, or synchronous, remote procedure calls via message passing, or asynchronous method calls?
T_f_J, you're entitled to an opinion, of course,
but your vocabulary in itself demonstrates the
problem. To serve the economic and egoistic
purposes of various Influential Entities, programming languages have become like car styles and Parisian fashions. Who judges that a programming language "belongs in a by-gone" era? What's the basis for that judgment? Is it that it hasn't a Roy Oily animal character and book
assigned it yet? Is it that there's no John Wayne icon picked for it? Surely, a programming language is judged based upon the readiness with which its practitioners can build real systems while keeping an eye on long term costs and adaptability to changes in requirements.
If popularity were the test of achievement, then
Visual Basic is (and remains, despite some
deflation) king of the hill. You can't really
mean that.
Most people who embrace Smalltalk have tried many other languages in professional contexts and are simply compelled to use it. There are lots
of reasons why programmers unfamiliar with Smalltalk are missing out, even if they don't or can't use it. It's a powerful idea. I've described some of these in a letter to the editor of Dr Dobbs about a year ago. Smalltalk repeatedly surprises even its afficianados with rediscovered power and grace.
I agree that anyone questioning this issue should read these books.
Also, understand that databases come in sizes and scales, too. Indeed, this often comes up in solicitations for job applicants to work with such databases. One such value point is whether or not table unloading/reloading is a "reasonable operation" or not. There are databases of tens of gigabyte size, typically up to 100 million rows (assuming some average bytes per row), for which
doing maintenance can involve an unload or, at worst, some kind of fast export. Then there are bigger ones for which this is an entirely unreasonable thing to do for which maintenance must be done using the same SQL interface that updates and queries on it are done.
One thing the Greenspun books can show you is
that there are other ways of using databases in
the construction of Web sites besides as simple containers for accounting, purchasing, or clickstream data. In particular, one can serve pieces of Web pages from the database and images stored as blobs. This is especially easy if one
uses a facility like MetaHTML. This does, of course, have the side effect of placing those pieces fetched that way beyond the reach of search engines. OTOH, some sites want to achieve precisely that effect.
Well, while this post might have been flamebait,
implicit is an interesting possibility. One
way out may well be to GPL your project and
provide it to your direct client on those terms,
take it or leave it. You can, of course, insist
they pay for your work. Naturally, they may
balk and, naturally, you'll lose any benefits --
of which undoubtedly there are some, whether
they're outweighed by costs or not -- from making
the product GPL.
You can, it seems to me, then proceed with
impunity working on the non-GPL project for
your employer and, obviously, cannot use any
of the code from your GPL version because that
would violate the GPL. I don't think your
employer would agree to use of GPL code.
You should, of course, check your employee
agreement and contract as several others
suggested. Check with an attorney. But you
may luck out. I worked for IBM many years,
and they had/have extremely stringent employee
agreements not to compete. However, our division
was sold (along with us) to Loral and both the
terms of the transfer and Loral's own employee
agreements didn't specify so, upon advice of an
attorney, I made a list of all my personal
documents and work I had done on the side for
IBM and also drew up a Doing-Business-As and,
effective upon the date Loral took control,
I presented to management and Loral's attorneys
a claim that this stuff was mine and would they
sign it. They were puzzled for a bit, but
finally did sign it and I was on my way.
Yeah, I think the statistics and math end got a
bad wrap in the CNN article. If, indeed, reality
is coming up different than the calculations
suggest, then, of course, the calculations are
either done wrong or are based upon wrong
assumptions. When one uses statistics,
assumptions are always necessary and needed.
I got irked that CNN tried to marshall the general
anti-intellectualism that's coming into office
with GW (damn Census folks re politically
motivated and we dont understand all that
math sampling malarkey) to say "the real rocket
scientists" are the seat-of-the-pants hardware
guys who can tell if an engine is working or
not by how it feels.
NASA's problem was a problem that continues
in the aerospace industry: Statistics are
used to prove a position of argument, and
truth is considers some unrealistic,
un-grounded-in-business ideal which is
too expensive to pursue. The Other Guy
doesn't care about it and if We're to survive
in this business, we have to be as dishonest
as they are.
So, when the results the numbers say are
dramatically contradicted by reality, of course,
blame the statistics, the engineers, and the
numbers, not all the shortcuts and posturing
we did to win the contract.... or the
funding.
The 70-hour workweek is one aspect of some
successful models of software development.
Nevertheless, it is hardly a sufficient aspect.
IBM and others have for years encouraged long
hours and it seems in my experience this was just
effort tossed away. Also, the extreme programming approach advocated by Jeffries and others puts a premium on proper design and pair programming work rather than isolated heroes, seems to be successful, and keeps within a reasonable workweek both so to not overly fatigue its participants and to be predicatable.
Simply put, a 40+ hour week is not sustainable for the long term. Further, it is not realistic as an HR policy. The participants will either get old enough to wonder about other things in their lives (and have made enough money so they can bolt and not give a damn) or pull back because of health reasons. And I really wonder about the
ethics of an industry that says its doesn't care
and demands such despite its effects.
Finally, one successful e-entrepeneur, Jeff Bezos, makes it a policy to demand he and folks around him get enough sleep. Or at least so
he told the Wall Street Journal. It appears he's
backed up by a lot of scientific evidence. There
are recent articles about this in Kinko's IMPRESS magazine, the Washington Post, and the above-mentioned Wall Street Journal, unfortunately either only available for a fee or only in dead-trees form.
Being an avid supporter of environmental causes as well as a geek, I have plenty of reasons to both vote, and to vote for Gore/Liebermann. I do not like the
anti-Hollywood/anti-'Net stance Gore and, in particular, Liebermann sometimes take. I am find
Mr Liebermann's criticism of the Walt Disney Company particularly distasteful. However,
I find no evidence that Bush/Cheney are any
better on these points.
While Bush says he can be trusted and will
"get things done", clearly the former is an
untestable claim and the latter could be achieved
in the narrow sense by passing a lot of bad
legislation. I also find Carl Pope and Paul Rauber's argument that with Bush, Republicans
could have a lock on three houses of government
to be a compelling reason to work for some "diversity" in the branches.
As for folks who feel the process is compromised beyond participation, I believe the
quote from Norman Mailer (The Deer Park) is appropriate to our national situation:
There was that law of life, so cruel and so just, that one must grow or else pay more for remaining the same.
IMO the ethical ambiguity you find yourself in
results from an ambiguity in your relationship
to the company and to the invention in question.
Ethical ambiguities are usually caused by such
things. In this case, your status as an inventor is a priori questionable both because you are no longer employed at the company, and because the agreement you signed makes your status as inventor one in name only.
The usual thing a company wanting to file a patent "in the clear" does is ask the parties who might contest it to sign waivers of interest, stating that they won't challenge their free ownership of the invention. That waiver then amounts to a contract. That the company wants to list you as a co-inventor complicates things, and implies your relationship to the company and to the invention is stronger than it seems from the
facts.
Here's what I think: You are no longer employed by the company, so you are no longer responsible for their actions. You shouldn't try to influence them.
If, in fact, you believe you are a co-inventor and believe you have rights to the invention, I think you have some standing with the Patent Office and can negotiate a better situation for yourself. For if the company didn't settle up this issue when you left their employment, they lost some control of the invention. The grey area is when is this invention considered "invented".
OTOH, if, as you say, you don't believe the invention should be filed at all, while you cannot control what the company does and shouldn't try to, you can refuse to sign as co-inventor but offer to sign a waiver of standing or claim or whatever it's called. I cannot see how the company can force you to sign as co-inventor. Your agreement didn't specify that. It simply said all inventions made during your tenure belonged to the company.
I have posted comments regarding Bible literalism
on the so-called "10 Commandments site" mentioned.
Unfortunately, the registry there is very limited
in size and could not retain the comments.
I therefore sent Mr Lee e-mail with the problems
I see with his approach.
What I don't understand is why Mr Lee bothers to
read Slashdot, unless he's trolling for a fight.
I heartily second this opinion, both because Smalltalk logic is simple and consistent and because anything about Smalltalk or OO with Smalltalk easily transfers to other OO languages, and even non-OO: May the class libraries be well done and with you!
Now, if, instead, one opts for Dolphin Smalltalk, as an implementation -- not Squeak and relatively free, I understand -- it has a package which programs and controls Lego Mindstorms Bots already.
With Squeak, of course, you have Morphic and a 3D build/control/modeling package that's heavily cross-platform.
I, for one, consider happenings on the market of interest, and well worthy of slashdot.org's attention. Not only have the Web and tech stocks become the darling of Wall Street, the Web and tek is refashioning the culture and business' image of itself. Thus, if, hypothetically, a fall in stocks is hung, unjustifiably, on the necks of "new business entrepeneurs", that could well affect me, and many of us.
Even now, there are important dissenting opinions as to how good it is for the culture that the Web and computing is Center Stage, with a good dose of worry dashed in that computing may get a bad name. There is, after all, a tradition of this in the computing industry: Expert systems, strong typing, and the DoD's Ada all promised lots more than they could possibly deliver and never recovered from the Public Disappointment.
OTOH, there is a really interesting analysis by Bob Cringely about how ridiculous some of the pricing of the stock market is, and how remarkably inefficient it seems to be, despite the claims of, for instance, the Chicago school and monetarists. (I might add, at risk of introducing extraneous detail and incurring the Wrath of Moderation, that one needs, uh, patience going to the latter two sites.)
While I might believe a compromise of a ship computing system -- ships like carriers are floating cities, after all, with huge infrastructures, lots of computers, and multiple nuclear reactors -- even high tech aircraft have a clear separation in their design between avionics and the controls, even if the vehicle is fly-by-wire. One of the most automated designs considered in recent decades was the Army's LHX helo. It cut its funding cut badly, but pilots have this Thing about handing over too much control to the boxes, even if there are compelling cases to be made that letting the boxes control would improve survivability. I strongly suspect the electronics in tanks serve a communications and advisory capacity. Besides, doctrine says that, eg, option to fire or engage always requires a human decision. Now, some of the FSU aircraft are, indeed, capable of being flow from the ground, although with collapse of infrastructure and desire to sell to the international market for currency, the manufacturers have recently made them more independent. So, my assessment is this is a military "wolf cry" on a theme of current concern to extract more funds for pet projects from the public using the military's accomplices, the Congress.
I don't think you'll get anywhere unless you let the source be "out there" and pick from that what you want. Indeed, the "capital" which folks gain when they make contributions is the source itself. Also, trying to control the plethora of source versions is likely to be an expensive thing, although it has and is being done in places.
So, China is trying to control. So, some US agencies and foreign countries are trying to control. So, why not create a free tool, perhaps coupled to a GPLed database, that allows a user to query whether any of the servers it relies upon are owned by an organization that complies with Chinese, or Kuwaitii, or US agency requests?
Then, the user would at least have the option of choosing not to do business with them. The trouble is, of course, an agent who did do business would try to hide the fact. But that attempt can be skirted.
It could be a resource like peacefire.org, except aimed at servers.
The was-it-worth-it debate just starting is amusing and, yes, there may be problems to come, and, yes, I'm sure many contractors and vendors hyped the Y2K bug to their benefit. Nevertheless, that we needed to do this last-minute-fixup-panic itself tells legions about the misreable state of software technology. To provide proper service, the compliance of any software with end-of-century dating should have been totally transparent. Indeed, the "opaqueness" of software to customers is a launchpad for a major diatribe: It is, indeed, part of the argument of the Free Software Foundation, that to really use software, customers of necessity need much more than binaries.
But, also, the Y2K phenomenon shows that Americans -- claiming to embrace technology in all forms -- actually worship it rather than use it. Technology appears to be an ultra-talisman, making one rich if one invests in it or can take a new fad public, and ultimately solving all one's problems, even if one doesn't understand how. There may have been hype in the IT industry about Y2K, but if that were deliberate it may have been so simply because those concerned knew Americans do not respond to sense or logical arguments, that they need emotion to move them, whether to support a sports team, a military campaign, to change their own habits, or to take reasonable precautions. Hence, Sputnik is a challenge to freedom, the Evil Empire must be beaten, and the world will melt down if we don't fix our ubiquitous computers.
Note that the per capita density of computers, understanding of technology, and preparedness for Y2K varied by orders of magnitude across countries on the planet. Yet we haven't yet heard of any documented Y2K problems. Right now, the winners seem to be those governments, laughed at heartily by all of us when they first made their apology, who decided to take action when they saw Y2K problems appear in other countries, realizing that they would have at least 12 hours notice.
We have a long way to go to make software technology as reliable as a television. But demanding that software vendors toe the line typically demanded of others, whether the vendors name has "Microsoft", "Sun", "IBM", or "Red Hat" in it, can only hasten that arrival.
The practice enabled by free software is collectivism and cooperation. That is its most important feature.
At one level, yes, it doesn't matter what any software is called, apart from the basic and natural and necessary encouragement to authors and the community provided by preserving the acknowledgement to whoever gave the original inspiration. That is, this is an application of the social process invoked when naming comets, stars, and species.
At another, more important level, the retention of the GNU prefix reminds us and all users of the reason why this was all started and works, and counteracts the all-too-common tendency, IMO, for "GNU" and "free software" to deteriorate into mere urban legends harnessed for the purpose of promotion. Remember, part of our ethos is that proper appreciation of software and the genius of its developers demands users be far more sophisticated about it than MS, IBM, or other vendors pretend they can be. IOW, free software doesn't suck like a "touchy, feelie" hyped GUI does and so it doesn't lie to the user.
There's no reason why people shouldn't make a proper living developing software under the GPL. But we should never sell our souls to do so, whether that entails forgetting the principles that GNU was founded to promote or the basic commitment to honesty and shirking of hype which characterizes the rest of the software industry.
You kid, of course. Anyone who calls RMS a dictator can hardly know the man.
Mr Stallman is, simply, far more ethical and conscientious than current social norms tolerate. Whatever sense of obligation or compulsion you feel is either because of the force of his persuasion or because the software industry and its fiercely creative "free" netherworld are mediaocracies rather than democracies and these folks are being led by the nose to either uncritically embrace or oppose RMS's opinions. Get a brain.
I don't agree with all that Richard says, but he has brought and kept issues critical to the essence of software and freedom on the front page, as well as seasoning them with proper and just notions of ethics and values. I cannot stand by and see him maligned unjustly.
I think there are several charges, one of them being "Theft of computer services". Presumably this refers to the guy's invention being the immediate cause of many systems being tied up and clogged.
As most crimes, the main issue is intent to commit the alleged act, and that'll be what the prosecutor will need to prove. But that's proved immediately once it is established that the person arrested actually wrote the virus and actually released it "into the wild".
Slashdot Mirror
Hopefully, there may be a change in mindset as a result. I know how hard it is to anticipate everything and think outside the box with pressures being what they are. And I understand some risk is unavoidable, and, as many experts have observed, the road through space will be paved, like any frontier, in blood.
It impressed me how it seems NASA has a launch-to-recovery mindset that may be hindering them. The riskiest parts of any Shuttle mission are launch and reentry. Any pilot puts their craft through a pre-flight check before heading out, including, with small aircraft, personally checking the engines, wings, control surfaces, and landing gear as well as avionics.
It seems to me prudent to do the same with the Shuttle before undertaking the riskiest parts of the mission. Maybe _all_ Shuttles should, as part of their mission, stop by the ISS for a look-over before starting reentry. Yes, I know that means a lot in terms of additional energy budget if the best orbit for the Shuttle mission is something rather different than ISS. (Maybe that can be helped using an external attachable booster, although I agree that might not improve the risks.) Doing that does have the advantage of offering a solution if something's found wrong with the Shuttle: Its crew can join the ISS until something is figured out.
The alternative, it seems to me, despite agency nay-saying, is to equip each Shuttle with an independently manuverable robot observer equipped with cameras which can be controlled from the flight deck. You'd obviously want a couple of 'em on hand for redundancy. And, whether you recover them for re-use or just de-orbit them (who needs more space junk) seems an unimportant matter. Then change the procedures to do a close inspection of the entire external surface.
And if something is found, keep the crew in orbit until an alternative means of return is available. Maybe that means finding a way of delivering additional consumables to them in a separate launch.
I think there may be a misunderstanding here. (AND, it was probably corrected below, but I haven't gotten there yet.)
The issue is over a new photo taken from New Mexico when Columbia was overhead prior to breakup. Unfortunately, the picture was hyped well beyond what it shows. It may show something, but it isn't obvious.
It seems to me the way to tell is not, as Ron Dittomore said at the last NASA briefing, to compare with pictures taken of other Shuttles landing from the same location. It seems to me that what you want are comparison images made to scale of a high resolution model of the Shuttle taken in profile, at the 3-space attitude the Shuttle was known to be at the time, and from the perspective of where the camera was. For that's what the image is: A black, low-resolution profile.
The late Richard Feynmann's report of the Challenger investigation had engineers coming up with failure rates of about one-in-a-hundred even at that time. In fact, being consistent with those .01 failure estimates was how Feynmann was able to ferret out engineers from suit types, the latter simply quoting the advertising that failure rates were one-in-a-hundred-thousand.
IB wrote:
Ian, you're kidding, right? I find Smalltalk much easier to work with than, e.g., Java when working with, say, relational databases because at some level in Smalltalk the cursor is just a pointer to a Collection of some kind. With Java, the writer of a query is obligated to decompose its result set rows down into Java typed variables 1-1 with their SQL counterparts, whether the class doing the query really "cares" about that level of detail or not. For instance, blobs are really problematical. The corresponding Smalltalk interface might need to do some conversion of types to standard form, but that can be built into the database API.
The same is true regarding interactions with results gathered by code from other programming languages.
Ian, I'm not sure what you mean by The runtime environment is just too limiting (Smalltalk over FTP?). Do you mean what's come to be known as distributed Smalltalk, or synchronous, remote procedure calls via message passing, or asynchronous method calls?
T_f_J, you're entitled to an opinion, of course, but your vocabulary in itself demonstrates the problem. To serve the economic and egoistic purposes of various Influential Entities, programming languages have become like car styles and Parisian fashions. Who judges that a programming language "belongs in a by-gone" era? What's the basis for that judgment? Is it that it hasn't a Roy Oily animal character and book assigned it yet? Is it that there's no John Wayne icon picked for it? Surely, a programming language is judged based upon the readiness with which its practitioners can build real systems while keeping an eye on long term costs and adaptability to changes in requirements.
If popularity were the test of achievement, then Visual Basic is (and remains, despite some deflation) king of the hill. You can't really mean that.
Most people who embrace Smalltalk have tried many other languages in professional contexts and are simply compelled to use it. There are lots of reasons why programmers unfamiliar with Smalltalk are missing out, even if they don't or can't use it. It's a powerful idea. I've described some of these in a letter to the editor of Dr Dobbs about a year ago. Smalltalk repeatedly surprises even its afficianados with rediscovered power and grace.
And if you want to see some of the other reasons Smalltalk wins, check out John McIntosh's site, Peter Lount's place, and the nifty (IMO) Dolphin Smalltalk.
I agree that anyone questioning this issue should read these books.
Also, understand that databases come in sizes and scales, too. Indeed, this often comes up in solicitations for job applicants to work with such databases. One such value point is whether or not table unloading/reloading is a "reasonable operation" or not. There are databases of tens of gigabyte size, typically up to 100 million rows (assuming some average bytes per row), for which doing maintenance can involve an unload or, at worst, some kind of fast export. Then there are bigger ones for which this is an entirely unreasonable thing to do for which maintenance must be done using the same SQL interface that updates and queries on it are done.
One thing the Greenspun books can show you is that there are other ways of using databases in the construction of Web sites besides as simple containers for accounting, purchasing, or clickstream data. In particular, one can serve pieces of Web pages from the database and images stored as blobs. This is especially easy if one uses a facility like MetaHTML. This does, of course, have the side effect of placing those pieces fetched that way beyond the reach of search engines. OTOH, some sites want to achieve precisely that effect.
Well, while this post might have been flamebait,
implicit is an interesting possibility. One
way out may well be to GPL your project and
provide it to your direct client on those terms,
take it or leave it. You can, of course, insist
they pay for your work. Naturally, they may
balk and, naturally, you'll lose any benefits --
of which undoubtedly there are some, whether
they're outweighed by costs or not -- from making
the product GPL.
You can, it seems to me, then proceed with
impunity working on the non-GPL project for
your employer and, obviously, cannot use any
of the code from your GPL version because that
would violate the GPL. I don't think your
employer would agree to use of GPL code.
You should, of course, check your employee
agreement and contract as several others
suggested. Check with an attorney. But you
may luck out. I worked for IBM many years,
and they had/have extremely stringent employee
agreements not to compete. However, our division
was sold (along with us) to Loral and both the
terms of the transfer and Loral's own employee
agreements didn't specify so, upon advice of an
attorney, I made a list of all my personal
documents and work I had done on the side for
IBM and also drew up a Doing-Business-As and,
effective upon the date Loral took control,
I presented to management and Loral's attorneys
a claim that this stuff was mine and would they
sign it. They were puzzled for a bit, but
finally did sign it and I was on my way.
Yeah, I think the statistics and math end got a bad wrap in the CNN article. If, indeed, reality is coming up different than the calculations suggest, then, of course, the calculations are either done wrong or are based upon wrong assumptions. When one uses statistics, assumptions are always necessary and needed.
I got irked that CNN tried to marshall the general anti-intellectualism that's coming into office with GW (damn Census folks re politically motivated and we dont understand all that math sampling malarkey) to say "the real rocket scientists" are the seat-of-the-pants hardware guys who can tell if an engine is working or not by how it feels.
NASA's problem was a problem that continues in the aerospace industry: Statistics are used to prove a position of argument, and truth is considers some unrealistic, un-grounded-in-business ideal which is too expensive to pursue. The Other Guy doesn't care about it and if We're to survive in this business, we have to be as dishonest as they are.
So, when the results the numbers say are dramatically contradicted by reality, of course, blame the statistics, the engineers, and the numbers, not all the shortcuts and posturing we did to win the contract.... or the funding.
The 70-hour workweek is one aspect of some successful models of software development. Nevertheless, it is hardly a sufficient aspect. IBM and others have for years encouraged long hours and it seems in my experience this was just effort tossed away. Also, the extreme programming approach advocated by Jeffries and others puts a premium on proper design and pair programming work rather than isolated heroes, seems to be successful, and keeps within a reasonable workweek both so to not overly fatigue its participants and to be predicatable.
Simply put, a 40+ hour week is not sustainable for the long term. Further, it is not realistic as an HR policy. The participants will either get old enough to wonder about other things in their lives (and have made enough money so they can bolt and not give a damn) or pull back because of health reasons. And I really wonder about the ethics of an industry that says its doesn't care and demands such despite its effects.
Finally, one successful e-entrepeneur, Jeff Bezos, makes it a policy to demand he and folks around him get enough sleep. Or at least so he told the Wall Street Journal . It appears he's backed up by a lot of scientific evidence. There are recent articles about this in Kinko's IMPRESS magazine, the Washington Post, and the above-mentioned Wall Street Journal, unfortunately either only available for a fee or only in dead-trees form.
Being an avid supporter of environmental causes as well as a geek, I have plenty of reasons to both vote, and to vote for Gore/Liebermann. I do not like the anti-Hollywood/anti-'Net stance Gore and, in particular, Liebermann sometimes take. I am find Mr Liebermann's criticism of the Walt Disney Company particularly distasteful. However, I find no evidence that Bush/Cheney are any better on these points.
While Bush says he can be trusted and will "get things done", clearly the former is an untestable claim and the latter could be achieved in the narrow sense by passing a lot of bad legislation. I also find Carl Pope and Paul Rauber's argument that with Bush, Republicans could have a lock on three houses of government to be a compelling reason to work for some "diversity" in the branches.
As for folks who feel the process is compromised beyond participation, I believe the quote from Norman Mailer ( The Deer Park ) is appropriate to our national situation:
IMO the ethical ambiguity you find yourself in results from an ambiguity in your relationship to the company and to the invention in question. Ethical ambiguities are usually caused by such things. In this case, your status as an inventor is a priori questionable both because you are no longer employed at the company, and because the agreement you signed makes your status as inventor one in name only.
The usual thing a company wanting to file a patent "in the clear" does is ask the parties who might contest it to sign waivers of interest, stating that they won't challenge their free ownership of the invention. That waiver then amounts to a contract. That the company wants to list you as a co-inventor complicates things, and implies your relationship to the company and to the invention is stronger than it seems from the facts.
Here's what I think: You are no longer employed by the company, so you are no longer responsible for their actions. You shouldn't try to influence them.
If, in fact, you believe you are a co-inventor and believe you have rights to the invention, I think you have some standing with the Patent Office and can negotiate a better situation for yourself. For if the company didn't settle up this issue when you left their employment, they lost some control of the invention. The grey area is when is this invention considered "invented".
OTOH, if, as you say, you don't believe the invention should be filed at all, while you cannot control what the company does and shouldn't try to, you can refuse to sign as co-inventor but offer to sign a waiver of standing or claim or whatever it's called. I cannot see how the company can force you to sign as co-inventor. Your agreement didn't specify that. It simply said all inventions made during your tenure belonged to the company.
Best of luck.
I have posted comments regarding Bible literalism
on the so-called "10 Commandments site" mentioned.
Unfortunately, the registry there is very limited
in size and could not retain the comments.
I therefore sent Mr Lee e-mail with the problems
I see with his approach.
What I don't understand is why Mr Lee bothers to
read Slashdot, unless he's trolling for a fight.
--jtg
I heartily second this opinion, both because Smalltalk logic is simple and consistent and because anything about Smalltalk or OO with Smalltalk easily transfers to other OO languages,
and even non-OO: May the class libraries be well
done and with you!
Now, if, instead, one opts for Dolphin Smalltalk,
as an implementation -- not Squeak and relatively
free, I understand -- it has a package which
programs and controls Lego Mindstorms Bots
already.
With Squeak, of course, you have Morphic and a
3D build/control/modeling package that's heavily
cross-platform.
Ah, heck, try 'em all.
--jtg
I, for one, consider happenings on the market of interest, and well worthy of slashdot.org's attention. Not only have the Web and tech stocks become the darling of Wall Street, the Web and tek is refashioning the culture and business' image of itself. Thus, if, hypothetically, a fall in stocks is hung, unjustifiably, on the necks of "new business entrepeneurs", that could well affect me, and many of us.
Even now, there are important dissenting opinions as to how good it is for the culture that the Web and computing is Center Stage, with a good dose of worry dashed in that computing may get a bad name. There is, after all, a tradition of this in the computing industry: Expert systems, strong typing, and the DoD's Ada all promised lots more than they could possibly deliver and never recovered from the Public Disappointment.
OTOH, there is a really interesting analysis by Bob Cringely about how ridiculous some of the pricing of the stock market is, and how remarkably inefficient it seems to be, despite the claims of, for instance, the Chicago school and monetarists. (I might add, at risk of introducing extraneous detail and incurring the Wrath of Moderation, that one needs, uh, patience going to the latter two sites.)
While I might believe a compromise of a ship computing system -- ships like carriers are floating cities, after all, with huge infrastructures, lots of computers, and multiple nuclear reactors -- even high tech aircraft have a clear separation in their design between avionics and the controls, even if the vehicle is fly-by-wire. One of the most automated designs considered in recent decades was the Army's LHX helo. It cut its funding cut badly, but pilots have this Thing about handing over too much control to the boxes, even if there are compelling cases to be made that letting the boxes control would improve survivability. I strongly suspect the electronics in tanks serve a communications and advisory capacity. Besides, doctrine says that, eg, option to fire or engage always requires a human decision. Now, some of the FSU aircraft are, indeed, capable of being flow from the ground, although with collapse of infrastructure and desire to sell to the international market for currency, the manufacturers have recently made them more independent. So, my assessment is this is a military "wolf cry" on a theme of current concern to extract more funds for pet projects from the public using the military's accomplices, the Congress.
I'm getting "document contained no data" now from the FBI FOIA site. Is that anyone else's experience?
Still, it is amazing what the suits-with-gun- straps will waste money on.
I agree. This is the best way all around.
I don't think you'll get anywhere unless you let the source be "out there" and pick from that what you want. Indeed, the "capital" which folks gain when they make contributions is the source itself. Also, trying to control the plethora of source versions is likely to be an expensive thing, although it has and is being done in places.
So, China is trying to control. So, some US agencies and foreign countries are trying to control. So, why not create a free tool, perhaps coupled to a GPLed database, that allows a user to query whether any of the servers it relies upon are owned by an organization that complies with Chinese, or Kuwaitii, or US agency requests?
Then, the user would at least have the option of choosing not to do business with them. The trouble is, of course, an agent who did do business would try to hide the fact. But that attempt can be skirted.
It could be a resource like peacefire.org, except aimed at servers.
The was-it-worth-it debate just starting
is amusing and, yes, there may be
problems to come, and, yes, I'm sure
many contractors and vendors hyped the
Y2K bug to their benefit. Nevertheless,
that we needed to do this
last-minute-fixup-panic itself tells
legions about the misreable state of
software technology. To provide proper
service, the compliance of any software
with end-of-century dating should have
been totally transparent. Indeed, the
"opaqueness" of software to customers is
a launchpad for a major diatribe: It is,
indeed, part of the argument of the
Free
Software Foundation, that to really use
software, customers of necessity need
much more than binaries.
But, also, the Y2K phenomenon shows that
Americans -- claiming to embrace
technology in all forms -- actually
worship it rather than use it.
Technology appears to be an
ultra-talisman, making one rich if one
invests in it or can take a new fad
public, and ultimately solving all one's
problems, even if one doesn't understand
how. There may have been hype in the IT
industry about Y2K, but if that were
deliberate it may have been so simply
because those concerned knew Americans
do not respond to sense or logical
arguments, that they need emotion to
move them, whether to support a sports
team, a military campaign, to change
their own habits, or to take reasonable
precautions. Hence, Sputnik is a
challenge to freedom, the Evil Empire
must be beaten, and the world will melt
down if we don't fix our ubiquitous
computers.
Note that the per capita density of
computers, understanding of technology,
and preparedness for Y2K varied by
orders of magnitude across countries on
the planet. Yet we haven't yet heard of
any documented Y2K problems. Right now,
the winners seem to be those
governments, laughed at heartily by all
of us when they first made their
apology, who decided to take action when
they saw Y2K problems appear in other
countries, realizing that they would
have at least 12 hours notice.
We have a long way to go to make
software technology as reliable as a
television. But demanding that software
vendors toe the line typically demanded
of others, whether the vendors name has
"Microsoft", "Sun", "IBM", or "Red Hat"
in it, can only hasten that arrival.
The practice enabled by free software is collectivism and cooperation. That is its most important feature.
At one level, yes, it doesn't matter what any software is called, apart from the basic and natural and necessary encouragement to authors and the community provided by preserving the acknowledgement to whoever gave the original inspiration. That is, this is an application of the social process invoked when naming comets, stars, and species.
At another, more important level, the retention of the GNU prefix reminds us and all users of the reason why this was all started and works, and counteracts the all-too-common tendency, IMO, for "GNU" and "free software" to deteriorate into mere urban legends harnessed for the purpose of promotion. Remember, part of our ethos is that proper appreciation of software and the genius of its developers demands users be far more sophisticated about it than MS, IBM, or other vendors pretend they can be. IOW, free software doesn't suck like a "touchy, feelie" hyped GUI does and so it doesn't lie to the user.
There's no reason why people shouldn't make a proper living developing software under the GPL. But we should never sell our souls to do so, whether that entails forgetting the principles that GNU was founded to promote or the basic commitment to honesty and shirking of hype which characterizes the rest of the software industry.
You kid, of course. Anyone who calls RMS a dictator can hardly know the man.
Mr Stallman is, simply, far more ethical and conscientious than current social norms tolerate. Whatever sense of obligation or compulsion you feel is either because of the force of his persuasion or because the software industry and its fiercely creative "free" netherworld are mediaocracies rather than democracies and these folks are being led by the nose to either uncritically embrace or oppose RMS's opinions. Get a brain.
I don't agree with all that Richard says, but he has brought and kept issues critical to the essence of software and freedom on the front page, as well as seasoning them with proper and just notions of ethics and values. I cannot stand by and see him maligned unjustly.
I think there are several charges, one of them being "Theft of computer services". Presumably this refers to the guy's invention being the immediate cause of many systems being tied up and clogged.
As most crimes, the main issue is intent to commit the alleged act, and that'll be what the prosecutor will need to prove. But that's proved immediately once it is established that the person arrested actually wrote the virus and actually released it "into the wild".
Salon is carrying today an article echoing Davie Bowie's raves about MP3 and the culture it allows.
Ha det!
--algebraist