Re:Open Source and DRM are fundamentally incompati
on
Open Source DRM
·
· Score: 1
Time and space shifting are no problem with this: a proper key escrow system can distribute "your" keys to all the equipment you own.
Sadly, it's a big problem. Rights are held by people -- not things. My VCR has no right to time shift. I have that right, whether I do so on my VCR or using someone else's. For example, if what you said was true, how would I take a cd to Kinkos to burn a copy on their CD burner, which at present I have every right to do there if I have a right to do it at all.
Entire extracts, bit-perfect, extracts for parody? While fair use, I find it unlikely that this would be done with a lengthy work in a manner that would require perfect extracts. I'm sure you can find fair use examples that are prevented with such DRM (since fair use can't yet be codified), but such uses probably comprise a small percentage of the fair use specturm -- time and space shifting, archival backups, and minor extracts are the big issues, IMHO.
It is utterly irrelevant whether it happens a lot. Copyright is intended to promote the public good, and it constitutionally required to have a fair use exception since to do otherwise would be to frustrate it's very aims. You're basically saying that copyright does not have to do what we want it to do, viz. perform a public service. That's totally unacceptable.
Furthermore, all uses start out small -- timeshifting began with the people that were testing out Sony's Betamax, and the famous lawsuit on the issue covered what they were doing; not what, eventually, tens of thousands or more people were doing.
Ditto for people spaceshifting CDs to mp3 back in the days of the Diamond lawsuit.
Your foolish, shortsighted proposal would have the effect of forever fixing the state of fair use without a single care as to whether or not it was actually a good idea. For how can public demand ever be measured for something if it is quite impossible to get there?
Think of the way that demand had to be cultivated for a myriad of products and services, from xerox machines to tupperware. There was no articulable preexisting demand at all.
So shall it be for the next major class of fair use, I suspect. We'll never know that everyone will do it until they discover that they can, thanks to the efforts of trailblazers that are engaging in it early.
If the "industry" screams for DRM, I'd rather provide somewhat palatable DRM as a fait acompli, rather than having clearly more draconian forms shoved doen my throat which make any fair use impossible.
I refuse to compromise on it. Frankly, I feel that if any author releases any copy or edition of their work in a protected format, that we ought to revoke their copyright then and there, as well as any existing prior causes of action.
DRM is fundementally incompatable with the goals of the copyright system. We cannot forbid it, but we certainly can utterly fail to reward those who would engage in it, and generally discourage it at every turn. (e.g. not permitting DRM to be a deductable business expense for tax purposes, etc.)
Sorry, I don't understand how you reach this conclusion [that government mandating the use of DRM would be a content based restriction on free speech].
Well, imagine if the government said that anything you write has to include the phrase 'God bless America' in it? That would be totally unacceptable, because they are forcing you to say something that you do not want to say.
Likewise, if the government said that everything you write has to include a DRM system, they are ALSO mandating speech, which is a hugely bad thing to do. Particularly if you're trying to write about how awful DRM is.
In the commercial arena there's the tiniest of exceptions for certain types of health and safety information (such as ingredients in drugs) and truthful advertising, but nothing to the level of what you propose.
a fair use is discovered that it prevents
Such a fair use likely never will be discovered. There'll be no capability to get that far. Read Lessig's book 'Code' for a discussion of how the capabilities of things limit or impede our ability to perceive anything outside of those existing capabilities.
There has been no proof that the organization he donated to is or supports a terrorist organization, however. The government is just saying so and hasn't actually proven it. Certainly the organization involved is denying it -- what if they're right?
And besides which, we don't know that that is why the government just grabbed him. They aren't saying anything about that either.
So yeah -- I'd say that it is kafkaesque. The government is basically kidnapping people without alleging any reason for doing so, and even if they did allege such a reason, without proving it.
If you think that's just, then what's to stop them from kidnapping you? They might claim that you gave money to terrorists. Even if it isn't true, if you have no opportunity to challenge that aren't you still up shit creek without a paddle?
Re:Open Source and DRM are fundamentally incompati
on
Open Source DRM
·
· Score: 1
One can, however, approximate its codification quite well: once limited plain text extracts can exist, and complete unlimited archival encrypted copies, what else is required?
Fair use can, depending on the circumstances, permit the entirety of a work to be copied. Timeshifting, spaceshifting, and parody are all examples.
If I were creating a parody of a work, I might do so by taking the entire work, and then juxtapose it with other elements. Or I might take an extremely substantial amount of the work -- the entire visual part of a movie for example, and combine it with another soundtrack.
How can any brainless technology decide what's okay and what isn't, when it can take a host of federal judges, who are pretty smart themselves, quite a lot of effort to hash things out?
Fair use is decided on a case by case basis. It makes reference to things that technology cannot possibly hope to anticipate or know, such as the economic impact of a use, or the user's intent.
Technology is not and likely will never be up to the job. Maybe if we had strong AI you'd have an argument.
Simple: the law can require that DRM software permit this, and open DRM software can be inspected to ensure that it does.
Sounds like a content-based restriction on free speech to me. Maybe even viewpoint discrimination.
Re:Integrating Finder with Terminal
on
A Better Finder?
·
· Score: 1
Computers are actually here to accomplish a myriad of tasks, not just to make users lives easier.
You want to name one that doesn't make some users' life easier? I certainly cannot think of a single example. Certainly not, when you consider that you essentially just said that computers do tasks that humans are wholly incapable of doing themselves or through other means, or that while computers don't do anything new, that they make it harder than it would be otherwise.
If a computer made something harder for you than it would be if you did it yourself, why would you use the computer? I mean, I guess a masochist might find that appealing, but that's hardly the typical case.
I am just saying that tacking a bunch of shit onto the shell until it becomes like the Finder (only more confusing) is a pointless endeavor - we ALREADY have the Finder.
Ah, you persist in thinking of the Finder and the shell as two separate things. What I'm saying is that generally there are times when a GUI is a useful interface to any aspect of the computer and times when a CLI is a useful interface to any aspect of the computer. I'm saying that both should be used in tandem as useful methods of interfacing with the computer where appropriate.
For example, a number of people desire voice control over computers, even in graphic-heavy applications. Voice interface is very similar to a command line interface, apparently. Thus I see nothing wrong with a user interfacing with Photoshop by means of a GUI or means of a CLI, or better yet, having both options available and then using whichever is best in any given situation.
Because the determination of which method of interface is superior will tend to vary based on any specific command and not just the overall use to which the computer is to be put, this demands having both available at all times -- i.e. a single interface that uses both GUI and CLI methods, with the choice of which to use at any _instant_ being the user's. As opposed to having a graphical program, or otherwise having to use a shell to get at it.
The GUI can be superior for certain tasks - taking the redeye off the picture of Grandma or video editing. But when it comes down to renaming 10000 files from all caps into small caps, the gui falls flat on its ass.
And this is precisely why I've been saying that we need to have both. But the mere fact that accepting textual commands might be superior DOESN'T MEAN that the CLI must forgo the superior DISPLAY of a GUI.
For example, if you want to enter a command into the CLI to get via ftp all files beginning with the letter 'a', that's fine. But the typical CLI ftp program has crappy-ass output, even with hashes turned on.
A GUI progress indicator listing queues of successfully retrieved files and files awaiting download, speed of the connection, progress of the download generally and the current file specifically is much better, and can best be achieved graphically.
I wouldn't be calling for CLIs and GUIs to be integrated if I wasn't well aware of the fact that GUIs are best for some tasks and CLIs best for other tasks.
Breaking the pipe forever.
You really think that there's no way to preserve piplines? Feh. I'm confident that it's easy to handle. Particularly since there's nothing that says that the output that human beings want to see is the same as the output that they want sent to other programs.
The mouse almost worthless in the shell. It works for selecting / pasting text. Unless there is a bunch of text to copy, or it is uniquely formatted, it doesn't get touched.
It is worthless because it isn't being used. People manage to use mice all the time in word processors, and they involve a lot of typing as well. The trick is that, at least since good word processors started to appear on the Mac back in the 80's (MacWrite, Word, etc.) people used the damn thing instead of relying on various textual control codes, and such.
Us
Re:Open Source and DRM are fundamentally incompati
on
Open Source DRM
·
· Score: 1
Problems with your key: 1) Fair use cannot be properly codified. It's a constitutional doctrine. Congress can provide its own definition of fair use, seperate and apart from the judicial doctrine, and basically has in the form of 17 USC 107 (which repeats what the current judicial doctrine is) but they cannot stop the courts from having their own.
2) While I like copyrights being of minimal duration to achieve maximal public benefit, how could DRM possibly be aware of changes in the law? Congress could wipe out copyright tomorrow if it wanted to. And of course, particular material may be determined not to be copyrighted, or may have copyrights suspended or revoked only after judicial intervention. Copyright holders cannot be relied upon to be honest; their interests are in asserting copyrights no matter what.
3) Fair use is applicable no matter what technology one wishes to employ. I can time shift and space shift with a VCR if I want to. Restrictive technology should simply never exist.
Really. Well having studied a lot of copyright law, and as a person who's planning to go into practice as a copyright lawyer (God willing) in a couple of years, it's certainly critical that I correct any misunderstandings I might have.
So would you please be more specific?
Re:short sighted
on
Open Source DRM
·
· Score: 2, Interesting
Who wants to outlaw it?
I'd NEVER suggest outlawing it. People should feel free to encrypt content as an aspect of their right of free speech.
HOWEVER, I will fight tirelessly to DISCOURAGE it. For example, we could revoke the copyright of any work that the author et al released in an encrypted format.
And we can refuse to legislate that people cannot break the protection; in fact we can offer them bounties for doing so, much as there is public financing of other sorts of information gathering such as digging up ancient tablets and such.
And we can exercise trade secret protection only in situations where it's appropriate; as a form of ensuring fair competition. Which not all hacking threatens.
And we can sure as hell not mandate that people respect DRM in any way whatsoever, save at their option.
DRM is a technology, yes. But it is not neutral; it is seriously skewed towards being very bad for society, much in the way that a specially created highly lethal bioweapon is. Or an atom bomb. Productive uses are rare and difficult and require serious work to keep them from fucking us all over.
DRM is definately in that category.
Re:Open Source and DRM are fundamentally incompati
on
Open Source DRM
·
· Score: 1
The problem of "fair" DRM then reduces to one of establishing a trust hierarchy that producers of decryptors, copyright content producers, and consumers can all accept.
That is total nonsense. What is a fair use is a fair use. The author can HATE that use, but it doesn't matter. It is STILL a fair use that the user can undertake.
Authors often hate parodies of their works. Or having to compete against used copies of their own works. Or having people take quotes or clips from their works. Or having people spaceshift or timeshift their works. Or importing copies of works legally made abroad that are infringing here under certain circumstances.
Fuck 'em. We get to do all of those things regardless. And as soon as the copyright term expires, we can do literally anything with it.
Unless DRM can PERFECTLY permit people to do whatever the Supreme Court would let them do under that exact same scenario, (meaning for example that the DRM will have to know what the intent of the user is), it is an abject failure.
It is entirely possible that if such works are only prone to being created under an unacceptable copyright regime that they come at too high a cost.
Music sung by castrati might be great. Pyramids built by slave labor might be wonderful. But for all the virtues of the end product, that doesn't mean that it is acceptable to have the systems that produced such things.
If the price of a sane copyright system is that blockbuster movies won't be produced, that's absolutely fine. Because the touchstone of a sane copyright system is that it benefits society more than if it didn't exist, if it were less protective or if it were more protective.
And of course, with shorter copyright terms, the Tolkien books would've begun to fall out of copyright by now -- meaning that a thousand different people could have made a thousand different films about them. Surely some would be better than what we've got now.
Well, it is certainly against the spirit of copyright to allow artists to protect their work too much. And DRM is too much.
Copyright ideally only allows artists to protect their work just enough. And what constitutes just enough is whatever is best for society generally -- not the artist.
And furthermore, since DRM never goes away in the manner that legal protections do, and is never tempered by exceptions in the way that legal protections are, DRM necessarily involves keeping people from data that they have a right to access. Eventually in all cases where the gatekeepers are keeping people from data that the gatekeeper DOESN'T own.
And I concur that information isn't property, and at least for 5th Amendment purposes neither are rights regarding information.
DRM is inherently contrary to the concept of Open Source and in fact, of copyright. DRM must be attacked at every turn and never allowed to thrive.
Back when I was writing a lot of web pages at my old job, I used labels to indicate which files needed to be edited or had already been edited. I couldn't change the filenames -- web links (stupidly at times) rely on them. And I couldn't keep things in different directories, because then I'd lose the basic structure of the site, and could not step through it, and inspect it. (or have linked files work, such as inline graphics, stylesheets, or scripts)
Furthermore, with regards to the icon, you're flat out wrong there too. It is faster and easier to set a label than it is to find an icon, copy the icon, and paste it onto the new file. Particularly since I don't want to change the basic shape of the icon -- just tint it. And tint it to a particular user-selected color, rather than one that might be supplied by a vendor.
Lots, and I mean LOTS of people use labels constantly. Presently I'm using Windows. Rarely does a day pass when I don't wish that it had labels -- a lovely feature that the Mac had since the late 80's IIRC.
Re:Integrating Finder with Terminal
on
A Better Finder?
·
· Score: 1
That's the most asinine post I've seen in a while.
Computers are here to make the lives of their users easier. There is absolutely no good cause for a computer to be designed in a way to be deliberately difficult to use. Nor for it to be designed in a way that happens to be difficult to use if it can be more approachable without impairing function.
Your bad attitude has been something that has been outdated and worth eradicating since microcomputers first started appearing, giving ordinary people resources that previously hadn't been extended to them by smug, superior acolytes of mainframes and minis. (Though to be fair the developers of timesharing minis were nothing like you, wanting to also make computers available to more people)
And if you don't like feature creep, I suggest you abandon shells altogether. Real men toggle switches on the front panel, you asshole. Actual alphanumerics are a luxury.
I really don't see much point in a complete shell -- at best it's a last resort option when there's not enough bandwidth available for a remote GUI. But textual commands do have their uses, particularly with regards to certain types of selection for other commands to act upon. (Though note that GUIs are superior in other types of selection)
But the CLI that ideally would be present would have to be as full-featured as the rest of the OS's UI.
Commands should be named and used consistantly regardless of how they're accessed. They should take full advantage of GUI resources -- for example, hovering the mouse cursor over a CLI command should spawn a tooltip or some other useful contextual help, just as it would if you did the same over a GUI button or menu entry.
Unlike the abyssmal help provided in most shells -- such as the awful, awful man pages -- help should be provided in parallel and not in series. A user that wants to refer to the help while in the middle of a command should not have to lose it, nor execute it in a half-baked state, nor jump through hoops with 'saving' it to the clipboard or to a file. A really good help system (see the AppleGuide from MacOS circa v7.5) will walk a user through particular functions, rather than simply referring to them and counting on the user to remember what to do for each step.
And output would typically be through the GUI. The CLI I imagine is merely a single input line. Perhaps similar to an address field in a browser window. There's certainly not much in the way of purely textual output that I can see a shell being good for. The superior formatting of a display that can show graphics and non-monospaced type makes that perfectly clear right away.
As for the mouse, so what? Mice are here to stay, at least until a better pointing device comes along. And if you're such a bonehead that you insist on not using a mouse, I'm sure that keyboard shortcuts can be implemented.
At any rate, this is a totally new CLI I'm looking for here. Bash, or tcsh, or all that other crap that couldn't find usability with both hands and a flashlight need not apply.
I thought we were talking about the arrangement of files and folders into particular directories, with particular names, of the contents of the hard disk.
At at any rate, your point ignores something I was pointing out before. If a library's true GUID is 12345, a program calling on it need not search through directories more than the single first time it wants to find it. It just jumps straight to that GUID, regardles of where it is located.
As for the purpose of defragging, I'd be amazed if it isn't needed on Unix systems, at least where people are creating and deleting, deleting and creating, files all the time. For defragging ensures that each file is a single block of space on the disk, and not spread about on the actual _sectors_.
Re:OS X Finder Laundry List - Please add yours.
on
A Better Finder?
·
· Score: 1
To clarify re: #2, I think that it was felt that since there _was_ going to be an unavoidable mode switch (or else filenames would have to be never-editable or always editable all the time), it was better to have no more than necessary.
Thus it's better to have an editing mode that changes the meaning of the alphanumeric keys from (IIRC on the original Mac) 'nothing' to 'type' and that would be all than to have it be that AND the button for 'open file' becomes 'go back to non-editing mode without opening the file.'
The original Mac team did have a strong anti-mode mentality, but it's not as though modes are completely avoidable. Mostly they just tried to minimize them.
However, modern thinking seems to be AFAIK that modes are acceptable IF the user is naturally making a mode switch anyway, and fully expects the function to change. The behavior of different tools in a paint program is a good example. Unexpected or undesired mode switches should still be avoided however.
Whether the enter key functions are expected or not seems to me to be debatable.
Re:OS X Finder Laundry List - Please add yours.
on
A Better Finder?
·
· Score: 1
2) Oh, I know. I didn't say I agreed, or that it made sense. I said that that was what, AFAICT, the point of doing it that way was.
3) Well, the thing about keyboard navigation is that it certainly _seems_ faster. And I won't deny that catering to user perception is not always a bad thing. But Apple had done some research along similar lines and determined that despite user perception, the mouse was in fact faster. Whether this still holds true, I can't say, but I encourage you to have someone time you doing various things with each method and check for yourself.
And yes, the mouse -- or at least a pointing device -- was basically required on the Mac. Keyboards were not. (which presumably is why you had to buy them seperately for a time in the 80's and 90's, no joke)
Re:Integrating Finder with Terminal
on
A Better Finder?
·
· Score: 1
Yeah, I've been saying this for a long time. The commands would all need to be renamed for consistency -- rm doesn't square with the Trash, or the absolute need for undo in every situation possible, for example. mkdir doesn't gibe with New Folder either. You get the idea.
But I'd integrate them entirely, rather than use pipelines. And then build in better mouse support. In fact it still boggles the mind that you cannot do a click on a command in a shell to get a menu or dialog of options for it, clearly explained, or contextual help, or anything.
Then it stops being surprising when you remember that no one has bothered to improve CLIs seriously since scrollback was fixed. I say 'fixed' because the old terminals that printed stuff out instead of displaying it on screen had scrollback -- you looked at an earlier point on the printout!
Re:Why so mad at Cut and Paste in Finder?
on
A Better Finder?
·
· Score: 1
Well, I'd at least like some consistancy.
If it is called Cut/Copy/Paste, then let it work within documents as well. If it's not going to do that, then call it something else, dammit.
After all, who would want to drive cross-country, but have to adjust their speed with the windshield wiper control when they're in Ohio? Pretty similar thing going on here.
UNIX is very particular in how it wants things placed. There is good reason for this; it makes things run faster and more reliably. Mac people understand this when talking about a visual interface (continuity) yet are absolutely against it when it comes to organizing files/folders.... UNIX was designed by people who demand organization and intelligence; in short, it was designed by engineers. Not the 'software engineers' of today, but good old fashioned classicly trained pencil and paper engineers. They don't employ hacks, they do it the right way. The only way. The best way.
Ah, no. The metric for usability is what the user finds best -- not the computer or the developers. If it's important for the computer to have things arranged in a particular fashion, then let it do that in a way that doesn't impede the user from arranging things in any way he wants. This is certainly not difficult, since the computer likely doesn't care about much above the inode level. Paths and filenames are all human conveniences. As an example, note the File ID Numbers that MacOS used. Rather than try to use a path and filename as a GUID, a real GUID was just assigned to each file. Users could name the file anything they liked, since the computer wasn't paying attention to that.
Personally I can't stand the Unix directory structure. It slows down how well I can use the computer and it offends me. A default structure that is the most comfortable and efficient for users, but which can be trivially replaced by any kind of structure a user chooses to create for themselves is infinitely superior.
Re:I may sound really stupid, but....
on
A Better Finder?
·
· Score: 1
Oh, you can quit the Finder. And even run a different program in its stead. Such as (back in the day) Multifinder, or Minifinder. At Ease was originally a Finder replacement as well.
And of course, since the OS would automatically run any program named Finder in the System Folder at boot, lots of people made boot disks with other programs that would run automatically, particularly diagnostic and repair tools, but it could be anything.
Re:Pah, cann't be bothered reading the article
on
A Better Finder?
·
· Score: 1
Regardless of its origins the Chooser interface is sorely missed by just about any MacOS user I've come across.
You're kidding, right? Everyone knew the Chooser was a big mistake at about the time it went from involving more than which serial port the printer was plugged into.
The real problem has just been that no one's ever had a good replacement for it.
Re:OS X Finder Laundry List - Please add yours.
on
A Better Finder?
·
· Score: 1
1) Because Cmd-O is already in use in pretty much every other program that can open files, and consistency is a virtue.
2) Because it is felt that modes should be avoided, where possible. So the Return key is thought of as the toggle-renaming-of-icons key, and this duality is believed to be important to the anti-mode goal.
And there may be a third factor, in that the preferred way to open files is with the mouse. People who have hands on the keyboard are more likely trying to rename something or use a keyboard shortcut than open anything.
Slashdot Mirror
Time and space shifting are no problem with this: a proper key escrow system can distribute "your" keys to all the equipment you own.
Sadly, it's a big problem. Rights are held by people -- not things. My VCR has no right to time shift. I have that right, whether I do so on my VCR or using someone else's. For example, if what you said was true, how would I take a cd to Kinkos to burn a copy on their CD burner, which at present I have every right to do there if I have a right to do it at all.
Entire extracts, bit-perfect, extracts for parody? While fair use, I find it unlikely that this would be done with a lengthy work in a manner that would require perfect extracts. I'm sure you can find fair use examples that are prevented with such DRM (since fair use can't yet be codified), but such uses probably comprise a small percentage of the fair use specturm -- time and space shifting, archival backups, and minor extracts are the big issues, IMHO.
It is utterly irrelevant whether it happens a lot. Copyright is intended to promote the public good, and it constitutionally required to have a fair use exception since to do otherwise would be to frustrate it's very aims. You're basically saying that copyright does not have to do what we want it to do, viz. perform a public service. That's totally unacceptable.
Furthermore, all uses start out small -- timeshifting began with the people that were testing out Sony's Betamax, and the famous lawsuit on the issue covered what they were doing; not what, eventually, tens of thousands or more people were doing.
Ditto for people spaceshifting CDs to mp3 back in the days of the Diamond lawsuit.
Your foolish, shortsighted proposal would have the effect of forever fixing the state of fair use without a single care as to whether or not it was actually a good idea. For how can public demand ever be measured for something if it is quite impossible to get there?
Think of the way that demand had to be cultivated for a myriad of products and services, from xerox machines to tupperware. There was no articulable preexisting demand at all.
So shall it be for the next major class of fair use, I suspect. We'll never know that everyone will do it until they discover that they can, thanks to the efforts of trailblazers that are engaging in it early.
If the "industry" screams for DRM, I'd rather provide somewhat palatable DRM as a fait acompli, rather than having clearly more draconian forms shoved doen my throat which make any fair use impossible.
I refuse to compromise on it. Frankly, I feel that if any author releases any copy or edition of their work in a protected format, that we ought to revoke their copyright then and there, as well as any existing prior causes of action.
DRM is fundementally incompatable with the goals of the copyright system. We cannot forbid it, but we certainly can utterly fail to reward those who would engage in it, and generally discourage it at every turn. (e.g. not permitting DRM to be a deductable business expense for tax purposes, etc.)
Sorry, I don't understand how you reach this conclusion [that government mandating the use of DRM would be a content based restriction on free speech].
Well, imagine if the government said that anything you write has to include the phrase 'God bless America' in it? That would be totally unacceptable, because they are forcing you to say something that you do not want to say.
Likewise, if the government said that everything you write has to include a DRM system, they are ALSO mandating speech, which is a hugely bad thing to do. Particularly if you're trying to write about how awful DRM is.
In the commercial arena there's the tiniest of exceptions for certain types of health and safety information (such as ingredients in drugs) and truthful advertising, but nothing to the level of what you propose.
a fair use is discovered that it prevents
Such a fair use likely never will be discovered. There'll be no capability to get that far. Read Lessig's book 'Code' for a discussion of how the capabilities of things limit or impede our ability to perceive anything outside of those existing capabilities.
There has been no proof that the organization he donated to is or supports a terrorist organization, however. The government is just saying so and hasn't actually proven it. Certainly the organization involved is denying it -- what if they're right?
And besides which, we don't know that that is why the government just grabbed him. They aren't saying anything about that either.
So yeah -- I'd say that it is kafkaesque. The government is basically kidnapping people without alleging any reason for doing so, and even if they did allege such a reason, without proving it.
If you think that's just, then what's to stop them from kidnapping you? They might claim that you gave money to terrorists. Even if it isn't true, if you have no opportunity to challenge that aren't you still up shit creek without a paddle?
One can, however, approximate its codification quite well: once limited plain text extracts can exist, and complete unlimited archival encrypted copies, what else is required?
Fair use can, depending on the circumstances, permit the entirety of a work to be copied. Timeshifting, spaceshifting, and parody are all examples.
If I were creating a parody of a work, I might do so by taking the entire work, and then juxtapose it with other elements. Or I might take an extremely substantial amount of the work -- the entire visual part of a movie for example, and combine it with another soundtrack.
How can any brainless technology decide what's okay and what isn't, when it can take a host of federal judges, who are pretty smart themselves, quite a lot of effort to hash things out?
Fair use is decided on a case by case basis. It makes reference to things that technology cannot possibly hope to anticipate or know, such as the economic impact of a use, or the user's intent.
Technology is not and likely will never be up to the job. Maybe if we had strong AI you'd have an argument.
Simple: the law can require that DRM software permit this, and open DRM software can be inspected to ensure that it does.
Sounds like a content-based restriction on free speech to me. Maybe even viewpoint discrimination.
Computers are actually here to accomplish a myriad of tasks, not just to make users lives easier.
You want to name one that doesn't make some users' life easier? I certainly cannot think of a single example. Certainly not, when you consider that you essentially just said that computers do tasks that humans are wholly incapable of doing themselves or through other means, or that while computers don't do anything new, that they make it harder than it would be otherwise.
If a computer made something harder for you than it would be if you did it yourself, why would you use the computer? I mean, I guess a masochist might find that appealing, but that's hardly the typical case.
I am just saying that tacking a bunch of shit onto the shell until it becomes like the Finder (only more confusing) is a pointless endeavor - we ALREADY have the Finder.
Ah, you persist in thinking of the Finder and the shell as two separate things. What I'm saying is that generally there are times when a GUI is a useful interface to any aspect of the computer and times when a CLI is a useful interface to any aspect of the computer. I'm saying that both should be used in tandem as useful methods of interfacing with the computer where appropriate.
For example, a number of people desire voice control over computers, even in graphic-heavy applications. Voice interface is very similar to a command line interface, apparently. Thus I see nothing wrong with a user interfacing with Photoshop by means of a GUI or means of a CLI, or better yet, having both options available and then using whichever is best in any given situation.
Because the determination of which method of interface is superior will tend to vary based on any specific command and not just the overall use to which the computer is to be put, this demands having both available at all times -- i.e. a single interface that uses both GUI and CLI methods, with the choice of which to use at any _instant_ being the user's. As opposed to having a graphical program, or otherwise having to use a shell to get at it.
The GUI can be superior for certain tasks - taking the redeye off the picture of Grandma or video editing. But when it comes down to renaming 10000 files from all caps into small caps, the gui falls flat on its ass.
And this is precisely why I've been saying that we need to have both. But the mere fact that accepting textual commands might be superior DOESN'T MEAN that the CLI must forgo the superior DISPLAY of a GUI.
For example, if you want to enter a command into the CLI to get via ftp all files beginning with the letter 'a', that's fine. But the typical CLI ftp program has crappy-ass output, even with hashes turned on.
A GUI progress indicator listing queues of successfully retrieved files and files awaiting download, speed of the connection, progress of the download generally and the current file specifically is much better, and can best be achieved graphically.
I wouldn't be calling for CLIs and GUIs to be integrated if I wasn't well aware of the fact that GUIs are best for some tasks and CLIs best for other tasks.
Breaking the pipe forever.
You really think that there's no way to preserve piplines? Feh. I'm confident that it's easy to handle. Particularly since there's nothing that says that the output that human beings want to see is the same as the output that they want sent to other programs.
The mouse almost worthless in the shell. It works for selecting / pasting text. Unless there is a bunch of text to copy, or it is uniquely formatted, it doesn't get touched.
It is worthless because it isn't being used. People manage to use mice all the time in word processors, and they involve a lot of typing as well. The trick is that, at least since good word processors started to appear on the Mac back in the 80's (MacWrite, Word, etc.) people used the damn thing instead of relying on various textual control codes, and such.
Us
Problems with your key:
1) Fair use cannot be properly codified. It's a constitutional doctrine. Congress can provide its own definition of fair use, seperate and apart from the judicial doctrine, and basically has in the form of 17 USC 107 (which repeats what the current judicial doctrine is) but they cannot stop the courts from having their own.
2) While I like copyrights being of minimal duration to achieve maximal public benefit, how could DRM possibly be aware of changes in the law? Congress could wipe out copyright tomorrow if it wanted to. And of course, particular material may be determined not to be copyrighted, or may have copyrights suspended or revoked only after judicial intervention. Copyright holders cannot be relied upon to be honest; their interests are in asserting copyrights no matter what.
3) Fair use is applicable no matter what technology one wishes to employ. I can time shift and space shift with a VCR if I want to. Restrictive technology should simply never exist.
Really. Well having studied a lot of copyright law, and as a person who's planning to go into practice as a copyright lawyer (God willing) in a couple of years, it's certainly critical that I correct any misunderstandings I might have.
So would you please be more specific?
Who wants to outlaw it?
I'd NEVER suggest outlawing it. People should feel free to encrypt content as an aspect of their right of free speech.
HOWEVER, I will fight tirelessly to DISCOURAGE it. For example, we could revoke the copyright of any work that the author et al released in an encrypted format.
And we can refuse to legislate that people cannot break the protection; in fact we can offer them bounties for doing so, much as there is public financing of other sorts of information gathering such as digging up ancient tablets and such.
And we can exercise trade secret protection only in situations where it's appropriate; as a form of ensuring fair competition. Which not all hacking threatens.
And we can sure as hell not mandate that people respect DRM in any way whatsoever, save at their option.
DRM is a technology, yes. But it is not neutral; it is seriously skewed towards being very bad for society, much in the way that a specially created highly lethal bioweapon is. Or an atom bomb. Productive uses are rare and difficult and require serious work to keep them from fucking us all over.
DRM is definately in that category.
The problem of "fair" DRM then reduces to one of establishing a trust hierarchy that producers of decryptors, copyright content producers, and consumers can all accept.
That is total nonsense. What is a fair use is a fair use. The author can HATE that use, but it doesn't matter. It is STILL a fair use that the user can undertake.
Authors often hate parodies of their works. Or having to compete against used copies of their own works. Or having people take quotes or clips from their works. Or having people spaceshift or timeshift their works. Or importing copies of works legally made abroad that are infringing here under certain circumstances.
Fuck 'em. We get to do all of those things regardless. And as soon as the copyright term expires, we can do literally anything with it.
Unless DRM can PERFECTLY permit people to do whatever the Supreme Court would let them do under that exact same scenario, (meaning for example that the DRM will have to know what the intent of the user is), it is an abject failure.
We have to fight it at every turn.
That doesn't matter.
It is entirely possible that if such works are only prone to being created under an unacceptable copyright regime that they come at too high a cost.
Music sung by castrati might be great. Pyramids built by slave labor might be wonderful. But for all the virtues of the end product, that doesn't mean that it is acceptable to have the systems that produced such things.
If the price of a sane copyright system is that blockbuster movies won't be produced, that's absolutely fine. Because the touchstone of a sane copyright system is that it benefits society more than if it didn't exist, if it were less protective or if it were more protective.
And of course, with shorter copyright terms, the Tolkien books would've begun to fall out of copyright by now -- meaning that a thousand different people could have made a thousand different films about them. Surely some would be better than what we've got now.
Well, it is certainly against the spirit of copyright to allow artists to protect their work too much. And DRM is too much.
Copyright ideally only allows artists to protect their work just enough. And what constitutes just enough is whatever is best for society generally -- not the artist.
And furthermore, since DRM never goes away in the manner that legal protections do, and is never tempered by exceptions in the way that legal protections are, DRM necessarily involves keeping people from data that they have a right to access. Eventually in all cases where the gatekeepers are keeping people from data that the gatekeeper DOESN'T own.
And I concur that information isn't property, and at least for 5th Amendment purposes neither are rights regarding information.
DRM is inherently contrary to the concept of Open Source and in fact, of copyright. DRM must be attacked at every turn and never allowed to thrive.
They allow you to sort by label.
Back when I was writing a lot of web pages at my old job, I used labels to indicate which files needed to be edited or had already been edited. I couldn't change the filenames -- web links (stupidly at times) rely on them. And I couldn't keep things in different directories, because then I'd lose the basic structure of the site, and could not step through it, and inspect it. (or have linked files work, such as inline graphics, stylesheets, or scripts)
Furthermore, with regards to the icon, you're flat out wrong there too. It is faster and easier to set a label than it is to find an icon, copy the icon, and paste it onto the new file. Particularly since I don't want to change the basic shape of the icon -- just tint it. And tint it to a particular user-selected color, rather than one that might be supplied by a vendor.
Lots, and I mean LOTS of people use labels constantly. Presently I'm using Windows. Rarely does a day pass when I don't wish that it had labels -- a lovely feature that the Mac had since the late 80's IIRC.
That's the most asinine post I've seen in a while.
Computers are here to make the lives of their users easier. There is absolutely no good cause for a computer to be designed in a way to be deliberately difficult to use. Nor for it to be designed in a way that happens to be difficult to use if it can be more approachable without impairing function.
Your bad attitude has been something that has been outdated and worth eradicating since microcomputers first started appearing, giving ordinary people resources that previously hadn't been extended to them by smug, superior acolytes of mainframes and minis. (Though to be fair the developers of timesharing minis were nothing like you, wanting to also make computers available to more people)
And if you don't like feature creep, I suggest you abandon shells altogether. Real men toggle switches on the front panel, you asshole. Actual alphanumerics are a luxury.
I really don't see much point in a complete shell -- at best it's a last resort option when there's not enough bandwidth available for a remote GUI. But textual commands do have their uses, particularly with regards to certain types of selection for other commands to act upon. (Though note that GUIs are superior in other types of selection)
But the CLI that ideally would be present would have to be as full-featured as the rest of the OS's UI.
Commands should be named and used consistantly regardless of how they're accessed. They should take full advantage of GUI resources -- for example, hovering the mouse cursor over a CLI command should spawn a tooltip or some other useful contextual help, just as it would if you did the same over a GUI button or menu entry.
Unlike the abyssmal help provided in most shells -- such as the awful, awful man pages -- help should be provided in parallel and not in series. A user that wants to refer to the help while in the middle of a command should not have to lose it, nor execute it in a half-baked state, nor jump through hoops with 'saving' it to the clipboard or to a file. A really good help system (see the AppleGuide from MacOS circa v7.5) will walk a user through particular functions, rather than simply referring to them and counting on the user to remember what to do for each step.
And output would typically be through the GUI. The CLI I imagine is merely a single input line. Perhaps similar to an address field in a browser window. There's certainly not much in the way of purely textual output that I can see a shell being good for. The superior formatting of a display that can show graphics and non-monospaced type makes that perfectly clear right away.
As for the mouse, so what? Mice are here to stay, at least until a better pointing device comes along. And if you're such a bonehead that you insist on not using a mouse, I'm sure that keyboard shortcuts can be implemented.
At any rate, this is a totally new CLI I'm looking for here. Bash, or tcsh, or all that other crap that couldn't find usability with both hands and a flashlight need not apply.
I thought we were talking about the arrangement of files and folders into particular directories, with particular names, of the contents of the hard disk.
At at any rate, your point ignores something I was pointing out before. If a library's true GUID is 12345, a program calling on it need not search through directories more than the single first time it wants to find it. It just jumps straight to that GUID, regardles of where it is located.
As for the purpose of defragging, I'd be amazed if it isn't needed on Unix systems, at least where people are creating and deleting, deleting and creating, files all the time. For defragging ensures that each file is a single block of space on the disk, and not spread about on the actual _sectors_.
To clarify re: #2, I think that it was felt that since there _was_ going to be an unavoidable mode switch (or else filenames would have to be never-editable or always editable all the time), it was better to have no more than necessary.
Thus it's better to have an editing mode that changes the meaning of the alphanumeric keys from (IIRC on the original Mac) 'nothing' to 'type' and that would be all than to have it be that AND the button for 'open file' becomes 'go back to non-editing mode without opening the file.'
The original Mac team did have a strong anti-mode mentality, but it's not as though modes are completely avoidable. Mostly they just tried to minimize them.
However, modern thinking seems to be AFAIK that modes are acceptable IF the user is naturally making a mode switch anyway, and fully expects the function to change. The behavior of different tools in a paint program is a good example. Unexpected or undesired mode switches should still be avoided however.
Whether the enter key functions are expected or not seems to me to be debatable.
2) Oh, I know. I didn't say I agreed, or that it made sense. I said that that was what, AFAICT, the point of doing it that way was.
3) Well, the thing about keyboard navigation is that it certainly _seems_ faster. And I won't deny that catering to user perception is not always a bad thing. But Apple had done some research along similar lines and determined that despite user perception, the mouse was in fact faster. Whether this still holds true, I can't say, but I encourage you to have someone time you doing various things with each method and check for yourself.
And yes, the mouse -- or at least a pointing device -- was basically required on the Mac. Keyboards were not. (which presumably is why you had to buy them seperately for a time in the 80's and 90's, no joke)
I agree. And when I want a doorstop, and a hammer is handy, it is a great tool for keeping my door propped open.
The proper way to use it is whatever you need at the time.
And a computer is great, because it is a tool that can act like a virtually limitless number of other tools, each different. Depending on user need.
But probably not in this case. Read the safe harbor provisions more carefully, and in full.
You dare forget about New Wave?
Yeah, I've been saying this for a long time. The commands would all need to be renamed for consistency -- rm doesn't square with the Trash, or the absolute need for undo in every situation possible, for example. mkdir doesn't gibe with New Folder either. You get the idea.
But I'd integrate them entirely, rather than use pipelines. And then build in better mouse support. In fact it still boggles the mind that you cannot do a click on a command in a shell to get a menu or dialog of options for it, clearly explained, or contextual help, or anything.
Then it stops being surprising when you remember that no one has bothered to improve CLIs seriously since scrollback was fixed. I say 'fixed' because the old terminals that printed stuff out instead of displaying it on screen had scrollback -- you looked at an earlier point on the printout!
Well, I'd at least like some consistancy.
If it is called Cut/Copy/Paste, then let it work within documents as well. If it's not going to do that, then call it something else, dammit.
After all, who would want to drive cross-country, but have to adjust their speed with the windshield wiper control when they're in Ohio? Pretty similar thing going on here.
UNIX is very particular in how it wants things placed. There is good reason for this; it makes things run faster and more reliably. Mac people understand this when talking about a visual interface (continuity) yet are absolutely against it when it comes to organizing files/folders. ... UNIX was designed by people who demand organization and intelligence; in short, it was designed by engineers. Not the 'software engineers' of today, but good old fashioned classicly trained pencil and paper engineers. They don't employ hacks, they do it the right way. The only way. The best way.
Ah, no. The metric for usability is what the user finds best -- not the computer or the developers. If it's important for the computer to have things arranged in a particular fashion, then let it do that in a way that doesn't impede the user from arranging things in any way he wants. This is certainly not difficult, since the computer likely doesn't care about much above the inode level. Paths and filenames are all human conveniences. As an example, note the File ID Numbers that MacOS used. Rather than try to use a path and filename as a GUID, a real GUID was just assigned to each file. Users could name the file anything they liked, since the computer wasn't paying attention to that.
Personally I can't stand the Unix directory structure. It slows down how well I can use the computer and it offends me. A default structure that is the most comfortable and efficient for users, but which can be trivially replaced by any kind of structure a user chooses to create for themselves is infinitely superior.
Oh, you can quit the Finder. And even run a different program in its stead. Such as (back in the day) Multifinder, or Minifinder. At Ease was originally a Finder replacement as well.
And of course, since the OS would automatically run any program named Finder in the System Folder at boot, lots of people made boot disks with other programs that would run automatically, particularly diagnostic and repair tools, but it could be anything.
You're kidding, right? Everyone knew the Chooser was a big mistake at about the time it went from involving more than which serial port the printer was plugged into.
The real problem has just been that no one's ever had a good replacement for it.
1) Because Cmd-O is already in use in pretty much every other program that can open files, and consistency is a virtue.
2) Because it is felt that modes should be avoided, where possible. So the Return key is thought of as the toggle-renaming-of-icons key, and this duality is believed to be important to the anti-mode goal.
And there may be a third factor, in that the preferred way to open files is with the mouse. People who have hands on the keyboard are more likely trying to rename something or use a keyboard shortcut than open anything.