It has little to do with trust. For all practical purposes, web users trust exactly the CAs that their browser distributor "trusts". Except that "trust" is not the right word for the latter relationship. Probably only a few people really know a CA gets into the default "trusted" list of the major browsers, but it's not likely to be trust.
Tim may be right that the Amazon patent is narrow and, in its specific details, may very well be novel. There still remains the criterion "obvious". As someone "skilled in the art", I want to say a few things about "obvious" that seem to have been overlooked.
First, just because something hasn't been done, doesn't mean it's not obvious. I can think of many other reasons why nobody before Amazon may have done one-click ordering on the web, among them:
Web commerce is relatively new, thus Web vendors have been charting unknown territory. Maybe they were so busy, they just didn't get around to one-click ordering.
One-click ordering requires especially careful implementation. Perhaps engineers at other Web vendors simply decided that the development and testing costs would be too high.
It isn't immediately obvious that customers will like one-click ordering. Amazon should perhaps be credited with proving they can; but this is a marketing/customer relations innovation, not the stuff of patents.
One-click is mostly valuable to frequent customers. Maybe Amazon was the first to have enough repeat buyers to make one-click pay off.
One-click works best with customers who feel secure about the vendor. Maybe Amazon was the first to win this trust from their customers.
One-click is not merely a feature of Amazon; it is part of their marketing strategy. It may be that one-click per se has little value, but that Amazon boosted its value with ingenious marketing. Again, a business innovation, not a technical one.
Taking an idea that everyone could see and being the first to make it work may be laudable, but it does not advance the art of software.
Second, the idea that narrowness somehow makes a patent less obvious is flawed. It is true that I might not have implemented one-click in the exact same way as Amazon. However, in software, it is typical for a problem to have many superficially different, but essentially similar, solutions; and while different programmers would come up with different implementations, another programmer comparing them would find no interesting differences. They're all "much of a muchness".
Put another way, you might say of one-click,
Your design is both useful and novel; but the parts that are useful are not novel, and the parts that are novel are not useful.
If the pattern of the solution is obvious (for one-click, it is; why do you think Netscape introduced cookies?), and the specifics of the implementation offer no notable benefits over other implementations, the criterion "obvious" is not met.
Don't allow changes. This one simply (and quite reasonably) implements within a PDF the same requirement that exists even in many open source licenses: don't make changes to someone else's work and then pass on those changes as if they were the original author's.
This is untrue in some fundamental respects. First, free software licenses may restrict only redistribution, not private use. xpdf effectively restricts private use. This is very differest, and much more pernicious. Second, free software licenses must allow redistribution with modifications, under some reasonable conditions. xpdf restricts me from making modifications, even if I am willing to credit the original author and clearly mark the changes. Granted, documents and software are not the same, so "free documents" may perhaps come with more restrictions than free software; but this is another flaw in your analogy.
If there is an insight to be drawn by comparison to free software licensing, it is that this issue should be addressed by social and legal means, not by adding obnoxious restrictions to programs.
I believe that an author's requests relating to the use of his/her work should be honored.
Honoring the requests of the creator is a nice principle, but it must be questioned when the authors make unreasonable requests. "Do not distributed modified versions" is a reasonable request. "Do not cut-n-paste" is flagrantly unreasonable, not to mention obnoxious. Systematic attempts to remove the ability to cut-n-paste should be fought.
The xpdf author's mistake is,
I'll choose to honor the author's request, no matter how misguided.
This is dangerous. At some point, the misguided author should be challenged, rather than mass-depriving users of their rights. To use a cliched example, what if the author's request were that only orange people read his document?
The best way for xpdf to honor reasonable requests by authors would be to pop up a dialog when the user attempts to cut-n-paste, saying, "The author of this document requests that you not distribute modified copies. Please cut-n-paste only for your own private use." (or whatever wording is most accurate).
The mouse speed controls in XFree86 are very crude; but if all you want is to make the pointer move quickly, just look at xset(1). Note that the acceleration is interpreted very differently depending on whether you have a (non-zero) threshhold: with a threshhold, it is a simple multiplier; without, an exponent. Very different feels, so try both ways. Also note that the acceleration can be a fraction (not a decimal!).
Aren't articles at a site called SatireWire supposed to be funny? Can anyone tell me what the joke was?
As for ad banners, I just meditated for 30 days at the W3C temple of semantic purity, and succeeded in training my optic nerves to block them before reaching my conscious mind. You could put a dozen banners on a page, and I wouldn't even notice!
Take inspiration from Pascal's definition of perfection. Read, revise, reread, until you can find nothing non-essential and nothing that could not be expressed more concisely. Then go to bed and do it again the next day. Convince a friend to help you. You will be amazed by the amount of content you can get onto a page, and how much better the whole thing comes across.
Unless you have a truly impressive background, and are applying for a very special position, you don't have more than a page's worth to say. Remember that in most circumstances, the hirer is looking for a reason to reject you.
PS. Don't even think about squeezing the font or skimping on margins.
Admittedly, things were worse in the past. You don't give a lot of details in your post, but remeber, if you're talking about libc 5 (which is only remotely related to an old version of glibc), or a linuxthreads add-on that was not blessed by the glibc developers, then it's not fair to blame glibc.
Everyone misunderstands Emacs. Emacs is NOT bloated. It is "extensible". There is a difference.
Yes, and I tend to agree that an editor should be extensible in this way. Extension languages are cool! But I don't think that having a small, extensible core makes the system fundamentally "small".
The problem is that the extension components are inextricably tied to Emacs. They don't do "one thing well" in the traditional sense, because they can't be used by arbitrary other programs, ony Emacs. Even within Emacs, their interfaces make them much less reusable than Unix utilities that communicate mostly by command name, stdin, stdout, and exit status. Thus, I think it is only fair to call the Emacs core plus the set of extensions you are using a single whole. And that's "big".
If you startup a barebones version of Emacs using "emacs -q", you will get an editor that starts up instantaneously, consumes little memory and is lightning fast.
Isn't that emacs "binary" an undumped image with all the required lisp already byte-compiled?
The glibc (and gcc) developers are so careful about binary backwards compatibility, it's not even funny. If you feel like getting thoroughly flamed by folks much smarter than the slashdot crowd, go suggest an incompatible change on the glibc mailing list (and if you're not such a masochist, read the list archives).
However, they offer clear conditions. First, they don't guarentee upwards-compatibility, that is code compiled against glibc 2.2 working with 2.1. Second, C++ is currently off limits (which will change with gcc 3.0). Third, it applies only to shared versions of the library. Fourth, private internal interfaces are off limits.
The Oracle problem is simple: they're using static libraries (ie, ar archives of object files). This doesn't work because symbol versioning (the magic that enables compatibility in shared libraries) isn't implemented for object files. HJ Lu has a page on this issue and possible resolutions.
90% of other compatibility problems result from using private interfaces. This happened to Star Office a while back.
Everything the FSF produces (with one notable exception) follows the philosophy that "small is beautiful"
Oh my God would any UNIX old-timer laugh at that! First, you seem to be claiming that the only exception to this "rule" is GNU libc. Ever heard of EMACS? It's the absolute antithesis of "small is beautiful"! Second, even though GNU has reproduced most of the tools that gave UNIX its minimalist slant, in almost all cases, they extended them to be much larger and more featureful than the originals. Go install FreeBSD sometime, take a sampling of programs, and compare binary sizes and manpages. tar(1) will provide an instructive example.
I'm not saying this is bad--I mostly like the GNU environment. But compared to real UNIX, it's heavy.
Fonts at small sizes often look better in their raw bitmap (or truetype hinted) form; anti-aliasing makes things look blurry.
True--but below a certain size (roughly, when the pixels are bigger than the features of the glyph), blurriness is the lesser of evils. In this domain, un-smoothed text is so blocky, it's hard to recognize. (On the other hand, it's probably best not to try to read such small letters in the first place!)
is it possible to use anti-aliasing for only large fonts (say, 14pt+)
14 points is not big enough at typical screen resolutions, IMO. Blurriness persists until lines are more than a pixel wide.
Though it may be a surprise to many, the security community generally agrees that immediate full disclosure of a discovered vulnerability is normally not the best policy. I cite for one rain forest puppy's Full Disclosure Policy, which has been widely approved and followed (see BugTrag archives for evidence). RFPolicy recommends a five day minimum before disclosure, even if the software maintainers are unresponsive, a ten day minimum if they at least respond, and arbitrary deferment of disclosure if they cooperate.
What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.
There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.
Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.
I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.
But as for state machines, in fact state machines were what I was writing all the times I have written my own scheduler
Everyone's written state machines--it's a standard CS exercise. Of course, your scheduler was probably more challenging than a textbook DFA because you had more events coming at you with less predictability, and how to react wasn't as obvious. I think Alan is implying that a raw computer has way more events; the complexity of the state machine grows exponentially with the number of event types; you have to cope with all sorts of unexpected combinations that don't make any sense; and if you mishandle even one of them, you're may be hopelessly lost.
In your scheduler, you were probably responding to alarms and yields. If you'd had to respond to hardware interrupts, page faults, and clock ticks, it probably would have taken a lot longer to get working! You were benefitting from the kernel presenting all that complexity as a simple process context. That's what Alan is saying (tongue-in-cheek, I hope!)
I strongly suspect having a kernel developer write a thread scheduler once and have everyone use it is far more efficient than to have every application developer write their own state machines.
Unless I'm misinterprenting, you sound like you aren't familiar with the Linux kernel. You might like the approach they have taken--check out the clone system call (copied from Plan9).
I'm pretty perplexed why Linus should think that thread programming is harder. This makes me wonder whether he's ever really tried in a serious way
Alan Cox said, "A computer is a state machine. Threads are for people who can't program
state machines.". In other words, kernel hackers are way (way, way, way, way!) past the complexity of threads.
The poster who said Linus hates threads was mistaken. Linus has trashed POSIX pthreads mercilessly, but I don't think he's ever made a general statement against threads or their usefulness (as is clear from that poster's own references, he very much wants a good Linux thread model). Other kernel notables have--eg, Larry McVoy and Ted T'so.
First, thank you for basing your complaint on Microsoft marketing material, vague anecdotes, and loaded terminology. That said,...
The "linuxthreads" add-on to glibc is heavily used and actively developed--a quick look at the mailing lists and changelogs will convince you. Both POSIX pthread compliance and performance are high priorities, and many users evidently find the thread support quite "real".
As for performance, I do know that a Solaris-like model is under consideration for glibc, although plenty of people (especially kernel developers) have well-founded objections. It might help if you could provide details on why you don't find the current model "lightweight" enough, such as performance numbers from a real application. You might even get some ideas on how to improve your application.
As for features, new functionality is always being added to linuxthreads. If you described exactly which functionality you need on the glibc lists (and on the kernel lists, if applicable), or pointed out shortcomings in existing functionality, you'd probably get some helpful replies. It's acknowledged that some things aren't there yet, but this is most definitely considered a bug (by glibc people, at least), and the priority of bugs is influenced by user input.
Hoping for a new project to appear is misguided when the glibc/linuxthreads wizards have done most of the job, and remain active and responsive. Your best bet is to work with them.
P.S. Linus does not hate threads--think of how ridiculous it would be for a SMP kernel hacker to condemn concurrency within a single address space. He added clone() to Linux, which enables just that! What he hates are POSIX threads.
If this guy wants a fork, he can have it (but he should have the honesty to state it plainly). He'll just have to do without the skills and judgement of the people who have made Linux what it is today. My bet is that he and his proposed consortium would turn it into a smoking heap of rubble in five years, but they can try.
If he wants to change the mainstream development model--well, that isn't up for discussion. It's Linus's kernel, and everyone else can take it or leave it. If you haven't heard, Linus has made it clear that he doesn't care about the financial interests surrounding Linux.
Asking Linus to change his development principles is like requesting the repeal of those quantum phenomena that (the nerve!) prevent us from making our transistors smaller.
If you so proud come clean and let the whole world know.
Sorry to sound like a wimp, but there are some aspects I'm not entirely comfortable discussing here.
But it's not that uncommon. A compelling vision is a good way to get people working hard together, which can lead to business success. And a business provides certain incomparable opportunities to the visionaries. So it makes perfect sense that some businesses are fueled by a vision. Obviously, you can't ignore the financials, but there's a big difference that and being focused on money. It may be a balancing act, but it can be done.
That's a good question. If you want to be very precise, I'm probably loyal to the founder of the company more than anything else. But they're not really separable, and I don't think there's any point to making a distinction. You could probably make the same argument for any organization.
If you really believed in what you were doing, you wouldn't try to make any money from it, you would be running a NON PROFIT ORGANIZATION!
There are many reasons why a company may be a much better vehicle for a dream, a vision, or a value
than a non-profit. If you can't see this, I can only imagine that you're hopelessly anti-capitalist. But I work for such a company, and it's amazing.
Slashdot Mirror
It has little to do with trust. For all practical purposes, web users trust exactly the CAs that their browser distributor "trusts". Except that "trust" is not the right word for the latter relationship. Probably only a few people really know a CA gets into the default "trusted" list of the major browsers, but it's not likely to be trust.
First, just because something hasn't been done, doesn't mean it's not obvious. I can think of many other reasons why nobody before Amazon may have done one-click ordering on the web, among them:
Taking an idea that everyone could see and being the first to make it work may be laudable, but it does not advance the art of software.
Second, the idea that narrowness somehow makes a patent less obvious is flawed. It is true that I might not have implemented one-click in the exact same way as Amazon. However, in software, it is typical for a problem to have many superficially different, but essentially similar, solutions; and while different programmers would come up with different implementations, another programmer comparing them would find no interesting differences. They're all "much of a muchness".
Put another way, you might say of one-click,
If the pattern of the solution is obvious (for one-click, it is; why do you think Netscape introduced cookies?), and the specifics of the implementation offer no notable benefits over other implementations, the criterion "obvious" is not met.This is untrue in some fundamental respects. First, free software licenses may restrict only redistribution, not private use. xpdf effectively restricts private use. This is very differest, and much more pernicious. Second, free software licenses must allow redistribution with modifications, under some reasonable conditions. xpdf restricts me from making modifications, even if I am willing to credit the original author and clearly mark the changes. Granted, documents and software are not the same, so "free documents" may perhaps come with more restrictions than free software; but this is another flaw in your analogy.
If there is an insight to be drawn by comparison to free software licensing, it is that this issue should be addressed by social and legal means, not by adding obnoxious restrictions to programs.
Honoring the requests of the creator is a nice principle, but it must be questioned when the authors make unreasonable requests. "Do not distributed modified versions" is a reasonable request. "Do not cut-n-paste" is flagrantly unreasonable, not to mention obnoxious. Systematic attempts to remove the ability to cut-n-paste should be fought.
The xpdf author's mistake is,
This is dangerous. At some point, the misguided author should be challenged, rather than mass-depriving users of their rights. To use a cliched example, what if the author's request were that only orange people read his document?The best way for xpdf to honor reasonable requests by authors would be to pop up a dialog when the user attempts to cut-n-paste, saying, "The author of this document requests that you not distribute modified copies. Please cut-n-paste only for your own private use." (or whatever wording is most accurate).
I would also have agreed if you had ended this sentence after "policies".
The mouse speed controls in XFree86 are very crude; but if all you want is to make the pointer move quickly, just look at xset(1). Note that the acceleration is interpreted very differently depending on whether you have a (non-zero) threshhold: with a threshhold, it is a simple multiplier; without, an exponent. Very different feels, so try both ways. Also note that the acceleration can be a fraction (not a decimal!).
I rather consider ubiquitous net access a killer app for the train.
As for ad banners, I just meditated for 30 days at the W3C temple of semantic purity, and succeeded in training my optic nerves to block them before reaching my conscious mind. You could put a dozen banners on a page, and I wouldn't even notice!
Unless you have a truly impressive background, and are applying for a very special position, you don't have more than a page's worth to say. Remember that in most circumstances, the hirer is looking for a reason to reject you.
PS. Don't even think about squeezing the font or skimping on margins.
We also know that version numbers are tuples, not fractions, right? Right?
Admittedly, things were worse in the past. You don't give a lot of details in your post, but remeber, if you're talking about libc 5 (which is only remotely related to an old version of glibc), or a linuxthreads add-on that was not blessed by the glibc developers, then it's not fair to blame glibc.
OF COURSE, I did too, until he started ranting cluelessly about glibc :-)
Yes, and I tend to agree that an editor should be extensible in this way. Extension languages are cool! But I don't think that having a small, extensible core makes the system fundamentally "small".
The problem is that the extension components are inextricably tied to Emacs. They don't do "one thing well" in the traditional sense, because they can't be used by arbitrary other programs, ony Emacs. Even within Emacs, their interfaces make them much less reusable than Unix utilities that communicate mostly by command name, stdin, stdout, and exit status. Thus, I think it is only fair to call the Emacs core plus the set of extensions you are using a single whole. And that's "big".
If you startup a barebones version of Emacs using "emacs -q", you will get an editor that starts up instantaneously, consumes little memory and is lightning fast.
Isn't that emacs "binary" an undumped image with all the required lisp already byte-compiled?
However, they offer clear conditions. First, they don't guarentee upwards-compatibility, that is code compiled against glibc 2.2 working with 2.1. Second, C++ is currently off limits (which will change with gcc 3.0). Third, it applies only to shared versions of the library. Fourth, private internal interfaces are off limits.
The Oracle problem is simple: they're using static libraries (ie, ar archives of object files). This doesn't work because symbol versioning (the magic that enables compatibility in shared libraries) isn't implemented for object files. HJ Lu has a page on this issue and possible resolutions.
90% of other compatibility problems result from using private interfaces. This happened to Star Office a while back.
Oh my God would any UNIX old-timer laugh at that! First, you seem to be claiming that the only exception to this "rule" is GNU libc. Ever heard of EMACS? It's the absolute antithesis of "small is beautiful"! Second, even though GNU has reproduced most of the tools that gave UNIX its minimalist slant, in almost all cases, they extended them to be much larger and more featureful than the originals. Go install FreeBSD sometime, take a sampling of programs, and compare binary sizes and manpages. tar(1) will provide an instructive example.
I'm not saying this is bad--I mostly like the GNU environment. But compared to real UNIX, it's heavy.
True--but below a certain size (roughly, when the pixels are bigger than the features of the glyph), blurriness is the lesser of evils. In this domain, un-smoothed text is so blocky, it's hard to recognize. (On the other hand, it's probably best not to try to read such small letters in the first place!)
is it possible to use anti-aliasing for only large fonts (say, 14pt+)
14 points is not big enough at typical screen resolutions, IMO. Blurriness persists until lines are more than a pixel wide.
This is a Unix FAQ, ksh FAQ, and a Bash FAQ. As a bonus, I found this pertinent discussion in the NetBSD bug database.
What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.
There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.
Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.
I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.
Everyone's written state machines--it's a standard CS exercise. Of course, your scheduler was probably more challenging than a textbook DFA because you had more events coming at you with less predictability, and how to react wasn't as obvious. I think Alan is implying that a raw computer has way more events; the complexity of the state machine grows exponentially with the number of event types; you have to cope with all sorts of unexpected combinations that don't make any sense; and if you mishandle even one of them, you're may be hopelessly lost.
In your scheduler, you were probably responding to alarms and yields. If you'd had to respond to hardware interrupts, page faults, and clock ticks, it probably would have taken a lot longer to get working! You were benefitting from the kernel presenting all that complexity as a simple process context. That's what Alan is saying (tongue-in-cheek, I hope!)
I strongly suspect having a kernel developer write a thread scheduler once and have everyone use it is far more efficient than to have every application developer write their own state machines.
Unless I'm misinterprenting, you sound like you aren't familiar with the Linux kernel. You might like the approach they have taken--check out the clone system call (copied from Plan9).
Alan Cox said, "A computer is a state machine. Threads are for people who can't program state machines.". In other words, kernel hackers are way (way, way, way, way!) past the complexity of threads.
The poster who said Linus hates threads was mistaken. Linus has trashed POSIX pthreads mercilessly, but I don't think he's ever made a general statement against threads or their usefulness (as is clear from that poster's own references, he very much wants a good Linux thread model). Other kernel notables have--eg, Larry McVoy and Ted T'so.
The "linuxthreads" add-on to glibc is heavily used and actively developed--a quick look at the mailing lists and changelogs will convince you. Both POSIX pthread compliance and performance are high priorities, and many users evidently find the thread support quite "real".
As for performance, I do know that a Solaris-like model is under consideration for glibc, although plenty of people (especially kernel developers) have well-founded objections. It might help if you could provide details on why you don't find the current model "lightweight" enough, such as performance numbers from a real application. You might even get some ideas on how to improve your application.
As for features, new functionality is always being added to linuxthreads. If you described exactly which functionality you need on the glibc lists (and on the kernel lists, if applicable), or pointed out shortcomings in existing functionality, you'd probably get some helpful replies. It's acknowledged that some things aren't there yet, but this is most definitely considered a bug (by glibc people, at least), and the priority of bugs is influenced by user input.
Hoping for a new project to appear is misguided when the glibc/linuxthreads wizards have done most of the job, and remain active and responsive. Your best bet is to work with them.
P.S. Linus does not hate threads--think of how ridiculous it would be for a SMP kernel hacker to condemn concurrency within a single address space. He added clone() to Linux, which enables just that! What he hates are POSIX threads.
If he wants to change the mainstream development model--well, that isn't up for discussion. It's Linus's kernel, and everyone else can take it or leave it. If you haven't heard, Linus has made it clear that he doesn't care about the financial interests surrounding Linux.
Asking Linus to change his development principles is like requesting the repeal of those quantum phenomena that (the nerve!) prevent us from making our transistors smaller.
Sorry to sound like a wimp, but there are some aspects I'm not entirely comfortable discussing here.
But it's not that uncommon. A compelling vision is a good way to get people working hard together, which can lead to business success. And a business provides certain incomparable opportunities to the visionaries. So it makes perfect sense that some businesses are fueled by a vision. Obviously, you can't ignore the financials, but there's a big difference that and being focused on money. It may be a balancing act, but it can be done.
That's a good question. If you want to be very precise, I'm probably loyal to the founder of the company more than anything else. But they're not really separable, and I don't think there's any point to making a distinction. You could probably make the same argument for any organization.
There are many reasons why a company may be a much better vehicle for a dream, a vision, or a value than a non-profit. If you can't see this, I can only imagine that you're hopelessly anti-capitalist. But I work for such a company, and it's amazing.