If you do everything in the constructor and the destructor, and in the meantime store a generic instance (or maybe a list of generic instances) somewhere.
This can be a quite rare situation, though. But not impossible.
one should also note that even if we take a fantasist hypothesis of a major breakthrough demonstrating a loose of strength of 2 bits for AES-128 once a year during ten years, we would probably still have tens of years to replace the cipher. Of course this theory is full baseless hypotheses, but even more is the theory that would says that there is a risk of a major breakthrough tomorrow reducing the strength of AES-128 to 64-bits.
Considering how i use computers, most of the time i found it far more convenient to apt-get search and 20s latter install (or the equivalent with the package manager you use) than downloading a random piece of software from a random internet site, which from this point might become a risk if it does not auto update, and if it does it's with a stupid yet-another rewritten auto update program that always uses 50 MB of RAM for just one program installed on the system, even when the program does not run.
And considering the success of "app stores" and the general dislike of the traditional windows desktop computers by the general public (except if you are fool enough to help them for free doing all the busy work maintenance tasks that can't even exist on serious systems), I guess the centralized packaging and distribution model is also pretty convenient for the general public...
I argue that it's claiming the traversal of linked lists, provided you have a choice between at least two linked lists containing the same set of elements. I argue that this restriction is meaningless, because it has no technical impact in this patent. Even when the patent seems to try to be a little more broad, by trying to describe the data structure itself, this description also depends on traversal and nothing else: "[claim 1 ...] said primary function pointer functioning as a primary linked list to direct a computer program to a first sequence to _traverse_ said computerized list [...]" (x2 because the same thing is written for the "auxiliary" list, then x3 in claim 2 for the "tertiary" one).
There is never any interaction described between one list and the other -- so from the point of view of patenting I don't see anything difference between this patent and a mere description of basic single linked lists, description centered on its traversal (the various enumerations are to be considered as irrelevant in themselves, and are not supplemented by anything else).
That reason alone would be one of the major angle of attack of the patent, would it not be already even more basically invalid because of triviality and prior art. The only challenge would be to present those formal concepts using casual language clearly enough so that nobody would mistake this description as the description of a new structure (even in the hypothetical alternate universe where nobody ever previously used two lists at a times for ordering the same sets of elements)
There is nothing anti-competitive in distributing something at marginal cost, when expected revenues that fit into a proven and habitual business model are elsewhere.
More on 2.; for the purpose of disclosing knowledge, patents are typically somewhere between 10 and 1000x less useful than a good scientific paper. And the content of the innovative parts of most scientific papers are not covered by patents. Open source software is another thing that makes software patents useless for the purpose of disclosure; the value it could bring to society is hugely inferior to the value achieved by open source software + academic publications, and the cost is hugely superior. In itself, that should be enough to forbid software patents, especially because there are at the same time proven efficient ways to protect computer programs.
I agree there is a risk of misinterpretation as in "all kind all linked lists have been patented, here is the patent" and for this reason, it maybe would have been better to get an even more precise title. By i'm technically still fine with the current one. The claims (both in the application and in the granted patent) barely talk about traversing the "primary" or the "auxiliary" list which provide another sequence (well, providing the same would be... useless), not any kind of tricky algorithm like efficient multiple simultaneous sorting or i don't know what, not even a plain and boring insertion is covered!
This is a special case of traversing multiple linked lists, which is a basic technique. I actually even hesitate to say it is a technique, or at least to distinguish this technique from the very same technique of using a single linked list, because I don't think I could ever come up with a plausible justification for why anybody previously knowing how to use one would not be able to use two.
The restriction making this a special case is that all lists contain the same set of elements. Given the claims, that restriction is unnecessarily narrow and have no technical effect. So the only thing that distinguish this patent from a patent on a particular (but still 100% basic) use of single linked lists, is the phrasing, and the empty (still given the context) emphasis on the fact there are not one, but two, or even three lists.
So despite the fact that basic singly-linked lists + limited to one list by element would not be covered by this patent even in the parallel universe where it would be considered valid (and while we can note that on the contrary, prev/next linked list would), given that it only claims (with many more sentences) that if you have two lists, you can traverse one, or you can traverse the other, i will continue to argue that it covers linked lists, maybe under certain conditions, all right, but those conditions are insufficient to mandate the precision that this is a modification of linked lists, because it is not a modification, it is just about the basic traversal of multiple plain classical linked lists.
(Also, one a side note, I found it cute how the claims are structured, like if the author thought there was a possibility that prior art could be found for two pointers but not three.)
Edit: About the inflammatory part, it might as well have been even more inflammatory by being even more descriptive. Somebody has patented traversal of linked lists.
At first I thought that too. But within 1 or 2s, I remembered that linked lists have never been limited to single linked lists (except maybe in poor quality courses), multiple linked lists have been around since Unix and very very probably before, have nothing inherently special, so it's absolutely all right to both simply call them "linked list" (like the patent properly does in its title) and to consider them as CS 101.
The patent is both obviously invalid and properly named "Linked List". That it is does not cover the single linked list special case does not changes this fact. The title is neutral, and you are inferring an anti-patent tendency from a neutral reporting (from which crowd btw?). I would be hugely curious to hear on which base you inferred that.
Summary by one sentence of the article: "Now, I’m not a software developer, mathematician, or patent expert". That reads in other parts of the text... and even in the poor choice of patent excerpts.
Some parts are naive at a rare level, e.g.:
"Those rules might actually solve the software patent dilemma for us if we just wait long enough: the gold rush to patent all these fundamental software technologies means that they’ll all be public domain prior art in a few years, and any obvious improvements won’t be patentable. The pendulum swings both ways."
And the long rant about software patent not being explicitly defined in the law and that fact being considered as an important advance in the discussion -- well did anybody did not know that? And even if it was the case, does that make the general discussion about the goodness or badness of patenting software irrelevant in any way?
IIRC Os X can now resize its own FS, so we can probably let my beautiful (just kidding) HFS code RIP. I won't talk for the other FS code, I have no special knowledge of them.
I have had no involvement in Parted for years (i'm doing radically different things), but as the one who wrote the HFS shrinking code I think and can explain my opinion on the subject. In summary it's a good idea to remove FS code if it has unknown status because the environment changed, and nobody is there to check every details.
Data security is to be taken very seriously in that kind of tool, and getting confident enough that a good level was achieved was actually what took most of the time when i wrote the hfs shrinker (I even unplugged the computer tens of times while resizing, then checked that the whole content of all files on the whole fs did not changed, then checked that OS X still booted and worked properly, + checked some internal metadata field of the FS, and so over). A correct review + tests in the modern context would take a lot of time, and I don't know if somebody have it but I haven't had in the last few years, still don't have, plus I don't even have the needed hardware anymore, so nobody should count on me.
Also one would have to check that the HFS+/HFSX has not evolved and implement support for interesting additional features Apple could have introduced in recent years.
That makes me a little nostalgic, but I 100% agree that without a careful review it is better to remove it (people who know what they are doing can still use an older version of the software, it's free software after all) than leave that kind of code that is now having an unknown status since the context of the environment has changed.
Of course that opinion is only relevant for the HFS code. I know nearly nothing about the other parts.
That is a little sad because the FS code was once the whole point of Parted. But that does not mean the removal was not justified, I don't know, I've been away from Parted for a very long time.
"Revolutions" in the industry are often not the result of a big bang, but more frequently of mere accumulation of little steps. GNU+Linux has not changed anything in the industry when initially released. It was years (decades?) behind current techs at this time (but has fast taken leadership in many areas), and at first only used by hobbyist, then only used for applications with simple needs on simple hardware as a cost reduction measure, then used in more areas and so over.
And I'm far from sure that the decisions good for the long term development of Linux would be done by bigcorps if Linus went missing anyway (especially not Google). Bigcorps have bad habits (with high impedance mismatch in the context of the Linux project), like development behind closed doors, and not only time-to-the-market centered but even for some of them time-to-the-market weighting 95% in their choices. Because of that, bigcorps were the cause of the arm branch mess in the first place. Bigcorps often lead big projects that fails big. And Linux is not lead by bigcorps anyway, it's lead by peoples.
Also, the same argument could be applied to lot of people in leadership positions anyway. Maybe Apple would not be Apple without Steve Jobs, but the CEO does not matter more in lots of big companies than Linus matters for Linux. Maybe it would be very equivalent with somebody else, or maybe not, but in the meantime they are in charge, and when they do a good job, they are the ones who matter.
It's debatable whether github is more important than git or not. Despite the impression a reader of this site could have that (hype and with an user interface copy pasted from the prototype hype fashion simple user interface of the moment, with Big Buttons tm included) hosted services are the best thing since sliced bread and will replace everything, the world is interestingly neither centered around that, and it's indeed very ironic to value importance of centralized services more than the decentralized tool it embraces and extend, given many of the advances in the source code management area and development workflow directly come from the decentralized aspects.
That Hg also exist does not make git less important than github, no more than the fact that sourceforge exists make github less important than git.
That does not make him irrelevant when he is still here. For example, the direction he "recently" gave to the arm branch (basically ordering everybody to clean up their shit immediately), will probably imply that Linux has been and will be more successful on portable devices. Would the same thing have happened without him? Maybe, or maybe not.
This can be a quite rare situation, though. But not impossible.