That sounds similar to my password generator, although I don't regenerate my PGP keys every week. (Sure this wasn't SSH keys?)
enter old password, some random data from/dev/random and whatever else is handy, and SHA-1 it.
get milliseconds component of current time. Add PID. Recursively apply SHA-1 this many times. XOR in a byte or two from/dev/random each time.
Now the fun part. Strip the high bit and treat the first 8 bytes as an ASCII string. If it matches the password policy (e.g., 2 upper, 2 lower, 1 special, 1 digit, 2 wildcards) print it and increment counter.
Repeat prior step until counter hits 50 or so.
It usually takes 5-10 seconds to generate a list of candidate passwords. I pick one that's easy to remember because of "muscle memory." To guess my new password, you need to know both my old password and the contents of/dev/random.
That policy is a sign of incompetence in the IT department.
If strong passwords are used, they should long expiration periods. It's not unreasonable to memorize a truly random password if you only have to do it once a year. If passwords are expiring every six weeks, you *have* to write it down (on a card in your wallet, on your PDA or celphone, etc.) because it's impossible to remember them otherwise.
Another good trick is to generate a list of a few dozen candidates and look for one with good "muscle memory." E.g., my main password now has a pattern of L-RR^-LL^-LRL where ^ means it's a key "straight above" the last key.
Yes. Pick up any introductory graphics textbook and you'll see that two key concepts are the "window" and the "viewport." One is the real estate on your screen, the other is the range of coordinates in the 2-D space. (In 3-D graphics, the viewport actually identifies a tetrahedron.) I can't remember which is which, but "window" is a term that dates to the earliest displays capable of displaying graphics.
This was the basis of "windowing graphical user interfaces." Originally these windows were fixed sizes and non-overlapping, but the desktop metaphor removed those restrictions. Now we have (patented?) movable, resizeable overlapping windows in our GUI.
Bottom line: "windows" for the GUI is as (non)arbitrary as "word" is for a word processor or "access" is for a database.
You're missing an important distinction here. The GPL limits what restrictions (none) you can place on redistribution of source code as a term of the license CONTRACT.
Security classifications, in contrast, are a matter of LAW.
This is an important distinction that comes up periodically. E.g., there's a fair amount of software that is used to control the operation of amateur radio station equipment. The licenses inevitably require that the user have suitable FCC (or local equivalent) certification suitable for the operation of this equipment, probably due to FCC regulations. Does this violate the GPL? I would argue it doesn't - it's the FCC that requires a license to operate the equipment, not the author, and the sole purpose of this restriction is to limit the author's liability in those cases when the receiver acts in bad faith.
Ditto the occasional licenses that require the receiver be old enough to enter into a binding contract. Of course it's silly to say that a 17-year-old can't make valuable contributions, but the law says that contracts with 17-year-olds are never binding except for some relatively rare circumstances. (E.g., they can be emanicpated by a court, by enlistment in the military, or by marriage. Or it could be a "necessity" such as a contract for housing.)
I think the same argument can be made here. Are you willing to make the source code available to any agency legally entitled to view it? If so, then I think you can still use the GPL.
I might not have been clear - I think products out of the academic environment are "born" when they are either widely used by that institution, or when they're made available to others. Commercial releases based on these products tend to occur much later, only after there's clearly a well-established market for the product. But commercial products, by definition, aren't "born" until they're offered for sale and a meaningful number of people actually buy the product.
As for X version 12, what it would cover would be things like texture mapping, antialiased fonts, and similar very-high-end features that don't map cleanly to the existing protocols. I'm not following this closely, but I seem to recall that doing this now (via the extension mechanism) requires a lot of traffic at the level of the wire protocol. With revisions in the model to reflect a more intelligent server (the part hooked up to the display), it may be possible to cut that way down... with better performance through the unix socket, and *much* better performance over an actual network.
The dates are very misleading... just ask some of the MS(tm) Trolls that pop up whenever this question comes up.
The X Window System was part of the Athena Project at MIT, and it was used internally and at other academic sites long before it was first commercialized. But it's that first commercial release which is always used as the "birthdate," cause thousands of users at academic or clued-in industial sites don't count.
It's also "X version 11" for a reason - when I first learned it there were still a large number of references in the documentation to an earlier "X version 10." I think I once read a history that said that X versions 1-7 were developmental versions that refined the API, and versions 8 and 9 were only used at MIT. Version 10 was the first one widely used. I've been expected an announcement of Version 12 for some time now, to reflect the tremendous improvements in graphics hardware, but for now everyone seems to be satisfied with the extensions mechanism.
In a world full of Gates, the date of first commercial release is the only thing that matters. But in the real world I suspect there were more users of X than MS Windows until Windows 3.1 was released in the early 90s.
And this brings up the second point. Bill announced Windows 1.0 in 1983. So what, talk is cheap. Windows 1.0 wasn't actually available until 1985, and it was totally unusable. Even with the fastest available CPUs and far more memory (at thousands of dollars) than the average system, performance was a dog and nobody was developing for it because of the incredible overhead.
MS Windows 2.0 was a bit better.
But MS Windows was not a viable system until 3.1, and some individuals make strong arguments that this was only because other companies were entering the same market with much leaner APIs. This was the early 90s (92?), and it was nothing but an application running under DOS. Same thing with MS Windows 95, although the relationship was hidden by then. That's why there's still some controversy (possibly even ongoing litigation) whether MS deliberately crippled MS Windows to fail with an unspecified "system error" if it detected DR-DOS instead of MS-DOS.
The bottom line is that there's just enough there for a lawyer to make these claims, but they don't stand up to even cursory examination. If you're cynical, you might even suspect that Bill made the announcement and first releases just to confuse the issue a decade or two later.
Nobody hopes to have wild monkey sex with an Amazon website.
But "windowing" graphical user interfaces is a term of art that has been incorporated into countless products, many predating the first commercial release of Windows. (And to answer the inevitiable point, MIT was working on the X Window System long before the first vaporware announcement of Windows 1.0, and it was released outside of the Athena project many years before the first practical release of MS Windows (3.1)).
Even the first releases of MS Windows was called just that - Microsoft Windows. I have no problem with MS enforcing a trademark on "Microsoft Windows," but over time they (and others) have abbreviated that to just "Windows" and now Microsoft is trying to claim that the unadorned word is not a generic. Well, tough, it is.
I should also reiterate my earlier point about the envitable confusion about what "X programming" is. "X" is also fairly generic, but there are billions of lines of code written to use the X Window System, and it's been commonly abbrievated to just "X" for close to two decades. Yet I'm already seeing indicators that "X programming" may refer to development for the very limited market, proprietary Microsoft X-Box.
So it shouldn't be hard to predict what I hope the judge will rule: "Microsoft Windows" can be trademarked, not "windows" alone. Ditto "Microsoft Word" vs "word," "Microsoft Office" vs "office," etc.
This struck me as a weird ruling at first, then I realized the judge actually has a better insight into the situation than us!
The weirdness is the "Statute of Frauds." Verbal contracts are not binding in a handful of situations, and sales of Real Property are one of them. (Real Property is real estate, easements, etc., transactions that still need to be traceable hundreds of years from now.) In these cases you *must* have a written contract.
But then I remembered that a "written" contract just means that it was reduced to "tangible" form. This usually means something written on paper, but email is just as good as long as all parties stipulate that the contents of the messages have not been altered. (If the messages where PGP-signed, this wouldn't be an issue since you could detect alterations. Otherwise paper is still a far better choice.)
Contracts need to be signed, though, and email isn't signed is it? Then I remember the research I did when a few particularly clueless individuals gave me grief about my illegible signature.
According to the UCC, a "signature" is any tangible mark indicating consent. Nowhere does it say it has to be a cursive representation of your own name in your own hand. It could be printed, it could be completely illegible. It could be a mechanical reproduction applied by your secretary with a "signing machine." This is also why your bank will cash one of your "unsigned" checks - if you hand-wrote the rest of the information, *that* becomes your signature since it indicates an intent to pay. Viewing the bodies of email as self-signing, in a legal sense, isn't a far stretch. In this particular situation (negotiating terms of a contract), the alternative is to believe that one party was attempting to defraud the other.
The only remaining question is whether the other party is who they claim to be, but this isn't a one-off message. This was an exchange that discussed something personally known to both parties (the property being sold), so the risk of impersonation is low. More importantly, it sounds like the issue is whether email can be viewed as a written contract, not whether any of the messages were forged.
First, EULAs have not been upheld by the courts. Especially when they "shock the sensibilities." That's why UCITA is trying to write enforceability into law.
Second, the EULA you saw focused on the main application being downloaded. It is unlikely that this EULA will discuss embedded applications with any depth, at most you might see a paragraph making vague references to third-party applications.
Third, one of the cornerstones of contracts is that it's an conscious, INFORMED agreement between multiple parties. One or more parties may decide to remain ignorant, but once one party begins to deliberately withhold pertinent information that another party wants it's a whole new ballgame. As the author points out, there is absolutely no reasonable way anyone could ever expect an application that computes the size of a speaker enclosure cause a critical part of the OS's network stack to be changed.
Finally, I think this situation is so outrageous that it's getting close to gross negligence, not just negligence. You can contractually limit your exposure due to negligence (you made an honest mistake), but you can't contractually limit your exposure due to gross negligence (you knew there was a problem, you know your inactions would cause harm to others, but you didn't give a damn).
A better analogy is that you bought a hot dog. Okay, this is a little iffy, but most people understand that some cheap hotdogs have filler and they'll pay more for a "100% beef" hotdog. But now you learn that you're now sterile because the hot dog producer has been dumping dangerous chemicals in the brew, but hey you agreed to this risk when you bought those cheap 'dogs.
The issue is NOT whether your (presumably) minor children should have access to drugs. I am not aware of any serious drug law liberalization proponent who would not continue to make pushing drugs to minors a serious crime.
The issue is whether your old college roommate should have access to marijuana so he'll survive his chemotherapy. Maybe the pot will help him, maybe the pot won't, but that's a matter for him and his doctor to decide, not some bureaucrat who can't see past the kids. The kids that we all agree need to be protected.
The issue is whether you can have your car legally stolen from you because some cop thinks you looked "suspicious." Nobody disputes the need for drug kingpins to have their profit motive removed, but the fact that "drug" seizure proceeds are shared with the seizing agency has resulted in the predictable results in some jurisdictions. Tell me again how it protects your kids when a popular restaurant just off the college campus is closed, and threatened with seizure until the public made its displeasure known, because an employee accepted payment for some 'shrooms at work. Without his employers or the owner's knowledge or consent. N.B., no drugs were ever on the premises (at least in this incident:-), the *only* connection was that this idiot gave his work address instead of his home address for the other person to mail the cash.
The issue is whether any of us will be needlessly exposed to future terrorist attacks because the INS staff (which tend to be dedicated but overworked, unlike their totally incompetent management) has been told to focus on drug traffic instead of terrorists. You might think this would never happen... unless you've been reading the news during the past 6 month.
People with good intentions can raise the questions. Note well that I am not suggesting that liberalization need apply to hard drugs, or major smugglers, or even necessarily anyone other than the "medical marijuana users" that the VOTERS of many states have approved referendums that liberalized local laws.
But according to Ashcroft, since I;m willing to let people fighting for their lives to use some pot if they think it will help them keep a bit more food down - possibly requiring a doctor's prescription to obtain joints from their local pharmacists - then I'm an equally valid target for surveillence as the guy who just got out of the state pen for the third time.
The problem with anti-liberalization restrictions
on
DOJ Dot-Narc
·
· Score: 2
I can never read arguments against even permitting discussion of liberalizing drug laws without making a simple substitution:
Replace "drug laws" with "slavery."
We can't discuss ending slavery. We can't discuss the social costs of the misguided attempts to enforce slavery (e.g., the "recovery" laws that allowed abuse of free citizens of free states.) We can't even discuss the really braindead proposals, like the time Maryland (IIRC) proposed a law making all black freemen (and there many) slaves at the stroke of a pen.
No, we gotta keep our head in the sand until the legitimate grievances blow up into a civil war. I don't want to do drugs, but I am terrified of "law enforcement agencies" who want to see kids FUCKING DIE from bad Ecstacy rather than be flexible enough to realize that DanceSafe saves lives... and is a far more effective anti-drug message than the official efforts.
<B>NOTHING CANNOT BE DISCUSSED.</B>. I don't give a flying fuck about the morons who still think that we should be worker's paradise. Where I draw the line, and the only place I will accept this line being drawn, is at discussion of the violent overthrow of the legitimate government of the United States. The government that was duly elected by the majority of the voters, or at least the plurality.
Incredibly, the latest proposed UCITA modifications (to make it acceptable to more states) is the exact opposite of this.
Commercial software is exempt from all liability. Even if they acted in bad faith and consciously lied to you about the presence of critical bugs, you have no resource.
Open source software is held to the highest legal standards.
The legislation doesn't state it this nakedly, but it moves commercial software out of the "product" category and into a new category, so none of the consumer protection or product liability laws apply. Esp. if you never release the "final" version of your software.
In contrast, other definitions apply to all software. But since there's no exchange of "items of value" with OSS, there's no contract and it gets hit with the full power of the law.
This is totally indefensible for the reasons mentioned elsewhere. Microsoft has the ability to test its software bettter, and denies me the ability to protect myself, yet it gets a free pass. Meanwhile the guy who spent his weekends trying out an idea and who posted it with warnings that the code is not yet well-tested could lose his house.
What's that old saying - what's good enough for the goose is good enough for the gander? (That's gander - male goose - not gandolf, you goof!)
If they want to claim Intellectual Property is the equal of Real Property in terms of legal protections, etc., then they should carry the same tax burdens. Property tax, creation tax, whatever. It's time for that corporate free ride to end.
My only concern is that a poorly-written law that targets predatory monopolies could also affect sites that just provide Linux or BSD mirrors (if there's a tax fee per download), or worse would cover the "lone wolf programmer" who just wants to write a better widget for some OSS application.
More generally, there's the issue of whether other services are also taxed. I know some states charge sales tax on *everything* - including the hourly charge for the car mechanic and plumber, for the lawyer, etc. Again, this law should be fair - only tax programmer time if lawyers and accountants are also taxed. Only tax volunteer services if other volunteer services are taxed.
But on this particular issue, if the producer gets as pissed off at you sharing a copy of their software as they would if you set up a family picnic on their campus headquarters, then the IP and RP should either both be taxed or neither be taxed.
That reminds me of a horror story I once heard. Fortunately it wasn't me....
This poor guy spent hours inspecting a parse tree after a core dump. He couldn't find anything wrong. Then, finally, he realized that he was looking at the *last* parse tree - the one that the system handled without a problem. The parse tree that caused the system to crash was a lot smaller and had an immediately obvious problem, but the address of the root node was just a little bit different from the address of the root node of the old parse tree. Something easily overlooked.
Starting that day this guy was religious about setting pointers to NULL, status flags to DELETED, etc., whenever he released an object.
Sorry for showing my age. I learned C in '83 or so, and back then free() did not do special checks for NULL pointers. At least, not in some of the cheap-ass libraries we used!
I knew that C++ delete was NULL-safe, but I had forgotten that the C free() is also supposed to be NULL-safe now.
Yeah, so what? I know plenty of other languages, but if a client has a few million LOC in C the only thing they will do when I suggest changing to a "safe" language is thank me for my services and show me the door.
In contrast, I can usually get by with baby steps. Turning on compiler warnings and code hygiene to start, then assertions, etc.
There were some mid-80s articles in Dr. Dobbs or Micro Cornucopia or the like that used a subset of C. No floats, and IIRC no typedefs, no multidimensional arrays, etc. Overall you probably lost about half of the features in a standard C compiler.
The idea was to bootstrap a full compiler via this intermediate language. It was good enough for you to write your full compiler, but simple enough that you could implement it in assembler in half the time required for the full compiler. (Remember that when you're bootstrapping a system you need to write all of the standard libraries, not just the compiler itself.)
A few years later gcc became good enough that this was a moot point. If you're developing for a new architecture, use GCC to bootstrap a cross-compiler.
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
This isn't an idle concern. A while back a Ponzi scheme went under, and the person in charge of the bankruptcy demanded everyone who had received a check in the past 6 months (?) return the money.
That sounds good... until you realize that many of these checks were refunds on the original investment that were immediately reinvested. (The basic idea was that people would invest $1000 and get a post-dated check for $1200.) There was no allowance for that reinvestment, so an initial $1000 deposit could incur a demand for many times that.
The investors shouldn't count on getting back 100 cents on the dollar, but even getting zero cents back on the dollar is far better than losing an additional $3-10 on every dollar invested because the bankruptcy master is a moron. Or a greedy bastard, since her fee was a sizeable percentage of all money put back into the pool.
It was so bad that some investors committed suicide. And who could blame them - the bankruptcy master had sued them for their house, car, and all personal property to satisfy this "debt."
Bottom line: if you are owed back pay, you must insist that you receive a paycheck, not a loan.
The market is shitty, but I'm sure that somebody could hire them.
Yeah, right. I don't know anyone who's working, and it's not for lack of trying. I don't recall where Loki is located, but in a lot of markets the only possibilities are an unpaid job or unemployment, and the former looks a lot better on the resume since a lot of people still think that this is a minor recession, not a 50+% unemployment depression with no end in sight.
The increased brightness, even for a few weeks, will cause problems with the weather. Not just the fact that days or nights will be much warmer (depending on where the SN appeared), but the changes in air circulation, evaporation, etc.
But that's not the killer. The killer is the nebula that will hit years after the light (and cosmic ray) flash. It has a lot of mass (relatively speaking) and is moving fast. If we're lucky, it just destroys the ozone layer.
No, use the standards when they exist. Don't try to "improve" them without understanding the analysis that went into those standards.
For your suggestions, the month name was explicitly rejected because 1) it's not the same worldwide, 2) it requires lookup tables to parse, 3) you can't sort on it, and 4) you can't represent all possible abbreviated months in the 7-bit ASCII, much less the 5- and 6-bit representations you might find in legacy hardware.
Taken to extremes, I'm not even sure that MMM is unique. Perhaps "Feb" means the second month of the year in English, but the fourth month of the year in Albanian. This is a well-known problem with time-zone abbreviations, which is why the standards now specify using the offtime in hours and minutes instead of the civil abbreviation.
More generally, ISO-8601 actually provides a number of additional formats. Specifically,
YY-MM-DD - usable if the century is unambiguous. All of the subsequent formats can drop the century, if desired. This format is largely indistinguisable from DD-MM-YY for years between 1 and 31 inclusive so DD-MM-YY is *not* acceptable. (Besides, it's hard to sort on this format.)
yyyy-mm-dd-Thh-mm-ss- the date and time, separated by a capital 'T' in the spec (but often dropped in practice). Minutes and seconds are optional. Again, the 'Thh-mm-ss' suffix can be added to any of the other formats where it makes sense.
2002-W23 - week 23 of year 2002 (common practice in Europe)
2002-W23-4 - day 4 (Thursday) of week 23 of year 2002.
2002-123 - 123rd day of year 2002
2002-02 - second month of year 2002
and while my synopsis doesn't cover, I'm sure few people would have a hard time understanding
2002-Q2 - second quarter of 2002
This is the long format for all dates - you can omit spaces where human legibility isn't a major concern (e.g., for filenames or within databases).
The final variant I've seen, which is highly unofficial, is to write the month as a single hex digit. This is a common format with files crunched into 8.3 format - you generally have a single type code, then month, day, hour and minute or month, day and sequence number. Many digital cameras use this format, with 'P' (for photo) as the leading character.
Let's say that the US makes a "no first use" pledge. Then some nut releases militarized smallpox or some other viriluent agent. But since they didn't use a nuke, the 50 million survivors are left with nothing more than wagging their fingers at him since we can't use nukes and we can't afford conventional military action with 5 out of 6 people dead. Where's the downside for that nut?
Now let's take one step back - we know that this nut has militarized smallpox prepared and almost ready for release. We have two days, and there's simply not enough time for a conventional strike. (And if we tried, the smallpox could be immediately released.) If we don't act, 250 million Americans (and a billion or two people in the rest of the world) will die. Or we can nuke the bastard. Maybe a few million will die if the nut has it in the middle of his capital city, but you will have a very hard time finding anyone who says that a few billion innocent deaths is preferable one-tenth of one percent of that number dying in a preemptive strike intended to save those lives.
It's easy to create strawmen arguments where the first use of nukes isn't necessary... but the scary scenarios are the ones where a first use prevents the use of other weapons of mass destruction.
That advice is a good way to get in trouble with the IRS in addition to the BSA.
Here's a big clue - the IRS is well aware of this trick, and it has a bunch of questions is asks to determine whether these people are truly independent contractors or if they're de facto employees. If they're employees, you get hit with back (payroll) taxes and penalties and basically have a miserable life for a few years as the IRS investigates whether you're a tax cheat elsewhere.
I don't remember the full list of 20 questions, but I do recall that many issues came down to independence, duration of employment, etc. Are your employees... independent consultants registered as a bona fide local business (LLC, DBA, etc?) Do they carry business liability insurance in addition to personal policies? Do they work for you exclusively?
You're both wrong. Use ISO-8601, YYYY-MM-DD. It's unambiguous, sortable, and already common in much of the world. This format is also widely used by programmers maintaining time-specific data, e.g., radar plots or weather models - it makes a very handy filename.
Unfortunately, Microsoft Windows (and at least one application) inexplicably fails to support this format, even though it's an ISO standard. Or should that be "because" it's an ISO standard?...
As for "9/11" itself, that particular date will always be said that way since 911 is the emergency number in the US, similar to 991 in the UK.
Slashdot Mirror
enter old password, some random data from /dev/random and whatever else is handy, and SHA-1 it.
get milliseconds component of current time. Add PID. Recursively apply SHA-1 this many times. XOR in a byte or two from /dev/random each time.
Now the fun part. Strip the high bit and treat the first 8 bytes as an ASCII string. If it matches the password policy (e.g., 2 upper, 2 lower, 1 special, 1 digit, 2 wildcards) print it and increment counter.
Repeat prior step until counter hits 50 or so.
It usually takes 5-10 seconds to generate a list of candidate passwords. I pick one that's easy to remember because of "muscle memory." To guess my new password, you need to know both my old password and the contents of /dev/random.
That policy is a sign of incompetence in the IT department.
If strong passwords are used, they should long expiration periods. It's not unreasonable to memorize a truly random password if you only have to do it once a year. If passwords are expiring every six weeks, you *have* to write it down (on a card in your wallet, on your PDA or celphone, etc.) because it's impossible to remember them otherwise.
Another good trick is to generate a list of a few dozen candidates and look for one with good "muscle memory." E.g., my main password now has a pattern of L-RR^-LL^-LRL where ^ means it's a key "straight above" the last key.
Yes. Pick up any introductory graphics textbook and you'll see that two key concepts are the "window" and the "viewport." One is the real estate on your screen, the other is the range of coordinates in the 2-D space. (In 3-D graphics, the viewport actually identifies a tetrahedron.) I can't remember which is which, but "window" is a term that dates to the earliest displays capable of displaying graphics.
This was the basis of "windowing graphical user interfaces." Originally these windows were fixed sizes and non-overlapping, but the desktop metaphor removed those restrictions. Now we have (patented?) movable, resizeable overlapping windows in our GUI.
Bottom line: "windows" for the GUI is as (non)arbitrary as "word" is for a word processor or "access" is for a database.
You're missing an important distinction here. The GPL limits what restrictions (none) you can place on redistribution of source code as a term of the license CONTRACT.
Security classifications, in contrast, are a matter of LAW.
This is an important distinction that comes up periodically. E.g., there's a fair amount of software that is used to control the operation of amateur radio station equipment. The licenses inevitably require that the user have suitable FCC (or local equivalent) certification suitable for the operation of this equipment, probably due to FCC regulations. Does this violate the GPL? I would argue it doesn't - it's the FCC that requires a license to operate the equipment, not the author, and the sole purpose of this restriction is to limit the author's liability in those cases when the receiver acts in bad faith.
Ditto the occasional licenses that require the receiver be old enough to enter into a binding contract. Of course it's silly to say that a 17-year-old can't make valuable contributions, but the law says that contracts with 17-year-olds are never binding except for some relatively rare circumstances. (E.g., they can be emanicpated by a court, by enlistment in the military, or by marriage. Or it could be a "necessity" such as a contract for housing.)
I think the same argument can be made here. Are you willing to make the source code available to any agency legally entitled to view it? If so, then I think you can still use the GPL.
I might not have been clear - I think products out of the academic environment are "born" when they are either widely used by that institution, or when they're made available to others. Commercial releases based on these products tend to occur much later, only after there's clearly a well-established market for the product. But commercial products, by definition, aren't "born" until they're offered for sale and a meaningful number of people actually buy the product.
As for X version 12, what it would cover would be things like texture mapping, antialiased fonts, and similar very-high-end features that don't map cleanly to the existing protocols. I'm not following this closely, but I seem to recall that doing this now (via the extension mechanism) requires a lot of traffic at the level of the wire protocol. With revisions in the model to reflect a more intelligent server (the part hooked up to the display), it may be possible to cut that way down... with better performance through the unix socket, and *much* better performance over an actual network.
The dates are very misleading... just ask some of the MS(tm) Trolls that pop up whenever this question comes up.
The X Window System was part of the Athena Project at MIT, and it was used internally and at other academic sites long before it was first commercialized. But it's that first commercial release which is always used as the "birthdate," cause thousands of users at academic or clued-in industial sites don't count.
It's also "X version 11" for a reason - when I first learned it there were still a large number of references in the documentation to an earlier "X version 10." I think I once read a history that said that X versions 1-7 were developmental versions that refined the API, and versions 8 and 9 were only used at MIT. Version 10 was the first one widely used. I've been expected an announcement of Version 12 for some time now, to reflect the tremendous improvements in graphics hardware, but for now everyone seems to be satisfied with the extensions mechanism.
In a world full of Gates, the date of first commercial release is the only thing that matters. But in the real world I suspect there were more users of X than MS Windows until Windows 3.1 was released in the early 90s.
And this brings up the second point. Bill announced Windows 1.0 in 1983. So what, talk is cheap. Windows 1.0 wasn't actually available until 1985, and it was totally unusable. Even with the fastest available CPUs and far more memory (at thousands of dollars) than the average system, performance was a dog and nobody was developing for it because of the incredible overhead.
MS Windows 2.0 was a bit better.
But MS Windows was not a viable system until 3.1, and some individuals make strong arguments that this was only because other companies were entering the same market with much leaner APIs. This was the early 90s (92?), and it was nothing but an application running under DOS. Same thing with MS Windows 95, although the relationship was hidden by then. That's why there's still some controversy (possibly even ongoing litigation) whether MS deliberately crippled MS Windows to fail with an unspecified "system error" if it detected DR-DOS instead of MS-DOS.
The bottom line is that there's just enough there for a lawyer to make these claims, but they don't stand up to even cursory examination. If you're cynical, you might even suspect that Bill made the announcement and first releases just to confuse the issue a decade or two later.
This argument is totally bogus.
Nobody expects to eat an Apple computer.
Nobody hopes to have wild monkey sex with an Amazon website.
But "windowing" graphical user interfaces is a term of art that has been incorporated into countless products, many predating the first commercial release of Windows. (And to answer the inevitiable point, MIT was working on the X Window System long before the first vaporware announcement of Windows 1.0, and it was released outside of the Athena project many years before the first practical release of MS Windows (3.1)).
Even the first releases of MS Windows was called just that - Microsoft Windows. I have no problem with MS enforcing a trademark on "Microsoft Windows," but over time they (and others) have abbreviated that to just "Windows" and now Microsoft is trying to claim that the unadorned word is not a generic. Well, tough, it is.
I should also reiterate my earlier point about the envitable confusion about what "X programming" is. "X" is also fairly generic, but there are billions of lines of code written to use the X Window System, and it's been commonly abbrievated to just "X" for close to two decades. Yet I'm already seeing indicators that "X programming" may refer to development for the very limited market, proprietary Microsoft X-Box.
So it shouldn't be hard to predict what I hope the judge will rule: "Microsoft Windows" can be trademarked, not "windows" alone. Ditto "Microsoft Word" vs "word," "Microsoft Office" vs "office," etc.
This struck me as a weird ruling at first, then I realized the judge actually has a better insight into the situation than us!
The weirdness is the "Statute of Frauds." Verbal contracts are not binding in a handful of situations, and sales of Real Property are one of them. (Real Property is real estate, easements, etc., transactions that still need to be traceable hundreds of years from now.) In these cases you *must* have a written contract.
But then I remembered that a "written" contract just means that it was reduced to "tangible" form. This usually means something written on paper, but email is just as good as long as all parties stipulate that the contents of the messages have not been altered. (If the messages where PGP-signed, this wouldn't be an issue since you could detect alterations. Otherwise paper is still a far better choice.)
Contracts need to be signed, though, and email isn't signed is it? Then I remember the research I did when a few particularly clueless individuals gave me grief about my illegible signature.
According to the UCC, a "signature" is any tangible mark indicating consent. Nowhere does it say it has to be a cursive representation of your own name in your own hand. It could be printed, it could be completely illegible. It could be a mechanical reproduction applied by your secretary with a "signing machine." This is also why your bank will cash one of your "unsigned" checks - if you hand-wrote the rest of the information, *that* becomes your signature since it indicates an intent to pay. Viewing the bodies of email as self-signing, in a legal sense, isn't a far stretch. In this particular situation (negotiating terms of a contract), the alternative is to believe that one party was attempting to defraud the other.
The only remaining question is whether the other party is who they claim to be, but this isn't a one-off message. This was an exchange that discussed something personally known to both parties (the property being sold), so the risk of impersonation is low. More importantly, it sounds like the issue is whether email can be viewed as a written contract, not whether any of the messages were forged.
First, EULAs have not been upheld by the courts. Especially when they "shock the sensibilities." That's why UCITA is trying to write enforceability into law.
Second, the EULA you saw focused on the main application being downloaded. It is unlikely that this EULA will discuss embedded applications with any depth, at most you might see a paragraph making vague references to third-party applications.
Third, one of the cornerstones of contracts is that it's an conscious, INFORMED agreement between multiple parties. One or more parties may decide to remain ignorant, but once one party begins to deliberately withhold pertinent information that another party wants it's a whole new ballgame. As the author points out, there is absolutely no reasonable way anyone could ever expect an application that computes the size of a speaker enclosure cause a critical part of the OS's network stack to be changed.
Finally, I think this situation is so outrageous that it's getting close to gross negligence, not just negligence. You can contractually limit your exposure due to negligence (you made an honest mistake), but you can't contractually limit your exposure due to gross negligence (you knew there was a problem, you know your inactions would cause harm to others, but you didn't give a damn).
A better analogy is that you bought a hot dog. Okay, this is a little iffy, but most people understand that some cheap hotdogs have filler and they'll pay more for a "100% beef" hotdog. But now you learn that you're now sterile because the hot dog producer has been dumping dangerous chemicals in the brew, but hey you agreed to this risk when you bought those cheap 'dogs.
The issue is NOT whether your (presumably) minor children should have access to drugs. I am not aware of any serious drug law liberalization proponent who would not continue to make pushing drugs to minors a serious crime.
:-), the *only* connection was that this idiot gave his work address instead of his home address for the other person to mail the cash.
The issue is whether your old college roommate should have access to marijuana so he'll survive his chemotherapy. Maybe the pot will help him, maybe the pot won't, but that's a matter for him and his doctor to decide, not some bureaucrat who can't see past the kids. The kids that we all agree need to be protected.
The issue is whether you can have your car legally stolen from you because some cop thinks you looked "suspicious." Nobody disputes the need for drug kingpins to have their profit motive removed, but the fact that "drug" seizure proceeds are shared with the seizing agency has resulted in the predictable results in some jurisdictions. Tell me again how it protects your kids when a popular restaurant just off the college campus is closed, and threatened with seizure until the public made its displeasure known, because an employee accepted payment for some 'shrooms at work. Without his employers or the owner's knowledge or consent. N.B., no drugs were ever on the premises (at least in this incident
The issue is whether any of us will be needlessly exposed to future terrorist attacks because the INS staff (which tend to be dedicated but overworked, unlike their totally incompetent management) has been told to focus on drug traffic instead of terrorists. You might think this would never happen... unless you've been reading the news during the past 6 month.
People with good intentions can raise the questions. Note well that I am not suggesting that liberalization need apply to hard drugs, or major smugglers, or even necessarily anyone other than the "medical marijuana users" that the VOTERS of many states have approved referendums that liberalized local laws.
But according to Ashcroft, since I;m willing to let people fighting for their lives to use some pot if they think it will help them keep a bit more food down - possibly requiring a doctor's prescription to obtain joints from their local pharmacists - then I'm an equally valid target for surveillence as the guy who just got out of the state pen for the third time.
I can never read arguments against even permitting discussion of liberalizing drug laws without making a simple substitution:
Replace "drug laws" with "slavery."
We can't discuss ending slavery. We can't discuss the social costs of the misguided attempts to enforce slavery (e.g., the "recovery" laws that allowed abuse of free citizens of free states.) We can't even discuss the really braindead proposals, like the time Maryland (IIRC) proposed a law making all black freemen (and there many) slaves at the stroke of a pen.
No, we gotta keep our head in the sand until the legitimate grievances blow up into a civil war. I don't want to do drugs, but I am terrified of "law enforcement agencies" who want to see kids FUCKING DIE from bad Ecstacy rather than be flexible enough to realize that DanceSafe saves lives... and is a far more effective anti-drug message than the official efforts.
<B>NOTHING CANNOT BE DISCUSSED.</B>. I don't give a flying fuck about the morons who still think that we should be worker's paradise. Where I draw the line, and the only place I will accept this line being drawn, is at discussion of the violent overthrow of the legitimate government of the United States. The government that was duly elected by the majority of the voters, or at least the plurality.
Like President Bus... Oh shit!
Incredibly, the latest proposed UCITA modifications (to make it acceptable to more states) is the exact opposite of this.
Commercial software is exempt from all liability. Even if they acted in bad faith and consciously lied to you about the presence of critical bugs, you have no resource.
Open source software is held to the highest legal standards.
The legislation doesn't state it this nakedly, but it moves commercial software out of the "product" category and into a new category, so none of the consumer protection or product liability laws apply. Esp. if you never release the "final" version of your software.
In contrast, other definitions apply to all software. But since there's no exchange of "items of value" with OSS, there's no contract and it gets hit with the full power of the law.
This is totally indefensible for the reasons mentioned elsewhere. Microsoft has the ability to test its software bettter, and denies me the ability to protect myself, yet it gets a free pass. Meanwhile the guy who spent his weekends trying out an idea and who posted it with warnings that the code is not yet well-tested could lose his house.
What's that old saying - what's good enough for the goose is good enough for the gander? (That's gander - male goose - not gandolf, you goof!)
If they want to claim Intellectual Property is the equal of Real Property in terms of legal protections, etc., then they should carry the same tax burdens. Property tax, creation tax, whatever. It's time for that corporate free ride to end.
My only concern is that a poorly-written law that targets predatory monopolies could also affect sites that just provide Linux or BSD mirrors (if there's a tax fee per download), or worse would cover the "lone wolf programmer" who just wants to write a better widget for some OSS application.
More generally, there's the issue of whether other services are also taxed. I know some states charge sales tax on *everything* - including the hourly charge for the car mechanic and plumber, for the lawyer, etc. Again, this law should be fair - only tax programmer time if lawyers and accountants are also taxed. Only tax volunteer services if other volunteer services are taxed.
But on this particular issue, if the producer gets as pissed off at you sharing a copy of their software as they would if you set up a family picnic on their campus headquarters, then the IP and RP should either both be taxed or neither be taxed.
That reminds me of a horror story I once heard. Fortunately it wasn't me....
This poor guy spent hours inspecting a parse tree after a core dump. He couldn't find anything wrong. Then, finally, he realized that he was looking at the *last* parse tree - the one that the system handled without a problem. The parse tree that caused the system to crash was a lot smaller and had an immediately obvious problem, but the address of the root node was just a little bit different from the address of the root node of the old parse tree. Something easily overlooked.
Starting that day this guy was religious about setting pointers to NULL, status flags to DELETED, etc., whenever he released an object.
Sorry for showing my age. I learned C in '83 or so, and back then free() did not do special checks for NULL pointers. At least, not in some of the cheap-ass libraries we used!
I knew that C++ delete was NULL-safe, but I had forgotten that the C free() is also supposed to be NULL-safe now.
Yeah, so what? I know plenty of other languages, but if a client has a few million LOC in C the only thing they will do when I suggest changing to a "safe" language is thank me for my services and show me the door.
In contrast, I can usually get by with baby steps. Turning on compiler warnings and code hygiene to start, then assertions, etc.
There were some mid-80s articles in Dr. Dobbs or Micro Cornucopia or the like that used a subset of C. No floats, and IIRC no typedefs, no multidimensional arrays, etc. Overall you probably lost about half of the features in a standard C compiler.
The idea was to bootstrap a full compiler via this intermediate language. It was good enough for you to write your full compiler, but simple enough that you could implement it in assembler in half the time required for the full compiler. (Remember that when you're bootstrapping a system you need to write all of the standard libraries, not just the compiler itself.)
A few years later gcc became good enough that this was a moot point. If you're developing for a new architecture, use GCC to bootstrap a cross-compiler.
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
This isn't an idle concern. A while back a Ponzi scheme went under, and the person in charge of the bankruptcy demanded everyone who had received a check in the past 6 months (?) return the money.
That sounds good... until you realize that many of these checks were refunds on the original investment that were immediately reinvested. (The basic idea was that people would invest $1000 and get a post-dated check for $1200.) There was no allowance for that reinvestment, so an initial $1000 deposit could incur a demand for many times that.
The investors shouldn't count on getting back 100 cents on the dollar, but even getting zero cents back on the dollar is far better than losing an additional $3-10 on every dollar invested because the bankruptcy master is a moron. Or a greedy bastard, since her fee was a sizeable percentage of all money put back into the pool.
It was so bad that some investors committed suicide. And who could blame them - the bankruptcy master had sued them for their house, car, and all personal property to satisfy this "debt."
Bottom line: if you are owed back pay, you must insist that you receive a paycheck, not a loan.
Yeah, right. I don't know anyone who's working, and it's not for lack of trying. I don't recall where Loki is located, but in a lot of markets the only possibilities are an unpaid job or unemployment, and the former looks a lot better on the resume since a lot of people still think that this is a minor recession, not a 50+% unemployment depression with no end in sight.
The increased brightness, even for a few weeks, will cause problems with the weather. Not just the fact that days or nights will be much warmer (depending on where the SN appeared), but the changes in air circulation, evaporation, etc.
But that's not the killer. The killer is the nebula that will hit years after the light (and cosmic ray) flash. It has a lot of mass (relatively speaking) and is moving fast. If we're lucky, it just destroys the ozone layer.
No, use the standards when they exist. Don't try to "improve" them without understanding the analysis that went into those standards.
For your suggestions, the month name was explicitly rejected because 1) it's not the same worldwide, 2) it requires lookup tables to parse, 3) you can't sort on it, and 4) you can't represent all possible abbreviated months in the 7-bit ASCII, much less the 5- and 6-bit representations you might find in legacy hardware.
Taken to extremes, I'm not even sure that MMM is unique. Perhaps "Feb" means the second month of the year in English, but the fourth month of the year in Albanian. This is a well-known problem with time-zone abbreviations, which is why the standards now specify using the offtime in hours and minutes instead of the civil abbreviation.
More generally, ISO-8601 actually provides a number of additional formats. Specifically,
YY-MM-DD - usable if the century is unambiguous. All of the subsequent formats can drop the century, if desired. This format is largely indistinguisable from DD-MM-YY for years between 1 and 31 inclusive so DD-MM-YY is *not* acceptable. (Besides, it's hard to sort on this format.)
yyyy-mm-dd-Thh-mm-ss- the date and time, separated by a capital 'T' in the spec (but often dropped in practice). Minutes and seconds are optional. Again, the 'Thh-mm-ss' suffix can be added to any of the other formats where it makes sense.
2002-W23 - week 23 of year 2002 (common practice in Europe)
2002-W23-4 - day 4 (Thursday) of week 23 of year 2002.
2002-123 - 123rd day of year 2002
2002-02 - second month of year 2002
and while my synopsis doesn't cover, I'm sure few people would have a hard time understanding
2002-Q2 - second quarter of 2002
This is the long format for all dates - you can omit spaces where human legibility isn't a major concern (e.g., for filenames or within databases).
The final variant I've seen, which is highly unofficial, is to write the month as a single hex digit. This is a common format with files crunched into 8.3 format - you generally have a single type code, then month, day, hour and minute or month, day and sequence number. Many digital cameras use this format, with 'P' (for photo) as the leading character.
Have you ever studied this issue?
Let's say that the US makes a "no first use" pledge. Then some nut releases militarized smallpox or some other viriluent agent. But since they didn't use a nuke, the 50 million survivors are left with nothing more than wagging their fingers at him since we can't use nukes and we can't afford conventional military action with 5 out of 6 people dead. Where's the downside for that nut?
Now let's take one step back - we know that this nut has militarized smallpox prepared and almost ready for release. We have two days, and there's simply not enough time for a conventional strike. (And if we tried, the smallpox could be immediately released.) If we don't act, 250 million Americans (and a billion or two people in the rest of the world) will die. Or we can nuke the bastard. Maybe a few million will die if the nut has it in the middle of his capital city, but you will have a very hard time finding anyone who says that a few billion innocent deaths is preferable one-tenth of one percent of that number dying in a preemptive strike intended to save those lives.
It's easy to create strawmen arguments where the first use of nukes isn't necessary... but the scary scenarios are the ones where a first use prevents the use of other weapons of mass destruction.
That advice is a good way to get in trouble with the IRS in addition to the BSA.
Here's a big clue - the IRS is well aware of this trick, and it has a bunch of questions is asks to determine whether these people are truly independent contractors or if they're de facto employees. If they're employees, you get hit with back (payroll) taxes and penalties and basically have a miserable life for a few years as the IRS investigates whether you're a tax cheat elsewhere.
I don't remember the full list of 20 questions, but I do recall that many issues came down to independence, duration of employment, etc. Are your employees... independent consultants registered as a bona fide local business (LLC, DBA, etc?) Do they carry business liability insurance in addition to personal policies? Do they work for you exclusively?
You're both wrong. Use ISO-8601, YYYY-MM-DD. It's unambiguous, sortable, and already common in much of the world. This format is also widely used by programmers maintaining time-specific data, e.g., radar plots or weather models - it makes a very handy filename.
Unfortunately, Microsoft Windows (and at least one application) inexplicably fails to support this format, even though it's an ISO standard. Or should that be "because" it's an ISO standard?...
As for "9/11" itself, that particular date will always be said that way since 911 is the emergency number in the US, similar to 991 in the UK.