How about a software firm contracted to write a control system for a city's traffic grid. A bug or poor design causes a set of lights to go on the blink, two people run an intersection and both die in the resulting collision. Who pays the damages? Not sure, perhaps the city... but its not their fault. But they can't pass that onto the software firm... not currently.
But instead, if we had licensed software engineers, who in certain instances like the one above, who were now indefinately liable for their work, and who are required by the customer to "sign off" on it... well, it can only bode well for the quality of software.
The big thing here is that the customer has to demand accountability ...
Well, if you think bespoke software is expensive now, you just wait until it becomes possible to sue in this way.
My employer will not enter into supply of software where the potential liabiity exceeds the contract value, as far as I know. And they are, I think, about the 20th largest IT organisation in the world (we do however, have additional processes in place for software projects having a safety aspect - the safety of the system is audited at all stages by a senior person appointed by senior management).
At the moment, the liability of the supplier is governed by their contract with the customer. If the customer wants the option to sue for more than they would have paid for the system, they negotiate appropriate contract terms - it's that simple.
The situation is qualitatively different for COTS software, where the contract isn't negotiated at all, though.
If this kind of suit were always possible (i.e you could not appropriately limit you liability in the contract), conringency in costs would go through the roof, and software companies would start hiring lots more lawyers.
(I have no idea what we do in terms of liability for govenment, defense and space work, that's not my area).
The
Apache Portable Runtime has good cross-platform I/O, threading and networking support. Plus you know it will have been tested in a demanding environment (Apache!)
I think Donaldson will be read for a long time to come; I think his work won't date too badly (well The Chronicles of Thomas Covenant won't but maybe the Gap sequence will).
I think that a lot of Clarke's work will live on - after all, awasn't The Sentinel once voted the best SF short story of all time?
Also I think that in say 50 years the playing field will be levelled across the C20, so some of the century's earlier writers will become more popular in comparision to today's fashionable writers, since in 50 years late-twentieth-century writers won't have the distinction of being "modern" and the large print runs of the current writers will no longer give them an advantage (i.e. in 50 years everybody will be reading reprints of the classics, whatever they turn out to be, so the fact that modern writers sold 100,000 copies in paperback in the 90s will not affect tomorrows readers as much as todays).
Here's another question for the panel - which will live longer - Iain Banks books, or Iain M. Banks books (i.e. the SF or the other stuff)?
Terry Pratchett -
When I worked in an SF bookshop (that's a science fiction bookshop. In Dublin), Pratchett was consistently our best-sellign author
I just bought a copy of Pratchett's The Truth. On it it says that Pratchett is the UK's best selling novelist (note - not the UK's best seling SF/Fantasy novelist).
A lot of people and companies did, but the main one would have to be IBM. Their attempt to stuff the genie back in the bottle by taking a 90 degree turn with OS/2 and the PS/2 MicroChannel line was the fumble that let MicroSquish inherit the mediocrity franchise lock, stock, and Barrel.
I suspect that IBM would have stood a much better chance at that enterprise if they had tried to change only the software. It was fairly obvious even at the time that the MCA change was never going to fly.
I tried to install OS/2 2.1 on a VESA Local Bus 486DX2/66 once. IBM technical support informed me that my installation problems were occurring because my new machine was too fast.
I have trying to get a comprehensive list of what *IS* wrong with Unix. The sort of faults I am looking for are the things like root is god, files can have only one owner at a time etc... Does anyone know of such a list.
The trouble is, this is simply a matter of expectation and emhasis. This means that "right" and "wrong" don't really apply very well - we're talking about design choices here. But to address your points...
root is god -
This can be a problem from a security point of view. The modern introduction of capabilities offsets this, meaning that fewer programs run as root. In the future we may see Unix-like systems in which no one user has all system capabilities (e.g. roles separated into System Operator, System Manager and Security Officer, as in OS/400). However, although this improves the security of the system, it makes some things hardeer (e.g. to update a single package may require two sets of credentials, perhaps three). But this is probably good news for normal operation og a system (rather than for sysadmin proceses). For a long time, it has been received wisdom to do much stuff logged in as root - and so the awesome ability of root to make a huge mistake very quickly is diluted.
files can have only one owner at a time -
I'm not convinced about what benefit you are expecting from changing this - for example, what about correctly setting the group ownership of the file, and common umask values for the users who want to share the file (and in the case of directories, seting the setgid bit of the directory)? If the Unix you are using supports ACLs, they will probably also offer 90% of whatever it is you are trying to achieve. But please do explain what benefits you're looking for here.
As for what my thoughts are...
It may well be time for a POSIX-alike entity to bring a little more standardisation to system administration (this is outside the scope of POSIX). This looks like a very hard thing to do now but in a couple of years, a great deal of alignment to Linux will have gone on, because Linux will increasingly dominate as the de facto standard, both in terms of interface and user expectation.
It may be time consider bring more things into the "required core" of X, for example antialiased fonts. This would be a development which is motivated in a similar way to the changes currently being mooted in OpenGL.
It would not surprise me if for every two people you could get to agree that Unix should improve in a certain way in a given area, you could find a third person who argues that the current state of affairs is ideal or that the suggested movement is in exactly the wrong direction.
Too large a proprtion of the webservers on the planet are something other than IIS to make it easy for Microsoft to fundamentally change the protocols. What they would find easier is to embrace and extend HTML. Oh, they already did that.
I migrated my / filesystem (only the one Linux filesystem on my laptop - it dual-boots) from ext2 ro ext3. Totally seamless. No time lost with fsck.
I accidentally nobbled the ext3 module (by upgrading the kernel and omitting the initrd that normally loads the ext3 module from linuxrc). Red Hat seamlessly mounted as ext2 - no loss of data (but obviously no journalling). Puttng the initrd back brought me back into the ext3 fold, again seamlessly. It was completely painless -I was really impressed. This experience is with 7.1.93 - I have not yet tried 7.2
In fact, I might not ever try 7.2 because of the really annoying ppp-watcher in 7.1. I had an ISP problem where the chat script would fail to authenticate, and the ppp-watcher just dialled again and again and again... Really annoying, and hard to change. I'm sure I'd miss RH if I stopped using it because I've used it since RH 2.1. For the moment I'm running Red Hat 7.1.93 at home and Debian on my laptop.
Architects need to be wide as well as deep
on
Coder or Architect?
·
· Score: 5, Informative
The nature of the architect role varies a bit according to whether you are an architect for a product (or a product suite) in a company working in one industry segment, or an architect working for an IT consultancy. In the former case there is a great emphasis on development strategy and an understanding of the market but in the latter case while these factors are important, you will also need some analysis skills and perhaps some sales skills.
I suspect that you will find, as I did, that the principal new demand is for breadth as well as depth in your technical knowledge. I know lots of Unix and C-oriented development stuff plus some networking, but there is a gap between that and devising the complete architecture for a website exposing previously internal business processes of a company with millions of customers. Depending on the nature of your organisation and products, you may also need to know a bit about third-party products in various market segments (i.e. for this bit of functionality we drop in product X and allocate Y man-weeks of effort for configuration, interfacing, deployment and support, insteasd of coding that part ourselves)
Things I have found useful are
Know what you don't know - and figure out where to go for the expertise (e.g. who makes the best SSL accelerator / load-balancing switches? - I don't know for sure but I know who to ask).
Consider a range of options - you haven't really done the job of architectural design justice if you have only considered one main approach. Even if it is the right approach it's good to show that it's right by comparing it to alternatives you considered.
Build/discover/create a peer group of software architects. With software development & bug hunting it often helps to explain the problem - sometimes you stop in the middle and go "aha!" and rush off because you have figured it out. Architecture can be very similar. Watch out for the look on your peer's face that says "Why are you doing it that way?" It might mean that you're barking up the wrong tree, but it also might mean that this element of the solution will have to be carefully explained to the client in terms of its advantages, otherwise they won't go for your proposal.
Scope control - learn to negotiate the scope of the system. This was probably mostly out of your control as a developer, but as an architect this can be one of the most powerful tools you have. Tight/clever/detailed/thoughtful control over the scope of the system to be built can lead to great improvements in reliability or reductions in development time - i.e. push those stupid features that take 10x the effort for 10% of the benefit out of scope. The sales guys won't like it if you say "it's too hard" but they'll listen a lot better if you say "if we remove that from the scope we reduce the delivery risk (and hence the risk to the customer as well as us) and increase our profit margin". They like that wording a lot better. You may have to phrase it as "let's defer that until phase 2 because..." of course.
Because of the wider scope of your role (i.e. responsible for the design of the whole shooting match) you may find that you need to make decisions - in principle - about things which you would not have had to code yourself in your previous role. At least learn a bit about all that stuff. Depending on your role, this may mean learning more about middleware, distributed database architectures, wiring, user interfaces, credit vetting, image processing, or some other thing you don't already know about. Figure out what this is and who knows it.
Undestand the capabilities of the developers who will write the code. This is important when considering multiple approaches. There is no point basing your system on J2EE if it has to be delivered in 3 months and nobody knows Java. However, you should always know when to break this rule - for example, if you have to transfer lots of files, use SCP or Perl's Net::FTP instead of coding it in C.
Sometimes you will need really detailed understanding of a specific thing. For example, there are things you just can't do reliably over NFS. Figure out what these potential pitfalls are.
Again depending on your role you may find that you need a bit of training in presentation skills, team leading, sales techniques, product selection in some market area, or various technical things that previously weren't your problem.
Talk to your peer architects. Which approaches worked, and which didn't? Why? Which bits are harder/more expensive than people normally realise?
Try and think of it like this: the Weak Atheist does not believe in the existence of God whereas the Strong Atheist position believes in the non-existence of God.
Actually, what you call a "Weak Atheist" is more properly an Agnostic and what you call a "Strong Atheist" is just an Atheist.
To express this another way, there is a more precise name for someone who has no belief in God - and that's "Agnostic". The name for someone who believes there is no God is "Atheist".
To feel like you are moving forward, not firefighting all the time
Your boss wants:-
Happy clients
Good reference stories of previous successes
To reduce the risks to projects (i.e. reduce risk of non delivery or late delivery)
To maximise the rate of return business
To maximise the profit made on each delivery (i.e reduce the effort of turning out another project)
To reduce the dependency of the business on skills held by individuals, in favour of skills held jointly among the team
The trick is to find an approach which fulfils both these sets of goals. Several exist, but the most obvious one is to work over the course of several projects to turn what you have (which you say are all very similar) into an actual product. This means
You get to work on the same set of code, and improve and refine it over time
To reduce the number of bugs, over time
To to reinvent the wheel, since you have a working wheel already
To feel like you are making progress, because you don't start from scratch every time
Your boss gets:-
To be able to deliver repeatably successful systems
Clients who are happy because not starting from scratch every time means fewer bugs
Rediced delivery effort, because delivery projects are customisations of your product(s), not bespoke work
Better rates of return, because you have reduced the effort required to deliver a solution, without reducing the value to the client of the delivered solution
No reliance on knowledge held by just one person, becase the whole team will understand (significant parts of) the product
In addition you both get
Documentation
Less bugs
Promoted
To successfully sell this to your management you will need to be able to demonstrate that this can be done off the backof your regular project stream, and does not have to mean that some guy gets to sit in a corner contemplating his navel "writing the product" for a year. You will never sell that to your boss. Instead, devise a plan where you use the code for project A, and generalise it a bit and add customisations to support project B. By the time you have delivered C and D as well, what you have is a product.
To make this work, you will have to retain the IP on the software you write, which I guess you don't at the moment.
The best way round this is to tell the clients explicitly that they are getting a product (clients often like products because it means that the project delivery risk is reduced).
But the client will refise to allow themselves to be marooned without support. Hence you do a deal with them whereby they get a non-exclusive license to modify the code which is transferrable if the business is bought or sold. You can also tell them that this means that they are free to seek support for your code from elsewhere (but that they cannot sell the code on). They may well like this (it has several good features, e.g. insulating them from risk of your company folding). Your support agreement will need to be clear on the fact that you won't support the code if they have just hacked upon it madly.
In short: develop a strategy that benefity you, your boss and your clients, and think about hoe to sell it to all three.
Ah, yet another wonderful idea from the Open Source crowd. Yet another hopeless attempt to unseat the Cathedral.
Mobs, forges, lone genius. None of that is going to rescue your precious development model, it is inherently flawed. People want things. They want recognition, which you cover fairly well. They want to do good things, you have that. Unfortunately for you, they also want money. Lots and lots of money so they can buy all of the shiny objects that their neighbors have. You don't have that base covered and you never will, thus nothing of merit will come out of your system.
Yawn.
I have a day job. I also work on Free software, and other things related to open sytems (e.g. standards for things, not "Open Source").
I also have plural shiny things. This is because my achievements _outside_ may day job have two effects:
I gain useful skills that eventually get used in my day job. I become the foobar guru.
I can point to my achievements outside the day job and say "look! See, I am of consequence elsewhere; I understand the industry well, have a little influence in it, and another employer would jump at the chance to employ me".
Actually, the problem is, no time to play with the shiny things because I'm too busy hacking interesting code. Interesting code is a real breath of fresh air because you do it when you want to, and not today if you don't feel like it.
People say (said) that Win3.1 was not an operating system because there was already an operating system, DOS, running under it.
However, the same argument would apply to Linux running on top of RTLinux; the Linux "environment" relies upon the underlying system (RTLinux) to provide it with some (but not all) services. The situation with Win31. and DOS was quite similar -- Win3.1 relied on DOS for file I/O but on the other hand it managed the display resources by itself.
Fopr this reason I would say (though I'm not a lawyer) that the example of Win3.1 running on top of an RTOS would seem to count as prior art.
That said, there will certainly be specific claims in the Y patent which are not covered by this (potential) prior art, so the patent would not be completely invalidated.
Also note that a patent covers not the doing of a thing, but the method by which that thing is done. For example, you can't get a patent on the wheel, but you can get a patent on a new way for making or using wheels. The fact that the wheel has existed for a long time doesn't mean that no new methods or inventions around it could exist. For example, it's probably possible to get a patent on a method for manufacturing identical sets of almost perfectly round wheels via nanotechnology (e.g. think - how do the nanobots know how much local curvature to apply, and how to they avoid generating a sphere rather than a disc). So, plenty of room for innovation even in established areas.
Happily this probably means that there are ways of achieving this without falling afoul of the patent. On the down side, it's possible that nobody will figure out how to do it faster or more efficiently than the way that the patent specifies. That's life, but you can always wait for the patent to expire.
Ask enough factual questions about the technical items on their CV to establish that they have the skills they claim. When discussing these issues, always say "do you know/have XX" instead of just going by the CV, because agencies often rewrite CVs and they may (well, they do) tell lies on behalf of the applicant that the applicant would not have. So, if is says "foo" on their CV, it may be that they actually know "foobar" and the agency doesn't know the difference. However, if they really have lied on their CV, just put it in the bin.
Don't ask questions like "what is tcpdump for", ask about a situation that they would want to use tcpdump for and see if they "get it right". But don't be too prescriptive. It's sometimes also worth asking "how else could you approach this problem".
Always work from their experience, avoid the hypothetical. If the interview reaches a point where most questions are hypothetical, the candidate almost certainly doesn't have actual experience of the things you want - this is usually but not always going to mean they're unsuitable.
Look for general skills like problem solving, communications skills, can they take initiative (EXAMPLES!), and can they win someone over to their point of view (i.e. if they know a good technical solution to a problem, and one would hope that they would, can they convince people that this is the right approach?). Look for evidence of planning, risk assessment (we can to the upgrade this way, but that's too risky; we'll roll it out that way instead -- very valuable skill). Can they estimate tasks? Do they hit their estimates. Ask for an example of what happened when they didn't (e.g. did they tell their boss? Did they ask for help?).
Can they understand issues from other people's point of view? Are they flexible (look for multiple ways of solving problems), resourceful, cautious, measured, adventurous - can they take and avoid risks, judging according to the circumstances which is the right to do?
Ask simple questions and then hard ones. But don't launch right in, let them get comfortable first. Explain the purpose and structure of the interview, how long it will take and what the result will be. Maybe explain your own job and how theirs will fit into it.
Ask them about your own organisation -- that is, can they do research? Ask them about their own organisation -- that is, do they pay attention to their own organisation.
Look for exampes of how they have analysed their own workplace, dicovered a defect and gone about changing it (or persuading someone else to change it). Work from their own experience. Make some allowance for situations where the candidate works in a shop which is totally different to yours, but also draw a line -- if they have no evidence that they can do what you need, you can't usually justify hiring them.
Ask them what their strengths and weaknesses are. Then ask them what they really are. Ask them why they're leaving, and why they want to come to you.
Can they describe things (i.e. sequences of events or problems) clearly and simply? Do they make sure they understand the question? Ask them for examples; anybody can guess at a good hypothetical answer, look for evidence they they've really done it.
Another poster talked about "fit". It's essential. Can they work in your environment, did they win you over, are they easy to talk to, can they assert their own point of view when this is important, can they give a viable rationale for their courses of action? What special skill(s) will they bring to your environment?
At the time the spelling of the English language was not regulated in any way, and the spelling of common words often varied. Shakespeare himself used to spell his own name in several different ways, "Shakspear" also being used. So this spelling is not, strictly, incorrect.
The lessons from the Challenger disaster are equally appropriate to the field of software engineering. However, the software field does not seem to have benefitted from those lessons in the same way as NASA has.
The lessons I'm talking about are:-
1. Technical failures don't endanger lives etc, it's the failure of people to adequately assess and prepare for risks that is dangerous.
2. Ideally, it should take more than a single technical faillure to cause a system failure. Where this level of preparation is too expensive or time-consuming, stakeholders should explicitly take the cost versus safety decision. And review it.
3. It's quite possible to produce systems whose complexity and reliability are impressive, but you can't do it just with brilliant individuals. You have to have a process; review and criticism is vital. Having brilliant individuals certaily helps. If all you have is dumb individuals, don't bother starting.
The GPL is *not* a legal agreement which is why you are not required to sign your name on it and send it back to the vendor before using GNU/Linux. The GPL is very clear about exactly what it is.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted
...
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
In other words, the GPL is a license that covers the acts of copying or modifying the original work. You don't need to be able to agree to anything at all, and simply using the software is not a restricted act.
There are some other possibilities to consider; for example, do your queues contain many deferred items (due to note unreachability or DNS problems)? If so, you are trawling through a large mail queue to process a small number of items (since some of the items are not due to be reried yet [I'm no exim expert]).
If you're using a lot of disk in re-reading the queue, consider using an MTA which has a separate queue for deferred items, and/or a hashed directory structure. The Postfix mailer (by Wietse Venema) fits the bill here. Postfix is particularly good for large queues.
Postfix also is deliberately written to make filesystem accesses an absolute minimum of times for each item of mail (I think you can have as few as 3 disk accesses per item). This really reduces disk loading, especially on systems with synchronous filesystems.
On the RAID side, consider alternatives to RAID5. RAID0+1, for example, is as safe as RAID5, but faster (though it uses slightly more disk drives).
What is the balance between writes and reads on your mail server?
Are you logging syslog locally on the mail server? If so, consider either moving syslog logging to a dedicated log box. If you can't do that, consider using the leading-dash feature in/etc/syslog.conf to make syslogd avoid calling fsync() on the mail log for every single logged message.
Slashdot Mirror
My employer will not enter into supply of software where the potential liabiity exceeds the contract value, as far as I know. And they are, I think, about the 20th largest IT organisation in the world (we do however, have additional processes in place for software projects having a safety aspect - the safety of the system is audited at all stages by a senior person appointed by senior management).
At the moment, the liability of the supplier is governed by their contract with the customer. If the customer wants the option to sue for more than they would have paid for the system, they negotiate appropriate contract terms - it's that simple.
The situation is qualitatively different for COTS software, where the contract isn't negotiated at all, though.
If this kind of suit were always possible (i.e you could not appropriately limit you liability in the contract), conringency in costs would go through the roof, and software companies would start hiring lots more lawyers.
(I have no idea what we do in terms of liability for govenment, defense and space work, that's not my area).
The Apache Portable Runtime has good cross-platform I/O, threading and networking support. Plus you know it will have been tested in a demanding environment (Apache!)
I think that a lot of Clarke's work will live on - after all, awasn't The Sentinel once voted the best SF short story of all time?
Also I think that in say 50 years the playing field will be levelled across the C20, so some of the century's earlier writers will become more popular in comparision to today's fashionable writers, since in 50 years late-twentieth-century writers won't have the distinction of being "modern" and the large print runs of the current writers will no longer give them an advantage (i.e. in 50 years everybody will be reading reprints of the classics, whatever they turn out to be, so the fact that modern writers sold 100,000 copies in paperback in the 90s will not affect tomorrows readers as much as todays).
Here's another question for the panel - which will live longer - Iain Banks books, or Iain M. Banks books (i.e. the SF or the other stuff)?
- Terry Pratchett -
When I worked in an SF bookshop (that's a science fiction bookshop. In Dublin), Pratchett was consistently our best-sellign author
I just bought a copy of Pratchett's The Truth. On it it says that Pratchett is the UK's best selling novelist (note - not the UK's best seling SF/Fantasy novelist).A lot of people and companies did, but the main one would have to be IBM. Their attempt to stuff the genie back in the bottle by taking a 90 degree turn with OS/2 and the PS/2 MicroChannel line was the fumble that let MicroSquish inherit the mediocrity franchise lock, stock, and Barrel.
I suspect that IBM would have stood a much better chance at that enterprise if they had tried to change only the software. It was fairly obvious even at the time that the MCA change was never going to fly.
I tried to install OS/2 2.1 on a VESA Local Bus 486DX2/66 once. IBM technical support informed me that my installation problems were occurring because my new machine was too fast.
The trouble is, this is simply a matter of expectation and emhasis. This means that "right" and "wrong" don't really apply very well - we're talking about design choices here. But to address your points ...
- root is god -
This can be a problem from a security point of view. The modern introduction of capabilities offsets this, meaning that fewer programs run as root. In the future we may see Unix-like systems in which no one user has all system capabilities (e.g. roles separated into System Operator, System Manager and Security Officer, as in OS/400). However, although this improves the security of the system, it makes some things hardeer (e.g. to update a single package may require two sets of credentials, perhaps three). But this is probably good news for normal operation og a system (rather than for sysadmin proceses). For a long time, it has been received wisdom to do much stuff logged in as root - and so the awesome ability of root to make a huge mistake very quickly is diluted.
- files can have only one owner at a time -
I'm not convinced about what benefit you are expecting from changing this - for example, what about correctly setting the group ownership of the file, and common umask values for the users who want to share the file (and in the case of directories, seting the setgid bit of the directory)? If the Unix you are using supports ACLs, they will probably also offer 90% of whatever it is you are trying to achieve. But please do explain what benefits you're looking for here.
As for what my thoughts are...- It may well be time for a POSIX-alike entity to bring a little more standardisation to system administration (this is outside the scope of POSIX). This looks like a very hard thing to do now but in a couple of years, a great deal of alignment to Linux will have gone on, because Linux will increasingly dominate as the de facto standard, both in terms of interface and user expectation.
- It may be time consider bring more things into the "required core" of X, for example antialiased fonts. This would be a development which is motivated in a similar way to the changes currently being mooted in OpenGL.
It would not surprise me if for every two people you could get to agree that Unix should improve in a certain way in a given area, you could find a third person who argues that the current state of affairs is ideal or that the suggested movement is in exactly the wrong direction.Too large a proprtion of the webservers on the planet are something other than IIS to make it easy for Microsoft to fundamentally change the protocols. What they would find easier is to embrace and extend HTML. Oh, they already did that.
I migrated my / filesystem (only the one Linux filesystem on my laptop - it dual-boots) from ext2 ro ext3. Totally seamless. No time lost with fsck.
I accidentally nobbled the ext3 module (by upgrading the kernel and omitting the initrd that normally loads the ext3 module from linuxrc). Red Hat seamlessly mounted as ext2 - no loss of data (but obviously no journalling). Puttng the initrd back brought me back into the ext3 fold, again seamlessly. It was completely painless -I was really impressed. This experience is with 7.1.93 - I have not yet tried 7.2
In fact, I might not ever try 7.2 because of the really annoying ppp-watcher in 7.1. I had an ISP problem where the chat script would fail to authenticate, and the ppp-watcher just dialled again and again and again... Really annoying, and hard to change. I'm sure I'd miss RH if I stopped using it because I've used it since RH 2.1. For the moment I'm running Red Hat 7.1.93 at home and Debian on my laptop.
rofl.
I suspect that you will find, as I did, that the principal new demand is for breadth as well as depth in your technical knowledge. I know lots of Unix and C-oriented development stuff plus some networking, but there is a gap between that and devising the complete architecture for a website exposing previously internal business processes of a company with millions of customers. Depending on the nature of your organisation and products, you may also need to know a bit about third-party products in various market segments (i.e. for this bit of functionality we drop in product X and allocate Y man-weeks of effort for configuration, interfacing, deployment and support, insteasd of coding that part ourselves)
Things I have found useful are
- Know what you don't know - and figure out where to go for the expertise (e.g. who makes the best SSL accelerator / load-balancing switches? - I don't know for sure but I know who to ask).
- Consider a range of options - you haven't really done the job of architectural design justice if you have only considered one main approach. Even if it is the right approach it's good to show that it's right by comparing it to alternatives you considered.
- Build/discover/create a peer group of software architects. With software development & bug hunting it often helps to explain the problem - sometimes you stop in the middle and go "aha!" and rush off because you have figured it out. Architecture can be very similar. Watch out for the look on your peer's face that says "Why are you doing it that way?" It might mean that you're barking up the wrong tree, but it also might mean that this element of the solution will have to be carefully explained to the client in terms of its advantages, otherwise they won't go for your proposal.
- Scope control - learn to negotiate the scope of the system. This was probably mostly out of your control as a developer, but as an architect this can be one of the most powerful tools you have. Tight/clever/detailed/thoughtful control over the scope of the system to be built can lead to great improvements in reliability or reductions in development time - i.e. push those stupid features that take 10x the effort for 10% of the benefit out of scope. The sales guys won't like it if you say "it's too hard" but they'll listen a lot better if you say "if we remove that from the scope we reduce the delivery risk (and hence the risk to the customer as well as us) and increase our profit margin". They like that wording a lot better. You may have to phrase it as "let's defer that until phase 2 because..." of course.
Because of the wider scope of your role (i.e. responsible for the design of the whole shooting match) you may find that you need to make decisions - in principle - about things which you would not have had to code yourself in your previous role. At least learn a bit about all that stuff. Depending on your role, this may mean learning more about middleware, distributed database architectures, wiring, user interfaces, credit vetting, image processing, or some other thing you don't already know about. Figure out what this is and who knows it.Undestand the capabilities of the developers who will write the code. This is important when considering multiple approaches. There is no point basing your system on J2EE if it has to be delivered in 3 months and nobody knows Java. However, you should always know when to break this rule - for example, if you have to transfer lots of files, use SCP or Perl's Net::FTP instead of coding it in C.
Sometimes you will need really detailed understanding of a specific thing. For example, there are things you just can't do reliably over NFS. Figure out what these potential pitfalls are.
Again depending on your role you may find that you need a bit of training in presentation skills, team leading, sales techniques, product selection in some market area, or various technical things that previously weren't your problem.
Talk to your peer architects. Which approaches worked, and which didn't? Why? Which bits are harder/more expensive than people normally realise?
Actually, what you call a "Weak Atheist" is more properly an Agnostic and what you call a "Strong Atheist" is just an Atheist.
To express this another way, there is a more precise name for someone who has no belief in God - and that's "Agnostic". The name for someone who believes there is no God is "Atheist".
Your boss wants
The trick is to find an approach which fulfils both these sets of goals. Several exist, but the most obvious one is to work over the course of several projects to turn what you have (which you say are all very similar) into an actual product. This means
Your boss gets
In addition you both get
To successfully sell this to your management you will need to be able to demonstrate that this can be done off the backof your regular project stream, and does not have to mean that some guy gets to sit in a corner contemplating his navel "writing the product" for a year. You will never sell that to your boss. Instead, devise a plan where you use the code for project A, and generalise it a bit and add customisations to support project B. By the time you have delivered C and D as well, what you have is a product.
To make this work, you will have to retain the IP on the software you write, which I guess you don't at the moment.
The best way round this is to tell the clients explicitly that they are getting a product (clients often like products because it means that the project delivery risk is reduced).
But the client will refise to allow themselves to be marooned without support. Hence you do a deal with them whereby they get a non-exclusive license to modify the code which is transferrable if the business is bought or sold. You can also tell them that this means that they are free to seek support for your code from elsewhere (but that they cannot sell the code on). They may well like this (it has several good features, e.g. insulating them from risk of your company folding). Your support agreement will need to be clear on the fact that you won't support the code if they have just hacked upon it madly.
In short: develop a strategy that benefity you, your boss and your clients, and think about hoe to sell it to all three.
Compaq also produce some MIPS systems in the Compaq NonStop Himalaya series.
I have a day job. I also work on Free software, and other things related to open sytems (e.g. standards for things, not "Open Source").
I also have plural shiny things. This is because my achievements _outside_ may day job have two effects:
- I gain useful skills that eventually get used in my day job. I become the foobar guru.
- I can point to my achievements outside the day job and say "look! See, I am of consequence elsewhere; I understand the industry well, have a little influence in it, and another employer would jump at the chance to employ me".
Actually, the problem is, no time to play with the shiny things because I'm too busy hacking interesting code. Interesting code is a real breath of fresh air because you do it when you want to, and not today if you don't feel like it.However, the same argument would apply to Linux running on top of RTLinux; the Linux "environment" relies upon the underlying system (RTLinux) to provide it with some (but not all) services. The situation with Win31. and DOS was quite similar -- Win3.1 relied on DOS for file I/O but on the other hand it managed the display resources by itself.
Fopr this reason I would say (though I'm not a lawyer) that the example of Win3.1 running on top of an RTOS would seem to count as prior art.
That said, there will certainly be specific claims in the Y patent which are not covered by this (potential) prior art, so the patent would not be completely invalidated.
Also note that a patent covers not the doing of a thing, but the method by which that thing is done. For example, you can't get a patent on the wheel, but you can get a patent on a new way for making or using wheels. The fact that the wheel has existed for a long time doesn't mean that no new methods or inventions around it could exist. For example, it's probably possible to get a patent on a method for manufacturing identical sets of almost perfectly round wheels via nanotechnology (e.g. think - how do the nanobots know how much local curvature to apply, and how to they avoid generating a sphere rather than a disc). So, plenty of room for innovation even in established areas.
Happily this probably means that there are ways of achieving this without falling afoul of the patent. On the down side, it's possible that nobody will figure out how to do it faster or more efficiently than the way that the patent specifies. That's life, but you can always wait for the patent to expire.
Ask enough factual questions about the technical items on their CV to establish that they have the skills they claim. When discussing these issues, always say "do you know/have XX" instead of just going by the CV, because agencies often rewrite CVs and they may (well, they do) tell lies on behalf of the applicant that the applicant would not have. So, if is says "foo" on their CV, it may be that they actually know "foobar" and the agency doesn't know the difference. However, if they really have lied on their CV, just put it in the bin.
Don't ask questions like "what is tcpdump for", ask about a situation that they would want to use tcpdump for and see if they "get it right". But don't be too prescriptive. It's sometimes also worth asking "how else could you approach this problem".
Always work from their experience, avoid the hypothetical. If the interview reaches a point where most questions are hypothetical, the candidate almost certainly doesn't have actual experience of the things you want - this is usually but not always going to mean they're unsuitable.
Look for general skills like problem solving, communications skills, can they take initiative (EXAMPLES!), and can they win someone over to their point of view (i.e. if they know a good technical solution to a problem, and one would hope that they would, can they convince people that this is the right approach?). Look for evidence of planning, risk assessment (we can to the upgrade this way, but that's too risky; we'll roll it out that way instead -- very valuable skill). Can they estimate tasks? Do they hit their estimates. Ask for an example of what happened when they didn't (e.g. did they tell their boss? Did they ask for help?).
Can they understand issues from other people's point of view? Are they flexible (look for multiple ways of solving problems), resourceful, cautious, measured, adventurous - can they take and avoid risks, judging according to the circumstances which is the right to do?
Ask simple questions and then hard ones. But don't launch right in, let them get comfortable first. Explain the purpose and structure of the interview, how long it will take and what the result will be. Maybe explain your own job and how theirs will fit into it.
Ask them about your own organisation -- that is, can they do research? Ask them about their own organisation -- that is, do they pay attention to their own organisation.
Look for exampes of how they have analysed their own workplace, dicovered a defect and gone about changing it (or persuading someone else to change it). Work from their own experience. Make some allowance for situations where the candidate works in a shop which is totally different to yours, but also draw a line -- if they have no evidence that they can do what you need, you can't usually justify hiring them.
Ask them what their strengths and weaknesses are. Then ask them what they really are. Ask them why they're leaving, and why they want to come to you.
Can they describe things (i.e. sequences of events or problems) clearly and simply? Do they make sure they understand the question? Ask them for examples; anybody can guess at a good hypothetical answer, look for evidence they they've really done it.
Another poster talked about "fit". It's essential. Can they work in your environment, did they win you over, are they easy to talk to, can they assert their own point of view when this is important, can they give a viable rationale for their courses of action? What special skill(s) will they bring to your environment?
Also (no particular order)
But there are loads more...
...isn't really mis-spelled.
At the time the spelling of the English language was not regulated in any way, and the spelling of common words often varied. Shakespeare himself used to spell his own name in several different ways, "Shakspear" also being used. So this spelling is not, strictly, incorrect.
The lessons I'm talking about are :-
1. Technical failures don't endanger lives etc, it's the failure of people to adequately assess and prepare for risks that is dangerous.
2. Ideally, it should take more than a single technical faillure to cause a system failure. Where this level of preparation is too expensive or time-consuming, stakeholders should explicitly take the cost versus safety decision. And review it.
3. It's quite possible to produce systems whose complexity and reliability are impressive, but you can't do it just with brilliant individuals. You have to have a process; review and criticism is vital. Having brilliant individuals certaily helps. If all you have is dumb individuals, don't bother starting.
So, if AES means Advanced Encryption Standard, does DES now mean Dumb Encryption Standard?
No, compare the US market with (say) Finland, the UK or Japan. The US lags behind in cellphone technlogy.
I thought that Vanderbilt and Biltmore were both large houses in New England...
There was also Rembrandt. Your numbering of the early versions should also include 3.0.3 and 2.1.
I can't spot a name for version 2.1 ("Red hat Commercial Linux").
In other words, the GPL is a license that covers the acts of copying or modifying the original work. You don't need to be able to agree to anything at all, and simply using the software is not a restricted act.
There are some other possibilities to consider; for example, do your queues contain many deferred items (due to note unreachability or DNS problems)? If so, you are trawling through a large mail queue to process a small number of items (since some of the items are not due to be reried yet [I'm no exim expert]).
/etc/syslog.conf to make syslogd avoid calling fsync() on the mail log for every single logged message.
If you're using a lot of disk in re-reading the queue, consider using an MTA which has a separate queue for deferred items, and/or a hashed directory structure. The Postfix mailer (by Wietse Venema) fits the bill here. Postfix is particularly good for large queues.
Postfix also is deliberately written to make filesystem accesses an absolute minimum of times for each item of mail (I think you can have as few as 3 disk accesses per item). This really reduces disk loading, especially on systems with synchronous filesystems.
On the RAID side, consider alternatives to RAID5. RAID0+1, for example, is as safe as RAID5, but faster (though it uses slightly more disk drives).
What is the balance between writes and reads on your mail server?
Are you logging syslog locally on the mail server? If so, consider either moving syslog logging to a dedicated log box. If you can't do that, consider using the leading-dash feature in