Re:Good.. we need Ideas, not just complaints
on
"Squishy" DRM?
·
· Score: 2
I too think there should be some Open Source people, with a lot of crypto experience, trying to come up with a *real* solution.
Basically any real solution should allow open-source players. The companies have to realize that, to a determined pirate, ALL players are open-source. Thus if their system requires closed-source to secure it, by definition the system is not secure and can be broken.
It seems like their are two solutions.
One is to encrypt each piece of data to play back only on a specific piece of hardware. Though you know how the encoders and decoders work, some variation on PK encryption is used so that knowing how to encrypt data for your player does not allow you to decrypt. Publishers would only give you the encrypted data. Attempts to write a fake player would fail because the publisher would have a database of all players that have been manufactured and would refuse to encode using keys that are not in this database. I think crypto systems can be made so that only a small "decrypt block" has to be specific to a device, it tells the hardware how to decrypt the main block of data. The obvious problems with this is that all-new hardware is needed, and that playpack is limited to one piece of hardware. However the publisher should allow a tiny or fee for additional hardware to be added, you send them the encoding you have and the old key and they reencode it for the new key. They can limit how many times this is done so it could be free.
The other much nicer solution is watermarks. Not the "don't copy" watermarks, but watermarks that do very little to the music and do not affect the operation of any devices in any way. In fact they must be absolutely as invisible as possible so there is no incentive to detect or remove them. The watermark may contain your personal identification, but this could work if it just contains the publisher's idenfication. They can then look at the net and easily detect pirated songs by looking for the watermark, and then use normal laws to go after the people doing it. How to decode the watermarks must be kept secret. It would be nice if you were still allowed to *add* watermarks but this will only work if knowing how to do this does not allow you to decode them, I'm not sure if this is possible. If you can add watermarks, adding enough of them may eventually hide the original watermark, but it should be designed so that the music deteriorates to unacceptable levels long before this happens.
Both of these schemes could be done. In my opinion both of these are really workable and legal and are fair to users. I also believe anything that does not allow open-source players is not only unfair but in fact will fail to achieve their goals. Convincing them of this fact is going to be hard, but a serious investigation of a real working scheme may do that.
This is easy. The rippers have no way to detect if they successfully removed the watermark, and they have no incentive to do so (because the music plays anyway). This does require that there be no software that reports what the watermark is, instead the RIAA should keep a machine in a vault in their basement with the only copy of the watermark-reading software, because any program outside anywhere (closed source or not) will threaten the watermark with being hacked.
It would be nice if there was software to *add* a watermark but I'm not sure if this would be possible without revealing how to remove or read the watermark. What it would do is make it so both watermarks are visible. If it is designed right you can't hide the watermark by adding thousands of new ones because the music would deteriorate to unusable long before the first watermark is hidden.
If this really is just a watermark, then Open-source players would be allowed and they won't track listening habits. I would also recommend that they not imbed the watermark reader into any closed-source files, because hackers are going to find it and figure out how to defeat it (suddenly all p2p music files are owned by George Bush!). Keep that information out of private computers completely if they want it to be safe.
Also closed-source players have lots of other ways to track listening habits and don't need this tag for that.
Both you and Bob should get busted. You did violate the copyright by giving the music to Bob! Also Bob also did obvious copyright violations so he was caught directly.
Most likely they will go after Bob because they can prove he is doing something that is not allowed by copyright. You could always claim Bob broke into your house and copied your music without your permission.
Anyway if the RIAA is starting to consider sensible things like this is is a great relief. But people here should show their support by indicating they will fully support lawful prosecution of copyright violators and not act like a bunch of children, which will just make them go back to their earlier stance which is going to outlaw all non-MicroSoft systems eventually.
You are right, after I posted this I realized that it could work if the algorithim is something where the answer can easily be confirmed. For instance factoring a large number, the answer can be easily confirmed but the server did not need to know it ahead of time.
In fact after reading the hashcash docs, it appears that it is actually the client that picks the "question" and also calculates the "answer" at the same time. The server only checks to make sure the same question is not used more than once. So anyway there is no way for the server to know the answer ahead of time, it does not even know the question.
Actually both use copyrights to restrict what you do. The records have no license because you are not allowed to do anything more than copyright allows you to do. The GPL *IS* a license because it lets you do a little bit more: you can distribute copies if you provide all the source code.
And certainly a lot of CD copying is not for "backup purposes" as stated here, plenty of it is for violating copyright by distributing it.
The main difference I see is what the RIAA is trying to prevent. For instance if Epson posted rips of all the latest music on their website for you to download, the RIAA has exactly the same case as the FSF against them and can certainly force them to remove it, just like Epson had to remove these drivers. However the RIAA seems committed to trying to prevent people from doing anything with the data on the disk by artificial restricions that are not enforced by copyright or any other laws. While the FSF does not care at all if you copy the source code or back it up or make secret closed-source inhouse modifications or anything else you are allowed to do by law, and only cares if you violate the copyright for real by an actual *distribution* of the code.
And the zealots are wrong. They have no rights to the source code.
The only "rule" is that Epson cannot give away or sell the software without this source code. They currently took the solution of not distributing the software at all.
I expect either somebody at Epson will realize that whatever part they have is not so valuable and they can give out the source code, or they will quickly write a replacement that does not use their secret algorithim and thus does not work so well, or (most likely) whoever already granted exceptions to the GPL license on this code (it is allowed to be plugged into closed-source programs according to an earlier email) will add this as an exception as well.
I personally feel that a block of code as described could be closed-source without harming things, as long as the interface is very limited and it is clear what it does. For instance if it takes a block of pixel values read from the scanner and processed it and rewrote the block with the cleaned-up image, this is pretty clear and easily replaced. If instead it talked directly to the scanner or decoded a block of data such as encrypted stuff from the scanner, I would consider that a bad idea. Maybe it should be allowed if they also write an open-source replacement that "works" but is not as good, for instance my first example could be replaced with code that returns immediately without changing the buffer. The second example could not be replaced with anything. Maybe there is some way to make a modified GPL where such modules are allowed. It has to be worded very carefully so the closed-source parts can be replaced easily.
I don't think it can do Seti at home, because the server needs to confirm the answer, which would take just as much computation on the server. The question has to be something the server already knows the answer to.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
That's a very good example of what I need.
The important thing is that I am not saying that *no* clicks raise the windows. Besides the title bar and edges, I recommend that programs raise themselves when clicked on any interior areas that do nothing. The writer of the software or toolkit could also decide that some clicks that do something should also raise the window. I think it may also make sense to raise the parent when a modal dialog box is closed, but again this can be done by the program.
The main thing to realize is that if the system raises windows on a click, it is impossible to get another behavior. While if the system does not raise windows on a click, but provides a raise_window() function, then it is trivial to get the standard behavior. This is why I am quite adamant that this is a feature we need in the GUI. It does not matter which is better, what matters is a system where both are possible.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
That version of NeWS was the NeWS/X11 merge which Sun tried first. It contained all the code of the X server. The "pure" NeWS system was very short-lived, perhaps only a year, around 1986.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
Of course if you tile the windows then none of these things are problems. The problem is if you have data that is large enough that you cannot tile the windows and they have to overlap. Try working with 2048x1556 images in the special effects industry and you will know that this is not an unrealistic scenario.
Basically click-to-raise makes it impossible to work with these images even at.5 zoom. We are forced to use scrollbars (actually I was forced to get rid of the scrollbars to increase the available space and use alt+drag to move the contents) reduce the windows and pan which makes it impossible to make good decisions because you cannot see the whole image. And working at.25 or smaller zoom is just bad for spotting details (ie mistakes). And this is not a problem with just multiple images, most programs have an extremely large control panel and you cannot mess with it because raising it necessarily hides the image you are working on!
Basically the problem is that you are using data that is small enough that you can tile the screen. When windows are arranged this way, there is no difference between click-raise and click-does-nothing. I'm sure you think this is sufficient but you have been forced into this point of view by the absolute necessity of tiling your data, because click-raise makes overlapping windows impossible to use.
Also I know that window edges are very narrow. This is why programs should always raise the window on clicks that don't serve any purpose. Most programs add a pretty significant border inside the window that can be used to raise it. I believe that as long as programs do this you would never miss click-raise, as there is always a very large amount of available clickable space. Also as I said the programmer can also decide that various clicks mean that the user wants the program in the foreground, ideally they should do this when the actions make it clear that the user is not copying or referring to data outside the window but instead looking at data inside the window.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
I personally hate that "feature" (point to type) with a passion.
To me this means you have refused to try it.
I prefer this behaviour (clicks raise) myself.
Again I don't think you have tried a system that correctly works. And you have become too used to programs that use tiled to get around these bugs. However try MSWord and edit several documents that you want to cross-reference and you will quickly see the light. PS: it is easy for click to raise windows, the user can click on the title bar or any edges. Also any program can raise itself in response to a click, so if you are writing software and are convinced that this behavior is necessary, you can make it do it. I recommend that any clicks that don't serve any other purpose (such as clicks on the gray background of control panels) should raise the window.
Layers: Another feature I prefer. If I didn't want my toolbars permenently visable, I'd set them to hide.
Alright I'm not so adamant about that. However I don't think it is necessary as long as a click on a dead area or the edge of the toolbar raises it. What I really hated was NeXTStep that insisited on putting the menus atop *all* windows due to "layers" and then thinking that hiding the menus when you "switch appliations" was an innovation, when in fact it was a kludge to get around the fact that the system could not put a window atop a menu. And now it takes two clicks, plus you must look for the menu, to pick an item on NextStep from another program's menu. And you don't get the edge-of-screen-navigation speedup of Mac menubar so you eliminate the only plausable reason to switch appliation menus.
Anyway auto-hide toolbars really solve my complaints there. However since the "unhiding" action could also "raise" there are no layers necessary. I would like to see Windows and KDE/Gnome get rid of that stupid 1-2 pixel border, just use an invisible X11 window to pick up the mouse position and *really* hide that toolbar!
Appliation activation: I can count the number of times this would be useful to me on zero hands. I highlight from app A, raise app B, paste. No need for the window I'm pasting from to be raised when I've already gotten the data I'm copying from it.
Exactly the same problem as click-to-raise but now besides one window you have *all* the windows of app B raising to obscure the information from A you want to see. And again you make the stupid assumption that all communication can be done with cut & paste.
On the other hand, it has been useful for me to have the window associated with a dialog raised when I'm going to interact with it again.
Actually this is a serious bug because it prevents a program from having more than one "main" window. Both X11 and Windows have the idea that a dialog box has a *single* "parent" window, which is acceptable for interface reasons since usually the actions in only one window are blocked by the dialog. But Windows and KDE (not sure about Gnome) and most CDE window managers insist on raising that window when you raise the dialog. This makes overlapping main windows useless for the same reason click-raise and application-activation-raise make overlapping windows between applications useless, by hiding information you want. The result has been that virtually everybody has been forced to single "tiled" main windows or "MDI" main window containing all the subwindows, which is a huge waste of screen realestate and very confusing to the user because of the extra borders. Tiled windows are stupid, if they were a good idea we would be using the Andrew window system or Windows 3.1 and tiling *all* the windows. Unfortunately this simple bug in the window management convinces people that tiled windows are necessary.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
You are talking about Sun's version of X11, not MIT's.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
I don't really like the "wild light show" effect
This can be eliminated by the brilliant "innovation" of not highlighting windows. In my uses of point-to-type I find that I automatically assumme the mouse cursor indicates the window with focus, even in the KDE window manager where this is not true, and it has correctly highlighted the window titles. This is proof to me that window title highlighting is useless when point-to-type is in effect.
pointer warp - I'm pretty strongly against this;
It only warps the pointer when necessary so that the window with focus and the cursor position agree. This is vital so that knocking the mouse does not change the focused window and so the feedback of mouse position is correct. It would not be necessary to warp the pointer ever if the only way the focus changed windows was when the user moved the mouse. However it appears that it is much more user-friendly to set the focus to each new window as it appears, especially for pop-up dialog boxes. You also suggest that the box should appear positioned so that it is under the mouse, that would work if X did not have such delays that it can't be guaranteed, but if the user moved the mouse too much then we have to warp it anyway.
not raising windows on click or move - I bet you have a very different strategy for arranging windows.
All I want to do is copy information from "small" window B to "big" window A without A popping up and obscuring B. This is impossible on Windows, KDE, Gnome, OS/X. It is possible on older X11 machines. This is really a huge step backwards in usability. My note about X11 is that the X11R5 release notes say quite clearly that "we used to have clicks raise windows, this was determined to be stupid, so we removed it". This cannot have been any later than 1983 since it was released before I graduated from MIT (X11R6 that most people are familiar with is later). It is pretty horrifying that something that was discovered almost 20 years ago has still not gotten into the standard. And everybody stop talking about "copy & paste". I am NOT trying to copy the text literally, I may be trying to compare it, or transcribe it like changing digits to words, or any of a million other things that copy & paste cannot do!
PS I do certainly propose that you raise windows by clicking on the title bar or on any of the edges. Also watch a novice Windows user and see what they do when they want to raise the window: they click on the title! (why: because clicking on the contents may do some unwanted action) So everybody is already used to this behavior.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 4, Interesting
Why can't the open source desktop people come up with something innovative and useful instead of trying to build a cradle for all of the MS converts?
A lot of responses here seem to say "it must look like MS for people to understand it" and assumme that "innovation" means totally different, like some sort of 3D interface. This is not what is needed, and I agree with the original poster in being unhappy with Gnome/KDE's windows-copying.
Here are some ideas I would VERY much like to see:
POINT TO TYPE!!!!!! Goddamm it, make it the default. Complete novices learn it very very quickly and it makes it almost impossible to return to a click-to-type system. This is the biggest way to get Linux converts. It also does not confuse Windows users, if when a new window openes or otherwise grabs the focus, you warp the pointer to the window.
STOP RAISING WINDOWS WHEN YOU CLICK ON THEM. This is one of the biggest problems with the systems today (because both KDE and Gnome and even NT let you turn on point-to-type, even though it is not the default). This stupid behavior, which was eliminated in f**king 1982 by X11 (see X10 for the last version that did this), makes overlapping windows and the desktop metaphor completly useless because it is impossible to refer to one piece of data while working on another. Click-raising is also the reason for monstrosities like "MDI" and "paned windows", which seriously limit the ability to display large amounts of data in a window.
RESIZE AND MOVE WINDOWS WITHOUT RAISING THEM! Here is a bit of cleverness from X11 history that seems to have gotten lost. If you click a window frame without moving, it raises. But if you move or resize it, it stays where it is! This can be done even if click-raises or click-to-type is left on.
GET RID OF "LAYERS". This crap appeared with NeXTstep and refuses to go away. I WANT to put a window atop the toolbar. Just let me raise the toolbar by clicking on it. There, that wasn't too hard, was it? The only windows that should be forced to stay above others are "modal dialogs", and the ONLY thing they should do is be forced to lie above the windows they are blocking interaction to, they should have no effect on other applications.
GET RID OF "APPLIACATION ACTIVATION". There is aboslutely no reason that all windows created by a program have to stick together in a layer. PLEASE make it possible to raise a dialog without raising the underlying window, so I can copy data from another window into it!
You can try my window manager fltk for my attempts to do these ideas. It really isn't hard, in fact the window manager is much shorter than most.
This "consistent GUI" argument is introduced over and over and over and over, and a huge number of people seem to accept it as a god-given truth. But I want to question it. I want you to find an actual real "user" who really really is "confused" because the shadings on the buttons look a bit different in application A than in B.
In my experience writing cross-platform apps it is far more important for the applications to look pixel-identical across platforms, and NOT to match the "system look". I have already been ORDERED by the users of my software to not change Alt to Ctrl shortcuts, and to stop paying attention to system colors so that the colors of the GUI are the same on all platforms. And my software uses my own toolkit that certainly does not match any others, and I have never gotten a complaint that was tookit based. (the toolkit does resemble Windows a lot but is mostly used on Linux).
If "consistent look" were really necessary for understanding everything, then people would be forced to buy every appliance and car from the same manufacturer. They would be confused because the color of the tape dispenser and the phone on their desk do not match. And computer games would not work because the designers insist on coloring the buttons different to try to fit them in the theme of the game. This is utter nonsense.
I actually think that applications that look different will help users distinguish them on the computer desktop, and it would be an improvement.
Now I know a bunch of you are going to say "well by brothers wife's friend was confused once because a scrollbar jumped instead of paging". But I want real examples where people were fully unable to continue or cope because of an "inconsistent user interface".
Others are sure to point out that "athena widgets really sucked" without realizing that besides being inconsistent, the interface "sucked"!!! In fact I think every single complaint about "inconsistent" is really when comparing two things where one sucks.
I would love to see some REAL examples.
But otherwise I see this as an excuse to freeze GUI design and avoid any possibilities of progress. We will be stuck with the mess of stupid ideas from CDE and MicroSoft's additions forever because of this insane mindset.
You are talking about the wrong thing. Such an infected compiler, if told to compile the compiler, would make a new program that had the keyboard monitor in it, but the new program would not have the keyboard-monitor *INSERTING* code in it. Using the new compiler might transmit your keystrokes, but would not infect other programs.
The trick is to recognize that you are compiling the compiler and insert the *inserting* code. You can also infect other programs (and copy this infecting code when compiling the compiler) but that is trivial once you figure out this hard part.
I agree with the original poster that this is interesting in theory but impossible in practice. I would expect it to quickly fail in that either the inserted code becomes non-effective, or the resulting compiler does not work or crashes.
I had not heard of Apple buying this Emagic company and then announcing that they would discontinue their Windows version of the product, but in the special effects industry Apple made big waves by buying Nothing Real and discontinuing their Shake compositing software for Windows (and probably for Linux, though they have not said yet). The negative reaction was similar to what you describe.
Has Apple done this in any other fields? Is this a good or really stupid strategy?
I was hoping for the "kludge in AA text support for apps using the core X protocol". I expected that all the old fonts would disappear at that point and only the TrueType fonts would be accessable, and they would all advertise as scalable fonts in ISO-8859-1 encoding. I don't really see much need to make the bitmap fonts accessible.
But you are right that the Xft extension is being written (by you, I think) to emulate itself on older X servers, which is excellent (I have used this plenty in fltk btw). All new programs should use this. Is this going to be true of the other XRender extensions as well, such as the shape drawing? It would seem that it can draw an aliased and non-transparent simulation pretty well. This would be very exciting because we could ditch all the X drawing code completely.
I know some people are going to apologize, but I agree with this poster.
Though there are lots of reasons to add new interfaces, I find it inexcusable that XFree86 has not been fixed so that the old font interface draws the text anti-aliased.
Lot's of people then say "You don't understand X, it is impossible". But I do understand X. Yes, it will only work on trueColor. Yes, it probably needs to clip the antialiasing off at the edges of the glyph bounding box (I would enlarge the bounding box so this is not a problem). Yes, antialiasing will need to be turned off if they set Xor bitblt mode (I would ignore this problem, actually, nobody xor's fonts). Yes, it won't work with existing font servers. None of these are real problems.
The truth is that the innards of XFree86 are such a mess that nobody could figure out how to remove the 1-bit/pixel limitation from the pipeline between the font renderer and the screen. This is very sad and also indicates that X is very slow and bloated and that nobody will ever be able to fix it. It is also true that there is an incredible paranoia about back-compatability that must be overcome, in fact Linux's ability to ignore back-compatability somewhat is a big advantage over Windows.
I also want to point out that MicroSoft successfully updated their interface to use antialiasing, and they had all the same issues as X did. In case you forgot, originally Windows did not do antialiasing. They changed it and all the old programs started using it *without* being rewritten! The fact that X could not do this same sort of fix is far worse than the delay it has taken to get antialiasing.
I think you have a pretty good list. Almost all of them fall into the area of needing a standard location for configuring the X window manager. My comments on these:
I don't know anything about it, but it sure sounds like SDL and ADSL is the agreed on thing for games and sound. I would dearly love to see Linux do better than Windows and actually make an interface that is usable for *both* games and regular programs, but it looks like that ain't going to happen.
Single standard for the clipboard: it exists now. The problem is older programs that don't know about CLIPBOARD. There is no way to fix this. Windows would have the exact same problem if somebody decided to make drag-less drag & drop, which is really what the middle-mouse cut & paste is.
Adding/removing menu items from the Start menu. I believe there is a standard that KDE and Gnome follow. But good luck trying to find it described anywhere. There is a serious need for this to be documented in a simple and obvious way with explicit "it is in this file and here is an example", without the need for Qt or any library to read it (the library is also a fatal problem on Windows). Without this other window managers and other programs will not use it.
Mime type associations. This could also be done with more config files, but I would really like to see a more Unix solution, which is the addition of a simple "open" command-line program. Any GUI that wants to "open" a file just runs this program. It can do anything it wants. There should also be simple "mail" and "print" programs that take the data in stdin and do the right thing, it is quite annoying that Mozilla knows how to mail on my machine but the "mail" program does not. In a similar vein, I would like to see the prefixes like smb: and html: on files be handled by the glibc library level so that *ALL* programs can read/write these without linking in Qt libraries.
By "adding control panels" I think you mean adding stuff to the "configuration" application. One idea is to make a tiny extension to the Start menu, so that if you have a program lying around that "configures" something, it can appear where the user will look for it, in the list of stuff in the configuration program. It does not really matter if this opens another window. I would avoid any complexity about describing the questions or imbedding panels and other than this "run some other program" leave the design and implementation of configuration up to the programmers. Windows and Mac have fallen into the trap of making a seperate app for each part of configuration, this artificially seperates concepts into program packages, which does not necessarily agree with how users catagorize concepts.
I don't think event sounds are a big deal. Looking at Windows you can see that virtually all event sounds are specific to each application. I would consider this part of the application's configuration and as a beginning user would expect to find it there.
Display of notification icons in the desktop toolbar: here I would disagree. One thing I would like to see is the ability to change GUI ideas. If applications can assumme a toolbar it is bad news, we will never be rid of it. I think the ultimate interface will someday get rid of all things on the screen other than the data being worked on, but stupid stuff like this is what is keeping us frozen with ideas from 1985...
Registration of keyboard shortcuts is exactly the same as the "Start" menu stuff, and should be stored in the same place. One big help is that there be no difference between "applications" and "actions" so that either can be on a start menu or on a shortcut. Windows also blows in this area. "Getting back to the right program" is a window manager issue and is true whether a shortcut of a menu item or typing a command brought up the new program. Windows also screws up here, worse than most X window managers, if you have ever closed two nested modal control panels you know what I mean.
So we need a "start menu configuration" which in my opinion should be the union of a directory in your home and a system-wide directory. Each file and subdirectory describes a single "item" or a submenu. There are special names to make menu items appear in different places such as the configuration application or in the popup, or as a shortcut key. The files should be trivial to parse without using a library. It should be trivial to locate documentation describing every detail of these files without going off into unrelated areas of the desktops.
We also need command-line tools that appliations can use in place of libraries. We need "open", "mail", "print", etc. We also need a unified file interface where "http:" and other prefixes work for every program like cat and the shells.
In case you didn't notice, Patents and Copyrights are enforced by the *government*. They are not a natural effect of free markets and they are as Socialist as they come.
I was hoping somebody could come up with a better way of stating this argument. What I am trying to say is that the cost of the patent is the a major cost for a software developer. For somebody making a machine it is a minor cost compared to the cost of manufacturing the invention. This completely reverses the whole purpose of patents, in my opinion.
Re:What exactly is ITC/Afga's complaint based on?
on
Adobe Gets Hit By DMCA
·
· Score: 2
PostScript fonts contain a "do not copy" bit. Ignoring it is a DMCA violation. Of course everybody ignores it, the library I have to read the fonts does not even have a call to find out how the bit is set!
Slashdot Mirror
Basically any real solution should allow open-source players. The companies have to realize that, to a determined pirate, ALL players are open-source. Thus if their system requires closed-source to secure it, by definition the system is not secure and can be broken.
It seems like their are two solutions.
One is to encrypt each piece of data to play back only on a specific piece of hardware. Though you know how the encoders and decoders work, some variation on PK encryption is used so that knowing how to encrypt data for your player does not allow you to decrypt. Publishers would only give you the encrypted data. Attempts to write a fake player would fail because the publisher would have a database of all players that have been manufactured and would refuse to encode using keys that are not in this database. I think crypto systems can be made so that only a small "decrypt block" has to be specific to a device, it tells the hardware how to decrypt the main block of data. The obvious problems with this is that all-new hardware is needed, and that playpack is limited to one piece of hardware. However the publisher should allow a tiny or fee for additional hardware to be added, you send them the encoding you have and the old key and they reencode it for the new key. They can limit how many times this is done so it could be free.
The other much nicer solution is watermarks. Not the "don't copy" watermarks, but watermarks that do very little to the music and do not affect the operation of any devices in any way. In fact they must be absolutely as invisible as possible so there is no incentive to detect or remove them. The watermark may contain your personal identification, but this could work if it just contains the publisher's idenfication. They can then look at the net and easily detect pirated songs by looking for the watermark, and then use normal laws to go after the people doing it. How to decode the watermarks must be kept secret. It would be nice if you were still allowed to *add* watermarks but this will only work if knowing how to do this does not allow you to decode them, I'm not sure if this is possible. If you can add watermarks, adding enough of them may eventually hide the original watermark, but it should be designed so that the music deteriorates to unacceptable levels long before this happens.
Both of these schemes could be done. In my opinion both of these are really workable and legal and are fair to users. I also believe anything that does not allow open-source players is not only unfair but in fact will fail to achieve their goals. Convincing them of this fact is going to be hard, but a serious investigation of a real working scheme may do that.
It would be nice if there was software to *add* a watermark but I'm not sure if this would be possible without revealing how to remove or read the watermark. What it would do is make it so both watermarks are visible. If it is designed right you can't hide the watermark by adding thousands of new ones because the music would deteriorate to unusable long before the first watermark is hidden.
Also closed-source players have lots of other ways to track listening habits and don't need this tag for that.
Most likely they will go after Bob because they can prove he is doing something that is not allowed by copyright. You could always claim Bob broke into your house and copied your music without your permission.
Anyway if the RIAA is starting to consider sensible things like this is is a great relief. But people here should show their support by indicating they will fully support lawful prosecution of copyright violators and not act like a bunch of children, which will just make them go back to their earlier stance which is going to outlaw all non-MicroSoft systems eventually.
In fact after reading the hashcash docs, it appears that it is actually the client that picks the "question" and also calculates the "answer" at the same time. The server only checks to make sure the same question is not used more than once. So anyway there is no way for the server to know the answer ahead of time, it does not even know the question.
And certainly a lot of CD copying is not for "backup purposes" as stated here, plenty of it is for violating copyright by distributing it.
The main difference I see is what the RIAA is trying to prevent. For instance if Epson posted rips of all the latest music on their website for you to download, the RIAA has exactly the same case as the FSF against them and can certainly force them to remove it, just like Epson had to remove these drivers. However the RIAA seems committed to trying to prevent people from doing anything with the data on the disk by artificial restricions that are not enforced by copyright or any other laws. While the FSF does not care at all if you copy the source code or back it up or make secret closed-source inhouse modifications or anything else you are allowed to do by law, and only cares if you violate the copyright for real by an actual *distribution* of the code.
The only "rule" is that Epson cannot give away or sell the software without this source code. They currently took the solution of not distributing the software at all.
I expect either somebody at Epson will realize that whatever part they have is not so valuable and they can give out the source code, or they will quickly write a replacement that does not use their secret algorithim and thus does not work so well, or (most likely) whoever already granted exceptions to the GPL license on this code (it is allowed to be plugged into closed-source programs according to an earlier email) will add this as an exception as well.
I personally feel that a block of code as described could be closed-source without harming things, as long as the interface is very limited and it is clear what it does. For instance if it takes a block of pixel values read from the scanner and processed it and rewrote the block with the cleaned-up image, this is pretty clear and easily replaced. If instead it talked directly to the scanner or decoded a block of data such as encrypted stuff from the scanner, I would consider that a bad idea. Maybe it should be allowed if they also write an open-source replacement that "works" but is not as good, for instance my first example could be replaced with code that returns immediately without changing the buffer. The second example could not be replaced with anything. Maybe there is some way to make a modified GPL where such modules are allowed. It has to be worded very carefully so the closed-source parts can be replaced easily.
I don't think it can do Seti at home, because the server needs to confirm the answer, which would take just as much computation on the server. The question has to be something the server already knows the answer to.
The important thing is that I am not saying that *no* clicks raise the windows. Besides the title bar and edges, I recommend that programs raise themselves when clicked on any interior areas that do nothing. The writer of the software or toolkit could also decide that some clicks that do something should also raise the window. I think it may also make sense to raise the parent when a modal dialog box is closed, but again this can be done by the program.
The main thing to realize is that if the system raises windows on a click, it is impossible to get another behavior. While if the system does not raise windows on a click, but provides a raise_window() function, then it is trivial to get the standard behavior. This is why I am quite adamant that this is a feature we need in the GUI. It does not matter which is better, what matters is a system where both are possible.
That version of NeWS was the NeWS/X11 merge which Sun tried first. It contained all the code of the X server. The "pure" NeWS system was very short-lived, perhaps only a year, around 1986.
Basically click-to-raise makes it impossible to work with these images even at .5 zoom. We are forced to use scrollbars (actually I was forced to get rid of the scrollbars to increase the available space and use alt+drag to move the contents) reduce the windows and pan which makes it impossible to make good decisions because you cannot see the whole image. And working at .25 or smaller zoom is just bad for spotting details (ie mistakes). And this is not a problem with just multiple images, most programs have an extremely large control panel and you cannot mess with it because raising it necessarily hides the image you are working on!
Basically the problem is that you are using data that is small enough that you can tile the screen. When windows are arranged this way, there is no difference between click-raise and click-does-nothing. I'm sure you think this is sufficient but you have been forced into this point of view by the absolute necessity of tiling your data, because click-raise makes overlapping windows impossible to use.
Also I know that window edges are very narrow. This is why programs should always raise the window on clicks that don't serve any purpose. Most programs add a pretty significant border inside the window that can be used to raise it. I believe that as long as programs do this you would never miss click-raise, as there is always a very large amount of available clickable space. Also as I said the programmer can also decide that various clicks mean that the user wants the program in the foreground, ideally they should do this when the actions make it clear that the user is not copying or referring to data outside the window but instead looking at data inside the window.
I personally hate that "feature" (point to type) with a passion.
To me this means you have refused to try it.
I prefer this behaviour (clicks raise) myself.
Again I don't think you have tried a system that correctly works. And you have become too used to programs that use tiled to get around these bugs. However try MSWord and edit several documents that you want to cross-reference and you will quickly see the light. PS: it is easy for click to raise windows, the user can click on the title bar or any edges. Also any program can raise itself in response to a click, so if you are writing software and are convinced that this behavior is necessary, you can make it do it. I recommend that any clicks that don't serve any other purpose (such as clicks on the gray background of control panels) should raise the window.
Layers: Another feature I prefer. If I didn't want my toolbars permenently visable, I'd set them to hide.
Alright I'm not so adamant about that. However I don't think it is necessary as long as a click on a dead area or the edge of the toolbar raises it. What I really hated was NeXTStep that insisited on putting the menus atop *all* windows due to "layers" and then thinking that hiding the menus when you "switch appliations" was an innovation, when in fact it was a kludge to get around the fact that the system could not put a window atop a menu. And now it takes two clicks, plus you must look for the menu, to pick an item on NextStep from another program's menu. And you don't get the edge-of-screen-navigation speedup of Mac menubar so you eliminate the only plausable reason to switch appliation menus.
Anyway auto-hide toolbars really solve my complaints there. However since the "unhiding" action could also "raise" there are no layers necessary. I would like to see Windows and KDE/Gnome get rid of that stupid 1-2 pixel border, just use an invisible X11 window to pick up the mouse position and *really* hide that toolbar!
Appliation activation: I can count the number of times this would be useful to me on zero hands. I highlight from app A, raise app B, paste. No need for the window I'm pasting from to be raised when I've already gotten the data I'm copying from it.
Exactly the same problem as click-to-raise but now besides one window you have *all* the windows of app B raising to obscure the information from A you want to see. And again you make the stupid assumption that all communication can be done with cut & paste.
On the other hand, it has been useful for me to have the window associated with a dialog raised when I'm going to interact with it again.
Actually this is a serious bug because it prevents a program from having more than one "main" window. Both X11 and Windows have the idea that a dialog box has a *single* "parent" window, which is acceptable for interface reasons since usually the actions in only one window are blocked by the dialog. But Windows and KDE (not sure about Gnome) and most CDE window managers insist on raising that window when you raise the dialog. This makes overlapping main windows useless for the same reason click-raise and application-activation-raise make overlapping windows between applications useless, by hiding information you want. The result has been that virtually everybody has been forced to single "tiled" main windows or "MDI" main window containing all the subwindows, which is a huge waste of screen realestate and very confusing to the user because of the extra borders. Tiled windows are stupid, if they were a good idea we would be using the Andrew window system or Windows 3.1 and tiling *all* the windows. Unfortunately this simple bug in the window management convinces people that tiled windows are necessary.
You are talking about Sun's version of X11, not MIT's.
This can be eliminated by the brilliant "innovation" of not highlighting windows. In my uses of point-to-type I find that I automatically assumme the mouse cursor indicates the window with focus, even in the KDE window manager where this is not true, and it has correctly highlighted the window titles. This is proof to me that window title highlighting is useless when point-to-type is in effect.
pointer warp - I'm pretty strongly against this;
It only warps the pointer when necessary so that the window with focus and the cursor position agree. This is vital so that knocking the mouse does not change the focused window and so the feedback of mouse position is correct. It would not be necessary to warp the pointer ever if the only way the focus changed windows was when the user moved the mouse. However it appears that it is much more user-friendly to set the focus to each new window as it appears, especially for pop-up dialog boxes. You also suggest that the box should appear positioned so that it is under the mouse, that would work if X did not have such delays that it can't be guaranteed, but if the user moved the mouse too much then we have to warp it anyway.
not raising windows on click or move - I bet you have a very different strategy for arranging windows.
All I want to do is copy information from "small" window B to "big" window A without A popping up and obscuring B. This is impossible on Windows, KDE, Gnome, OS/X. It is possible on older X11 machines. This is really a huge step backwards in usability. My note about X11 is that the X11R5 release notes say quite clearly that "we used to have clicks raise windows, this was determined to be stupid, so we removed it". This cannot have been any later than 1983 since it was released before I graduated from MIT (X11R6 that most people are familiar with is later). It is pretty horrifying that something that was discovered almost 20 years ago has still not gotten into the standard.
And everybody stop talking about "copy & paste". I am NOT trying to copy the text literally, I may be trying to compare it, or transcribe it like changing digits to words, or any of a million other things that copy & paste cannot do!
PS I do certainly propose that you raise windows by clicking on the title bar or on any of the edges. Also watch a novice Windows user and see what they do when they want to raise the window: they click on the title! (why: because clicking on the contents may do some unwanted action) So everybody is already used to this behavior.
A lot of responses here seem to say "it must look like MS for people to understand it" and assumme that "innovation" means totally different, like some sort of 3D interface. This is not what is needed, and I agree with the original poster in being unhappy with Gnome/KDE's windows-copying.
Here are some ideas I would VERY much like to see:
POINT TO TYPE!!!!!! Goddamm it, make it the default. Complete novices learn it very very quickly and it makes it almost impossible to return to a click-to-type system. This is the biggest way to get Linux converts. It also does not confuse Windows users, if when a new window openes or otherwise grabs the focus, you warp the pointer to the window.
STOP RAISING WINDOWS WHEN YOU CLICK ON THEM. This is one of the biggest problems with the systems today (because both KDE and Gnome and even NT let you turn on point-to-type, even though it is not the default). This stupid behavior, which was eliminated in f**king 1982 by X11 (see X10 for the last version that did this), makes overlapping windows and the desktop metaphor completly useless because it is impossible to refer to one piece of data while working on another. Click-raising is also the reason for monstrosities like "MDI" and "paned windows", which seriously limit the ability to display large amounts of data in a window.
RESIZE AND MOVE WINDOWS WITHOUT RAISING THEM! Here is a bit of cleverness from X11 history that seems to have gotten lost. If you click a window frame without moving, it raises. But if you move or resize it, it stays where it is! This can be done even if click-raises or click-to-type is left on.
GET RID OF "LAYERS". This crap appeared with NeXTstep and refuses to go away. I WANT to put a window atop the toolbar. Just let me raise the toolbar by clicking on it. There, that wasn't too hard, was it? The only windows that should be forced to stay above others are "modal dialogs", and the ONLY thing they should do is be forced to lie above the windows they are blocking interaction to, they should have no effect on other applications.
GET RID OF "APPLIACATION ACTIVATION". There is aboslutely no reason that all windows created by a program have to stick together in a layer. PLEASE make it possible to raise a dialog without raising the underlying window, so I can copy data from another window into it!
You can try my window manager fltk for my attempts to do these ideas. It really isn't hard, in fact the window manager is much shorter than most.
In my experience writing cross-platform apps it is far more important for the applications to look pixel-identical across platforms, and NOT to match the "system look". I have already been ORDERED by the users of my software to not change Alt to Ctrl shortcuts, and to stop paying attention to system colors so that the colors of the GUI are the same on all platforms. And my software uses my own toolkit that certainly does not match any others, and I have never gotten a complaint that was tookit based. (the toolkit does resemble Windows a lot but is mostly used on Linux).
If "consistent look" were really necessary for understanding everything, then people would be forced to buy every appliance and car from the same manufacturer. They would be confused because the color of the tape dispenser and the phone on their desk do not match. And computer games would not work because the designers insist on coloring the buttons different to try to fit them in the theme of the game. This is utter nonsense.
I actually think that applications that look different will help users distinguish them on the computer desktop, and it would be an improvement.
Now I know a bunch of you are going to say "well by brothers wife's friend was confused once because a scrollbar jumped instead of paging". But I want real examples where people were fully unable to continue or cope because of an "inconsistent user interface".
Others are sure to point out that "athena widgets really sucked" without realizing that besides being inconsistent, the interface "sucked"!!! In fact I think every single complaint about "inconsistent" is really when comparing two things where one sucks.
I would love to see some REAL examples.
But otherwise I see this as an excuse to freeze GUI design and avoid any possibilities of progress. We will be stuck with the mess of stupid ideas from CDE and MicroSoft's additions forever because of this insane mindset.
The trick is to recognize that you are compiling the compiler and insert the *inserting* code. You can also infect other programs (and copy this infecting code when compiling the compiler) but that is trivial once you figure out this hard part.
I agree with the original poster that this is interesting in theory but impossible in practice. I would expect it to quickly fail in that either the inserted code becomes non-effective, or the resulting compiler does not work or crashes.
Unlike Windows vs OS/2 it is easy and inexpensive to use both MP3 and OGG at the same time. This is a big difference.
Has Apple done this in any other fields? Is this a good or really stupid strategy?
I was hoping for the "kludge in AA text support for apps using the core X protocol". I expected that all the old fonts would disappear at that point and only the TrueType fonts would be accessable, and they would all advertise as scalable fonts in ISO-8859-1 encoding. I don't really see much need to make the bitmap fonts accessible.
But you are right that the Xft extension is being written (by you, I think) to emulate itself on older X servers, which is excellent (I have used this plenty in fltk btw). All new programs should use this. Is this going to be true of the other XRender extensions as well, such as the shape drawing? It would seem that it can draw an aliased and non-transparent simulation pretty well. This would be very exciting because we could ditch all the X drawing code completely.
Though there are lots of reasons to add new interfaces, I find it inexcusable that XFree86 has not been fixed so that the old font interface draws the text anti-aliased.
Lot's of people then say "You don't understand X, it is impossible". But I do understand X. Yes, it will only work on trueColor. Yes, it probably needs to clip the antialiasing off at the edges of the glyph bounding box (I would enlarge the bounding box so this is not a problem). Yes, antialiasing will need to be turned off if they set Xor bitblt mode (I would ignore this problem, actually, nobody xor's fonts). Yes, it won't work with existing font servers. None of these are real problems.
The truth is that the innards of XFree86 are such a mess that nobody could figure out how to remove the 1-bit/pixel limitation from the pipeline between the font renderer and the screen. This is very sad and also indicates that X is very slow and bloated and that nobody will ever be able to fix it. It is also true that there is an incredible paranoia about back-compatability that must be overcome, in fact Linux's ability to ignore back-compatability somewhat is a big advantage over Windows.
I also want to point out that MicroSoft successfully updated their interface to use antialiasing, and they had all the same issues as X did. In case you forgot, originally Windows did not do antialiasing. They changed it and all the old programs started using it *without* being rewritten! The fact that X could not do this same sort of fix is far worse than the delay it has taken to get antialiasing.
I don't know anything about it, but it sure sounds like SDL and ADSL is the agreed on thing for games and sound. I would dearly love to see Linux do better than Windows and actually make an interface that is usable for *both* games and regular programs, but it looks like that ain't going to happen.
Single standard for the clipboard: it exists now. The problem is older programs that don't know about CLIPBOARD. There is no way to fix this. Windows would have the exact same problem if somebody decided to make drag-less drag & drop, which is really what the middle-mouse cut & paste is.
Adding/removing menu items from the Start menu. I believe there is a standard that KDE and Gnome follow. But good luck trying to find it described anywhere. There is a serious need for this to be documented in a simple and obvious way with explicit "it is in this file and here is an example", without the need for Qt or any library to read it (the library is also a fatal problem on Windows). Without this other window managers and other programs will not use it.
Mime type associations. This could also be done with more config files, but I would really like to see a more Unix solution, which is the addition of a simple "open" command-line program. Any GUI that wants to "open" a file just runs this program. It can do anything it wants. There should also be simple "mail" and "print" programs that take the data in stdin and do the right thing, it is quite annoying that Mozilla knows how to mail on my machine but the "mail" program does not. In a similar vein, I would like to see the prefixes like smb: and html: on files be handled by the glibc library level so that *ALL* programs can read/write these without linking in Qt libraries.
By "adding control panels" I think you mean adding stuff to the "configuration" application. One idea is to make a tiny extension to the Start menu, so that if you have a program lying around that "configures" something, it can appear where the user will look for it, in the list of stuff in the configuration program. It does not really matter if this opens another window. I would avoid any complexity about describing the questions or imbedding panels and other than this "run some other program" leave the design and implementation of configuration up to the programmers. Windows and Mac have fallen into the trap of making a seperate app for each part of configuration, this artificially seperates concepts into program packages, which does not necessarily agree with how users catagorize concepts.
I don't think event sounds are a big deal. Looking at Windows you can see that virtually all event sounds are specific to each application. I would consider this part of the application's configuration and as a beginning user would expect to find it there.
Display of notification icons in the desktop toolbar: here I would disagree. One thing I would like to see is the ability to change GUI ideas. If applications can assumme a toolbar it is bad news, we will never be rid of it. I think the ultimate interface will someday get rid of all things on the screen other than the data being worked on, but stupid stuff like this is what is keeping us frozen with ideas from 1985...
Registration of keyboard shortcuts is exactly the same as the "Start" menu stuff, and should be stored in the same place. One big help is that there be no difference between "applications" and "actions" so that either can be on a start menu or on a shortcut. Windows also blows in this area. "Getting back to the right program" is a window manager issue and is true whether a shortcut of a menu item or typing a command brought up the new program. Windows also screws up here, worse than most X window managers, if you have ever closed two nested modal control panels you know what I mean.
So we need a "start menu configuration" which in my opinion should be the union of a directory in your home and a system-wide directory. Each file and subdirectory describes a single "item" or a submenu. There are special names to make menu items appear in different places such as the configuration application or in the popup, or as a shortcut key. The files should be trivial to parse without using a library. It should be trivial to locate documentation describing every detail of these files without going off into unrelated areas of the desktops.
We also need command-line tools that appliations can use in place of libraries. We need "open", "mail", "print", etc. We also need a unified file interface where "http:" and other prefixes work for every program like cat and the shells.
In case you didn't notice, Patents and Copyrights are enforced by the *government*. They are not a natural effect of free markets and they are as Socialist as they come.
I was hoping somebody could come up with a better way of stating this argument. What I am trying to say is that the cost of the patent is the a major cost for a software developer. For somebody making a machine it is a minor cost compared to the cost of manufacturing the invention. This completely reverses the whole purpose of patents, in my opinion.
PostScript fonts contain a "do not copy" bit. Ignoring it is a DMCA violation. Of course everybody ignores it, the library I have to read the fonts does not even have a call to find out how the bit is set!