Offtopic, I suppose, to critique the site and not the content, but what's up with flexbeta? Still slashdotted, it looks like, almost 24 hours later...
(And they're using some oh-so-clever vibrantmedia intellitxt hotlinked adwords scheme, which had me momentarily afraid that my computer had been -- impossibly -- infested with some adware, until I realized it's an all-JavaScript solution, oh joy.
Yet Another Reason to leave JavaScript turned off, I guess.
[But yes, I'll be 127.0.0.1'ing vibrantmedia.com and itxt.vibrantmedia.com in my hosts file right away.])
Nice idea, but how likely is it that the Big Media Companies will want to work with a scheme that isn't (a) closed source and (b) controlled by the likes of M_______t?
You ask whether persons filing the electronic-only
preregistration form prescribed by the Copyright Office would
experience difficulties if it were necessary to use Microsoft's
Internet Explorer web browser. I would absolutely experience
difficulties: not only do I not use Microsoft Internet Explorer
on my computers; that browser is not available for my computers
at all. If it were necessary to use Microsoft Internet Explorer
in order to preregister a work, I simply would not be able to
preregister a work, period.
The Internet was founded on the principle of interoperability,
meaning that its protocols are all vendor-neutral and users are
supposed to be able to successfully communicate regardless of the
different kinds of hardware and software their computer systems
might be useing. No website or other component of the Internet
should ever mandate that one particular piece of software from
one particular vendor be used. This dictum is especially
important when the website in question is one operated by the
U.S. government, which must perforce be accessible by all
citizens. (I am all too aware that the dictum is widely flouted,
but that sad precedent should not be allowed to invalidate the
principle.)
Your notice additionally states: "Support for Netscape 7.2,
Firefox 1.0.3, and Mozilla 1.7.7 is planned but will not be
available when preregistration goes into effect", suggesting
that the programmers implementing the registration system are
attempting to but are experiencing difficulty in designing a
cross-platform website. If I might offer some unsolicited
advice: those programmers need some additional education, or,
if they work for a firm under contract to the Copyright Office,
the Office should seriously consider terminating that firm for
incompetence. They may claim that there is some specific
technical reason why they need to tie their implementation so
closely to the vagaries and foibles of individual browsers,
meaning that support for each additional browser would require
additional work, but if that is the claim, it proves that the
design of the website is faulty.
Approached correctly, the task of creating a cross-platform
website is straightforward; in fact one generally has to go out
of one's way to devise artificial and unnecessary constraints
which seem to mandate the use of one particular browser.
Approached correctly, a properly-designed website is automatically
accessible via all standards-conforming browsers: one does not
even need to provide a short list of four browsers which are or
will be supported, let alone an unacceptably degenerate list of
one.
Analogies are always risky, but to help understand why a
requirement to use Internet Explorer is unacceptable, and
indeed to understand why the question shouldn't even arise,
imagine that a contract has been let to provide an access-control
system for a new parking garage, and that the vendor is warning
that as initially deployed, only Ford automobiles will be able to
park successfully. Drivers of Chevrolets, Toyotas, and Nissans
may experience difficulties, while drivers of Deloreans and Yugos
will not be able to park at all. When asked for an explanation,
the vendor explains that their sophisticated new vehicle-recognition
system, necessary in order to know how high to raise the gate so
that the current vehicle can enter, currently knows only how to
recognize Ford automobiles. The programming to recognize
Chevrolets, Toyotas, and Nissans is not complete, and support
for Deloreans and Yugos would not be cost-effective so is not
planned at all.
The analogy seems ludicrous, because obviously no "sophisticated
vehicle-recognition system" is required in the first place:
wouldn't it make more sense to always raise the gate all the
way, so that any vehicle -- or at least any vehicle meeting DOT
standards for passenger vehicle dimensions -- could enter?
But when we look carefully at websites which support only the
"mainstream" browser, or which support only some prespecif
According to this post, Microsoft uses an essentially zoneonfo-like mechanism embedded in the Registry. So it sounds like it's no harder to patch Windows than *nix.
With many IT applications... having automatic adjustments for DST, how will the IT world
handle this change? And with the proposal reportedly taking effect this year, is there
enough time to implement change?
If the answers are not "trivially" and "yes", respectively, then someone has been incompetent.
Everyone knows that DST rules are subject to change at politicians' whim -- the historical record amply demonstrates this. Moreover, handling those changes is a solved problem: have a central, easily-updatable repository of the DST rulesets, such that the "upgrade" to handle any new rules requires no patch at all, unless you call updating the repository to be a "patch". But you certainly shouldn't have N separate applications to patch.
Most systems implement this sort of scheme already.
DST may be a stupid idea, and there are fine reasons to oppose it, but if someone says that the reason we shouldn't tinker with the rules is because of potential IT costs or problems, that's an embarrasment: said someone has just shouted for all the world to hear that IT doesn't have its house in order.
Every server and app I maintain is going to need OS and class library mods.
They're all that poorly written, that they didn't (a) centralize this functionality via a facility which (b) could be dynamically updated?
What braindead software are you running?
>...The only music I listen to is generally indie...
Precisely. But my question is, where the article says, "The transcoding will basically add DRM to anything that touches the box", does that imply that the only way to get media onto the box is in an Approved DRM format from an Approved DRM vendor? In other words, will there even be a way for you to transfer unlocked content from or to an "indie" provider?
(Before you say, "yes, of course there will be",
and call me paranoid, but think how much even more secure it would make things for the RIAA if there weren't.)
Detecting (and acting on) the browser type isn't just silly, it's the biggest baddest broken thing there is on the Internet. I14y be damned! Jon Postel is spinning in his grave.
Kiddie porn aside, every conventional porn site -- not to mention every pay-to-visit site at all -- better hope that the browser cache doesn't count as "possession". Otherwise it's impossible for any legitimate subscriber to comply with the site's terms and conditions, which presumably always state that subscribers may only "view" the content, not "download" or otherwise "possess" it.
...proving once again that the number one security problem... is user stupidity.
Wrong, wrong, a thousand times wrong.
If what you say were true, we would make cars safer by telling drivers to be more careful; we wouldn't muck around with seat belts and air bags.
Why should the user have to constantly worry about which attachments are safe or not, when the computer is in a much, much better position to do so reliably and accurately? Performing mundane tasks reliably and accurately is what computers are for.
Teach the computer that GIFs and JPEGs are safe and can be opened, that EXEs are not and cannot be opened, and be done with it.
(Yes, I know about JPEG exploits. That's a separate issue, and serves only to distract from the point that untrustworthy executables are inherently unsafe and should never be opened.)
...who would expect opening
an e-mail to be a risky proposition? The fact that it undeniably is
(in some environments) doesn't mean that people are stupid for not
knowing which e-mails to leave closed, it means that e-mail is broken
for many millions of users. The fact that e-mail as a medium can be
exploited like that is a weakness of the medium, not the user.
Right on, brother!
Having to train users to do alien things should be taken as a sign
that your system may not be so well-designed
Listen to this man.
He knows what he's talking about.
Then, if you haven't done so already, read some
Don Norman.
Yes, well-designed systems do protect users from their mistakes.
That's simply appropriate design.
It's a tragedy that so few designers understand this,
and saddle us with hard-to-use or (in this case) badly dangerous products,
and then blame the user when things go wrong.
"But who would expect opening an e-mail to be a risky proposition?"
- A person who has any idea that a computer is a general purpose machine...
A user that does not know this was never given a proper foundation...
No, it's not that simple.
Users click on things all day long.
That's the way modern GUI's work.
If we expect users to magically stop and think and reliably decline to click on just those attachmetns that are "dangerous", we will never, ever solve the e-mail virus problem.
It's just way to easy, eveb for an experienced user, to accidentally click on one.
The software knows which attachments are dangerous: those that are executable.
The software is in a position to trivially protect the user:
don't run executable attachments when clicked on.
Adopting this simple policy would cut the e-mail virus problem by 90%.
Why it can't be adopted is beyond me.
Why must the responsibility be placed solely on the software developer,
and the user be indemnified of all wrong-doing?
Because that's the way the real world works.
(And anyway it's not as black-and-white as you paint it.)
Look around you: even if I agreed that "educate the user"
were an appropriate strategy, we've been trying it for years and
it doesn't work.
Time to try something else.
When, oh when, will someone fix things so that clicking on an attachment of type.exe does not go and execute it?
That one simple change would reduce the e-mail virus problem by about 90%.
It shouldn't be hard, no, and if you've got 'em, clearly you
should.
No unit tests? Probably not a well-controlled system then, is it?
It's one of those strange, Catch-22-like paradoxes, isn't it?
The more test suites you have (and the more they're automated),
the less likely it is you need them.
...unless you're omniscient and can see EVERY possible
ramification of your change, especially in a large code base...
But in a (hypothetical?) "well-controlled" system, you
can see every possible ramification of a proposed
change, pretty easily, and without being omniscient --
because having modularity that works, so that changes are isolated,
is one of the hallmarks of a well-controlled system!
Which is basically a fancy way of saying you're going to treat your user base as guinea pigs...
Granted, the notion that you might release a patch without much testing is a heretical one.
But here's another heretical notion:
Some changes (to some systems) require less testing than others.
A small, isolated patch to a well-controlled system should not require an exhaustive, timeconsuming, complete test pass.
If you have found that every change does require an exhaustive test pass (because of the number of times you've been burned by seemingly unrelated new bugs cropping up as a result of a seemingly-innocous patch), this is a symptom that your project is not well-controlled.
There's also the point that when a patch is to fix a critical security hole for which exploits may already be circulating, users may actively want to deploy that patch ASAP, even if there's some risk of a newly-introduced bug -- a BSOD is not nearly as bad as being 0wned.
Easy example: suppose the existence of a molecular replicator on a small level, i.e. a device capable of "reading" medicine and generating perfect duplicates...
Well, if you're going to erect analogical strawmen, how about this one?
Suppose my business model is, "I smile at you nicely, and you give me $1."
When I discover that I'm not making enough money using this model, I get Congress to pass a law requiring you to give me the dollar.
(In other words, I'm deeply suspicious of any newly proposed, authoritarian, antilibertarian rule that is supported with arguments of the form, "But without this law, how could the business that depends on it make moey?".)
The huge advantage of zip over compressed tar archives comes from the fact that you
have random access...
Contrariwise, the huge advantage of compressed tar archives is that you can get much better compression, especially if there are lots of small files.
(The reason is that with archive-then-compress, the compressor can exploit redundancy across files.
If you compress-then-archive, à la zip, for small files you can end up with almost no compression at all.)
...continuing investigation that uses observation, hypothesis testing, measurement, experimentation, logical argument and theory building to lead to more adequate explanations of natural phenomena.
I'm not sure what the proponents are trying to accomplish with that definition (and no, I'm not so naive that I don't imagine they're trying to accomplish something), but on its face, that's actually quite a fine definition -- about all you'd need to make it really complete would be to add "rigorous debate and criticism" to its list.
I've always thought that a nice, side-by side comparison of creation and evolution, presenting the evidence for each (this one book plus a whole lotta faith on the one hand, versus all this direct and indirect evidence on the other), would make an excellent object-lesson on the scientific method, though I suppose it'd be too subtle for some (and too unpalatable for many).
The problem is that it is hard as fuck to interoperate with them as they are closed, messy formats...
And of course Microsoft works hard to keep them messy; they don't want other programs interoperating. They keep imagining that if they can devise messy enough formats and protocols, that only their Mongloian hordes will be able to successfully implement them, and that competitors will be left out in the cold. (Fortunately, the intrepid F/OSS programmers keep proving them wrong...)
Backwards compatibility means that a program can read (and sometimes write) its older version files. Future (or "forward") compatibility means that it can read (and very occasionally write) its newer version files.
How is this possible?
First of all, the file format must be flexible and extensible, not fixed. Also, generally, the various fields are explicitly tagged in some way (as opposed to, say, specifying that fields are in a fixed order, or begin and end at fixed byte offsets). Also, generally, the file format includes a version number in a well-defined spot at the beginning of the file that never changes its representation, so that a version 1 program can at least recognize (if not process) even a version 99 file.
Then, all you have to do is rig things up so that programs ignore information that they don't recognize (i.e. tags that they don't know). You can also get creative whenever you add information to add it in such a way that the results when the new informaation is ignored are reasonable.
Often, you use a major/minor scheme in the file format version number. Typically, changes to the minor version number are backwards and forwards compatible, but when you make a major change to the structure that old programs won't be able to deal with, or add significant new information that they won't be able to safely ignore, you bump the major version number, and then the old programs say, "Sorry, I can't read this file, it requires a newer version of me." (But at least the older program doesn't interpret the newer file as garbage, or crash while trying to read it. That's crass.)
Needless to say, XML (among other metaformats) is amenable to just about everything I've touched on here.
Future compatibility sounds impossible at first, especially if you've been subliminally taught by Microsoft that every upgrade to a file format "obviously" requires an upgrade to all the programs that deal with it. And it's easy to come up with "strawman" arguments why future compatibility is "impossible" -- in some worst-case scenario. But it can be made to work, most of the time, and it gives you a glorious kind of freedom and flexibility that distinguishes excellent from mundane software.
Slashdot Mirror
(And they're using some oh-so-clever vibrantmedia intellitxt hotlinked adwords scheme, which had me momentarily afraid that my computer had been -- impossibly -- infested with some adware, until I realized it's an all-JavaScript solution, oh joy. Yet Another Reason to leave JavaScript turned off, I guess. [But yes, I'll be 127.0.0.1'ing vibrantmedia.com and itxt.vibrantmedia.com in my hosts file right away.])
Nice idea, but how likely is it that the Big Media Companies will want to work with a scheme that isn't (a) closed source and (b) controlled by the likes of M_______t?
You ask whether persons filing the electronic-only preregistration form prescribed by the Copyright Office would experience difficulties if it were necessary to use Microsoft's Internet Explorer web browser. I would absolutely experience difficulties: not only do I not use Microsoft Internet Explorer on my computers; that browser is not available for my computers at all. If it were necessary to use Microsoft Internet Explorer in order to preregister a work, I simply would not be able to preregister a work, period.
The Internet was founded on the principle of interoperability, meaning that its protocols are all vendor-neutral and users are supposed to be able to successfully communicate regardless of the different kinds of hardware and software their computer systems might be useing. No website or other component of the Internet should ever mandate that one particular piece of software from one particular vendor be used. This dictum is especially important when the website in question is one operated by the U.S. government, which must perforce be accessible by all citizens. (I am all too aware that the dictum is widely flouted, but that sad precedent should not be allowed to invalidate the principle.)
Your notice additionally states: "Support for Netscape 7.2, Firefox 1.0.3, and Mozilla 1.7.7 is planned but will not be available when preregistration goes into effect", suggesting that the programmers implementing the registration system are attempting to but are experiencing difficulty in designing a cross-platform website. If I might offer some unsolicited advice: those programmers need some additional education, or, if they work for a firm under contract to the Copyright Office, the Office should seriously consider terminating that firm for incompetence. They may claim that there is some specific technical reason why they need to tie their implementation so closely to the vagaries and foibles of individual browsers, meaning that support for each additional browser would require additional work, but if that is the claim, it proves that the design of the website is faulty.
Approached correctly, the task of creating a cross-platform website is straightforward; in fact one generally has to go out of one's way to devise artificial and unnecessary constraints which seem to mandate the use of one particular browser. Approached correctly, a properly-designed website is automatically accessible via all standards-conforming browsers: one does not even need to provide a short list of four browsers which are or will be supported, let alone an unacceptably degenerate list of one.
Analogies are always risky, but to help understand why a requirement to use Internet Explorer is unacceptable, and indeed to understand why the question shouldn't even arise, imagine that a contract has been let to provide an access-control system for a new parking garage, and that the vendor is warning that as initially deployed, only Ford automobiles will be able to park successfully. Drivers of Chevrolets, Toyotas, and Nissans may experience difficulties, while drivers of Deloreans and Yugos will not be able to park at all. When asked for an explanation, the vendor explains that their sophisticated new vehicle-recognition system, necessary in order to know how high to raise the gate so that the current vehicle can enter, currently knows only how to recognize Ford automobiles. The programming to recognize Chevrolets, Toyotas, and Nissans is not complete, and support for Deloreans and Yugos would not be cost-effective so is not planned at all.
The analogy seems ludicrous, because obviously no "sophisticated vehicle-recognition system" is required in the first place: wouldn't it make more sense to always raise the gate all the way, so that any vehicle -- or at least any vehicle meeting DOT standards for passenger vehicle dimensions -- could enter? But when we look carefully at websites which support only the "mainstream" browser, or which support only some prespecif
Oh, dear. I see. Thanks for the correction.
According to this post, Microsoft uses an essentially zoneonfo-like mechanism embedded in the Registry. So it sounds like it's no harder to patch Windows than *nix.
If the answers are not "trivially" and "yes", respectively, then someone has been incompetent.
Everyone knows that DST rules are subject to change at politicians' whim -- the historical record amply demonstrates this. Moreover, handling those changes is a solved problem: have a central, easily-updatable repository of the DST rulesets, such that the "upgrade" to handle any new rules requires no patch at all, unless you call updating the repository to be a "patch". But you certainly shouldn't have N separate applications to patch.
Most systems implement this sort of scheme already.
DST may be a stupid idea, and there are fine reasons to oppose it, but if someone says that the reason we shouldn't tinker with the rules is because of potential IT costs or problems, that's an embarrasment: said someone has just shouted for all the world to hear that IT doesn't have its house in order.
They're all that poorly written, that they didn't (a) centralize this functionality via a facility which (b) could be dynamically updated? What braindead software are you running?
> ...The only music I listen to is generally indie...
Precisely. But my question is, where the article says, "The transcoding will basically add DRM to anything that touches the box", does that imply that the only way to get media onto the box is in an Approved DRM format from an Approved DRM vendor? In other words, will there even be a way for you to transfer unlocked content from or to an "indie" provider?
(Before you say, "yes, of course there will be", and call me paranoid, but think how much even more secure it would make things for the RIAA if there weren't.)
Detecting (and acting on) the browser type isn't just silly, it's the biggest baddest broken thing there is on the Internet. I14y be damned! Jon Postel is spinning in his grave.
Kiddie porn aside, every conventional porn site -- not to mention every pay-to-visit site at all -- better hope that the browser cache doesn't count as "possession". Otherwise it's impossible for any legitimate subscriber to comply with the site's terms and conditions, which presumably always state that subscribers may only "view" the content, not "download" or otherwise "possess" it.
Wrong, wrong, a thousand times wrong.
If what you say were true, we would make cars safer by telling drivers to be more careful; we wouldn't muck around with seat belts and air bags.
Why should the user have to constantly worry about which attachments are safe or not, when the computer is in a much, much better position to do so reliably and accurately? Performing mundane tasks reliably and accurately is what computers are for.
Teach the computer that GIFs and JPEGs are safe and can be opened, that EXEs are not and cannot be opened, and be done with it.
(Yes, I know about JPEG exploits. That's a separate issue, and serves only to distract from the point that untrustworthy executables are inherently unsafe and should never be opened.)
Right on, brother!
Having to train users to do alien things should be taken as a sign that your system may not be so well-designed
Listen to this man. He knows what he's talking about. Then, if you haven't done so already, read some Don Norman. Yes, well-designed systems do protect users from their mistakes. That's simply appropriate design. It's a tragedy that so few designers understand this, and saddle us with hard-to-use or (in this case) badly dangerous products, and then blame the user when things go wrong.
- A person who has any idea that a computer is a general purpose machine...
A user that does not know this was never given a proper foundation...
No, it's not that simple. Users click on things all day long. That's the way modern GUI's work. If we expect users to magically stop and think and reliably decline to click on just those attachmetns that are "dangerous", we will never, ever solve the e-mail virus problem. It's just way to easy, eveb for an experienced user, to accidentally click on one.
The software knows which attachments are dangerous: those that are executable. The software is in a position to trivially protect the user: don't run executable attachments when clicked on. Adopting this simple policy would cut the e-mail virus problem by 90%. Why it can't be adopted is beyond me.
Why must the responsibility be placed solely on the software developer, and the user be indemnified of all wrong-doing?
Because that's the way the real world works. (And anyway it's not as black-and-white as you paint it.)
Look around you: even if I agreed that "educate the user" were an appropriate strategy, we've been trying it for years and it doesn't work. Time to try something else.
When, oh when, will someone fix things so that clicking on an attachment of type .exe does not go and execute it?
That one simple change would reduce the e-mail virus problem by about 90%.
It shouldn't be hard, no, and if you've got 'em, clearly you should.
No unit tests? Probably not a well-controlled system then, is it?
It's one of those strange, Catch-22-like paradoxes, isn't it? The more test suites you have (and the more they're automated), the less likely it is you need them.
But in a (hypothetical?) "well-controlled" system, you can see every possible ramification of a proposed change, pretty easily, and without being omniscient -- because having modularity that works, so that changes are isolated, is one of the hallmarks of a well-controlled system!
Granted, the notion that you might release a patch without much testing is a heretical one.
But here's another heretical notion: Some changes (to some systems) require less testing than others.
A small, isolated patch to a well-controlled system should not require an exhaustive, timeconsuming, complete test pass. If you have found that every change does require an exhaustive test pass (because of the number of times you've been burned by seemingly unrelated new bugs cropping up as a result of a seemingly-innocous patch), this is a symptom that your project is not well-controlled.
There's also the point that when a patch is to fix a critical security hole for which exploits may already be circulating, users may actively want to deploy that patch ASAP, even if there's some risk of a newly-introduced bug -- a BSOD is not nearly as bad as being 0wned.
Best...
Headline...
Ever...
Well, if you're going to erect analogical strawmen, how about this one? Suppose my business model is, "I smile at you nicely, and you give me $1." When I discover that I'm not making enough money using this model, I get Congress to pass a law requiring you to give me the dollar.
(In other words, I'm deeply suspicious of any newly proposed, authoritarian, antilibertarian rule that is supported with arguments of the form, "But without this law, how could the business that depends on it make moey?".)
But of course they're no different from any public company in this respect.
You wonder?!
It's an absolute certainty!
Contrariwise, the huge advantage of compressed tar archives is that you can get much better compression, especially if there are lots of small files.
(The reason is that with archive-then-compress, the compressor can exploit redundancy across files. If you compress-then-archive, à la zip, for small files you can end up with almost no compression at all.)
Chill. I'm a regular /. reader and I had no idea who this MOG was, either.
I'm not sure what the proponents are trying to accomplish with that definition (and no, I'm not so naive that I don't imagine they're trying to accomplish something), but on its face, that's actually quite a fine definition -- about all you'd need to make it really complete would be to add "rigorous debate and criticism" to its list.
I've always thought that a nice, side-by side comparison of creation and evolution, presenting the evidence for each (this one book plus a whole lotta faith on the one hand, versus all this direct and indirect evidence on the other), would make an excellent object-lesson on the scientific method, though I suppose it'd be too subtle for some (and too unpalatable for many).
The problem is that it is hard as fuck to interoperate with them as they are closed, messy formats...
And of course Microsoft works hard to keep them messy; they don't want other programs interoperating. They keep imagining that if they can devise messy enough formats and protocols, that only their Mongloian hordes will be able to successfully implement them, and that competitors will be left out in the cold. (Fortunately, the intrepid F/OSS programmers keep proving them wrong...)
How is this possible? First of all, the file format must be flexible and extensible, not fixed. Also, generally, the various fields are explicitly tagged in some way (as opposed to, say, specifying that fields are in a fixed order, or begin and end at fixed byte offsets). Also, generally, the file format includes a version number in a well-defined spot at the beginning of the file that never changes its representation, so that a version 1 program can at least recognize (if not process) even a version 99 file.
Then, all you have to do is rig things up so that programs ignore information that they don't recognize (i.e. tags that they don't know). You can also get creative whenever you add information to add it in such a way that the results when the new informaation is ignored are reasonable.
Often, you use a major/minor scheme in the file format version number. Typically, changes to the minor version number are backwards and forwards compatible, but when you make a major change to the structure that old programs won't be able to deal with, or add significant new information that they won't be able to safely ignore, you bump the major version number, and then the old programs say, "Sorry, I can't read this file, it requires a newer version of me." (But at least the older program doesn't interpret the newer file as garbage, or crash while trying to read it. That's crass.)
Needless to say, XML (among other metaformats) is amenable to just about everything I've touched on here.
Future compatibility sounds impossible at first, especially if you've been subliminally taught by Microsoft that every upgrade to a file format "obviously" requires an upgrade to all the programs that deal with it. And it's easy to come up with "strawman" arguments why future compatibility is "impossible" -- in some worst-case scenario. But it can be made to work, most of the time, and it gives you a glorious kind of freedom and flexibility that distinguishes excellent from mundane software.