Would you wear a life jacket in the wading pool but discard it to go out to sea? Maybe you could make a case for profiling to find the biggest few bottlenecks, test them exhaustively, and then wrap the assertions in
#if SPEED_OVER_SAFETY
but globally ignoring all of them (letting phases such as initialization quietly fail) is deranged.
To trash liberty in favor of safety is a slap in the face to all the brave men who died to give it to us. If you have US citizenship, you are unworthy of it.
That's analysis, not architecture. Without a good idea what's actually going on in-core, that "architect's" designs probably won't even be feasible, much less robust, maintainable, or efficient.
The GPL isn't a contract; what authors enforce are their copyrights. There's nothing you can do before accepting the GPL that you can't do after, because all it does is selectively grant rights you wouldn't have otherwise. You're free to not accept the GPL, but then you're under all the normal restrictions of copyright law without any of the extra rights granted to you by the authors. Almost every other EULA imposes restrictions above and beyond copyright law, so that you have something to gain if it is indeed possible to buy and use the software without accepting that.
If every software vendor required you to sign an appropriate EULA contract on the spot before selling you the software, that would clearly be valid and enforceable, but if the contract is hidden in the box and it's effectively impossible to get a refund if you won't enter into it, IMHO that copy has been sold to you (rather than licensed under the surprise contract) and you ought to be able to run it or sell it as permitted by copyright law.
Because they have their own domain? I can imagine how painful it'd be if I had to ssh to my web host every time I wanted to send mail (and I'm lucky enough to have a shell account that isn't trapped behind my cable modem with the evil ToS, and know how to use it).
It's perfectly legitimate for a utility to impose technical requirements on your equipment. I'm not sure about electricity or water, but I know you can't hook your phone line into any device that wasn't approved by the FCC.
All you can argue is that, rather than a proprietary standard like SPA (has anyone ever seen a spec for this?), MSN should have chosen different requirements (APOP, SSL...) that don't extend Microsoft's monopoly power. But how much interoperability the government can legitimately mandate is an open question.
He has made a joint statement that "patents as they stand now are a real problem".
Are you sure? What does it actually claim? The USPTO search page says no inventor named Torvalds has filed for a patent in the last 211 years. Are you thinking of his trademark (very different both legally and ethically)?
How long ago you thought of the invention is irrelevant. What matters is the filing date, because any published description or public sale of the invention more than one year before that is prior art and the examiner should (but probably won't--they're rewarded for fast approvals or rejections, not diligence) exclude those claims.
<IANAL>There's a principle called "estoppel" (legalese for changing your mind about what you've said) that means (in part):
If a patent holder or owner of any other rights or property advises another party that they may freely utilize their property and the party acts on that advice, the owner cannot at a later date deny use of that property or claim impropriety on the part of the other party.
but otherwise patents can be selectively enforced without being voided, unlike trademarks.<IANAL>
Invalid patents effectively are enforceable, as long as you demand less than the victim would have to spend defending themselves in court (unless you pick a victim with both lots of money and high principles, but our system makes that unlikely). Loser-pays civil courts are the only fix I know of for this form of legalized extortion.
RMS even argued against prior art databases, saying that it's safer to save the prior art for the inevitable court cases. It seems courts have a history of disregarding any prior art that was known before the patent was issued--there's a very strong (IMHO unwarranted) official assumption of validity around the USPTO's work.
There's no such thing as a defensive patent. There are patents that aren't currently used offensively to inhibit competition, but the holder can change their mind at any point about new licenses--and a corporation must do so, if the shareholders can show the profit would be greater than the loss from antagonizing their peers. Good will is a flimsy thing to rely on.
But what happens if I cache the site, and they update themselves?
HTTP has already solved this problem. Use their Expires value, with a reasonable default depending on the urgency (hours? minutes?) if they didn't bother to send one. It's not as if they can expect individuals to see their updates if they don't offer correct metadata--our user agents cache by the same rules. Hey, wouldn't squid or something correctly refresh its cache automatically?
do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?
The alternative is a up-to-the-minute link that's effectively useless, and a few hundred comments expressing nothing more than ignorance and wild guesses. Or we start asking those lucky souls that get slashdotted resources to post comments with their freenet IDs for good distributed caching but without any support for updates....
Just like C++, Eiffel, Perl 4, and most other languages that predate Java, Common Lisp doesn't specify a threading interface, but several vendors offer proprietary threading interfaces after having made their runtimes thread-safe.
As environments go, Emacs-Lisp is awfully primitive. No lexical variables, no package system, no reader macros, and worst of all no object system. There's a "cl" package that tries to emulate some of these, but since the interpreter can't special-case them the speed hit is often stunning.
If an immutable literal appears to have a class and methods, it's effectively an object. I don't care whether it's boxed or not any more than I care whether overridden methods are implemented using jump tables, branch-on-type, or telepathy. Having to explicitly write out all the (un)boxing code is ridiculous, since it can always be reliably inferred--Lisp got this right, what, 20 years ago?
You mean trademark holders (domain names are far too short to qualify for copyright). The problem is that trademarks are specific to an industry but domain names aren't (with the sole exception of that wacky new "museum" gTLD), so one rich trademark holder can stop all the others from using the domain name corresponding to their own rightful trademarks.
Certainly DRAM latency is negligible compared to read head seek time, it's just not zero--which I suppose means we've really been using Almost Random Access Memory for a while now.
The block device abstraction provides caching and scheduling for I/O requests, neither of which suit a RAM-based filesystem. It's not at all obvious that 512B..2048B "sectors" are appropriate without interface-imposed granularity or overhead per command. We'd probably want an algorithm that looks more like malloc() over a character device than sector chaining, unless we really need to emulate spinning rust....
Solid-state seeking has a cost, though much smaller (even relative to linear bursts) than moving parts. DRAM is arranged in a grid, but keeping each cell ready for instant access would be prohibitively expensive in space and power. Instead, each cell maintains a tiny charge, and each row and column has a sense amplifier to detect it that takes a little time to ready for use. The memory controller assumes you'll read columns sequentially--if you don't, you send a new column number and then wait CAS (column access strobe) latency (2~3 clocks) before data is available. Switching rows is even more expensive--you have to wait for both RAS and CAS. Allegedly the hit for truly random access to RDRAM is even worse, only partly because of the narrow bus.
What's the value of opening the same sort of documents in different apps? Either I don't care (and any will do) or I prefer one (and running any other is never the Right Thing).
... and every current or potential programmer ought to learn to implement CipherSaberfrom memory, for much the same reasons--especially now that recent events have made governments and citizens more hostile to privacy.
You forgot "Preferences", "Setup", and "Configure", and whether it goes on the "File", "Tools", or "Edit" (huh?) menu. Do UI guidelines not cover this, or are app authors just being brain-damaged?
Between MIME and HTTP, there's no longer any reason to infer the type or encoding of a resource from some cryptic piece of its name. MacOS rightfully stores the type in the filesystem (but a filesystem that stores the charset and compression in use would be even better--wouldn't BeOS have handled some of this?).
However, storing the creating app is a bad idea. The whole point being made here is that which-app-to-run is a decision that rightfully belongs to the user. It's none of my business which app the creator of the file used; if I already prefer PNG-o-matic I'm certainly not going to put up with PNG-o-rama just because you like it (heathen!).
Slashdot Mirror
To trash liberty in favor of safety is a slap in the face to all the brave men who died to give it to us. If you have US citizenship, you are unworthy of it.
That's analysis, not architecture. Without a good idea what's actually going on in-core, that "architect's" designs probably won't even be feasible, much less robust, maintainable, or efficient.
The GPL isn't a contract; what authors enforce are their copyrights. There's nothing you can do before accepting the GPL that you can't do after, because all it does is selectively grant rights you wouldn't have otherwise. You're free to not accept the GPL, but then you're under all the normal restrictions of copyright law without any of the extra rights granted to you by the authors. Almost every other EULA imposes restrictions above and beyond copyright law, so that you have something to gain if it is indeed possible to buy and use the software without accepting that.
If every software vendor required you to sign an appropriate EULA contract on the spot before selling you the software, that would clearly be valid and enforceable, but if the contract is hidden in the box and it's effectively impossible to get a refund if you won't enter into it, IMHO that copy has been sold to you (rather than licensed under the surprise contract) and you ought to be able to run it or sell it as permitted by copyright law.
Because they have their own domain? I can imagine how painful it'd be if I had to ssh to my web host every time I wanted to send mail (and I'm lucky enough to have a shell account that isn't trapped behind my cable modem with the evil ToS, and know how to use it).
It's perfectly legitimate for a utility to impose technical requirements on your equipment. I'm not sure about electricity or water, but I know you can't hook your phone line into any device that wasn't approved by the FCC.
All you can argue is that, rather than a proprietary standard like SPA (has anyone ever seen a spec for this?), MSN should have chosen different requirements (APOP, SSL...) that don't extend Microsoft's monopoly power. But how much interoperability the government can legitimately mandate is an open question.
How long ago you thought of the invention is irrelevant. What matters is the filing date, because any published description or public sale of the invention more than one year before that is prior art and the examiner should (but probably won't--they're rewarded for fast approvals or rejections, not diligence) exclude those claims.
<IANAL>There's a principle called "estoppel" (legalese for changing your mind about what you've said) that means (in part):
but otherwise patents can be selectively enforced without being voided, unlike trademarks.<IANAL>Invalid patents effectively are enforceable, as long as you demand less than the victim would have to spend defending themselves in court (unless you pick a victim with both lots of money and high principles, but our system makes that unlikely). Loser-pays civil courts are the only fix I know of for this form of legalized extortion.
RMS even argued against prior art databases, saying that it's safer to save the prior art for the inevitable court cases. It seems courts have a history of disregarding any prior art that was known before the patent was issued--there's a very strong (IMHO unwarranted) official assumption of validity around the USPTO's work.
There's no such thing as a defensive patent. There are patents that aren't currently used offensively to inhibit competition, but the holder can change their mind at any point about new licenses--and a corporation must do so, if the shareholders can show the profit would be greater than the loss from antagonizing their peers. Good will is a flimsy thing to rely on.
Or even better, use fetchmail with that SSH port forward as your "preconnect" option.
HTTP has already solved this problem. Use their Expires value, with a reasonable default depending on the urgency (hours? minutes?) if they didn't bother to send one. It's not as if they can expect individuals to see their updates if they don't offer correct metadata--our user agents cache by the same rules. Hey, wouldn't squid or something correctly refresh its cache automatically?
The alternative is a up-to-the-minute link that's effectively useless, and a few hundred comments expressing nothing more than ignorance and wild guesses. Or we start asking those lucky souls that get slashdotted resources to post comments with their freenet IDs for good distributed caching but without any support for updates....
Just like C++, Eiffel, Perl 4, and most other languages that predate Java, Common Lisp doesn't specify a threading interface, but several vendors offer proprietary threading interfaces after having made their runtimes thread-safe.
std::map and std::set are implemented by sorting, not hashing. There are hashtable classes often called hashmap, but none is mandated by the standard.
As environments go, Emacs-Lisp is awfully primitive. No lexical variables, no package system, no reader macros, and worst of all no object system. There's a "cl" package that tries to emulate some of these, but since the interpreter can't special-case them the speed hit is often stunning.
If an immutable literal appears to have a class and methods, it's effectively an object. I don't care whether it's boxed or not any more than I care whether overridden methods are implemented using jump tables, branch-on-type, or telepathy. Having to explicitly write out all the (un)boxing code is ridiculous, since it can always be reliably inferred--Lisp got this right, what, 20 years ago?
You mean trademark holders (domain names are far too short to qualify for copyright). The problem is that trademarks are specific to an industry but domain names aren't (with the sole exception of that wacky new "museum" gTLD), so one rich trademark holder can stop all the others from using the domain name corresponding to their own rightful trademarks.
Certainly DRAM latency is negligible compared to read head seek time, it's just not zero--which I suppose means we've really been using Almost Random Access Memory for a while now.
The block device abstraction provides caching and scheduling for I/O requests, neither of which suit a RAM-based filesystem. It's not at all obvious that 512B..2048B "sectors" are appropriate without interface-imposed granularity or overhead per command. We'd probably want an algorithm that looks more like malloc() over a character device than sector chaining, unless we really need to emulate spinning rust....
Solid-state seeking has a cost, though much smaller (even relative to linear bursts) than moving parts. DRAM is arranged in a grid, but keeping each cell ready for instant access would be prohibitively expensive in space and power. Instead, each cell maintains a tiny charge, and each row and column has a sense amplifier to detect it that takes a little time to ready for use. The memory controller assumes you'll read columns sequentially--if you don't, you send a new column number and then wait CAS (column access strobe) latency (2~3 clocks) before data is available. Switching rows is even more expensive--you have to wait for both RAS and CAS. Allegedly the hit for truly random access to RDRAM is even worse, only partly because of the narrow bus.
What's the value of opening the same sort of documents in different apps? Either I don't care (and any will do) or I prefer one (and running any other is never the Right Thing).
... and every current or potential programmer ought to learn to implement CipherSaber from memory, for much the same reasons--especially now that recent events have made governments and citizens more hostile to privacy.
You forgot "Preferences", "Setup", and "Configure", and whether it goes on the "File", "Tools", or "Edit" (huh?) menu. Do UI guidelines not cover this, or are app authors just being brain-damaged?
Between MIME and HTTP, there's no longer any reason to infer the type or encoding of a resource from some cryptic piece of its name. MacOS rightfully stores the type in the filesystem (but a filesystem that stores the charset and compression in use would be even better--wouldn't BeOS have handled some of this?).
However, storing the creating app is a bad idea. The whole point being made here is that which-app-to-run is a decision that rightfully belongs to the user. It's none of my business which app the creator of the file used; if I already prefer PNG-o-matic I'm certainly not going to put up with PNG-o-rama just because you like it (heathen!).