I have a friend by the name of Simon Tufty who made a piece of software for designing kites. The output of this software was the plan which you then had to cut out to make the kite. The plan was on a scale of 1:1 and was therefore considerably bigger than most people's printer. He therefore wrapped it in a postscript wrapper that would do the tiling inside the postscript file itself. Therefore if you opened the plan in GV, then the number of pages that the document had would depend on the size of the output format that you set. It would also auto-create the cut marks around the edge along with labels to let you know which page should line up with which other page. Very cool. I don't believe that he is supporting the kite application any more, but I'm sure that if you got in touch with him then he would be happy to discuss the postscript hack.
And with 10,000 of those defined in your code, that's 10,000 instances of slightly-relabled Object to be constructed at startup and sit in RAM afterward, doing diddly-squat. A "public static final int CONST_FOO = 1" type definition meanwhile occupies precisely 4 bytes of space and takes no time to initialize.
Fair enough. Couple of points that I would bounce back at you though:-
If you have 10,000 constants of any type inside a program design then I reckon that you are going to have larger problems than just your boot-up time.
If you have to have these constants then compartmentalising them in some way into sections that can be loaded individually by the classloader (either on demand or in a background thread) will help the start-up time.
Try running a decent java debugger / profiler like OptimizeIt and look at the number of "system" level Objects that are created. You may well find that the overhead of your 10,000 Objects is really not a major issue after all.
The benefits in terms of enforced range checking that is provided with the private constructor / public final static instances in will generally pay dividends in the long run. I know that we are all good programmers and we always check the range of any integer constant, but what happens when this range changes in the future? Do you want to be responsible for checking through all the 3rd party code that utilises your constants to make sure that they handle the new values?
Also, one thing I had wondered, do you overload toString to return the internationalized string, or do you return the key to the properties file for external use? The first controls all access in one place, but the second makes it easier to centralize internationalization one place and turn it over to the translators.
I would generally say that something as generic as toString() shouldn't be tied to a particular meaning (especially when interfaces are concerned). Instead, I would be much more likely to provide a seperate Interface that described i8n (if I was using it). Another reason for this is that I kind of feel that toString() should be "relatively" constant for a given Object and if the value changed as some external entity changed the current language then this might confuse matters. I would be more likely to return the name of the key, with some additional information to make it clear that this is the key to a MyEnum Object such as "MyEnum(key)" to clarify the difference between it and a normal String with a value of "key". All depends on the context though...
Don't forget to overload hashCode() as well if you are going to supply your own implementation of equals(). You'll have all sorts of fun trying to make sense of putting your Objects into hashed data structures otherwise.
The
equals-hashCode contract states that two objects that are equal must return the same hashCode.
The easiest way of making a cleaner approach to storing the ranges of items in the maps (without having to remember to update lots of locations when you change the contents of your MyEnum[] is to use the contents of the Array itself. So if you just want a List then you would say:-
public final static List FIRST_AND_THIRD_LIST = Collections.unmodifiableList( Arrays.AsList( FIRST_AND_THIRD ) );
Now in your example, you are using a Hashtable with a method of MyEnum called getName(). I would be tempted to extract this Nameable method into an interface (Named) and then create a dedicated Map that would look something like this:-
public class NamedMap extends HashMap { public NamedMap() { super(); }
public NamedMap(Collection collection) { this(); put(collection); }
public Object put(Named named) { put(named.getName(), named); }
public Object put(Collection collection) { Iterator items = collection.iterator(); while (items.hasNext()) { Object item = items.next(); if (item instanceof Named) { put((Named) item); }}}
}
Then you can finish up by adding another constant to your MyEnum class that provides you with the Map functionality that you wanted:-
public final static Map FIRST_AND_LAST_MAP = new NamedMap(FIRST_AND_THIRD_LIST);
Now if you change the definition of FIRST_AND_LAST then all of your other constants (List and Map) will get updated automatically thereby ensuring that you preserve the main benefit of utilising constants: only having to remember to Get Things Right Once.
I actually think of this as an indicator of Bad design. Use of symbolic constants, especially as a replacement for Enum, is a serious breach of OO design in most cases. Static immutable instances of classes that the enum represents are quite often a better way to go.
The Static immutable instances of classes gets half-way there, but doesn't stop people creating new instances of the classes and then you are back where you where to begin with. A better thing to do is to forcibly limit the instances of the classes to a fixed number of instances like so:-
public class MyEnum { private MyEnum() { } public final static MyEnum OPTION1 = new MyEnum(); public final static MyEnum OPTION2 = new MyEnum(); public final static MyEnum OPTION3 = new MyEnum(); }
Now you are guaranteed that there is only ever going to be MyEnum.OPTION1, MyEnum.OPTION2 and MyEnum.OPTION3.
Does anyone know why interfaces have data members at all?
It can be a very useful way of exposing constants. For example, consider the following:-
public interface VariableList { public final static String VAL1 = "val1"; public final static String VAL2 = "val2"; public final static String[] VAL_ARRAY = { VAL1, VAL2 }; public final static List VAL_LIST = Collections.unmodifiableList( Arrays.asList( VAL_ARRAY ) ); }
This will provide you with a slightly more flexible set of constants that are automatically acquired by anything that implemnts the VariableList interface.
Alternatively, you can use Mutable variables. Remember that it is only the references to the variable that is final. If the Object itself contains information then it accessed by all classes that implement the interface. For example:-
public interface CountMe { public Set INSTANCES = new Set(); }
If we now stipulate that all instances of CountMe that want to be included in the CountMe functionality should register themselves inside the INSTANCES variable, for example:-
import java.util.*;
public class Test {
public Test() { Class1 class1 = new Class1(); Class2 class2 = new Class2(); Iterator instances = class1.INSTANCES.iterator(); while( instances.hasNext() ) { System.out.println(instances.next()); } }
public interface CountMe { public Set INSTANCES = new HashSet(); }
public class Class1 implements CountMe { public Class1() { INSTANCES.add(this); } }
public class Class2 implements CountMe { public Class2() { INSTANCES.add(this); } }
public static void main(String[] args) { new Test(); } }
and there you have it - data sharing across interfaces with no extending classes at all. Of course, you cannot force classes to register themselves in the INSTANCES variable, but if you wanted to extend a couple of base classes then it would be trivial to make a couple of implementations of CountMe that extend each of them which enforce the functionality explicitly.
But it sounds like your marketters want to combine the two: Use a "forwarded email"-type of marketing, but where the big elements reside on your servers in your office. That is not cheap.
Totally agree. Only reasons for taking this course of action might be:-
If the technology being used necessitates a server driven solution
If the filesizes involved are unpractical to transfer over email channels
If the tracking information from the usage logs of the server (especially in interactive applications) is worth more in itself to the company than the cost of hosting it.
If the ROI turns out to be high enough (although this is a big IF)
If the coverage is sufficiently higher - admins block large attachments and people are starting to think about what they send to other folk after being battered by so many emails, but people will generally forward URL's to each other without a thought.
Recently, I had the pleasure of attending the VFX 2002 conferance where I was treated to a preview of the new render of Shrek by Don MacBain on behalf of PDI / Dreamworks. This was an extension of the work that they had done on Antz and basically consisted of:-
re-rendering for IMAX. As a result of the larger screen format, a lot of the cuts where no longer appropriate so they changed a load of the camera views and speed of pans to make it more palatable on an IMAX screen (no motion sickness).
Upping the resolution. I forget what the original resolution of render was but the target for this version is (from memory) 4000 x 3000 pixels.
Rendering the whole thing as fully polarised-light 3d.
They only had one scene completed which was the crossing the rope bridge over the lava scene, but I can say that it was the most incredible bit of computer animation that I've ever scene. Don't know when the final thing is going to be finished, but I would definately recommend it to anyone...
Finally a post which actually addresses the points that I was actually hoping to have a discussion about...
If that's what you mean by "viral" ads, go for it, and don't feel bad about it. Just be sure it's quality stuff, because the quality will reflect directly on the sponsor. One issue you should worry about is bandwidth. If these ads are large, consider a format where people can email links to their friends rather than the ads themselves.
This is the key. By definition, once a viral campaign gets going, you have no control at all over who looks at your gimmick or even how many people look at it. If folk are emailing it to each other then this is not your concern because there is no direct cost to yourself or the client. However, if the cost of participating in the gimmick is carried by yourself (because you are hosting the data), then hundred's of thousands of unsuitable eyes looking at your ad suddenly becomes a problem.
Most advertising mediums have a modicum of targetting. You decide roughly speaking where and how you are going to release the advertisments in the hope of targetting a specific audience which is hopefully relevant to the product. However, once a viral campaign is under way then you have no control at all. You have no idea what sort of people are going to participating or whether it is sucessful...
So what I am interested in is if there is any research done on the demographic spread of viral style ads as defined by the previous poster and whether or not they have been effective in terms of a return on the investment. (Maybe it's time to try and hack webalizer into one of the graphical traceroute functions to try and plot the spread of a site...)
If by 'valid' you mean 'effective', yes. So are many other forms of fraud and deception.
This is where I am confused. Yes, there are situations when folk "in the name of Viral Marketing" masquerade as someone who they are not. Yes, this is fraud and deception and you tend to end up looking really stupid (as microsoft's switch campaign showed). But unless I'm being really obtuse, then this isn't what I'm talking about. How is a company hiring a designer or an artist to create a work that they feel is interesting and innovative which is branded by the sponsor that created it in the hope that the members of the public promote it themselves fraudulent or deceptive? If we take this into account, then is your answer to my question still yes and if so then what are your reasons for this?
It has very little to do with large email attachments. It's all about focusing on a small, tight-knit community who communicates alot, and then exploiting those communication channels. Word of mouth.
I would totally agree with you except in cases when the the incentive to forward the email on to another load of people is the payload of the email (rather than some direct transaction with the company (as you mentioned elsewhere with bribes). If an email forwarded item is going to become self-sustaining then it either has to forward itself (in the case of a software virus) or it has to provide the host with an excuse to pass it on to new folk. The more folk that it can interest, the greater the chances of actually reaching the coverage that it desires. If it "dies" (ie is not forwarded on to anyone else) as soon as it arrives at a person who is not directly interested in the product then it will by definition be less sucessful. Therefore an email that carries an attachment that is entertaining in it's own right will, by definition, provide better dispersion than an item that directly narrows down the target audience to the product.
Now, what I was trying to ask when I posted the story was (and judging from the general posts so far I failed miserably to get my point across) was: Is the creation of marketing material that is so far removed from the target product to become an interesting thing in its own right a valid model for doing business?
Gimmick Promotions
These centre around some kind of novelty, such as an email attachment game, interactive section to the website, 'special offer' requiring you to 'recommend' the email addresses of friends in order to get a discount. In terms of generating traffic these can be the most productive tactics. Many variations on this exist, and chances are you've received or seen some form of it at some time, athough you may not be aware of it.
This is closer to what I was referring to when I posted the original story. Or to put it another way:-
Eventually the attachments got to some exec in advertising who, instead of worrying about their copyright being ripped off, realised that if they could get people to forward their adverts to each other they could save a hell of a lot on airtime and look cool in the bargain without worrying about the censors. Bingo.
My understanding was that once a sucessful viral campaign was under way, it would become self-sustaining thereby opening up the possibility of exposure to a load more eyeballs...
I am still of the opinion people would have to look quite hard to try and beat games such as Jetpac by Ultimate for the 16K Spectrum. Or if you wanted a bit more depth to the game then there was the followup Lunar Jetman which had a massive gameplaying area - but then you had to shell out and get a Spectrum with the somewhat excessive memory of 48K!!! Hmmm. Progress is good. Isn't it???
(quick aside: while trying to verify the name of Lunar Jetman, I came across this site. Nice trip down memory lane for all Spectrum users...
So what's wrong with colorful graphics and cartoonish characters? Do games have to feature gore and ultra-violence to be entertaining? Hell no.
I also reckon that shying away from the photo-realistic eye-candy approach also means that you have to focus on gameplay which I quite often feel is sadly lacking from a lot of the more "modern adult games"
As chance would have it, I had to perform this task for one of my clients at the weekend as they had just deleted their entire active database (doh!). After a load of research, I found that the best resources are to be found in the reiserfs mailing list.
The key post was this one which pointed me at using:-
Very scary. Had to boot into a rescue system off CD first, mount HDD RO, then get enough tools to be able to backup the HDD to a remote box. Unmount disk and then run reiserfsck. Pray for a bit. Got all the db files back (and because they where in a directory that was deleted, they had all the correct names as well (once I'd found the directory)).
There was some minor file-system corruption for files that had been written frequently, but this was taken care of by restoring the previous backup and checking everything else from the RPM db. So, all-in-all not an experience that you would want to do on a daily basis, but definately worth it to restore 2 months of lost work (why oh why don't people use backups?).
As far as kernel hooks for undeleting data, the mailing list link above contains several discussions about this, but the general feeling seems to be that it is possible but Linus doesn't want it (see here.
You are confusing "shades of blue" and "linear interpolation between two colours". Yes there are lots of shades of blue (some people might even say that every colour where B > R && B > G is a shade of blue), but if you are doing a gradient then you want the shortest distant between two points. If this is of length 443 and your unit resolution is that of 1 then I don't see where you are going to get your extra colours from. In fact what you are going to have to do is to take alias your colours when you do the interpolation and therefore you will be introducing colours that do not strictly speaking lie on the perfect line at all. The smaller that your quantisation limit is, the closer to the ideal your interpolation becomes and the less visible artifacts are introduced.
Also remember that the figure of 443 is the theoretical maximum number that can be achieved. Most interpolations will be from two points in the colour cube that are much closer together and will therefore result in correspondingly worse artifacts.
If you want to display a gradient from say, dark blue to light blue, you have quite a few shades of blue to choose from. More than 1024, that's for sure, especially in 32 bit color. But your monitor can only display 1024 vertical lines, each being a different shade. (Depending on your resolution, blah, blah, blah.)
Hmmm. Close but still not quite right. Think of the colour space as a cube with RGB as the three axis of the cube. In 32bit colour you have 8 bits per colour plane, giving you a cube that is 256 x 256 x 256. Any gradient from any point on the cube to any other point on the cube is going to be a maximum of 443 (if my maths is freaked out - distance from two opposite corners of the cube). Plus some messing about with the various quantisation that this line will pass through gives you definite banding on all but the lowest resolution displays...
It's things like this that make writing supposedly cross-platform java code a nightmare. The number of times that people introduce subtle bugs that are a nightmare for people to debug by assuming that filenames are case insensitive or that the path seperator is the "\" character...
actually I'll rephrase that, its folk making assumptions like this (or just having a lazy day) that make maintaining cross-platform code on a different platform to one that the developers had access to a nightmare...
I was going to recommend that you went to talk to the folks over at demudi who are building a distro variant of Debian tailored to audio applications, and therefore will probably have plenty of information about multi-channel IO, but on visiting their site I found that they have merged with agnula which is news to me and looks quite interesting. Am off to go and read up on what is going on...
If you have it, can you post the patch too? (If the lame filter allows it, of course...)
I do have it, but I left it off because of the amount of mangling that I had to do to the message to get it to accept that I thought it was unwise to do the same to a patch...
Doh! received it on suse-security, so here is a link to their archive of the mail (including patch). Enjoy...
This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.
Advisory 1
A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.
Vulnerabilities
All four of these are potentially remotely exploitable.
1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.
2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.
3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.
4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4.
In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.
Who is affected?
Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is
vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable.
SSLeay is probably also affected.
Recommendations
Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or
TLS.
A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).
Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.
Client should be disabled altogether until the patches are applied.
Known Exploits
There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is possible, but have not released the exploit code.
The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research
Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537.
The patch and advisory were prepared by Ben Laurie.
Advisory 2
Vulnerabilities
The ASN1 parser can be confused by supplying it with certain invalid encodings.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.
Who is affected?
Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME
(PKCS#7) or certificate generation routines.
Recommendations
Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.
Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.
Exploits
There are no known exploits for this vulnerability.
"some time in the future" sounds to me like "if I can't sell it to somebody first"
or when I am sufficiently happy with the internal data structure of my code that it is not going to go through any major structural changes and therefore has an API that is interesting to link to...
Slashdot Mirror
off topic, but touche! :-)
I have a friend by the name of Simon Tufty who made a piece of software for designing kites. The output of this software was the plan which you then had to cut out to make the kite. The plan was on a scale of 1:1 and was therefore considerably bigger than most people's printer. He therefore wrapped it in a postscript wrapper that would do the tiling inside the postscript file itself. Therefore if you opened the plan in GV, then the number of pages that the document had would depend on the size of the output format that you set. It would also auto-create the cut marks around the edge along with labels to let you know which page should line up with which other page. Very cool. I don't believe that he is supporting the kite application any more, but I'm sure that if you got in touch with him then he would be happy to discuss the postscript hack.
Fair enough. Couple of points that I would bounce back at you though:-
I would generally say that something as generic as toString() shouldn't be tied to a particular meaning (especially when interfaces are concerned). Instead, I would be much more likely to provide a seperate Interface that described i8n (if I was using it). Another reason for this is that I kind of feel that toString() should be "relatively" constant for a given Object and if the value changed as some external entity changed the current language then this might confuse matters. I would be more likely to return the name of the key, with some additional information to make it clear that this is the key to a MyEnum Object such as "MyEnum(key)" to clarify the difference between it and a normal String with a value of "key". All depends on the context though...
The easiest way of making a cleaner approach to storing the ranges of items in the maps (without having to remember to update lots of locations when you change the contents of your MyEnum[] is to use the contents of the Array itself. So if you just want a List then you would say:-
Now in your example, you are using a Hashtable with a method of MyEnum called getName(). I would be tempted to extract this Nameable method into an interface (Named) and then create a dedicated Map that would look something like this:-
Then you can finish up by adding another constant to your MyEnum class that provides you with the Map functionality that you wanted:-
Now if you change the definition of FIRST_AND_LAST then all of your other constants (List and Map) will get updated automatically thereby ensuring that you preserve the main benefit of utilising constants: only having to remember to Get Things Right Once.
The Static immutable instances of classes gets half-way there, but doesn't stop people creating new instances of the classes and then you are back where you where to begin with. A better thing to do is to forcibly limit the instances of the classes to a fixed number of instances like so:-
Now you are guaranteed that there is only ever going to be MyEnum.OPTION1, MyEnum.OPTION2 and MyEnum.OPTION3.
It can be a very useful way of exposing constants. For example, consider the following:-
This will provide you with a slightly more flexible set of constants that are automatically acquired by anything that implemnts the VariableList interface.
Alternatively, you can use Mutable variables. Remember that it is only the references to the variable that is final. If the Object itself contains information then it accessed by all classes that implement the interface. For example:-
If we now stipulate that all instances of CountMe that want to be included in the CountMe functionality should register themselves inside the INSTANCES variable, for example:-
and there you have it - data sharing across interfaces with no extending classes at all. Of course, you cannot force classes to register themselves in the INSTANCES variable, but if you wanted to extend a couple of base classes then it would be trivial to make a couple of implementations of CountMe that extend each of them which enforce the functionality explicitly.
Totally agree. Only reasons for taking this course of action might be:-
They only had one scene completed which was the crossing the rope bridge over the lava scene, but I can say that it was the most incredible bit of computer animation that I've ever scene. Don't know when the final thing is going to be finished, but I would definately recommend it to anyone...
Finally a post which actually addresses the points that I was actually hoping to have a discussion about...
This is the key. By definition, once a viral campaign gets going, you have no control at all over who looks at your gimmick or even how many people look at it. If folk are emailing it to each other then this is not your concern because there is no direct cost to yourself or the client. However, if the cost of participating in the gimmick is carried by yourself (because you are hosting the data), then hundred's of thousands of unsuitable eyes looking at your ad suddenly becomes a problem.
Most advertising mediums have a modicum of targetting. You decide roughly speaking where and how you are going to release the advertisments in the hope of targetting a specific audience which is hopefully relevant to the product. However, once a viral campaign is under way then you have no control at all. You have no idea what sort of people are going to participating or whether it is sucessful...
So what I am interested in is if there is any research done on the demographic spread of viral style ads as defined by the previous poster and whether or not they have been effective in terms of a return on the investment. (Maybe it's time to try and hack webalizer into one of the graphical traceroute functions to try and plot the spread of a site...)
This is where I am confused. Yes, there are situations when folk "in the name of Viral Marketing" masquerade as someone who they are not. Yes, this is fraud and deception and you tend to end up looking really stupid (as microsoft's switch campaign showed). But unless I'm being really obtuse, then this isn't what I'm talking about. How is a company hiring a designer or an artist to create a work that they feel is interesting and innovative which is branded by the sponsor that created it in the hope that the members of the public promote it themselves fraudulent or deceptive? If we take this into account, then is your answer to my question still yes and if so then what are your reasons for this?
I would totally agree with you except in cases when the the incentive to forward the email on to another load of people is the payload of the email (rather than some direct transaction with the company (as you mentioned elsewhere with bribes). If an email forwarded item is going to become self-sustaining then it either has to forward itself (in the case of a software virus) or it has to provide the host with an excuse to pass it on to new folk. The more folk that it can interest, the greater the chances of actually reaching the coverage that it desires. If it "dies" (ie is not forwarded on to anyone else) as soon as it arrives at a person who is not directly interested in the product then it will by definition be less sucessful. Therefore an email that carries an attachment that is entertaining in it's own right will, by definition, provide better dispersion than an item that directly narrows down the target audience to the product.
Now, what I was trying to ask when I posted the story was (and judging from the general posts so far I failed miserably to get my point across) was: Is the creation of marketing material that is so far removed from the target product to become an interesting thing in its own right a valid model for doing business?
This is closer to what I was referring to when I posted the original story. Or to put it another way:-
My understanding was that once a sucessful viral campaign was under way, it would become self-sustaining thereby opening up the possibility of exposure to a load more eyeballs...
I am still of the opinion people would have to look quite hard to try and beat games such as Jetpac by Ultimate for the 16K Spectrum. Or if you wanted a bit more depth to the game then there was the followup Lunar Jetman which had a massive gameplaying area - but then you had to shell out and get a Spectrum with the somewhat excessive memory of 48K!!! Hmmm. Progress is good. Isn't it???
(quick aside: while trying to verify the name of Lunar Jetman, I came across this site. Nice trip down memory lane for all Spectrum users...
I also reckon that shying away from the photo-realistic eye-candy approach also means that you have to focus on gameplay which I quite often feel is sadly lacking from a lot of the more "modern adult games"
Why not download PD from here and have a play around. Creating a delay between the audio inputs and outputs is very easy...
The key post was this one which pointed me at using:-
Very scary. Had to boot into a rescue system off CD first, mount HDD RO, then get enough tools to be able to backup the HDD to a remote box. Unmount disk and then run reiserfsck. Pray for a bit. Got all the db files back (and because they where in a directory that was deleted, they had all the correct names as well (once I'd found the directory)).
There was some minor file-system corruption for files that had been written frequently, but this was taken care of by restoring the previous backup and checking everything else from the RPM db. So, all-in-all not an experience that you would want to do on a daily basis, but definately worth it to restore 2 months of lost work (why oh why don't people use backups?).
As far as kernel hooks for undeleting data, the mailing list link above contains several discussions about this, but the general feeling seems to be that it is possible but Linus doesn't want it (see here.
Also remember that the figure of 443 is the theoretical maximum number that can be achieved. Most interpolations will be from two points in the colour cube that are much closer together and will therefore result in correspondingly worse artifacts.
Hmmm. Close but still not quite right. Think of the colour space as a cube with RGB as the three axis of the cube. In 32bit colour you have 8 bits per colour plane, giving you a cube that is 256 x 256 x 256. Any gradient from any point on the cube to any other point on the cube is going to be a maximum of 443 (if my maths is freaked out - distance from two opposite corners of the cube). Plus some messing about with the various quantisation that this line will pass through gives you definite banding on all but the lowest resolution displays...
actually I'll rephrase that, its folk making assumptions like this (or just having a lazy day) that make maintaining cross-platform code on a different platform to one that the developers had access to a nightmare...
I was going to recommend that you went to talk to the folks over at demudi who are building a distro variant of Debian tailored to audio applications, and therefore will probably have plenty of information about multi-channel IO, but on visiting their site I found that they have merged with agnula which is news to me and looks quite interesting. Am off to go and read up on what is going on...
I do have it, but I left it off because of the amount of mangling that I had to do to the message to get it to accept that I thought it was unwise to do the same to a patch...
Doh! received it on suse-security, so here is a link to their archive of the mail (including patch). Enjoy...
OpenSSL Security Advisory [30 July 2002]
This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.
Advisory 1
A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.
Vulnerabilities
All four of these are potentially remotely exploitable.
1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.
2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.
3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.
4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4.
In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.
Who is affected?
Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable.
SSLeay is probably also affected.
Recommendations
Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS.
A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).
Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.
Client should be disabled altogether until the patches are applied.
Known Exploits
There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is possible, but have not released the exploit code.
References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0655
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0656
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0657
Acknowledgements
The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537.
The patch and advisory were prepared by Ben Laurie.
Advisory 2
Vulnerabilities
The ASN1 parser can be confused by supplying it with certain invalid encodings.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.
Who is affected?
Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.
Recommendations
Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.
Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.
Exploits
There are no known exploits for this vulnerability.
References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0659
Acknowledgements
This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly based on a version by Adi Stav.
The patch and advisory were prepared by Dr. Stephen Henson.
or when I am sufficiently happy with the internal data structure of my code that it is not going to go through any major structural changes and therefore has an API that is interesting to link to...