Full-seek time has improved relatively little over the years, so a new high RPM disk will help when you have little data on the disk, which is all packed into a few close tracks, but not so much when the disk is 90% full. You can therefore sometimes be better off with a multi-disk set up (RAID, or just multiple file systems).
Freedom is slavery.
War is peace.
Yes citizen,
it is just words.
But words enable us to communicate concepts,
and thereby spread them.
If distinctions are undermined,
communication is hindered.
Sometimes,
especially when communicating unfamiliar concepts,
notational clarity is important.
The Best of All Possible Worlds
on
Microsoft's new CLI
·
· Score: 5, Interesting
'Monads' are part of
Leibnitz's philosophy,
which
Voltaire
famously satirised in
Candide
with the figure of
Dr. Pangloss,
who resolutely maintained that we live
in
'this, the best of all possible worlds'
despite a succession of disasters that would convince any sane man that he was wrong.
Based on my experience, a characteristic of a good manager is the ability to say no. Others posters have said you should not say "no" itself, but express it differently, in terms of scheduling and preferences: communication skill, scheduling and planning are what managers are paid to do.
I've seen the problems when managers were too spineless to say no. As you say, it might annoy the customer (who might be an 'internal' customer) in the short term, but that is nothing compared to the long-terms problems. In the long term, you need to have a good working relationship with your customers. That means mutual respect, including respect for the limitations under which you operate. Saying yes only seems like the easy option. It inevitably leads to an excessive workload, which means that somethings will not be done, or done late, or quality will suffer. The customer will then perceive you as being untrustworthy, for failing to deliver what was promised (perhaps implicitly). Aware that you have failed them, the customer will make even more demands, which you will be tempted to accept, to make up for it. A few cycles of this and your relationship will be entirely dysfunctional; they will make outrageous shrill demands, hoping to bully you into doing some of what they really want, and you will forever be in conflict. Don't go there.
If a techie is being placed in a position where he feels he has to say no, there has been a management failure: the techie is either being asked to also be a manager without having been formally made a manager, or a manager has not done their job.
If the techie is being asked to act as a manager, it might be useful if this was explicitly indicated in someway, so everyone is clear that he has the right to demand particular information (priority) and the right to bluntly say no (as a last resort).
Establish a relationship with your tech support:
If you have a tech support group you need to work with on a regular basis, try to get to know them by name, and be known to them by name. IF you prove to the Tier-2 guys that you really are Group 2, they MAY give you a direct number to them.
I've seen this work.
I was a sysadmin in a small software development company. I don't think they every realised it, but the (other) sysadmins there were very good (I was the junior), and the four of us gave them a very godd sysadmin to user ratio. We were an SGI shop. We often had problems that took far too long to resolve because everything had to go through tier-1, who could never help, before they were finally escalated to tier-2 (and rarely tier-3). My boss had a meeting with their manager. Thereafter, tier-1 officially knew it was OK to rapidly escalate us to tier-2, because we were clueful enough to fix simple problems.
I put three nics in a Pentium 90 that I found on a trash heap [to create a firewall]....
It's really easy to use and so far I've had no problems....
and all of them are using iptables...
so everything is really secure.
I've done something similar.
But did you RTFA?
It's point was that backdoors are often not blocked by firewalls because firewall policies on outgoing connections are usually permissive.
What matters, in the context of this article, is what your iptables restrict, not whether you have them at all.
As I read this little blurb, I was thinking to myself that this probably won't help me any, since I have a pirated copy of XP.
Well, either buy a legitimate copy or install an operating system that is free-as-in-beer.
You deserve no sympathy.
You are a thief.
Like many here, I'm no fan of Microsoft,
but there are no excuses for using pirate software.
If you genuinely can't afford it,
there are free (beer/dom) options instead.
But I find the idead that you can't afford it unconvincing.
Or did you steal your computer too?
Programming is all about tradeoffs. Sometimes you make sacrifices in order to get the job done.
Yes, and there's no sin in that... provided they are the right tradeoffs.
Too often I've seen managers demand 'tradeoffs' that were clueless. The classic is cutting testing because the customer is unhappy because the product is late. As if they would be happy with a useless bug riddled product. So next time management talks to that customer, the customer is pissed, has them over a barrel, and makes outrageous demands, which are agreed. Repeat. I've seen that cycle go around four times with management doing nothing to break it.
I've come across my fair share of incompetent programmers, but I would be overjoyed to have managers who were as competent at managing as the programmers are at programming.
As programmers we are paid to have and develop complex technical skills that are hard to use.
We are therefore paid more than the minimum wage.
Since managers are typically paid more than programmers, they should be more skilled at their job or should take responsibility for their mistakes. Yet when there is a management SNAFU,
the solution, apparently, is for the programmers to work harder.
Either that or the "laws" of nature are not laws, but merely guidelines, or emergent phenomenon.
Saying something is a 'law of nature' is to say that it is a regualrity that has been repeatedly well observed, with no relaible counter instances.
And that is all.
That's what the words mean.
The philosopher Hume
demolished
the idea of having certain knowledge about natural laws, two centuries ago.
The original poster was quite correct.
...a user base floating around 1M...
over 20 duplicate bugs for a single incident...
email to 5+ accounts, multiple forum posts, bugtracker, etc.
There are two aspects to user 'bug reports':
improving product quality (fixing bugs) and
user support (helping the user with a problem).
Organizations doing much of the latter
distinguish 'incidents' from defects (bugs).
An incident is a user report of a problem;
other users might have experienced the same problem,
but no matter, the incident is recorded
and a user-support person provides assistance.
The user is not responsible for recording bugs at all; the user-support person (or someone else)
does that.
Thereby, all bug reports are produced by internal staff, rather than customers, so you can enforce good bug reporting.
Also, the organization is set up so the
user has only one point of contact,
the user-support department,
so duplicate incident reports are eliminated too.
If this is new to you,
you might be interested in the
ITIL
Guidelines
Had Columbia been unmanned, there would be much less hand wringing. With astronauts on board, all the components must be higher-rated for safety, and you need all the additional mass for life-support, reducing the economic incentives. Astronauts don't become lighter, but Moore's Law makes unmanned craft better all the time.
Why do we have things like Columbine nowadays when these things were unheard of 30 years ago?
What makes you think things like it didn't happen 30 years ago?
Have you conducted an analysis of violence in schools?
I guess not.
The difference between then and now may simply be that you are much more aware of what is happening now, because of the are fresh in your mind and you were more than a baby at the time.
There is a general law-and-order nostalgia effect:
people say '30 years ago we didn't have violent problem X', but people have been say that for as far back as we have good records of popular opinion.
See
Pearson, C. (1983). Hooligan. A History of Respectable Fears. London, Macmillan.
Samples of work and confidentiality
on
Immortal Code
·
· Score: 1
a guy I was interviewing showed me (unasked) a spec he'd done, as a sample of his work. The copyright/confidentiality notice for a very large company was clearly printed right across the top.
to which a poster replied
What am I supposed to do? Say "I've done lots of cool stuff, but I can't tell you about it. Do I get the job?"
I was worried about being able to show a potential employer what I can do,
without breaking confidentiality.
Also, I wanted to be able to show that I could do more than the immediate job requirements of my previous job.
My solution was to put code I'd written in my spare time (GPL'ed) on my website.
When writing in high level languages, I'm finding that debuggers are wholly unnecessary.
Is that because of the high level language, or because high-level languages encourage better coding styles?
I'm thinking of programming by contract here. My C++ and C is fairly sprinkled with assert()s, and my Java will be be likewise, when I move to version 1.4.
With assertions on preconditions and postconditions and some unit tests, you can locate a bug to one method almost immediately, and if your methods are small (the current bast practice), that means only a handful of lines for you to inspect.
One of your repliers says:
I would like to add a third purpose that you should consider using a debugger for: Understanding other peoples code.
If you need a debugger to understand
what some code does, I suggest it it is badly written.
In light of the features of Fortran90, like
implicit none, do while, modules and derived types, a few of the points the poster makes are at least a decade out of date.
These days, many Fortran programmers may well compile their code using a Fortran-90 compiler. But many still write mostly Fortran-77; they don't take advatage of the improvements (or only a few); indeed, they are in a frightening number of cases unaware of the advantages of the improvements.
I've seen quite a bit of Fortran over the years, produced by people educated in England, the US, Canada, France, Germany, India, Iran, South Africa, Ireland, China, the former Yugoslavia (most parts), Scotland and Egypt. What is interesting is just how similar it all is, and how similar the attitudes of the people who wrote it are. Consider that it took about a dozen years for all the changes in Fortran-77 to percolate into the Fortran community.
I think its interesting that such a subculture should exist, especially in an academic (or quasi academic) area where values such as expertise, innovation and technical skill might be expected to be influential. The very fact that you hang out on/. makes you exceptional. Perhaps your own particular area has a slightly different sub culture. Good for you!
The C++ code does not use any object-oriented or exception-handling features of C++; essentially, this is a C program with minor C++ convenience features
God, it feels like I've spent most of my professional life arguing with Fortran programmers.
These people are ignorant, but arrogant.
They think that because they have a Phd in Engineering (or Physics, or whatever) and can produce a syntactically-correct Fortran program, they know how to program, and can ignore advice backed up by thirty years of software engineering research and experience.
Bizarrely, what little knowledge they have is about 35 years out of date, even for those in their twenties.
They live in a ghetto.
As anyone with even the slightest real computing knowledge knows, what gives you performance is the algorithm chosen, not the implementation.
Therefore, what matters is how easy it is to implement a good algorithm.
Which means, how easy it is to write a program that implements a difficult to understand algorithm (because an inobvious algorithm-- of course, there are some exceptions).
Which means that support for modern programming techniques that help you produce easy to understand programs is important for producing high performance programs. You know, things like the following that are absent from the still widely used Fortran-77:
Requiring all variables are explicitly defined before use (accounts for one third of all coding errors in even carefully written Fortran progams). A requirement enforced by all other compiled languages now in common use.
Programmer-defined data structures (struct in C).
Widely available elsewhere since the late 1960s.
Structured control structures (while, etc.). Old timers might be aware that that goto battles were fought and won in the rest of the world by about 1970.
Aggregation of subroutines into modules or packages.
Widely available elsewhere since the mid 1970s.
Support for abstract data types.
Widely available elsewhere since the early 1980s.
Support for polymorphism and inheritence (object orientation).
Widely available elsewhere since the mid 1980s.
So, comparing the performance of toy a Fortran program with its translation into C++ or Java shows nothing.
What has happended is a second Software Engineering Crisis.
The first 'Crisis was in the mainstream, data processing, part of the software industry. The introduction of more powerful computers resulted in large, complex programs that were failures because they were complicated (See The Mythical Man Month). Since then, we have developed software engineering techniques to deal with their problems, so now large programs can be much more complex (composed of many parts) without being excessively complicated (difficult to produce and understand).
Since about twelve years ago, the increasing performance of computers means that number-crunching programs (e.g. CFD programs) don't merely process large amounts of data; they are also large and complicated in their own right.
The Software Engineering Crisis has caught up with engineers and scientists.
The sad thing is, many don't know it, or ignore the advice (and screamingly obvious signs) that it is here.
I applaud Seagate for providing adequate technical information. However, not everyone does.
Your insulting tone, implying my stupidity and ignorance, merely reveals your own: my remarks were directed at the industry in general, not at Seagate. Having looked for such precise technical information, I know how hard it is to find in many cases.
Staggered spinup. All SCSI drives have it as a jumpered option these days.
Not all drives have it as a jumpered option. Some only have the option not to auto-spinup the disk, in which case you have to spin it up later under software control.
Says mjwise:
Every computer I've had since about 1997 with more than one IDE drive in it staggered the spinup of the drives
I believe that 'slave' IDE disks often have a spinup delay, which means all your IDE disks spin up in two groups (the masters, then the slaves). For SCSI staggered spinup the spinup delay is proportional to the SCSI ID, so you can (if you wish) spinup the disks one at a time--not quite the same thing.
I'm currently planning my second own-built PC,
and I must echo the article's request for more
(precise) electrical information from manufacturers. It is outrageous that the peak current at 12V drawn by a HDD, or the maximum current at 12V provided by a PSU, is missing from documents that call themselves 'technical specifications'.
This information is vital: it only takes a high-end PC with 3 modern HDDs (what you might use
for RAID or for other multi-disk performance tricks
to overload a 400W PSU. Not because it draws 400W during normal operation, but because on startup the disks draw too much current at 12V.
Many others have pointed out that studies consistently show that formal reviews (especially of specifications and designs) are the most cost effective ways of removing defects.
Others have provided references to the classic books on the subject.
Anyone considering doing formal reviews should read them.
I personnally like Tom Gilb's books.
There is a downside to consider, however, which is little mentioned, even in the formal review literature.
Formal reviews require a particular type of company culture, and not all companies have or want that kind of culture.
Trying to introduce formal reviews in a company that has an incompatible culture will be some mixture of painful, counter productive and political suicide.
The idea that a company would, in any way, be opposed to using the most cost effective way of removing defects seems bizarre.
The truth is, not all companies care about product quality.
Sure, everyone will say they care,
but words are cheap.
To find out what a company really cares about, see what decisions they make under pressure.
See what they sacrifice, and what they keep.
Do they cut testing to release the product on time? That means schedule is more important than quality.
Do they refuse to return an error riddled specification to the customer so the errors are corrected before work even begins? That means saying yes (a 'can do' attitude) is more important than quality.
When engineers start pointing out defects, are the whistleblowers labelled as 'troublemakers'? That means internal politics or a harmonious working environment are more important than quality.
The difficulty is, that before you can introduce formal reviews into an organisation, that organisation must already be highly committed to quality.
Quite simply, many organisations have to introduce other, fundamental, improvements before they can use the advanced technique of formal reviews.
The Capability Maturity Model (CMM) produced by the Software Engineering Institute (SEI) is a useful way of prioritising these improvements. I recommend it; I've used it in a project, and ISO 9001/9000-3 in another, and I conclude that CMM is the better of the two.
They have a website.
I have applied for EVERYTHING here in the Midwest (meaning ALL IT jobs I've come across and anything else in the newspaper, even bank tellers, secretary positions, retail stores (damn college degree), and I can't get anything)
Applying to all those jobs would sure take a long time. I guess you didn't spend much time on each application. Did you just send in the same copy of your CV (Resume in USAian, I believe) to them all? A generic CV radiates laziness, even comtempt. The employer is looking for someone who can fill a particular role, which means a particular set of skills, some of which the employer will consider more important than others. If you send a generic CV, the employer will have to wade through distracting and irrelevant material to learn the information they want.
This will annoy them.
They might give up before they find the information that shows you are suitable for the job.
They will believe that you have not bothered to do any research about the employer, what they do and what they want. They might conclude that you are probably lazy and/or not really very interested in this job, and therefore will not be motivated to do it well.
You don't want the employer to believe any of those things.
Your CV should show how you are suitable for that particular job. That means each job application could require a separate, taylor made, CV.
Also, it is better to apply for a smaller number of jobs, placing more effort in each application, than to use a 'shotgun' approach.
I recommend an excellent book called What Color is Your Parachute?
how DO you setup ipchains to do packet filteringt?
The information you need is in various Linux HOWTO documents. These should have come with your distribution. You can fetch updated versions of the documents from
The Linux Documentation Project.
You should study the following HOWTOs:
I asume you simply have a home box which you connect to the Internet using a ppp dial-up connection.
If you have something more sophisticated,
you will have to learn more.
I'd say the most important thing to do is to block connections to the privileged ports via your ppp interfaces, for the following reasons.
You shouldn't be providing any services to the Internet unless you really know what you are doing.
If you have a dial-up ppp connection without a static IP adress and your own domain name, there is no legitimate reason for anyone to ever try and connect to those ports.
Security exploits of privileged services will immediately given an intruder a root shell, and thus complete control of your computer.
The following rule will do the trick (warning, untested--myipchains rules are more complex than this):
ipchains -A input -i ppp+ -p TCP -y -d 0.0.0.0/0 0:1023 -j DENY -l
Yep, got my home box r00ted six weeks ago.
All because I hadn't taken all the usual basic precautions. (insert your sarcastic insult here).
Being an ex sysadmin, I should have known better.
Tightening up the security didn't take too long.
The hardest part was setting up ipchains to do packet filtering.
Lord help a newbie doing this; you have to know a fair amount about TCP/IP.
The various security HOWTOs make a brave effort of trying to explain it all, but I really wonder how many novices will understand it.
I don't see how any Linux distribution can make this easy: there are too many variables about the intended use of the computer. The rules for a DMZ computer, a LAN computer, a lone dial-up computer and a firewall are completely different.
but you have to admit blatant inconsistencies in the game world distract from the experience
I strongly disagree. Indeed, the opposite is true. The Roman Empire was:
A pinnacle of civilisation, bringing benefits such as coinage, roads, drainage and literacy to Europe.
A nasty, fascist regime that enslaved most of Europe for centuries, grinding down its peasants with 60% taxation for the benefit of a tiny elite.
Would simultaneous existence of such views in a game world distract from the expereince or enhance it?
Such inconsistencies makes things more interesting, right?
How about a fantasy world in which even basic facts such as whether the world is round or flat are merely matters of opinion?
Better?
You want to produce something that appears 'realsitic'. Seen any films? They usually look realistic, but wait! The camera angles and distances are choosen just so. If you could walk about the set you would see that the walls are just flats, and the actress had to be sewn into her costume. To produce 'realism' by generating the statstics of a village is completely useless and wrong footed: you could do better faking it by just describing the things immediately apparent to the players. Nobody will ever know, because none of them have a 'god's eye view'.
Slashdot Mirror
Full-seek time has improved relatively little over the years, so a new high RPM disk will help when you have little data on the disk, which is all packed into a few close tracks, but not so much when the disk is 90% full. You can therefore sometimes be better off with a multi-disk set up (RAID, or just multiple file systems).
Don't go there. it provides no real benefits.
Freedom is slavery. War is peace. Yes citizen, it is just words. But words enable us to communicate concepts, and thereby spread them. If distinctions are undermined, communication is hindered. Sometimes, especially when communicating unfamiliar concepts, notational clarity is important.
'Monads' are part of Leibnitz's philosophy, which Voltaire famously satirised in Candide with the figure of Dr. Pangloss, who resolutely maintained that we live in 'this, the best of all possible worlds' despite a succession of disasters that would convince any sane man that he was wrong.
How very suitable for a Microsoft product.
Based on my experience, a characteristic of a good manager is the ability to say no. Others posters have said you should not say "no" itself, but express it differently, in terms of scheduling and preferences: communication skill, scheduling and planning are what managers are paid to do.
I've seen the problems when managers were too spineless to say no. As you say, it might annoy the customer (who might be an 'internal' customer) in the short term, but that is nothing compared to the long-terms problems. In the long term, you need to have a good working relationship with your customers. That means mutual respect, including respect for the limitations under which you operate. Saying yes only seems like the easy option. It inevitably leads to an excessive workload, which means that somethings will not be done, or done late, or quality will suffer. The customer will then perceive you as being untrustworthy, for failing to deliver what was promised (perhaps implicitly). Aware that you have failed them, the customer will make even more demands, which you will be tempted to accept, to make up for it. A few cycles of this and your relationship will be entirely dysfunctional; they will make outrageous shrill demands, hoping to bully you into doing some of what they really want, and you will forever be in conflict. Don't go there.
If a techie is being placed in a position where he feels he has to say no, there has been a management failure: the techie is either being asked to also be a manager without having been formally made a manager, or a manager has not done their job.
If the techie is being asked to act as a manager, it might be useful if this was explicitly indicated in someway, so everyone is clear that he has the right to demand particular information (priority) and the right to bluntly say no (as a last resort).
I've seen this work.
I was a sysadmin in a small software development company. I don't think they every realised it, but the (other) sysadmins there were very good (I was the junior), and the four of us gave them a very godd sysadmin to user ratio. We were an SGI shop. We often had problems that took far too long to resolve because everything had to go through tier-1, who could never help, before they were finally escalated to tier-2 (and rarely tier-3). My boss had a meeting with their manager. Thereafter, tier-1 officially knew it was OK to rapidly escalate us to tier-2, because we were clueful enough to fix simple problems.
I've done something similar. But did you RTFA? It's point was that backdoors are often not blocked by firewalls because firewall policies on outgoing connections are usually permissive. What matters, in the context of this article, is what your iptables restrict, not whether you have them at all.
Well, either buy a legitimate copy or install an operating system that is free-as-in-beer. You deserve no sympathy. You are a thief. Like many here, I'm no fan of Microsoft, but there are no excuses for using pirate software. If you genuinely can't afford it, there are free (beer/dom) options instead. But I find the idead that you can't afford it unconvincing. Or did you steal your computer too?
Yes, and there's no sin in that... provided they are the right tradeoffs. Too often I've seen managers demand 'tradeoffs' that were clueless. The classic is cutting testing because the customer is unhappy because the product is late. As if they would be happy with a useless bug riddled product. So next time management talks to that customer, the customer is pissed, has them over a barrel, and makes outrageous demands, which are agreed. Repeat. I've seen that cycle go around four times with management doing nothing to break it.
I've come across my fair share of incompetent programmers, but I would be overjoyed to have managers who were as competent at managing as the programmers are at programming.
As programmers we are paid to have and develop complex technical skills that are hard to use. We are therefore paid more than the minimum wage. Since managers are typically paid more than programmers, they should be more skilled at their job or should take responsibility for their mistakes. Yet when there is a management SNAFU, the solution, apparently, is for the programmers to work harder.
Saying something is a 'law of nature' is to say that it is a regualrity that has been repeatedly well observed, with no relaible counter instances. And that is all. That's what the words mean. The philosopher Hume demolished the idea of having certain knowledge about natural laws, two centuries ago. The original poster was quite correct.
Quoth the poster:
There are two aspects to user 'bug reports': improving product quality (fixing bugs) and user support (helping the user with a problem). Organizations doing much of the latter distinguish 'incidents' from defects (bugs). An incident is a user report of a problem; other users might have experienced the same problem, but no matter, the incident is recorded and a user-support person provides assistance. The user is not responsible for recording bugs at all; the user-support person (or someone else) does that. Thereby, all bug reports are produced by internal staff, rather than customers, so you can enforce good bug reporting. Also, the organization is set up so the user has only one point of contact, the user-support department, so duplicate incident reports are eliminated too.
If this is new to you, you might be interested in the ITIL Guidelines
Had Columbia been unmanned, there would be much less hand wringing. With astronauts on board, all the components must be higher-rated for safety, and you need all the additional mass for life-support, reducing the economic incentives. Astronauts don't become lighter, but Moore's Law makes unmanned craft better all the time.
What makes you think things like it didn't happen 30 years ago? Have you conducted an analysis of violence in schools? I guess not. The difference between then and now may simply be that you are much more aware of what is happening now, because of the are fresh in your mind and you were more than a baby at the time. There is a general law-and-order nostalgia effect: people say '30 years ago we didn't have violent problem X', but people have been say that for as far back as we have good records of popular opinion. See Pearson, C. (1983). Hooligan. A History of Respectable Fears. London, Macmillan.
to which a poster replied
I was worried about being able to show a potential employer what I can do, without breaking confidentiality. Also, I wanted to be able to show that I could do more than the immediate job requirements of my previous job. My solution was to put code I'd written in my spare time (GPL'ed) on my website.
Is that because of the high level language, or because high-level languages encourage better coding styles?
I'm thinking of programming by contract here. My C++ and C is fairly sprinkled with assert()s, and my Java will be be likewise, when I move to version 1.4. With assertions on preconditions and postconditions and some unit tests, you can locate a bug to one method almost immediately, and if your methods are small (the current bast practice), that means only a handful of lines for you to inspect.
One of your repliers says:
If you need a debugger to understand what some code does, I suggest it it is badly written.
These days, many Fortran programmers may well compile their code using a Fortran-90 compiler. But many still write mostly Fortran-77; they don't take advatage of the improvements (or only a few); indeed, they are in a frightening number of cases unaware of the advantages of the improvements.
I've seen quite a bit of Fortran over the years, produced by people educated in England, the US, Canada, France, Germany, India, Iran, South Africa, Ireland, China, the former Yugoslavia (most parts), Scotland and Egypt. What is interesting is just how similar it all is, and how similar the attitudes of the people who wrote it are. Consider that it took about a dozen years for all the changes in Fortran-77 to percolate into the Fortran community. I think its interesting that such a subculture should exist, especially in an academic (or quasi academic) area where values such as expertise, innovation and technical skill might be expected to be influential. The very fact that you hang out on /. makes you exceptional. Perhaps your own particular area has a slightly different sub culture. Good for you!
God, it feels like I've spent most of my professional life arguing with Fortran programmers. These people are ignorant, but arrogant. They think that because they have a Phd in Engineering (or Physics, or whatever) and can produce a syntactically-correct Fortran program, they know how to program, and can ignore advice backed up by thirty years of software engineering research and experience. Bizarrely, what little knowledge they have is about 35 years out of date, even for those in their twenties. They live in a ghetto.
As anyone with even the slightest real computing knowledge knows, what gives you performance is the algorithm chosen, not the implementation. Therefore, what matters is how easy it is to implement a good algorithm. Which means, how easy it is to write a program that implements a difficult to understand algorithm (because an inobvious algorithm-- of course, there are some exceptions). Which means that support for modern programming techniques that help you produce easy to understand programs is important for producing high performance programs. You know, things like the following that are absent from the still widely used Fortran-77:
So, comparing the performance of toy a Fortran program with its translation into C++ or Java shows nothing.
What has happended is a second Software Engineering Crisis. The first 'Crisis was in the mainstream, data processing, part of the software industry. The introduction of more powerful computers resulted in large, complex programs that were failures because they were complicated (See The Mythical Man Month). Since then, we have developed software engineering techniques to deal with their problems, so now large programs can be much more complex (composed of many parts) without being excessively complicated (difficult to produce and understand). Since about twelve years ago, the increasing performance of computers means that number-crunching programs (e.g. CFD programs) don't merely process large amounts of data; they are also large and complicated in their own right. The Software Engineering Crisis has caught up with engineers and scientists. The sad thing is, many don't know it, or ignore the advice (and screamingly obvious signs) that it is here.
I applaud Seagate for providing adequate technical information. However, not everyone does. Your insulting tone, implying my stupidity and ignorance, merely reveals your own: my remarks were directed at the industry in general, not at Seagate. Having looked for such precise technical information, I know how hard it is to find in many cases.
Says ewhac:
Not all drives have it as a jumpered option. Some only have the option not to auto-spinup the disk, in which case you have to spin it up later under software control. Says mjwise:
I believe that 'slave' IDE disks often have a spinup delay, which means all your IDE disks spin up in two groups (the masters, then the slaves). For SCSI staggered spinup the spinup delay is proportional to the SCSI ID, so you can (if you wish) spinup the disks one at a time--not quite the same thing.
I'm currently planning my second own-built PC, and I must echo the article's request for more (precise) electrical information from manufacturers. It is outrageous that the peak current at 12V drawn by a HDD, or the maximum current at 12V provided by a PSU, is missing from documents that call themselves 'technical specifications'.
This information is vital: it only takes a high-end PC with 3 modern HDDs (what you might use for RAID or for other multi-disk performance tricks to overload a 400W PSU. Not because it draws 400W during normal operation, but because on startup the disks draw too much current at 12V.
Many others have pointed out that studies consistently show that formal reviews (especially of specifications and designs) are the most cost effective ways of removing defects. Others have provided references to the classic books on the subject. Anyone considering doing formal reviews should read them. I personnally like Tom Gilb's books.
There is a downside to consider, however, which is little mentioned, even in the formal review literature. Formal reviews require a particular type of company culture, and not all companies have or want that kind of culture. Trying to introduce formal reviews in a company that has an incompatible culture will be some mixture of painful, counter productive and political suicide.
The idea that a company would, in any way, be opposed to using the most cost effective way of removing defects seems bizarre. The truth is, not all companies care about product quality. Sure, everyone will say they care, but words are cheap. To find out what a company really cares about, see what decisions they make under pressure. See what they sacrifice, and what they keep.
The difficulty is, that before you can introduce formal reviews into an organisation, that organisation must already be highly committed to quality. Quite simply, many organisations have to introduce other, fundamental, improvements before they can use the advanced technique of formal reviews. The Capability Maturity Model (CMM) produced by the Software Engineering Institute (SEI) is a useful way of prioritising these improvements. I recommend it; I've used it in a project, and ISO 9001/9000-3 in another, and I conclude that CMM is the better of the two. They have a website.
hendridn says:
Applying to all those jobs would sure take a long time. I guess you didn't spend much time on each application. Did you just send in the same copy of your CV (Resume in USAian, I believe) to them all? A generic CV radiates laziness, even comtempt. The employer is looking for someone who can fill a particular role, which means a particular set of skills, some of which the employer will consider more important than others. If you send a generic CV, the employer will have to wade through distracting and irrelevant material to learn the information they want.
You don't want the employer to believe any of those things.
Your CV should show how you are suitable for that particular job. That means each job application could require a separate, taylor made, CV. Also, it is better to apply for a smaller number of jobs, placing more effort in each application, than to use a 'shotgun' approach.
I recommend an excellent book called What Color is Your Parachute?
packeteer asks
The information you need is in various Linux HOWTO documents. These should have come with your distribution. You can fetch updated versions of the documents from The Linux Documentation Project. You should study the following HOWTOs:
I asume you simply have a home box which you connect to the Internet using a ppp dial-up connection. If you have something more sophisticated, you will have to learn more. I'd say the most important thing to do is to block connections to the privileged ports via your ppp interfaces, for the following reasons.
- You shouldn't be providing any services to the Internet unless you really know what you are doing.
- If you have a dial-up ppp connection without a static IP adress and your own domain name, there is no legitimate reason for anyone to ever try and connect to those ports.
- Security exploits of privileged services will immediately given an intruder a root shell, and thus complete control of your computer.
The following rule will do the trick (warning, untested--myipchains rules are more complex than this): ipchains -A input -i ppp+ -p TCP -y -d 0.0.0.0/0 0:1023 -j DENY -lYep, got my home box r00ted six weeks ago. All because I hadn't taken all the usual basic precautions. (insert your sarcastic insult here). Being an ex sysadmin, I should have known better. Tightening up the security didn't take too long.
The hardest part was setting up ipchains to do packet filtering. Lord help a newbie doing this; you have to know a fair amount about TCP/IP. The various security HOWTOs make a brave effort of trying to explain it all, but I really wonder how many novices will understand it. I don't see how any Linux distribution can make this easy: there are too many variables about the intended use of the computer. The rules for a DMZ computer, a LAN computer, a lone dial-up computer and a firewall are completely different.
Sayeth the poster:
I strongly disagree. Indeed, the opposite is true. The Roman Empire was:
Would simultaneous existence of such views in a game world distract from the expereince or enhance it? Such inconsistencies makes things more interesting, right? How about a fantasy world in which even basic facts such as whether the world is round or flat are merely matters of opinion? Better?
You want to produce something that appears 'realsitic'. Seen any films? They usually look realistic, but wait! The camera angles and distances are choosen just so. If you could walk about the set you would see that the walls are just flats, and the actress had to be sewn into her costume. To produce 'realism' by generating the statstics of a village is completely useless and wrong footed: you could do better faking it by just describing the things immediately apparent to the players. Nobody will ever know, because none of them have a 'god's eye view'.