The IRS rarely goes back more than three years, and then only if there appears to be a serious problem. As far as the value of keeping receipts for minor expenses from even three years ago goes, one might consider the cost to you if the IRS arbitrarily decided to disallow all of them. For many people that is a such a small number it is not worth losing sleep over.
If you run a non-trivial business, are relatively well off, or have deductions for large transactions, however, you better keep documentation for all of that.
You yourself give the authors of GPL software the right to force you to open your code when you agreed to use their software
That's not true. If the authors of the software in question sue you and win, the remedy will be a combination of two things - monetary damages and future compliance with the terms of the license, if the code in question is going to continue to be used. The authors can't force you to open your code. What they can do, with the help of the courts, is require you to comply or quit.
No problem. I did some limited application programming on the ST and I am pretty sure TOS didn't do multitasking at all (preemptive, cooperative, or otherwise) until 1993 or so.
The ST had decent hardware though, much nicer than most of the Macs at the time, and in some respects better than the Amiga. Better (if smaller) monitors, better (non-interlaced) hi-res monochrome than the Amiga had for several years, more memory standard, and of course built in MIDI ports. Hard drives were more common on the Atari ST early on too.
The Amiga OS had a preemptive multitasking with a "proper" task scheduler from the very beginning. It was designed for it. Perhaps you are thinking of the Mac, to which cooperative multitasking was added using a clever hack about three years after release.
True multitasking, yes - on an eight bit computer, which is outstanding. But multitasking is not very useful on a personal computer without a multitasking GUI, and those required a lot more resources than were available on affordable computers in the early 80s.
The Amiga 1000 shipped with 256K of ram, but it was more or less a toy without 512K. A 16/32 bit MC68000 processor, multitasking kernel and GUI, multichannel digital sampled sound, and scads of custom hardware support made it a much more attractive proposition than an 8 bit box on steroids. Of course it is not a fair comparison - the Amiga came five years later and cost a lot more, at least at first.
The original ST only did "cooperative" multitasking
The original ST didn't multitask at all. Neither did the original Mac - unless you count desk accessories. Cooperative multitasking wasn't standard on the Mac until System 7 in 1991, although it was available as an option after 1987. Pre-emptive multitasking didn't come to the Mac until 1999.
The Atari ST was nearly obsolete by the time Atari started supported multitasking - in 1993. The Amiga had a "real" pre-emptive multitasking operating system on release in 1985, back when the non-multitasking TOS could open a grand total of _four_ windows.
OS-9 was great, for the same reason as Unix was great. Only problem was no multitasking graphical user interface. The Amiga, the Mac, and the ST had a much more useful GUI than almost any Unix system (vertical market applications aside) for the next ten years. The less said about Windows 3.1 the better. OS/2 2.x was nice, though.
First, only MS SQL Server seems to be affected. This isn't because of a flaw in SQL Server
Strictly speaking, that is true. However, SQL Server supports a multiple statement binding syntax that makes it uniquely vulnerable to these kinds of injections in poorly written programs - i.e. you can start a new SQL statement anywhere simply by injecting a semicolon followed by whatever SQL you like.
That is why if a SQL injection attack ever affects tens of thousands of sites, it is inevitably a poorly written SQL Server application. If I were Microsoft, I would add an option to turn the traditional syntax off, deprecate it for future use, and require block syntax to process multiple statements. That doesn't eliminate the problem, but it greatly reduces the possible attack surface, and the severity of the attacks that do get through.
After all, FSF says that dynamically linking to libraries does create a derived work for GPL purposes - and that is not fundamentally different from doing syscalls. In both cases, the client binary doesn't have any machine code derived from the source code of the library/kernel, but only calls with matching names & arguments.
That is entirely wishful thinking on the part of the FSF. There is no rational argument that can be made that mere compatibility between A and B necessarily makes A "based upon" B or vice versa in a manner protected by copyright law.
Technical interfaces are not copyrightable, and that is a good thing. If it were not the case, merely connecting a network cable between a Linux system and a Windows system could create a prohibited "derived work", and more especially if the Linux system implemented anything compatible with Windows - Wine, Samba, FAT etc.
Do we really want a world where you can't read the contents of a Flash drive on any Linux system? Where opening a Microsoft Office compatible document on anything not licensed by Microsoft is illegal? Where accessing a Windows network share is similarly restricted?
Patent restrictions are bad enough. If Congress or the courts decided to enshrine the FSF's absurd conception of "derived work" into law, most of the software industry would be rendered illegal over night, and Linux in particular would be reduced into a footnote in history. It could never actually boot on virtually anything.
You couldn't even compile a kernel for any commercial microprocessor without violating the manufacturer's copyright. Technical interface you see, and running a kernel on proprietary hardware would be illegal without licenses from hundreds of integrated circuit and printed circuit board manufacturers. Assuming you could get licenses from the every network and router manufacturer on the planet, so you could plug it into the Internet, to say nothing of the electrical grid.
In this case, Google stripping that out is definitely wrong, because their process clearly creates a derived work (after all, it does take the original header as input, and applies purely mechanical transformations; I think this is clear cut).
Courts have held in the United States that technical interfaces are not copyrightable. That includes structure names, layouts, and so on. See here (pdf).
So if you take a header file and remove all the copyrightable contents (comments and so forth), what you are left with is technical interface meta data that is not protectable by copyright. That is not likely to go so far as legitimizing copies of non-trivial inline functions, but so far as ordinary manifest constants, structure layouts, and function declarations are concerned, if Baystate v. Bentley Systems (1996) means anything, Google appears to be in the clear.
Fact of the matter is that IPv6 should be slightly faster since the routers don't have to recalculate a CRC for every hop
Virtually every layer 2 protocol in the world (Ethernet for example) calculates a CRC in hardware for every frame. This is not a measurable overhead.
IPv6 doesn't require routers to calculate header checksums (not CRCs, checksums) the way IPv4 does, and that improves core router efficiency, but it is not the sort of thing that is going to make more than a couple of microseconds difference in actual latency.
Latency is primarily determined by congestion and the actual path packets take, which is a function of routing protocols like BGP, the way they are administered, the location of peering / interconnection points, and so on.
Who cares? Netflix is the pre-eminent example of an application that cannot benefit from open standards. Open DRM is a contradiction in terms. It can't work. It is mathematically impossible.
If you ever want to run something like Netflix on a non-proprietary operating system, some sort of proprietary hardware based DRM will be required instead. I suppose it might be helpful someday to standardize the interface to that, but I wouldn't hold my breath.
Since we would already be calculating the 512-bit hash, why not just use it instead of truncating it?
Because there are many applications where carrying the extra 256 bits either breaks compatibility or is storage/transmission cost prohibitive for some reason or another. ZFS style block checksums, for example. Hashed authentication of network packets is another.
network engineers don't care about packet losses and hope the transport layer will fix them
That is a bit of a generalization don't you think? Excessive packet loss is death to any real network, which is why there has been a lot of effort to do various forms of explicit congestion notification instead.
On the Internet, that may be hard, but on a local network it is much easier. Some switches even have ECN marking these days, which is a far superior solution to avoiding loss through buffer bloat.
If we eliminated IP law, innovation would continue, but information sharing would largely disappear. New discoveries would simply be kept secret.
That is a joke. Do you think that Microsoft has even one trade secret worth the paper it is printed on? Do you think that Monsanto or Dupont has even one substance under development not susceptible of independent invention within months?
Signing a patent cross-licensing agreement with MPEG-LA to be able to continue selling your VP8-products...might very well constitute 'facilitation of patent litigation against VP8' since you'd be pretty much acknowledging VP8 infringes MPEG-LA patents if you did that.
Nice theory, completely unsupported by any actual facts though. The pertinent language states:
If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that any implementation of this specification constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under the License for this specification shall terminate as of the date such litigation is filed.
Licensing a patent from someone else does not make you a party to their patent claims. If they win, do you share in the proceeds? Do you share in the legal costs if they lose? Their patent, not yours.
The people at risk of losing a royalty free license to VP8 are those who make their own patent claims against VP8 or submit a patent that they own to a patent pool that does.
In addition, do you read anywhere that Google is unwilling to license VP8 on royalty bearing terms to those who do not qualify for royalty free? If Apple wants a license to VP8 without withdrawing from the MPEG-LA patent pool, I am all too sure that Google will be happy to sell them one.
H.264 is a standard all right, the standard of an evil empire. A patent encumbered standard is no standard at all - not in the way the rest of the world uses the term. All the complaints about VP8 pale in comparison to this fundamental fact.
IPv6 was chosen from the candidates in part because it isn't a "dirty hack"
That is small comfort when sixteen years later approximately no one has adopted it yet.
I grant that putting extra addressing information in an IP option would indeed be a "dirty hack", but there were other proposals like TP/IX that if implemented properly would have been transparently deployed everywhere by now. No dual stack, no double configuration, no throwing the old network away and replacing it with a new one.
One million units total of 4000 IPs each doesn't sound like a good market to me.
It is a lot better than nothing. What you really want to do if have a system where people bear the cost to have an address prefix independently routeable, in addition to the cost of consuming so much of the global address space in the first place.
Then people would have the requisite incentive not just to give up address blocks that are larger than they need, but also to acquire contiguous address blocks to reduce the cost of independently advertising discrete address prefixes.
You'll just have two addresses. One will be a IPv4 that will be NATed, the other won't. Easy. Done.
Easy from an end user perspective. From a network administration perspective for any substantial organization (especially large ISPs) at least twice as complex as what we have now. It didn't have to be that way, but as DJB said, the IETF made a conceptual mistake when deciding to make IPv6 an alternative rather than an extension.
Slashdot Mirror
The IRS rarely goes back more than three years, and then only if there appears to be a serious problem. As far as the value of keeping receipts for minor expenses from even three years ago goes, one might consider the cost to you if the IRS arbitrarily decided to disallow all of them. For many people that is a such a small number it is not worth losing sleep over.
If you run a non-trivial business, are relatively well off, or have deductions for large transactions, however, you better keep documentation for all of that.
No money? Don't be silly. And certainly sufficient power as well.
There isn't a libertarian on the planet who doesn't believe that the government should protect against force and fraud.
You yourself give the authors of GPL software the right to force you to open your code when you agreed to use their software
That's not true. If the authors of the software in question sue you and win, the remedy will be a combination of two things - monetary damages and future compliance with the terms of the license, if the code in question is going to continue to be used. The authors can't force you to open your code. What they can do, with the help of the courts, is require you to comply or quit.
No problem. I did some limited application programming on the ST and I am pretty sure TOS didn't do multitasking at all (preemptive, cooperative, or otherwise) until 1993 or so.
The ST had decent hardware though, much nicer than most of the Macs at the time, and in some respects better than the Amiga. Better (if smaller) monitors, better (non-interlaced) hi-res monochrome than the Amiga had for several years, more memory standard, and of course built in MIDI ports. Hard drives were more common on the Atari ST early on too.
if you look closely you really see stuff from the Atari 8-bits in the Amiga...
That is because the same guy, Jay Miner, did the graphic chip designs for both.
The Amiga OS had a preemptive multitasking with a "proper" task scheduler from the very beginning. It was designed for it. Perhaps you are thinking of the Mac, to which cooperative multitasking was added using a clever hack about three years after release.
True multitasking, yes - on an eight bit computer, which is outstanding. But multitasking is not very useful on a personal computer without a multitasking GUI, and those required a lot more resources than were available on affordable computers in the early 80s.
The Amiga 1000 shipped with 256K of ram, but it was more or less a toy without 512K. A 16/32 bit MC68000 processor, multitasking kernel and GUI, multichannel digital sampled sound, and scads of custom hardware support made it a much more attractive proposition than an 8 bit box on steroids. Of course it is not a fair comparison - the Amiga came five years later and cost a lot more, at least at first.
The original ST only did "cooperative" multitasking
The original ST didn't multitask at all. Neither did the original Mac - unless you count desk accessories. Cooperative multitasking wasn't standard on the Mac until System 7 in 1991, although it was available as an option after 1987. Pre-emptive multitasking didn't come to the Mac until 1999.
The Atari ST was nearly obsolete by the time Atari started supported multitasking - in 1993. The Amiga had a "real" pre-emptive multitasking operating system on release in 1985, back when the non-multitasking TOS could open a grand total of _four_ windows.
OS-9 was great, for the same reason as Unix was great. Only problem was no multitasking graphical user interface. The Amiga, the Mac, and the ST had a much more useful GUI than almost any Unix system (vertical market applications aside) for the next ten years. The less said about Windows 3.1 the better. OS/2 2.x was nice, though.
First, only MS SQL Server seems to be affected. This isn't because of a flaw in SQL Server
Strictly speaking, that is true. However, SQL Server supports a multiple statement binding syntax that makes it uniquely vulnerable to these kinds of injections in poorly written programs - i.e. you can start a new SQL statement anywhere simply by injecting a semicolon followed by whatever SQL you like.
That is why if a SQL injection attack ever affects tens of thousands of sites, it is inevitably a poorly written SQL Server application. If I were Microsoft, I would add an option to turn the traditional syntax off, deprecate it for future use, and require block syntax to process multiple statements. That doesn't eliminate the problem, but it greatly reduces the possible attack surface, and the severity of the attacks that do get through.
After all, FSF says that dynamically linking to libraries does create a derived work for GPL purposes - and that is not fundamentally different from doing syscalls. In both cases, the client binary doesn't have any machine code derived from the source code of the library/kernel, but only calls with matching names & arguments.
That is entirely wishful thinking on the part of the FSF. There is no rational argument that can be made that mere compatibility between A and B necessarily makes A "based upon" B or vice versa in a manner protected by copyright law.
Technical interfaces are not copyrightable, and that is a good thing. If it were not the case, merely connecting a network cable between a Linux system and a Windows system could create a prohibited "derived work", and more especially if the Linux system implemented anything compatible with Windows - Wine, Samba, FAT etc.
Do we really want a world where you can't read the contents of a Flash drive on any Linux system? Where opening a Microsoft Office compatible document on anything not licensed by Microsoft is illegal? Where accessing a Windows network share is similarly restricted?
Patent restrictions are bad enough. If Congress or the courts decided to enshrine the FSF's absurd conception of "derived work" into law, most of the software industry would be rendered illegal over night, and Linux in particular would be reduced into a footnote in history. It could never actually boot on virtually anything.
You couldn't even compile a kernel for any commercial microprocessor without violating the manufacturer's copyright. Technical interface you see, and running a kernel on proprietary hardware would be illegal without licenses from hundreds of integrated circuit and printed circuit board manufacturers. Assuming you could get licenses from the every network and router manufacturer on the planet, so you could plug it into the Internet, to say nothing of the electrical grid.
In this case, Google stripping that out is definitely wrong, because their process clearly creates a derived work (after all, it does take the original header as input, and applies purely mechanical transformations; I think this is clear cut).
Courts have held in the United States that technical interfaces are not copyrightable. That includes structure names, layouts, and so on. See here (pdf).
So if you take a header file and remove all the copyrightable contents (comments and so forth), what you are left with is technical interface meta data that is not protectable by copyright. That is not likely to go so far as legitimizing copies of non-trivial inline functions, but so far as ordinary manifest constants, structure layouts, and function declarations are concerned, if Baystate v. Bentley Systems (1996) means anything, Google appears to be in the clear.
Fact of the matter is that IPv6 should be slightly faster since the routers don't have to recalculate a CRC for every hop
Virtually every layer 2 protocol in the world (Ethernet for example) calculates a CRC in hardware for every frame. This is not a measurable overhead.
IPv6 doesn't require routers to calculate header checksums (not CRCs, checksums) the way IPv4 does, and that improves core router efficiency, but it is not the sort of thing that is going to make more than a couple of microseconds difference in actual latency.
Latency is primarily determined by congestion and the actual path packets take, which is a function of routing protocols like BGP, the way they are administered, the location of peering / interconnection points, and so on.
There is a difference between doing something and doing it legally.
Without DRM there is no Netflix in HTLM 5
Who cares? Netflix is the pre-eminent example of an application that cannot benefit from open standards. Open DRM is a contradiction in terms. It can't work. It is mathematically impossible.
If you ever want to run something like Netflix on a non-proprietary operating system, some sort of proprietary hardware based DRM will be required instead. I suppose it might be helpful someday to standardize the interface to that, but I wouldn't hold my breath.
Since we would already be calculating the 512-bit hash, why not just use it instead of truncating it?
Because there are many applications where carrying the extra 256 bits either breaks compatibility or is storage/transmission cost prohibitive for some reason or another. ZFS style block checksums, for example. Hashed authentication of network packets is another.
FC over *ethernet* has no ip and no provisions to span gateways
That is why they invented TRILL. Link state routing at layer 2.
network engineers don't care about packet losses and hope the transport layer will fix them
That is a bit of a generalization don't you think? Excessive packet loss is death to any real network, which is why there has been a lot of effort to do various forms of explicit congestion notification instead.
On the Internet, that may be hard, but on a local network it is much easier. Some switches even have ECN marking these days, which is a far superior solution to avoiding loss through buffer bloat.
If we eliminated IP law, innovation would continue, but information sharing would largely disappear. New discoveries would simply be kept secret.
That is a joke. Do you think that Microsoft has even one trade secret worth the paper it is printed on? Do you think that Monsanto or Dupont has even one substance under development not susceptible of independent invention within months?
Where did it all go wrong?
Live by the sword, die by the sword. Government granted monopolies are evil, and there is no way you can fix that problem.
Signing a patent cross-licensing agreement with MPEG-LA to be able to continue selling your VP8-products...might very well constitute 'facilitation of patent litigation against VP8' since you'd be pretty much acknowledging VP8 infringes MPEG-LA patents if you did that.
Nice theory, completely unsupported by any actual facts though. The pertinent language states:
If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that any implementation of this specification constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under the License for this specification shall terminate as of the date such litigation is filed.
Licensing a patent from someone else does not make you a party to their patent claims. If they win, do you share in the proceeds? Do you share in the legal costs if they lose? Their patent, not yours.
The people at risk of losing a royalty free license to VP8 are those who make their own patent claims against VP8 or submit a patent that they own to a patent pool that does.
In addition, do you read anywhere that Google is unwilling to license VP8 on royalty bearing terms to those who do not qualify for royalty free? If Apple wants a license to VP8 without withdrawing from the MPEG-LA patent pool, I am all too sure that Google will be happy to sell them one.
H.264 is a standard all right, the standard of an evil empire. A patent encumbered standard is no standard at all - not in the way the rest of the world uses the term. All the complaints about VP8 pale in comparison to this fundamental fact.
IPv6 was chosen from the candidates in part because it isn't a "dirty hack"
That is small comfort when sixteen years later approximately no one has adopted it yet.
I grant that putting extra addressing information in an IP option would indeed be a "dirty hack", but there were other proposals like TP/IX that if implemented properly would have been transparently deployed everywhere by now. No dual stack, no double configuration, no throwing the old network away and replacing it with a new one.
One million units total of 4000 IPs each doesn't sound like a good market to me.
It is a lot better than nothing. What you really want to do if have a system where people bear the cost to have an address prefix independently routeable, in addition to the cost of consuming so much of the global address space in the first place.
Then people would have the requisite incentive not just to give up address blocks that are larger than they need, but also to acquire contiguous address blocks to reduce the cost of independently advertising discrete address prefixes.
You'll just have two addresses. One will be a IPv4 that will be NATed, the other won't. Easy. Done.
Easy from an end user perspective. From a network administration perspective for any substantial organization (especially large ISPs) at least twice as complex as what we have now. It didn't have to be that way, but as DJB said, the IETF made a conceptual mistake when deciding to make IPv6 an alternative rather than an extension.