While there is some overlap between college and education, it's always been true and always will be that some people can get an education without college, and others can't get an education with unlimited college coursework.
While there is a statistical minority of people who drop out of college and learn more on through self teaching, the reality is:
1-these people will always be a small minority
2-they will be held up as an example by the intellectually lazy and by egotistical poseurs who want to be accorded respect they never have and never can earn on their own
3-most people who -can- learn on their own do just fine in a college environment
I think the 'leet-speak' wannabe sysadmin example indicates one of the key points. People who -can- walk the walk don't need to baffle with bullshit. Anytime anyone tries that kind of thing, it's usually safe to assume he's all talk. If he's not, he'll rise to the challenge and prove himself.
It's a bit like tossing the kid in the water to teach him to swim; just because it sometimes works doesn't make it the best method.
> Collisions are NOT and accidential everyday occurance.
Probably.
Playing the Devil's advocate here. Collisions would be impacted, possibly -very- strongly, by exactly how the GUIDs are generated. Just because there are 2^128 bits to play with doesn't mean we are using them all. There may be significant gaps; a large number of values may never be generated by the algorithm used.
Combine with human errors in coding the algorithm and the odds of a collision may be much greater than expected.
> Yes, I totally agree. Linux/UNIX shells have been developed, tested and improved by hundreds > (thousands?) of people who use them repeatedly every day over the course of more than 20 years. How > the hell is MS going to make something superior in 3-5?
By making something that does not require hacks to make Windows work sorta/kinda like Unix underneath it all, and in the process being more useful.
They won't make something better than bash -for all operating systems-; they'll make something better than bash -for Windows-. Cause bash on Windows sucks sewage. Bash on Windows, ultimately, is running on Windows. Bash + Xnix = Good; Bash + Windows = Barf.
They aren't trying to replace bash; most people on Windows don't use bash and never will. They use Rexx, and Perl, and VBScript, and 4DOS, and WinBatch, etc., etc.
MS is trying to replace CMD.EXE. To quote a certain jailbird named Stewart, "that's a good thing."
> This seems like a really weak defense and I'd be interested to know what the justifications the > judges are using to make such a ruling. It seems analagous to DNA testing. Should a rape suspect be > able to get off because he questioned how the DNA scanner works, and the court can't provide an answer?
Actually, yes. It has long been the standard in US courts that anyone presenting scientific or technological evidence -must- stand up to cross examination on details of the process.
DNA testing has often been challenged on this basis, and so has fingerprinting, drug testing, and other forensic evidence.
Throwing out the cases because the source is not available -may- be excessive, however the article indicated that the manufacturer has not been able or willing to provide answers to other questions as well.
It makes a -big- difference how some tests are conducted. Questionable data that can't be verified -should- be inadmissable.
Note: I am pretty much neutral on "open source", as in GPL'd source.
> The truth is that Sun has bent over backwards for the OSS community, and all they get for their > troubles are painful stabs in the back.
Depends on your point of view. In a sense, I agree with you.
Microsoft, for instance, has a blatantly adversarial relationship with the OSS community. While you are correct that Sun does not, there is a problem with Sun's relationship with the OSS community. It's a disfunctional relationship. Sun's leadership has an idea of how things ought to be, and the OSS community has a different idea of how things ought to be.
It's close, but Sun -really- would like to gloss over some things, like the fact that the OSS community believes in -giving up ownership of the source-, and Sun doesn't. So Sun keeps coming up with almost, but not quite open source moves, and people who view them as fair (like yourself), feel that the reactions are out of proportion.
They aren't. The parts that Sun wants to ignore are -critical- to the identity of the OSS movement. Sure, it's a religious issue. That doesn't mean it isn't an issue.
> Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable.
From a certain point of view, you're right. But some of those loud mouths -run- the company.
> Despite all the nonsense about "contamination", has anyone EVER had Sun sue them?
Sorry, not the point. Sun could, legitimately, sell their ownership of their Java IP to someone down the road; even Microsoft. What if that company decides to sue?
I once went to work for a company because I knew the guy who ran the department I'd be in. It was great...until he got promoted and transferred.
Then I got stuck with the biggest a**hole I ever worked for. Not happy again until I left that job.
It's not about "Sun sucks"; it's about not trusting in princes. Even if the prince is, well "a prince", princes die, they are overthrown; they even change their minds.
"A lot of things can happen in a year. The king might die. The horse might die. I might die. And, who knows? Maybe the horse will sing." -- The Mote in God's Eye.
You're right about practice, but some things that typing tutor programs can help with are:
- improving typing of less-frequently used letter combinations - forcing you to slow down and type correctly, by not letting you speed up until your accuracy improves - prohibiting the use of cut and paste for corrections (forces you to type more accurately)
> "Only question now is not if but when will Linux become the number one OS on earth?" > > This is the attitude that is going to prevent that from ever happening.
Agreed. About 20 years ago, many people said: "Only question now is not if but when will -Apple- become the number one -PC computer company- on earth?"
Apple had the opportunity to dominate, and failed to capitalize on it. No matter -how- good the product, no matter -how- perfect the opportunity, no matter -how- insanely ideal the timing, you can -always- fail to capitalize on it.
And in many ways the combination of product, opportunity and timing for Linux now is far from as good as the combination for Apple was then.
Linux might well come to dominate the market. But not because it cannot fail to do so. Failure can -always- happen.
> I wish the movers and shakers in the Linux world would decide to focus on a subset of the OS > market, and do it well, instead of trying to do everything and losing focus of good engineering practices.
Agreed wholeheartedly. Attitude is important. One significant reason Apple failed to dominate was that Apple and their adherents spent far too much time "waiting for those morons using Micro$oft's OS to wise up and recognize the inherent superiority of -our- product," something that is very common among Linux advocates now. That attitude makes it -very- comfortable to ignore your own inadequacies and disregard thos with legitimate complaints.
BTW, don't bother flaming me. I think Linux is going to continue to become more important; I just don't agree that dominance is inevitable. If it happens it will be the product of sustained hard work, alertness, and a willingness to admit mistakes and correct them.
> Afraid to upset MS? What have they got against saving money? Sounds like some people in education > need to get their asses fired.
One of the problems is typical of an entrenched bureaucracy: the feedback systems are set up to prevent blame from being attached rather than preventing errors or accomplishing goals.
Bureaucracies are geared toward getting all the ducks in a row. As long as all the ducks are in a row, all is well, even if they are facing the wrong direction. Uniformity is good. Being invisible is good. Being a standout is -very bad-.
Someone in the school that wishes to take a cost cutting move has to accept responsibility. Then he has to take action against the flow; he has to be the duck which is obviously facing a different direction.
This makes him a magnet for criticism. All the incompetents who might be made to look bad have to get him in line. Not only that, but there is pressure from those who quietly agree with him and all his close coworkers, because their proximity to him makes them magnets for criticism.
Even if he wins, he loses. Everyone now remembers him as the trouble-magnet.
Bureacracies don't work well with change. Better or worse is irrelevant. All they are concerned about is having the ducks in nice, neat rows.
That's one reason why educational standards in the U.S. took a nosedive after the creation of the federal Department of Education. They just increased the amount of bureaucracy, which just made the problem worse.
Educators, flame me if you wish; most teachers are good; but most school -systems- stink.
Agreed; most dissidents are technically criminals at one time or another. Civil disobedience, no matter how non-violent, tends to result in arrests, and frequently convictions.
The key point in the definition of 'terrorist' is the 'terror' part of it. They use violence and intimidation against non-combatents in order to induce terror, as part of a program of social disruption.
You make some good points. I think one thing that might be affecting people's perceptions is the different way people perceive and are calculating costs.
For example, a lot of people here have talked about the ease of installation and configuration and the learning curve on support people.
But here's a thought: if I have outsourced my support, it is irrelevant to ME what the actual difficulty is; it's a matter of 'what will I be charged?' Just because MySql is cheaper than SQL Server or Oracle, I may not see a significant difference in the support costs that the available local support firms charge for support; and you can't gloss over the key words 'available' and 'local'.
I know a number of firms that lease the PCs, with software. The question for them is not 'what is the cost of the software' but what is the cost of the PACKAGE the vendor leases. If Dell does not discount for Linux with Open Office, then I don't realize any benefit, regardless of the relative costs of Linux vs. Windows and Open Office vs. MS Office.
And the choice of going with [New vendor] versus Dell is not always an easy sell. The uncertainty overrules any cost benefit. I have seen many people absolutely stunned that I can get a PC locally for $300 that has the same approximate specs as a Dell costing more than twice the price. But that doesn't change the way they purchase or lease PCs; too much uncertainty on their part, similar to the old adage 'nobody ever got fired for buying IBM'.
If the decision to spend is made by someone not aware of the technical issues (which is a common occurrence), they look at other issues. I think people may be glossing over some factors in the middle economic layers of the transactions.
For example, one reason a lot of companies designed applications in Visual Basic is -not- because of technical reasons. A lot of times the decision was made because the HR department was confident they could hire or contract VB programmers. HR had the perception that there was a smaller pool of local talent in other, more technically efficient languages, and I can't honestly say that HR was wrong.
It's very difficult and time consuming the address all the issues like this that come up, especially for technicans who tend to be unaware of the non-technical business issues.
> Well, if you're using low level code still, like Win32 constructs and other windows C++ specific data > types, you may indeed be faced with work to do. I remember arguments passing from 16bit OLE interfaces > into 32bit C++ EXEs that was troublesome. However in this switch, the code should run fairly fine.
One major caveat. MS didn't widen the size of int for 64 bit, so they added a lot of new typedefs in the headers. This is to deal with trouble from void * parameters that -may- be pointers, or ints, or longs, etc., etc.
But there aren't -that- many, and MS has been agressively updating the docs and headers with these new typedefs for a couple of years now. The SDK includes a version of the 64-bit compiler so you can test-compile and see the likely trouble spots.
It should be much easier to port Win32->Win64 than Win16->Win32. But I haven't done any porting yet.
>> I kind of like "until the publishing author dies +10 years.
> I don't. That's too long and the length is highly unpredictable.
Agreed; it's too long if the creator is young and too unpredictable if the creator is older or dies young. You'll get a guy like Bill Gates, who creates something in his youth in the right place at the right time, who derives decades of advantage. To the -detriment- of society. Then you'll have a guy who creates something in his later years and dies of a coronary. His publisher then schedules publication so that they get all the revenue, and the family gets nothing.
> If you want to help survivors, I suggest using systems that EVERYONE can take advantage of -- > life insurance, social welfare systems, etc. To even imagine copyright as a way to provide for > survivors is reprehensible. You have better odds betting junior's college fund at the track!
I have to disagree. You're right about the fact that people generally -don't- make a lot money for the heirs through the property, but a lot of people also need the smaller revenue. I know of a -lot- of artists and writers whose families were kept together by the revenues from various works.
The real problem with the current system is that the periods are too long after the creator's death. Just limit the periods in a reasonable way, and allow for limited extensions. Do the math and look at all the ways a given calculation can be abused, rather than focusing on the 'typical' case.
>> Some may disagree - but then again, why should *my* works be subject to *your* whims?
> Well, you have no natural right to a copyright. I OTOH have a natural right of free speech and > press, encompassing repeating what you said.
That's a good point. The 'right to prohibit people from making copies of your work' is -NOT- a right. It's a legal privilege extended to the creators of works, in order to better society by stimulating the creation of works. But note that in today's secular humanist society, the idea of 'natural rights' may not be one that many posters are really familiar with.
Your reply seems a little hot; I wonder if you saw something in my post that I didn't intend. If so, my apologies.
>> But since this is a sponsored log inviting comments, it implies an open forum for honest comments
> No it doesn't. It implies that you will be given an opportunity to participate in discussion started by > people that work for HP, and that said discussion will flow in whatever way the people at HP wants.
I view this a bit differently, as do a large portion of the respondents. But neither my point of view or yours is definitive. As I said earlier, HP has the right to do what they want with the blog. And the public has a right to castigate them for the decisions they make. And some of the public has chosen to do so.
> That doesn't make them their blog biased or unbiased, it makes it edited.
Sorry, I have to view this a little differently. I'm not saying I'm right and your wrong; I'm saying that this is an area outside objective standards. The blog format begs comments. If they wanted to do that in a moderated fashion, they just had to say so. There isn't anything completely -immoral- about removing the comments. Just slightly deceptive. Not in a 'Where are the missing 18 minutes' way, but like mom saying 'Oh, no, we are one big happy family. -Other- families may fight on Thanksgiving, but not us' with a sickly, valium smile.
> There's nothing about the 'marketing' of these blogs that indicates that they are a forum for polemic.
That's probably one of the key disagreements here. I did not view the comments as an attack. Criticism, yes, but not over an implicit boundary that requires deletion. Again, they have the right to do so. But having the -right- to do so doesn't make it a good idea.
And while there is nothing in the marketing that indicates comments are welcomed, there is nothing to indicate that only positive feedback will be accepted. It -looks- like all comments not blatantly off-topic or obscene will be accepted.
> The funny thing about all of this non-issue about "censorship," is that a newspaper would just > toss the letters it doesn't want to publish in the garbage without anyone ever knowing their contents.
It's not a censorship issue, in my mind. That may be where we are having a conflict. You don't view it as censorship, and neither do I. But we still disagree. I view it as poor manners. Not unethical, but impolite, and indicative of a lack of understanding on HP's part (or David Gee's). On a par with posting improperly in a usenet newsgroup without reading the FAQ first, or inviting people to a business seminar and then trying to sell them a franchise. Just rude.
I started to argue about the value of taking legal action, then I noticed you recommending he deal directly with the labor board. Exactly right; you normally don't need a lawyer for this. Every labor board varies, but all I know of will accept the complain without a lawyer.
Another bonus; many states respond to allegations of employers fiddling with paychecks to audit the employer's payroll recordkeeping. Sometimes these rules are a pain; if they do so, it will most likely be a painful experience for the boss, even if they are diligent about recordkeeping. I once worked as an assistant manager for a company that got hit by the state for using the -wrong color pen- on bookeeper notes on employee timecards.
>> But they call it a blog, a term that means one thing - a site for public news and discourse. > > Oh, is that the definition...[my weblog is] not a "site for public news and discourse". > It's a site where I spew lies, write boring shit, display my incompetence for all > to see, and occasionally put something interesting up (Much like Slashdot!)
Good point. All blogs don't exist for the same reason.
> I think HP ought to have the same privilege on their own site.
They do. But since this is a sponsored log inviting comments, it implies an open forum for honest comments, both negative and positive. And there is no indication that negative comments will be deleted, nor indication that a negative comment -has- been deleted. HP has the -right- to set up a positive-comments only weblog, if they wish. But they also have to accept that doing so exposes them to legitimate criticism for doing so.
It's not that refusing to accept negative, spam, or off-topic comments is unfair. It's that they have given the -impression- that this is an unbiased comment log. Deleting unfavorable comments -quietly- is a subtle lie.
It might not be an evil, intentional lie, but it is a lie. That said, I think David Gee respondend adequately, if not as informatively as some would like.
> I don't like the idea of making assumptions that just because a system is 20 years old, that it absolutely must be replaced.
>...if I have a 20 year old system that I can't get parts for, that's a high risk system. > However, if I can get parts for a 20 year old system, then the risk is lower.
Good points. The article does contain some facts, though. The system was Fortran based, ran only on one aging hardware platform, and no one at Comair knew Fortran. Those are risk factors with older software.
A better lesson than the article's implied "don't use old software" lesson would be, "periodically review legacy systems against changed business conditions and environment. Do not assume that software and hardware will continue to function when the business environment changes significantly."
> Does anyone else see the shear irony of these words coming from a purveyor of MP3 players? > Sounds like a maker of pocket knives pooh-poohing those Swiss guys with their inferior, do-everything knives. > > Look, good enough is good enough.
Hard to say; hard-core music people tend to be -really- particular about the hardware they use. I'm sure there's a big enough market for 'good enough' quality for these to be a winner, but they may -not- be able to compete with the hardcore music buffs.
Re: "That comment is a good match for the code it is with. I never write comments like that unless dealing with a 3rd party interface, or something else that is a brick wall I can't refactor across, and there is something very quirky or unusual about it."
I think there's an important point there. Code == documentation makes the assumption that the code is clear. Many times it isn't -possible- to make the code as clear as it needs to be to be useful as documentation. Third-party code is one of the reasons; time constraints and legacy codebases are a couple of others.
I remember once in the newsgroups, P. J. Plaugher was discussing the C++ Standard Library implementation in VC6, and mentioned that one reason the code was unclear was because of compiler limits; when VC expanded certain templates, the identifiers for some template classes exceeded the compiler's limits.
What else makes it more difficult or impossible to write code that is clear enough to be documentation?
> Tridgell's decision to reverse-engineering Bitkeeper. The resulting clone would violate > BitMover's intellectual property -- something McVoy wasn't going to sit back and watch happen." > Again, no, it wouldn't. My understanding is that reverse engineering for interoperability is legally fine.
Without commenting on the issue of right or wrong, I feel that there is a difference of opinion on a core fact; was what Tridgel doing reverse engineering file formats for interoperability or not?
My understanding of BitKeeper's position (correct me if I am wrong) is that Tridgel had no separate application functionality for which he had a need to access the BitKeeper files. That he was not providing a separate application, which in addition to its normal operations, could access BitKeeper files.
Rather that he was cloning BitKeeper, by reverse engineering the file format -and- the application's operations.
I do not claim that this is what he did; I am simply stating that my understanding is that this is BitKeeper's claim.
It seems Linus would have been fine with Tridgell creating a new SCM system, and then making it able to use BitKeeper data. The objection is that in addition to reverse engineering the file formats, he was reverse engineering the application itself.
Please do not bother to argue me out of this view, it's not my view; I have no strong opinions on this. It's just my understanding of the view BitKeeper has expressed.
I like the Purpose And Context and System Overview at the start. I have never been on a project that failed if there was a clear vision of the purpose.
The Compliance Matrix is good too.
Regarding Assumptions:
> * Check these! Often the users needs to agree to these (but make sure they actually > understand the implications!)
Here be dragons; I've been thinking about the projects I have been on in the past where assumptions bit us, and I think one problem is that users agree to them too easily.
Too many projects start off for internal network use only; then need to support dial-up; then need to support 100 times as many users as originally decided.
I think it might be best to document the consequences of these assumptions. Add something in the design document like this:
'Application will support high-speed local LAN connections only. Adapting the application for other connections, including but not limited to VPN and web access, cannot be retrofitted into this version, and will require creating new application version. This will require all ordinary resources, calendar time, and expense for a -new- project, and will require a complete reestimation process.'
The idea being to deal with inevitable requests to just bolt on the web access. It doesn't have to be this wordy or formal, but document and get sign off that this is a major design decision, and that we can change these assumptions just like the requirements, -but- that it will have big consequences, and here is what they are.
You are correct that there is no contract, but not because "no signature, no verbal promise, no handshake, no nothing." A social contract doesn't require that. But a social contract does require good will on both sides, fair play, and static or -slowly- evolving terms. These terms become the contract. Like the common law, they evolve over time.
The advertisers are trying to say they can change their obligations; their side of the social contract at any time, without any veto power on our side. That's what makes it invalid. If you know going in to a site that it is ad-supported; that the ads are static images; and that viewing them is a prerequisite for using the site. then you accept a social contract when entering the site. Fair for both sides.
But the advertisers didn't like that deal; they changed it by adding pop-up windows; intrusive Javascript that opens one window as soon as you close the first; tying tracking cookies to image links on ad sites; flash animations; ActiveX controls; and more every day.
If they want a social contract, they have to play fair. They went beyond "social contracts" a long time ago. And if they want an actual contract, they need to start specifying terms up front.
And recognize that consumers -always- have veto power. As long as advertisers try to force their terms down people's throats using active content, blocking tools have legitimate uses.
Good documentation serves multiple different purposes. It should introduce new users to the tools, and assist them in answering the question, "is this the right tool for my needs?". It should help the user to understand how the tools work. It should give practical examples of how to perform various tasks. It should serve as a definitive function reference for skilled users. And it should be easy to search.
The first, introduction, requires a good table of contents, and some good overview and structural documentation. This cannot be automatically generated, and should not usually be written by the developers. The skills involved in good technical writing and good coding don't usually overlap that well.
The second, understanding, is an extension of the first. It should blend practical, real-world-type examples with subject-by-subject introduction and overview. The purpose here is not to teach "how to do [blank]" so much as to explain enough of how [blank] is done to allow readers to start putting the pieces together for themselves. Some tasks require contra-intuitive setup and tear-down, or an understanding of how the setup and tear-down tasks are intended to function.
The third, practical examples, can be partly automated. Two warnings:
1: Real code isn't necessarily the best example. Often, real, production code has dependencies or compromises that makes for over-complicated examples. Have a non-techie read it for sense.
2: Keep examples small but complete, and include the values of parameters where possible. I recently saw a fully accurate example for a vendor's API that was absolutely useless. Four of five function parameters were either custom format strings of bar-delimited command sequences, and nowhere were there examples of format strings or valid commands. The example was something like: "ExecPFECommand(fs, cs,....), where fs is a valid format string, cs is a valid command string,..." Accurate, but not worth the space it took up.
Fourth, a definitive reference, should be automated as much as possible. Keep in mind that real-life function names and parameter names can be cryptic. If they are, fix them up or alias the formal parameter names in the documentation to something meaningful. It's got to be correct; that's why so many people want to automate this kind of documentation. Beware of things that can trip up automated documentation generators. Sometimes developers add extra parameters to functions, for "the next version". Document that they are unused. If they must be NULL, then document that as well. Sometimes features are removed in non-obvious ways. Consider an API with an object that implements a printf() style formatted output function. Suppose a developer originally intended to support all the printf format-codes, but later they reduced this to a subset. Remove the references to format codes/options that the API no longer respects.
Fifth, search ability, is critical. This involves more than just having a decent search engine; you also need a human being to identify keywords and tag pages in the documentation to build high-quality indexes.
A few additional points:
Keep terminology consistent and avoid generic terms with existing meanings. Example: same vendor as above, used the terms Object and Entity in non-standard ways in a system using both objects and a relational database. Better to either qualify the term (PFEObject and PFEEntity, for instance), or come up with something else.
Watch out for cruft in function, variable, object and structure names. If you're lucky, it would be no worse than the Afx-prefixes all through Microsoft's MFC libraries. If you're not, you end up adding more people to phone support to explain defects in the documentation.
Plan for obsolescence. If various interfaces aren't really generic, don't pretend they are. You didn't mention languages, so I can't be specific. C++ for instance would let you use namespaces for multiple versions. But you might want to encode the application version in the names. But you might want to encode the application version in the function and type names. It's ugly, but it does work. And most people here would rather have "ugly but works" over "attractive, but breaks often".
One thing I think can cause conflicts with family is when you and the family member value your time differently. I have some relatives I won't do support for, simply because their time is worth nothing to them, and they suck up my time as if it means nothing to me.
Some people will spend hundreds of hours trying to get cheap garbage hardware working (like no-name sound cards or modems), rather than spend $20 for something that works.
I've been in situations where I've manually reconfigured the same modem 10 times in 6 months, because the relative reinstalls the same cute, but useless software package that kills it. Finally, you just give up.
Texas Forensic Association? Tennessee Firearms Association? Table Footie Association? (I like that one) Tampa Fencing Academy? Trifluoroacetic acid? Trees For Africa? Time Finance Adjusters? (seems to be repo men)
(I felt whimsical; posted a selection of the more interesting sounding Google results for 'TFA';> )
Slashdot Mirror
While there is some overlap between college and education, it's always been true and always will be that some people can get an education without college, and others can't get an education with unlimited college coursework.
While there is a statistical minority of people who drop out of college and learn more on through self teaching, the reality is:
1-these people will always be a small minority
2-they will be held up as an example by the intellectually lazy and by egotistical poseurs who want to be accorded respect they never have and never can earn on their own
3-most people who -can- learn on their own do just fine in a college environment
I think the 'leet-speak' wannabe sysadmin example indicates one of the key points. People who -can- walk the walk don't need to baffle with bullshit. Anytime anyone tries that kind of thing, it's usually safe to assume he's all talk. If he's not, he'll rise to the challenge and prove himself.
It's a bit like tossing the kid in the water to teach him to swim; just because it sometimes works doesn't make it the best method.
> Collisions are NOT and accidential everyday occurance.
Probably.
Playing the Devil's advocate here. Collisions would be impacted, possibly -very- strongly, by exactly how the GUIDs are generated. Just because there are 2^128 bits to play with doesn't mean we are using them all. There may be significant gaps; a large number of values may never be generated by the algorithm used.
Combine with human errors in coding the algorithm and the odds of a collision may be much greater than expected.
> Yes, I totally agree. Linux/UNIX shells have been developed, tested and improved by hundreds
> (thousands?) of people who use them repeatedly every day over the course of more than 20 years. How
> the hell is MS going to make something superior in 3-5?
By making something that does not require hacks to make Windows work sorta/kinda like Unix underneath it all, and in the process being more useful.
They won't make something better than bash -for all operating systems-; they'll make something better than bash -for Windows-. Cause bash on Windows sucks sewage. Bash on Windows, ultimately, is running on Windows. Bash + Xnix = Good; Bash + Windows = Barf.
They aren't trying to replace bash; most people on Windows don't use bash and never will. They use Rexx, and Perl, and VBScript, and 4DOS, and WinBatch, etc., etc.
MS is trying to replace CMD.EXE. To quote a certain jailbird named Stewart, "that's a good thing."
> This seems like a really weak defense and I'd be interested to know what the justifications the
> judges are using to make such a ruling. It seems analagous to DNA testing. Should a rape suspect be
> able to get off because he questioned how the DNA scanner works, and the court can't provide an answer?
Actually, yes. It has long been the standard in US courts that anyone presenting scientific or technological evidence -must- stand up to cross examination on details of the process.
DNA testing has often been challenged on this basis, and so has fingerprinting, drug testing, and other forensic evidence.
Throwing out the cases because the source is not available -may- be excessive, however the article indicated that the manufacturer has not been able or willing to provide answers to other questions as well.
It makes a -big- difference how some tests are conducted. Questionable data that can't be verified -should- be inadmissable.
Note: I am pretty much neutral on "open source", as in GPL'd source.
> The truth is that Sun has bent over backwards for the OSS community, and all they get for their
> troubles are painful stabs in the back.
Depends on your point of view. In a sense, I agree with you.
Microsoft, for instance, has a blatantly adversarial relationship with the OSS community. While you are correct that Sun does not, there is a problem with Sun's relationship with the OSS community. It's a disfunctional relationship. Sun's leadership has an idea of how things ought to be, and the OSS community has a different idea of how things ought to be.
It's close, but Sun -really- would like to gloss over some things, like the fact that the OSS community believes in -giving up ownership of the source-, and Sun doesn't. So Sun keeps coming up with almost, but not quite open source moves, and people who view them as fair (like yourself), feel that the reactions are out of proportion.
They aren't. The parts that Sun wants to ignore are -critical- to the identity of the OSS movement. Sure, it's a religious issue. That doesn't mean it isn't an issue.
> Yeah, Sun's got some loud mouths working for them. But their actions have ALWAYS been honorable.
From a certain point of view, you're right. But some of those loud mouths -run- the company.
> Despite all the nonsense about "contamination", has anyone EVER had Sun sue them?
Sorry, not the point. Sun could, legitimately, sell their ownership of their Java IP to someone down the road; even Microsoft. What if that company decides to sue?
I once went to work for a company because I knew the guy who ran the department I'd be in. It was great...until he got promoted and transferred.
Then I got stuck with the biggest a**hole I ever worked for. Not happy again until I left that job.
It's not about "Sun sucks"; it's about not trusting in princes. Even if the prince is, well "a prince", princes die, they are overthrown; they even change their minds.
"A lot of things can happen in a year. The king might die. The horse might die. I might die. And, who knows? Maybe the horse will sing." -- The Mote in God's Eye.
You're right about practice, but some things that typing tutor programs can help with are:
- improving typing of less-frequently used letter combinations
- forcing you to slow down and type correctly, by not letting you speed up until your accuracy improves
- prohibiting the use of cut and paste for corrections (forces you to type more accurately)
But as you say, practice is key.
> "Only question now is not if but when will Linux become the number one OS on earth?"
>
> This is the attitude that is going to prevent that from ever happening.
Agreed. About 20 years ago, many people said: "Only question now is not if but when will -Apple- become the number one -PC computer company- on earth?"
Apple had the opportunity to dominate, and failed to capitalize on it. No matter -how- good the product, no matter -how- perfect the opportunity, no matter -how- insanely ideal the timing, you can -always- fail to capitalize on it.
And in many ways the combination of product, opportunity and timing for Linux now is far from as good as the combination for Apple was then.
Linux might well come to dominate the market. But not because it cannot fail to do so. Failure can -always- happen.
> I wish the movers and shakers in the Linux world would decide to focus on a subset of the OS
> market, and do it well, instead of trying to do everything and losing focus of good engineering practices.
Agreed wholeheartedly. Attitude is important. One significant reason Apple failed to dominate was that Apple and their adherents spent far too much time "waiting for those morons using Micro$oft's OS to wise up and recognize the inherent superiority of -our- product," something that is very common among Linux advocates now. That attitude makes it -very- comfortable to ignore your own inadequacies and disregard thos with legitimate complaints.
BTW, don't bother flaming me. I think Linux is going to continue to become more important; I just don't agree that dominance is inevitable. If it happens it will be the product of sustained hard work, alertness, and a willingness to admit mistakes and correct them.
> Afraid to upset MS? What have they got against saving money? Sounds like some people in education
> need to get their asses fired.
One of the problems is typical of an entrenched bureaucracy: the feedback systems are set up to prevent blame from being attached rather than preventing errors or accomplishing goals.
Bureaucracies are geared toward getting all the ducks in a row. As long as all the ducks are in a row, all is well, even if they are facing the wrong direction. Uniformity is good. Being invisible is good. Being a standout is -very bad-.
Someone in the school that wishes to take a cost cutting move has to accept responsibility. Then he has to take action against the flow; he has to be the duck which is obviously facing a different direction.
This makes him a magnet for criticism. All the incompetents who might be made to look bad have to get him in line. Not only that, but there is pressure from those who quietly agree with him and all his close coworkers, because their proximity to him makes them magnets for criticism.
Even if he wins, he loses. Everyone now remembers him as the trouble-magnet.
Bureacracies don't work well with change. Better or worse is irrelevant. All they are concerned about is having the ducks in nice, neat rows.
That's one reason why educational standards in the U.S. took a nosedive after the creation of the federal Department of Education. They just increased the amount of bureaucracy, which just made the problem worse.
Educators, flame me if you wish; most teachers are good; but most school -systems- stink.
Agreed; most dissidents are technically criminals at one time or another. Civil disobedience, no matter how non-violent, tends to result in arrests, and frequently convictions.
The key point in the definition of 'terrorist' is the 'terror' part of it. They use violence and intimidation against non-combatents in order to induce terror, as part of a program of social disruption.
> It seems to me that a company profiting from its own security holes is a serious conflict of interest.
Yep. Additional concerns:
- MS altering the OS to 'enhance' the performance of their antivirus product, while reducing the performance of others.
- Effect of the existence of 'MS Antivirus' service on Microsoft's timing and implementation of security fixes.
The first two make me wonder about these possibilities:
- Requiring Microsoft Internet Explorer to access MS Antivirus updates.
- Requiring MS Antivirus updates to install OS security updates.
You make some good points. I think one thing that might be affecting people's perceptions is the different way people perceive and are calculating costs.
For example, a lot of people here have talked about the ease of installation and configuration and the learning curve on support people.
But here's a thought: if I have outsourced my support, it is irrelevant to ME what the actual difficulty is; it's a matter of 'what will I be charged?' Just because MySql is cheaper than SQL Server or Oracle, I may not see a significant difference in the support costs that the available local support firms charge for support; and you can't gloss over the key words 'available' and 'local'.
I know a number of firms that lease the PCs, with software. The question for them is not 'what is the cost of the software' but what is the cost of the PACKAGE the vendor leases. If Dell does not discount for Linux with Open Office, then I don't realize any benefit, regardless of the relative costs of Linux vs. Windows and Open Office vs. MS Office.
And the choice of going with [New vendor] versus Dell is not always an easy sell. The uncertainty overrules any cost benefit. I have seen many people absolutely stunned that I can get a PC locally for $300 that has the same approximate specs as a Dell costing more than twice the price. But that doesn't change the way they purchase or lease PCs; too much uncertainty on their part, similar to the old adage 'nobody ever got fired for buying IBM'.
If the decision to spend is made by someone not aware of the technical issues (which is a common occurrence), they look at other issues. I think people may be glossing over some factors in the middle economic layers of the transactions.
For example, one reason a lot of companies designed applications in Visual Basic is -not- because of technical reasons. A lot of times the decision was made because the HR department was confident they could hire or contract VB programmers. HR had the perception that there was a smaller pool of local talent in other, more technically efficient languages, and I can't honestly say that HR was wrong.
It's very difficult and time consuming the address all the issues like this that come up, especially for technicans who tend to be unaware of the non-technical business issues.
> Well, if you're using low level code still, like Win32 constructs and other windows C++ specific data
> types, you may indeed be faced with work to do. I remember arguments passing from 16bit OLE interfaces
> into 32bit C++ EXEs that was troublesome. However in this switch, the code should run fairly fine.
One major caveat. MS didn't widen the size of int for 64 bit, so they added a lot of new typedefs in the headers. This is to deal with trouble from void * parameters that -may- be pointers, or ints, or longs, etc., etc.
But there aren't -that- many, and MS has been agressively updating the docs and headers with these new typedefs for a couple of years now. The SDK includes a version of the 64-bit compiler so you can test-compile and see the likely trouble spots.
It should be much easier to port Win32->Win64 than Win16->Win32. But I haven't done any porting yet.
>> I kind of like "until the publishing author dies +10 years.
> I don't. That's too long and the length is highly unpredictable.
Agreed; it's too long if the creator is young and too unpredictable if the creator is older or dies young. You'll get a guy like Bill Gates, who creates something in his youth in the right place at the right time, who derives decades of advantage. To the -detriment- of society. Then you'll have a guy who creates something in his later years and dies of a coronary. His publisher then schedules publication so that they get all the revenue, and the family gets nothing.
> If you want to help survivors, I suggest using systems that EVERYONE can take advantage of --
> life insurance, social welfare systems, etc. To even imagine copyright as a way to provide for
> survivors is reprehensible. You have better odds betting junior's college fund at the track!
I have to disagree. You're right about the fact that people generally -don't- make a lot money for the heirs through the property, but a lot of people also need the smaller revenue. I know of a -lot- of artists and writers whose families were kept together by the revenues from various works.
The real problem with the current system is that the periods are too long after the creator's death. Just limit the periods in a reasonable way, and allow for limited extensions. Do the math and look at all the ways a given calculation can be abused, rather than focusing on the 'typical' case.
>> Some may disagree - but then again, why should *my* works be subject to *your* whims?
> Well, you have no natural right to a copyright. I OTOH have a natural right of free speech and
> press, encompassing repeating what you said.
That's a good point. The 'right to prohibit people from making copies of your work' is -NOT- a right. It's a legal privilege extended to the creators of works, in order to better society by stimulating the creation of works. But note that in today's secular humanist society, the idea of 'natural rights' may not be one that many posters are really familiar with.
Your reply seems a little hot; I wonder if you saw something in my post that I didn't intend. If so, my apologies.
>> But since this is a sponsored log inviting comments, it implies an open forum for honest comments
> No it doesn't. It implies that you will be given an opportunity to participate in discussion started by
> people that work for HP, and that said discussion will flow in whatever way the people at HP wants.
I view this a bit differently, as do a large portion of the respondents. But neither my point of view or yours is definitive. As I said earlier, HP has the right to do what they want with the blog. And the public has a right to castigate them for the decisions they make. And some of the public has chosen to do so.
> That doesn't make them their blog biased or unbiased, it makes it edited.
Sorry, I have to view this a little differently. I'm not saying I'm right and your wrong; I'm saying that this is an area outside objective standards. The blog format begs comments. If they wanted to do that in a moderated fashion, they just had to say so. There isn't anything completely -immoral- about removing the comments. Just slightly deceptive. Not in a 'Where are the missing 18 minutes' way, but like mom saying 'Oh, no, we are one big happy family. -Other- families may fight on Thanksgiving, but not us' with a sickly, valium smile.
> There's nothing about the 'marketing' of these blogs that indicates that they are a forum for polemic.
That's probably one of the key disagreements here. I did not view the comments as an attack. Criticism, yes, but not over an implicit boundary that requires deletion. Again, they have the right to do so. But having the -right- to do so doesn't make it a good idea.
And while there is nothing in the marketing that indicates comments are welcomed, there is nothing to indicate that only positive feedback will be accepted. It -looks- like all comments not blatantly off-topic or obscene will be accepted.
> The funny thing about all of this non-issue about "censorship," is that a newspaper would just
> toss the letters it doesn't want to publish in the garbage without anyone ever knowing their contents.
It's not a censorship issue, in my mind. That may be where we are having a conflict. You don't view it as censorship, and neither do I. But we still disagree. I view it as poor manners. Not unethical, but impolite, and indicative of a lack of understanding on HP's part (or David Gee's). On a par with posting improperly in a usenet newsgroup without reading the FAQ first, or inviting people to a business seminar and then trying to sell them a franchise. Just rude.
I started to argue about the value of taking legal action, then I noticed you recommending he deal directly with the labor board. Exactly right; you normally don't need a lawyer for this. Every labor board varies, but all I know of will accept the complain without a lawyer.
Another bonus; many states respond to allegations of employers fiddling with paychecks to audit the employer's payroll recordkeeping. Sometimes these rules are a pain; if they do so, it will most likely be a painful experience for the boss, even if they are diligent about recordkeeping. I once worked as an assistant manager for a company that got hit by the state for using the -wrong color pen- on bookeeper notes on employee timecards.
>> But they call it a blog, a term that means one thing - a site for public news and discourse.
>
> Oh, is that the definition...[my weblog is] not a "site for public news and discourse".
> It's a site where I spew lies, write boring shit, display my incompetence for all
> to see, and occasionally put something interesting up (Much like Slashdot!)
Good point. All blogs don't exist for the same reason.
> I think HP ought to have the same privilege on their own site.
They do. But since this is a sponsored log inviting comments, it implies an open forum for honest comments, both negative and positive. And there is no indication that negative comments will be deleted, nor indication that a negative comment -has- been deleted. HP has the -right- to set up a positive-comments only weblog, if they wish. But they also have to accept that doing so exposes them to legitimate criticism for doing so.
It's not that refusing to accept negative, spam, or off-topic comments is unfair. It's that they have given the -impression- that this is an unbiased comment log. Deleting unfavorable comments -quietly- is a subtle lie.
It might not be an evil, intentional lie, but it is a lie. That said, I think David Gee respondend adequately, if not as informatively as some would like.
> I don't like the idea of making assumptions that just because a system is 20 years old, that it absolutely must be replaced.
>...if I have a 20 year old system that I can't get parts for, that's a high risk system.
> However, if I can get parts for a 20 year old system, then the risk is lower.
Good points. The article does contain some facts, though. The system was Fortran based, ran only on one aging hardware platform, and no one at Comair knew Fortran. Those are risk factors with older software.
A better lesson than the article's implied "don't use old software" lesson would be, "periodically review legacy systems against changed business conditions and environment. Do not assume that software and hardware will continue to function when the business environment changes significantly."
> Does anyone else see the shear irony of these words coming from a purveyor of MP3 players?
> Sounds like a maker of pocket knives pooh-poohing those Swiss guys with their inferior, do-everything knives.
>
> Look, good enough is good enough.
Hard to say; hard-core music people tend to be -really- particular about the hardware they use. I'm sure there's a big enough market for 'good enough' quality for these to be a winner, but they may -not- be able to compete with the hardcore music buffs.
Re: "That comment is a good match for the code it is with. I never write comments like that unless dealing with a 3rd party interface, or something else that is a brick wall I can't refactor across, and there is something very quirky or unusual about it."
I think there's an important point there. Code == documentation makes the assumption that the code is clear. Many times it isn't -possible- to make the code as clear as it needs to be to be useful as documentation. Third-party code is one of the reasons; time constraints and legacy codebases are a couple of others.
I remember once in the newsgroups, P. J. Plaugher was discussing the C++ Standard Library implementation in VC6, and mentioned that one reason the code was unclear was because of compiler limits; when VC expanded certain templates, the identifiers for some template classes exceeded the compiler's limits.
What else makes it more difficult or impossible to write code that is clear enough to be documentation?
> Tridgell's decision to reverse-engineering Bitkeeper. The resulting clone would violate
> BitMover's intellectual property -- something McVoy wasn't going to sit back and watch happen."
> Again, no, it wouldn't. My understanding is that reverse engineering for interoperability is legally fine.
Without commenting on the issue of right or wrong, I feel that there is a difference of opinion on a core fact; was what Tridgel doing reverse engineering file formats for interoperability or not?
My understanding of BitKeeper's position (correct me if I am wrong) is that Tridgel had no separate application functionality for which he had a need to access the BitKeeper files. That he was not providing a separate application, which in addition to its normal operations, could access BitKeeper files.
Rather that he was cloning BitKeeper, by reverse engineering the file format -and- the application's operations.
I do not claim that this is what he did; I am simply stating that my understanding is that this is BitKeeper's claim.
It seems Linus would have been fine with Tridgell creating a new SCM system, and then making it able to use BitKeeper data. The objection is that in addition to reverse engineering the file formats, he was reverse engineering the application itself.
Please do not bother to argue me out of this view, it's not my view; I have no strong opinions on this. It's just my understanding of the view BitKeeper has expressed.
I like the Purpose And Context and System Overview at the start. I have never been on a project that failed if there was a clear vision of the purpose.
The Compliance Matrix is good too.
Regarding Assumptions:
> * Check these! Often the users needs to agree to these (but make sure they actually
> understand the implications!)
Here be dragons; I've been thinking about the projects I have been on in the past where assumptions bit us, and I think one problem is that users agree to them too easily.
Too many projects start off for internal network use only; then need to support dial-up; then need to support 100 times as many users as originally decided.
I think it might be best to document the consequences of these assumptions. Add something in the design document like this:
'Application will support high-speed local LAN connections only. Adapting the application for other connections, including but not limited to VPN and web access, cannot be retrofitted into this version, and will require creating new application version. This will require all ordinary resources, calendar time, and expense for a -new- project, and will require a complete reestimation process.'
The idea being to deal with inevitable requests to just bolt on the web access. It doesn't have to be this wordy or formal, but document and get sign off that this is a major design decision, and that we can change these assumptions just like the requirements, -but- that it will have big consequences, and here is what they are.
You are correct that there is no contract, but not because "no signature, no verbal promise, no handshake, no nothing." A social contract doesn't require that. But a social contract does require good will on both sides, fair play, and static or -slowly- evolving terms. These terms become the contract. Like the common law, they evolve over time.
The advertisers are trying to say they can change their obligations; their side of the social contract at any time, without any veto power on our side. That's what makes it invalid. If you know going in to a site that it is ad-supported; that the ads are static images; and that viewing them is a prerequisite for using the site. then you accept a social contract when entering the site. Fair for both sides.
But the advertisers didn't like that deal; they changed it by adding pop-up windows; intrusive Javascript that opens one window as soon as you close the first; tying tracking cookies to image links on ad sites; flash animations; ActiveX controls; and more every day.
If they want a social contract, they have to play fair. They went beyond "social contracts" a long time ago. And if they want an actual contract, they need to start specifying terms up front.
And recognize that consumers -always- have veto power. As long as advertisers try to force their terms down people's throats using active content, blocking tools have legitimate uses.
Good documentation serves multiple different purposes. It should introduce new users to the tools, and assist them in answering the question, "is this the right tool for my needs?". It should help the user to understand how the tools work. It should give practical examples of how to perform various tasks. It should serve as a definitive function reference for skilled users. And it should be easy to search.
....), where fs is a valid format string, cs is a valid command string, ..." Accurate, but not worth the space it took up.
The first, introduction, requires a good table of contents, and some good overview and structural documentation. This cannot be automatically generated, and should not usually be written by the developers. The skills involved in good technical writing and good coding don't usually overlap that well.
The second, understanding, is an extension of the first. It should blend practical, real-world-type examples with subject-by-subject introduction and overview. The purpose here is not to teach "how to do [blank]" so much as to explain enough of how [blank] is done to allow readers to start putting the pieces together for themselves. Some tasks require contra-intuitive setup and tear-down, or an understanding of how the setup and tear-down tasks are intended to function.
The third, practical examples, can be partly automated. Two warnings:
1: Real code isn't necessarily the best example. Often, real, production code has dependencies or compromises that makes for over-complicated examples. Have a non-techie read it for sense.
2: Keep examples small but complete, and include the values of parameters where possible. I recently saw a fully accurate example for a vendor's API that was absolutely useless. Four of five function parameters were either custom format strings of bar-delimited command sequences, and nowhere were there examples of format strings or valid commands. The example was something like: "ExecPFECommand(fs, cs,
Fourth, a definitive reference, should be automated as much as possible. Keep in mind that real-life function names and parameter names can be cryptic. If they are, fix them up or alias the formal parameter names in the documentation to something meaningful. It's got to be correct; that's why so many people want to automate this kind of documentation. Beware of things that can trip up automated documentation generators. Sometimes developers add extra parameters to functions, for "the next version". Document that they are unused. If they must be NULL, then document that as well. Sometimes features are removed in non-obvious ways. Consider an API with an object that implements a printf() style formatted output function. Suppose a developer originally intended to support all the printf format-codes, but later they reduced this to a subset. Remove the references to format codes/options that the API no longer respects.
Fifth, search ability, is critical. This involves more than just having a decent search engine; you also need a human being to identify keywords and tag pages in the documentation to build high-quality indexes.
A few additional points:
Keep terminology consistent and avoid generic terms with existing meanings. Example: same vendor as above, used the terms Object and Entity in non-standard ways in a system using both objects and a relational database. Better to either qualify the term (PFEObject and PFEEntity, for instance), or come up with something else.
Watch out for cruft in function, variable, object and structure names. If you're lucky, it would be no worse than the Afx-prefixes all through Microsoft's MFC libraries. If you're not, you end up adding more people to phone support to explain defects in the documentation.
Plan for obsolescence. If various interfaces aren't really generic, don't pretend they are. You didn't mention languages, so I can't be specific. C++ for instance would let you use namespaces for multiple versions. But you might want to encode the application version in the names. But you might want to encode the application version in the function and type names. It's ugly, but it does work. And most people here would rather have "ugly but works" over "attractive, but breaks often".
One thing I think can cause conflicts with family is when you and the family member value your time differently. I have some relatives I won't do support for, simply because their time is worth nothing to them, and they suck up my time as if it means nothing to me.
Some people will spend hundreds of hours trying to get cheap garbage hardware working (like no-name sound cards or modems), rather than spend $20 for something that works.
I've been in situations where I've manually reconfigured the same modem 10 times in 6 months, because the relative reinstalls the same cute, but useless software package that kills it. Finally, you just give up.
Call me stupid if you like, but vas ist 'TFA'?
;> )
Texas Forensic Association?
Tennessee Firearms Association?
Table Footie Association? (I like that one)
Tampa Fencing Academy?
Trifluoroacetic acid?
Trees For Africa?
Time Finance Adjusters? (seems to be repo men)
(I felt whimsical; posted a selection of the more interesting sounding Google results for 'TFA'