Not necessarily. By the definition in the grandparent, a black hole is the interior of any closed simple surface-- the event horizon-- through which escape velocity equals c; this does not necessarily imply the presence of a singularity within its bounds. As distance approaches infinity, the gravitational effect of an arbitrarily shaped non-point distribution of mass approaches the effect of a point source of gravity with the same total mass (in other words, a singularity) at the center of mass of the original distribution. The spacetime distortion created by internal gravity effectively makes the distance to the event horizon from any point inside infinite-- therefore making any distribution of mass inside indistinguishable from any other distribution, including a singularity, when viewed from outside.
"WWW-Authenticate: NTLM" is non-standard, but it's what IIS uses by default for pages that require authentication. Allowing Digest authentication involves tweaking settings that would probably scare most IT drones.
I beg to differ. Learning takes place in both settings.
To me, most of the courses were about learning and understanding new topics, and I really didn't care whether I got an A+ or a B- so long as I expanded my understanding. Of course, there were always a few classes here and there that either covered material I already knew, or presented a topic in such a manner that I had great difficulty absorbing it. For example, I had to take electromagnetic physics twice since it took the prof all semester to get to Maxwell's equations, from which I realized how the rest of the mess of poorly related special cases fit together-- but too late to save my mark.
As I see it, there are really two ways to get through an education: true comprehension, or mere scholarship. If your goals are simply high marks and acquisition of a diploma, any knowledge you gain is only a side-effect, and is often poor, limited, or difficult to relate to real-world problems. With a solid understanding, even if you can't impress someone with your paper credentials, you can see angles others miss, solve problems that balk the majority, and integrate your field experience with your academic knowledge.
I suppose the problem may in fact be the social, economic, and legal forces that demand completion of an educational program, turning it into an odious obligation rather than a journey of self-enrichment. In my opinion, that is the problem we need to solve.
A friend of mine had a lightning-induced surge hit the phone line of a BBS we were running a few years back... weird effects. It pretty much torched the external modem, came up the serial cable, lightly browned the UART (yes, the chip casing turned brown!), hopped down the bus, and grounded out through the power supply (blowing the lids off a few electrolytic capacitors in it in the process)... everything else in the box was fine.
Yeah, my Palm is feeding nutrition to my motherboards... alimentation my ass!
'Feed' is the key word here-- 'alimentation' is sometimes used (at least in French) to describe a power feed, or in printers, a paper feed. Of course, feed the wrong current into an I/O chip, and you might let the smoke out.
An XML document could thus be encoded by converting the tags into a lookup table and a single octect code. If the tags are too
many, or too long (i.e. FIRST-NAME) then there are significant savings by replacing the whole tag with an ASN.1 encoded datum. If
we assume there are up to 255 different potential tags in the XML document definition, then each could be assigned to a single byte.
Thus, encoding the tag <FIRST-NAME> would only take two bytes: One for the ID, one for the length octet, and zero for the contents
(the tag ID could carry its own meaning).
That's fine, but leaves the X out of XML: eXtensibility. A lot of existing XML schemas have slots of the form <xs:any namespace="##other"/> which allows any foreign tag, known or unknown, defined or not, to be incorporated at that point. As far as I know, ASN.1 can't cope with that without both explicit tagging and a fully-expanded OID for the incorporated entity (since it's not enumerable), which creates metadata bloat all over again.
Another XML design goal is that a document be parsable (at least as far as an abstract syntax tree) without foreknowledge of the type structure. A couple of mechanisms from SGML that were forbidden in XML but don't defeat this goal are empty end-tags and unquoted (single-token) attribute values. Empty end-tags would knock a large chunk out of the size of a complex XML document by allowing a simple </> to close whatever element was last opened. Unquoted attribute values can save 2 characters per attribute and also feel more natural when the values aren't stringlike in nature; quoting small integers just grates on me, anyway.
Another approach is defining a general binary shorthand coding for XML; a place I worked at had one in use for wire transmission of XML between hosts running their code base.
IANAL, but IIRC delaying before bringing suit in order to wreak greater havoc can backfire if the defendant can show that the plaintiff delayed excessively-- such delay is called laches, and can result in the plaintiff losing rights to equitable remedies (such as damages and injunction).
Institutions, one and all! Perhaps what we're seeing is in fact an evolution of institutional forms.
I think the key difference between the corporation and older institutions is that the primary purpose of a for-profit corporation is to acquire economic value for its constituency-- that is, its shareholders. Like the older institutional forms, though, corporations can be corrupted to serve those in power within them at the expense of their constituencies.
The first part is easy, and well-known. Generate a one-time email
address (various means are available). Associate it with the site
(e.g. by naming it something like fake-addy-ebay@mycomputer.com if
you're registering with ebay, say) Give it to the sign-up form,
purchase form or whatever. If you actually want to receive a limited
kind of email from them, or want to know if/when they've broken their
promise, ensure that this one-time email addy forwards to a real
address of yours, or at least ensure that you'll be able to read mail
sent to it.
There is already a site that provides this service: check out www.sneakemail.com. The e-mail addresses generated consist of random alphabet soup, rather than anything user-selectable (IMO this is a feature), and a decent Web interface is provided both for managing numerous aliases and configuring sender-filtering independently on each.
It's "withdrawal", not "withdrawl", AC. Bad enough that you have to stoop to a spelling flame, but to mess up yourself in the same breath makes you look more the fool than the person you're flaming.
This looks like it explicitly states that any product licensed under the ``GPL'' may not be used to `develop' any software used with the product. (Another part of the license explicitly includes all ``Open Source'' or ``Free Software'' products.) Before you complain this isn't really viral, consider: the license doesn't say `viral', it says `Potentially Viral'. If M$ says it might be viral, that's good enough for the purposes of the license.
Keep in mind that "the Software" in this case is the SDK itself, not software developed by the licensee. They're simply making it explicit that you're not allowed to snarf code (even sample code) from the SDK and republish it under an open source license. This doesn't mean you can't develop GPLed tools that use the SDK, except that you will have to add a special exception to your copyright notice that effectively bypasses the virality of the GPL with respect to the SDK (or whatever other non-free library you need). A similar exception permit
Even the tools clause only forbids "tools... licensed pursuant to terms that: (x) create, or purport to create, obligations for Microsoft with respect to the Software or (y) grant, or purport to grant, to any third party any rights to or immunities under Microsoft's intellectual property or proprietary rights in the Software." As I read this, that doesn't rule out the vast majority of open source tools-- it rules out tools which enforce a license upon the materials created or modified with them.
This isn't really much of a restriction, because it's very unusual for a development tool to impose conditions on materials created with them. One notable case was the old Bison license. Bison copied a large chunk of GPL-covered code into its generated output, thus "infecting" a program compiled with it. This irritated enough people that FSF created an exception. Think about it: just working on your code using Emacs doesn't create obligations for anyone, or grant rights or immunities to anyone, on the code you've pulled up! Also notably, some decidedly non-free tools, such as the level editors supplied with many games, place conditions on what you can do with what you create using them, such as requiring that levels you create not be used for revenue-generating purposes. Neither free software nor Microsoft is a villain here; this is merely alarmism.
I agree that gene therapy, germ-line genetic editing, and even the oft-maligned eugenics have great possibilities-- but they also have great risks. The phobia, even near hysteria, generated in the public about these technologies is likely due to journalists' and authors' over-dramatization of these risks. I think we shouldn't categorically rule them out, but rather explore carefully, and have respect for the risks.
What risks lurk in germ-line control? If genomes become too homogeneous, that leaves the whole population vulnerable to, say, that one new virus mutation that exploits a "security hole" in the now common genetic code. If some unforeseen bug in a custom gene, or its unexpected interaction with some other gene variant, causes major problems 20, 40, or more years into someone's life, how can we reasonably assign risk assumption, liability, or even just cost of resulting medical care? In essence, we'd be borrowing the problems of software engineering, compounded by working in a system that's haphazardly constructed and mind-bogglingly complex, with no documentation and only binaries to study!
Eugenics are not inherently evil-- for example, a number of states have premarital genetic screening to warn potential parents of the risks they face if one or both of them carry a deleterious or seriously maladaptive recessive (hemophilia A[carried on X, so not recessive in XY or XYY case], Tay-Sachs, sickle-cell anemia, etc.) the couple may choose to adopt, or to combine one partner's genes with a known good set taken from a gamete bank. Alternatively, if they decide to roll the dice on their own genes, amniocentesis can identify when these variants combine, and may lead parents to abort rather than allow a lifetime of suffering. Misguided application of eugenics, however, can certainly be evil, as can misguided application of other technologies-- the potential for evil is obvious in weapons of mass destruction, but what about remote sensing, psychology, and mass media being used for surreptitious surveillance, spin doctoring, and manufactured culture?
In short, there is immense power in genetic engineering, whether by genetic editing or eugenic breeding, and that power can be used for good or ill. Whatever we do, though, we need to do with both eyes open.
There are lies, there are damn lies, and then there are statistics. (sorry, can't remember the guy who said that)
IIRC that was Benjamin Disraeli, a British Prime Minister, though not in those exact words.
"There is no act of treachery or meanness of which a political party is not capable; for in politics there is no honour." -- Benjamin Disraeli, "Vivian Grey"
Speaking as someone who used to work for a (yes, totally legit) dot-com startup in Las Vegas that went public successfully, I think I can say that there's more to IT in Las Vegas than just people trying to cover up shady businesses. Admittedly, it's difficult to get decent pay there, but the cost of living is probably about half that of Silicon Valley (and electricity costs US$0.07/kwh!). For comparison, 50k/yr in Las Vegas is probably comparable to 85k/yr in Silicon Valley. As one IT manager in Las Vegas told me, though, you go to Silicon Valley for personal/career development, but Las Vegas if you want to keep the money you make.:-)
On the Pentium, IIRC, it's just as fast to check a bit in a number as it is to compare it (CMP is SUB without write, TEST is AND without write).
The Intel segmented memory architecture can deal with that too, if you're willing to put up with the hassle of "far" pointers (those that contain a segment selector and an address; 48 bits total). You just check the low 2 bits of the segment selector-- if 0, it's a kernel segment, if 3, it's a user segment.
Apparently, though, far pointers just complicate things (and slow things down) too much for most of the industry, so the segmented model just kinda faded in favor of the paged model used by most of the other 32-bit architectures.
This, though, seems to be the approach the corporate world, by and large, is taking to OSS: either create it in-house (like Java) or suck in a BSD-licensed product and hack on it (like Berkeley DB -- and either close the source (countless BSD derivatives) or keep it on a leashed license like APSL. The GPL prevents this sort of thing, but scares off a lot of companies in the process. (Then again, some provisions of the APSL do too...)
The upshot is that you should probably release code under whatever license you and your cohorts feel comfortable with, and deal with it when people do things you don't like but are within the rules of the license. After all, we're supposed to be responsible people, right?
Under the Street Performer Protocol, the teaser is the only thing released to anyone before the minimum-orders threshold is reached. Once the threshold is reached, the product is released, or in other words, all orders for the product are executed at once, and the content provider gets their specified minimum revenue. They're not guaranteed a revenue stream proportional to usage of the content, but the SPP paper essentially discounts this idea as impractical in the existing tech environment and explores alternatives.
I have to say that I admire your tenacity, but let's face it: The day
will come when somebody realizes that there's a lot of money going into your cube (office, whatever) and not a whole lot coming back out.
Hate to break it to you, but as far as management (and accounting) can see, if you're not a computing services company, IT is a cost center, not a profit center.
The cost savings/increased revenue generated by well-run IT are not directly attributable to it, since it serves to make other departments and employees more efficient, rather than producing results itself. Consider this: if you hire a good IT guy, and your 40 other employees each spend one hour a day less on average on "overhead" tasks, you're ahead by 160 man-hours a week.
As for the secretary argument, it seems that in spite of the software world's best efforts, the software that's designed to either manage itself or be manageable without a specialist's expertise breaks down in an open environment. Embedded systems can be a lot more bulletproof and/or idiot-proof, but they live in a closed world-- they're not in a constantly shifting network, constantly having to handle new tasks and run new software, and getting exposed to whatever the latest vendors, managers and users want to throw at them.
A truly good sysadmin should be all but invisible to the people who use the system he/she maintains, by making things work right. However, that means nobody sees you working, and all they remember is what you do on apparently idle time. I suppose this means that for job security, it's better to let little problems simmer for a while (so you appear to be loaded down), then come charging to the rescue like a white knight (so you get appreciated).:-)
The JVM's of two years ago were fscking unusable for complex GUI code. They've gotten decent nowadays though; I've worked on a fairly sizable project that used Swing, and with the Sun HotSpot VM (a fairly recent beast) it didn't suck mud. Of course, MediaTracker kept deadlocking, but that's a Sun bug (or a dozen; that class has been plaguing them for years).
Slashdot Mirror
Not necessarily. By the definition in the grandparent, a black hole is the interior of any closed simple surface-- the event horizon-- through which escape velocity equals c; this does not necessarily imply the presence of a singularity within its bounds. As distance approaches infinity, the gravitational effect of an arbitrarily shaped non-point distribution of mass approaches the effect of a point source of gravity with the same total mass (in other words, a singularity) at the center of mass of the original distribution. The spacetime distortion created by internal gravity effectively makes the distance to the event horizon from any point inside infinite-- therefore making any distribution of mass inside indistinguishable from any other distribution, including a singularity, when viewed from outside.
"WWW-Authenticate: NTLM" is non-standard, but it's what IIS uses by default for pages that require authentication. Allowing Digest authentication involves tweaking settings that would probably scare most IT drones.
I beg to differ. Learning takes place in both settings.
To me, most of the courses were about learning and understanding new topics, and I really didn't care whether I got an A+ or a B- so long as I expanded my understanding. Of course, there were always a few classes here and there that either covered material I already knew, or presented a topic in such a manner that I had great difficulty absorbing it. For example, I had to take electromagnetic physics twice since it took the prof all semester to get to Maxwell's equations, from which I realized how the rest of the mess of poorly related special cases fit together-- but too late to save my mark.
As I see it, there are really two ways to get through an education: true comprehension, or mere scholarship. If your goals are simply high marks and acquisition of a diploma, any knowledge you gain is only a side-effect, and is often poor, limited, or difficult to relate to real-world problems. With a solid understanding, even if you can't impress someone with your paper credentials, you can see angles others miss, solve problems that balk the majority, and integrate your field experience with your academic knowledge.
I suppose the problem may in fact be the social, economic, and legal forces that demand completion of an educational program, turning it into an odious obligation rather than a journey of self-enrichment. In my opinion, that is the problem we need to solve.
That usually seems to be expanded simply as "Microsoft-transmitted disease" [1] [2], though the derivation of the term is indeed as you suggest.
Tickware perhaps? It's a bloodsucker, digs in and is hard to remove.
A friend of mine had a lightning-induced surge hit the phone line of a BBS we were running a few years back... weird effects. It pretty much torched the external modem, came up the serial cable, lightly browned the UART (yes, the chip casing turned brown!), hopped down the bus, and grounded out through the power supply (blowing the lids off a few electrolytic capacitors in it in the process)... everything else in the box was fine.
'Feed' is the key word here-- 'alimentation' is sometimes used (at least in French) to describe a power feed, or in printers, a paper feed. Of course, feed the wrong current into an I/O chip, and you might let the smoke out.
That's fine, but leaves the X out of XML: eXtensibility. A lot of existing XML schemas have slots of the form <xs:any namespace="##other"/> which allows any foreign tag, known or unknown, defined or not, to be incorporated at that point. As far as I know, ASN.1 can't cope with that without both explicit tagging and a fully-expanded OID for the incorporated entity (since it's not enumerable), which creates metadata bloat all over again.
Another XML design goal is that a document be parsable (at least as far as an abstract syntax tree) without foreknowledge of the type structure. A couple of mechanisms from SGML that were forbidden in XML but don't defeat this goal are empty end-tags and unquoted (single-token) attribute values. Empty end-tags would knock a large chunk out of the size of a complex XML document by allowing a simple </> to close whatever element was last opened. Unquoted attribute values can save 2 characters per attribute and also feel more natural when the values aren't stringlike in nature; quoting small integers just grates on me, anyway.
Another approach is defining a general binary shorthand coding for XML; a place I worked at had one in use for wire transmission of XML between hosts running their code base.
IANAL, but IIRC delaying before bringing suit in order to wreak greater havoc can backfire if the defendant can show that the plaintiff delayed excessively-- such delay is called laches, and can result in the plaintiff losing rights to equitable remedies (such as damages and injunction).
Corporations, churches, aristocracies, states...
Institutions, one and all! Perhaps what we're seeing is in fact an evolution of institutional forms.
I think the key difference between the corporation and older institutions is that the primary purpose of a for-profit corporation is to acquire economic value for its constituency-- that is, its shareholders. Like the older institutional forms, though, corporations can be corrupted to serve those in power within them at the expense of their constituencies.
There is already a site that provides this service: check out www.sneakemail.com. The e-mail addresses generated consist of random alphabet soup, rather than anything user-selectable (IMO this is a feature), and a decent Web interface is provided both for managing numerous aliases and configuring sender-filtering independently on each.
It's "withdrawal", not "withdrawl", AC. Bad enough that you have to stoop to a spelling flame, but to mess up yourself in the same breath makes you look more the fool than the person you're flaming.
Keep in mind that "the Software" in this case is the SDK itself, not software developed by the licensee. They're simply making it explicit that you're not allowed to snarf code (even sample code) from the SDK and republish it under an open source license. This doesn't mean you can't develop GPLed tools that use the SDK, except that you will have to add a special exception to your copyright notice that effectively bypasses the virality of the GPL with respect to the SDK (or whatever other non-free library you need). A similar exception permit
Even the tools clause only forbids "tools ... licensed pursuant to terms that: (x) create, or purport to create, obligations for Microsoft with respect to the Software or (y) grant, or purport to grant, to any third party any rights to or immunities under Microsoft's intellectual property or proprietary rights in the Software." As I read this, that doesn't rule out the vast majority of open source tools-- it rules out tools which enforce a license upon the materials created or modified with them.
This isn't really much of a restriction, because it's very unusual for a development tool to impose conditions on materials created with them. One notable case was the old Bison license. Bison copied a large chunk of GPL-covered code into its generated output, thus "infecting" a program compiled with it. This irritated enough people that FSF created an exception. Think about it: just working on your code using Emacs doesn't create obligations for anyone, or grant rights or immunities to anyone, on the code you've pulled up! Also notably, some decidedly non-free tools, such as the level editors supplied with many games, place conditions on what you can do with what you create using them, such as requiring that levels you create not be used for revenue-generating purposes. Neither free software nor Microsoft is a villain here; this is merely alarmism.
I agree that gene therapy, germ-line genetic editing, and even the oft-maligned eugenics have great possibilities-- but they also have great risks. The phobia, even near hysteria, generated in the public about these technologies is likely due to journalists' and authors' over-dramatization of these risks. I think we shouldn't categorically rule them out, but rather explore carefully, and have respect for the risks.
What risks lurk in germ-line control? If genomes become too homogeneous, that leaves the whole population vulnerable to, say, that one new virus mutation that exploits a "security hole" in the now common genetic code. If some unforeseen bug in a custom gene, or its unexpected interaction with some other gene variant, causes major problems 20, 40, or more years into someone's life, how can we reasonably assign risk assumption, liability, or even just cost of resulting medical care? In essence, we'd be borrowing the problems of software engineering, compounded by working in a system that's haphazardly constructed and mind-bogglingly complex, with no documentation and only binaries to study!
Eugenics are not inherently evil-- for example, a number of states have premarital genetic screening to warn potential parents of the risks they face if one or both of them carry a deleterious or seriously maladaptive recessive (hemophilia A[carried on X, so not recessive in XY or XYY case], Tay-Sachs, sickle-cell anemia, etc.) the couple may choose to adopt, or to combine one partner's genes with a known good set taken from a gamete bank. Alternatively, if they decide to roll the dice on their own genes, amniocentesis can identify when these variants combine, and may lead parents to abort rather than allow a lifetime of suffering. Misguided application of eugenics, however, can certainly be evil, as can misguided application of other technologies-- the potential for evil is obvious in weapons of mass destruction, but what about remote sensing, psychology, and mass media being used for surreptitious surveillance, spin doctoring, and manufactured culture?
In short, there is immense power in genetic engineering, whether by genetic editing or eugenic breeding, and that power can be used for good or ill. Whatever we do, though, we need to do with both eyes open.
IIRC that was Benjamin Disraeli, a British Prime Minister, though not in those exact words.
"There is no act of treachery or meanness of which a political party is not capable; for in politics there is no honour." -- Benjamin Disraeli, "Vivian Grey"
Just pipe it through
The above message yields
Speaking as someone who used to work for a (yes, totally legit) dot-com startup in Las Vegas that went public successfully, I think I can say that there's more to IT in Las Vegas than just people trying to cover up shady businesses. Admittedly, it's difficult to get decent pay there, but the cost of living is probably about half that of Silicon Valley (and electricity costs US$0.07/kwh!). For comparison, 50k/yr in Las Vegas is probably comparable to 85k/yr in Silicon Valley. As one IT manager in Las Vegas told me, though, you go to Silicon Valley for personal/career development, but Las Vegas if you want to keep the money you make. :-)
On the Pentium, IIRC, it's just as fast to check a bit in a number as it is to compare it (CMP is SUB without write, TEST is AND without write).
The Intel segmented memory architecture can deal with that too, if you're willing to put up with the hassle of "far" pointers (those that contain a segment selector and an address; 48 bits total). You just check the low 2 bits of the segment selector-- if 0, it's a kernel segment, if 3, it's a user segment.
Apparently, though, far pointers just complicate things (and slow things down) too much for most of the industry, so the segmented model just kinda faded in favor of the paged model used by most of the other 32-bit architectures.
If the http server supports byte ranges, you can always use that approach.
Well, if we model a comet, dirty snowball that it is, as though it were a cubic mile of hot fudge sundae...
This, though, seems to be the approach the corporate world, by and large, is taking to OSS: either create it in-house (like Java) or suck in a BSD-licensed product and hack on it (like Berkeley DB -- and either close the source (countless BSD derivatives) or keep it on a leashed license like APSL. The GPL prevents this sort of thing, but scares off a lot of companies in the process. (Then again, some provisions of the APSL do too...)
The upshot is that you should probably release code under whatever license you and your cohorts feel comfortable with, and deal with it when people do things you don't like but are within the rules of the license. After all, we're supposed to be responsible people, right?
Under the Street Performer Protocol, the teaser is the only thing released to anyone before the minimum-orders threshold is reached. Once the threshold is reached, the product is released, or in other words, all orders for the product are executed at once, and the content provider gets their specified minimum revenue. They're not guaranteed a revenue stream proportional to usage of the content, but the SPP paper essentially discounts this idea as impractical in the existing tech environment and explores alternatives.
Hate to break it to you, but as far as management (and accounting) can see, if you're not a computing services company, IT is a cost center, not a profit center.
The cost savings/increased revenue generated by well-run IT are not directly attributable to it, since it serves to make other departments and employees more efficient, rather than producing results itself. Consider this: if you hire a good IT guy, and your 40 other employees each spend one hour a day less on average on "overhead" tasks, you're ahead by 160 man-hours a week.
As for the secretary argument, it seems that in spite of the software world's best efforts, the software that's designed to either manage itself or be manageable without a specialist's expertise breaks down in an open environment. Embedded systems can be a lot more bulletproof and/or idiot-proof, but they live in a closed world-- they're not in a constantly shifting network, constantly having to handle new tasks and run new software, and getting exposed to whatever the latest vendors, managers and users want to throw at them.
A truly good sysadmin should be all but invisible to the people who use the system he/she maintains, by making things work right. However, that means nobody sees you working, and all they remember is what you do on apparently idle time. I suppose this means that for job security, it's better to let little problems simmer for a while (so you appear to be loaded down), then come charging to the rescue like a white knight (so you get appreciated). :-)
The JVM's of two years ago were fscking unusable for complex GUI code. They've gotten decent nowadays though; I've worked on a fairly sizable project that used Swing, and with the Sun HotSpot VM (a fairly recent beast) it didn't suck mud. Of course, MediaTracker kept deadlocking, but that's a Sun bug (or a dozen; that class has been plaguing them for years).