Once processes are more or less defined (or redefined) with the participation of staff (meaning that they get to give feedback) you can implement a policy of 'all processes need to follow the documented procedure. Procedure can be changed if needed'. This will in turn help to keep your documentation updated.
In fact it is essential that the processes change over time. Putting in place must-be-followed processes is counter-productive if there is not also a process to vary those processes. You must expect that the processes put in place today will be found deficient in a few weeks or months.
Put another way, one of the most important processes is the "process review" process.
Advanced Communications Technologies (ACT) in Australia was doing this with GSM back in 2000 (probably before). AFAICT they never did manage to make it work. Spent millions.
Anyone from ACT/SDR reading this could perhaps fill in more details.
I think the company is out of business now. Here's an early press release:
Rather than collecting syslog entries in one place, disseminate them to many collectors. It then becomes a very difficult task for anyone to modify the received logs because they reside in different places under guard by different systems.
syslog-ng will happily do this.
Setup UDP transport for syslog to many destinations for the same data. Each destination will receive a copy of each syslog entry and store/guard it independently. The reliability of the data is specified by the reliability of the stores. These can be commercial data storage centres.
In any dispute, read back all the relevant copies and check for any differences.
100% trust is not achievable. Settle on an acceptible level of risk.
Maybe if the catalyst was chlorophyl and you used an energy source like, say, sunlight; and provided some fractal-like structure for the carbon deposits to grow in...
Well if Intel puts the effort and cash into getting better performance, the only way for AMD to catch up is to make sure they give the same level of support to Linux.
I see this as a win-win situation. There's nothing like an arms race to push the boundaries.
Too often you know what you are trying to do but make a mistake. Self documenting code is only useful if the code is free of mistakes. IMHO it is better to comment what the code is supposed to do.
If the intention is clear then it is easier for others to determine if the implementation is correct.
Intentions also better describe why particular design decisions were made.
The most useful thing to document in code comments is the intended behaviour of the code. With this information it is simple for any half-decent hacker to find out if the code does what it is supposed to do.
Takes the guesswork out of debugging. If the code doesn't do what the comments say it was intended to do then you know you've found a bug.
You have to remember that GIF and PNG tackle created works (artwork) which are a different type of image to what JPEG tackles. JPEG is designed to compress natural (photgraphic) images. JPEG200 is the same it is targetted at natural images, ie. photographs.
Also note that doxygen (IMHO the best tool for interface documentation) will easily output to LaTeX as well as creating HTML, man pages and even M$ help files.
If you do use LaTeX, which is probably a sensible thing for any printed doc, then using doxygen for the interface and implementation (ie. code) documentation is natural fit.
If you intend to have an online component then using something like docbook or SGML is probably more sensible because it's easier (IMO) to convert from XML (eg SGML, docbook) to LaTeX than the other way around.
These components are complimentary.
If you do decide to write docbook take a look at LyX. It's awesome for writing LinuxDoc and DocBook documentation as well as straight LaTeX.
You can't copyright a chord progression. I'd challenge the uniqueness of a 10 or 15 note melody. There are elements of music that can't be avoided.
What's next copyright on 440Hz tone.
We've all seen a million and one first-person shooters over the last few years, obviously starting with Doom/Wolfenstein. What do you see as the next big move in game genres and where do you see it coming from. Until now almost all the games we've seen have been developed on Windows for Windows yet there is untapped talent and creativity in the Open Source movement. How likely is it that we will see a significant contribution to gaming from the Open Source quarter.
With Telstra privatised they are no longer accountable to the government or the ombudsman. The government's response to this is that if there is a problem with the service then people will go to the competition... which doesn't exist.
They know how to play the game, all they do is keep the level of service hovering in the region just above getting so bad that people will go throught the tortures and inconvenience of changing providers.
Telstra make a mint out of the mobile market and don't give a shit about anything else now.
Slashdot Mirror
Pretty becomes an issue when you gain revenue displaying motion picture advertising and providing additional "value added" features.
It isn't just Diebold. I work with a few different brands of ATMs and they all seem to be moving in the same direction.
In fact it is essential that the processes change over time. Putting in place must-be-followed processes is counter-productive if there is not also a process to vary those processes. You must expect that the processes put in place today will be found deficient in a few weeks or months.
Put another way, one of the most important processes is the "process review" process.
Can anyone point at a good reference.
I'm familiar with Type1, Postscript, bitmap, TrueType; but not OTF.
Advanced Communications Technologies (ACT) in Australia was doing this with GSM back in 2000 (probably before). AFAICT they never did manage to make it work. Spent millions.
Anyone from ACT/SDR reading this could perhaps fill in more details.
I think the company is out of business now. Here's an early press release:
http://www.rmit.edu.au/browse/News%20and%20Events%2FFor%20Media%2FNews%2Fby%20date%2F2000%2F;ID=poid0yrprddq;STATUS=A
Rather than collecting syslog entries in one place, disseminate them to many collectors. It then becomes a very difficult task for anyone to modify the received logs because they reside in different places under guard by different systems.
syslog-ng will happily do this.
Setup UDP transport for syslog to many destinations for the same data. Each destination will receive a copy of each syslog entry and store/guard it independently. The reliability of the data is specified by the reliability of the stores. These can be commercial data storage centres.
In any dispute, read back all the relevant copies and check for any differences.
100% trust is not achievable. Settle on an acceptible level of risk.
Maybe if the catalyst was chlorophyl and you used an energy source like, say, sunlight; and provided some fractal-like structure for the carbon deposits to grow in...
:)
Damn! It's already patent-pending!
Well if Intel puts the effort and cash into getting better performance, the only way for AMD to catch up is to make sure they give the same level of support to Linux.
I see this as a win-win situation. There's nothing like an arms race to push the boundaries.
Too often you know what you are trying to do but make a mistake. Self documenting code is only useful if the code is free of mistakes. IMHO it is better to comment what the code is supposed to do.
If the intention is clear then it is easier for others to determine if the implementation is correct.
Intentions also better describe why particular design decisions were made.
The most useful thing to document in code comments is the intended behaviour of the code. With this information it is simple for any half-decent hacker to find out if the code does what it is supposed to do.
Takes the guesswork out of debugging. If the code doesn't do what the comments say it was intended to do then you know you've found a bug.
You have to remember that GIF and PNG tackle created works (artwork) which are a different type of image to what JPEG tackles. JPEG is designed to compress natural (photgraphic) images. JPEG200 is the same it is targetted at natural images, ie. photographs.
Also note that doxygen (IMHO the best tool for interface documentation) will easily output to LaTeX as well as creating HTML, man pages and even M$ help files.
If you do use LaTeX, which is probably a sensible thing for any printed doc, then using doxygen for the interface and implementation (ie. code) documentation is natural fit.
If you intend to have an online component then using something like docbook or SGML is probably more sensible because it's easier (IMO) to convert from XML (eg SGML, docbook) to LaTeX than the other way around.
These components are complimentary.
If you do decide to write docbook take a look at LyX. It's awesome for writing LinuxDoc and DocBook documentation as well as straight LaTeX.
You can't copyright a chord progression. I'd challenge the uniqueness of a 10 or 15 note melody. There are elements of music that can't be avoided. What's next copyright on 440Hz tone.
We've all seen a million and one first-person shooters over the last few years, obviously starting with Doom/Wolfenstein. What do you see as the next big move in game genres and where do you see it coming from.
Until now almost all the games we've seen have been developed on Windows for Windows yet there is untapped talent and creativity in the Open Source movement. How likely is it that we will see a significant contribution to gaming from the Open Source quarter.
They know how to play the game, all they do is keep the level of service hovering in the region just above getting so bad that people will go throught the tortures and inconvenience of changing providers.
Telstra make a mint out of the mobile market and don't give a shit about anything else now.
About time others were allowed fair access.