Having read some more, I believe this hack does not allow anything other than 8-bit data to be used. The reason is that the actual pixels are still stored in the "old" gimp format, and GEGL is reading from this image. Anything not using the GEGL api actually will bypass this and directly interact with the gimp-storage, so it can't change.
However this is not a complete loss. With this change it is now physically possible to change *some* of the calls to GEGL. This is much better than having to change *all* the calls at once. The hope is that with this incremental ability, it gives a path to having *all* the calls replaced, by doing a few at a time. At that moment they can scrap the Gimp storage format and use what GEGL wants, which will allow data other than 8 bits.
Conversely I am suspicious that even if all the calls are changed to GEGL, that the calling code will not make assumptions that the data is 8 bit, since currently they cannot try any format other than 8 bit. I don't know how GEGL's api is designed, it may be abstract enough that code cannot actually make such assumptions?
Use of CMYK inks does not mean that RGB images cannot be printed. I think you will find that a vast amount of those images you are thinking about were never anything other than RGB before they were converted by a printer driver to CMYK.
CMYK is vaguely useful for exact control of a known output device. It is useless if you plan to print on more than one type of printer, or if your printer does not accept raw control of the CMYK guns (most every non-professional device will not print raw CMYK, doing things like turning on the black 100% will turn the others off). Modern software has floating point so mismatched gamuts are no longer a problem.
Extra points for complainers who believe the word "gimp" was first used in the movie Pulp Fiction and the use in that movie defines what the word means.
It would be funny if it was not such a sad comment on the intelligence level here.
It has not been solved. 16-bit integers are not the answer because you lose resolution when you multiply brightness levels. 16-bit integers are actually a huge impediment to doing things correctly but they were forced on us by people who did not know better, and for machines that were not as fast as current ones they did offer a bit of benefit.
The correct method is to use *floats*, and ideally a linear colorspace. There is even a 16-bit float so it takes no more memory than 16-bit integers. When you multiply a float by 2 you still have the same number of levels between the darkest and brightest visible colors.
I have no idea what GEGL does but I suspect it gets it wrong still...
I think you will find that unless you install Xlib and glx and Qt and a bunch of other libraries, your headless server will not run that remote display.
It certainly would be nice if a wayland client would look at an environment variable and set up a remote connection to a wayland server without having to pre-run any software on the client end. But considering this is *exactly* what Xlib clients do, I don't see this as being impossible to solve.
In Wayland the client draws the window borders (and before you blurt out "but they will be different from each other and 'confuse the user'" be aware that nothing on X makes anything other than the window borders draw identically, but somehow there are all these applications where they draw their own scrollbars and buttons and text editors and they all look alike and fail to "confuse the user".)
X ICCCM window management was invented before there were shared libraries, so now there is a huge messy complex api built on top of the limited atom+value and signalling that existed in X11. Having written a toolkit (fltk) I can confirm that talking to the window manager literally takes 10 to 20 times as much code as if I drew the window borders myself. And we still have horrific problems where various window managers disagree on whether a window should vanish when the app loses focus and how "stay on top" should work, and we can't put the most trivial buttons or items in the window pulldown menu, something Windows allows and is making it increasingly difficult to port applications from Windows.
Wayland wisely has decided to scrap this mess by having the clients draw the borders.
Emulating X is trivial if you just work with the windows the X client knows about and repliate them on Wayland. The problem is that all that ICCCM stuff will need to be interpreted by something and draw window borders as well. It is not clear if this should be done by a local "act like xlib" library, or by a fake X server, or by an actual X11 window manager running on the fake X server. That's why window management is currently a "hack" because this has not been decided.
Nor does it support modern stuff like drag-and-drop
Actually DnD support was added and works quite well. Much better than the cut & paste because they scrapped a lot of stupid complexity that nobody uses.
and cut-and-paste has always been inconsistent (highlight-middle-click not being the same as the desktop or application's cut-and-paste buffer)
Actually this is a requirement so that selecting text should not interfere with the most recent cut or copy command. But what X gets wrong is failing to unify this selection with DnD. In fact a design goal should be that middle-click does the same action as dragging the selection and dropping it at the point the middle-click was done. The original X clipboard design was actually equivalent to DnD, not cut & paste, but too many intermediate users and developers failed to realize this and made the current mess which is only now being cleaned up.
I believe Wayland is a chance to fix this. Last I looked they have only worked on DnD and there is no clipboard support yet. It would be good to point out that selection + middle click should be unified with the DnD, not the clipboard.
No, wayland uses a socket to communicate between the client and the compositor. It is not function calls. Many calls to the client library can be (and are) consolidated into a single block message sent to the compositor. Wayland was designed for this, by avoiding return values from the calls, so they can be asynchronous (this is where Windows fails badly, and Xlib (though not X itself) also did in many cases, because they failed to realize that some calls they thought would be rarely used and thus ok to stick a return value on are used extensively).
I suspect that if you turn an amplifier up a lot you will also get distortion, which is what the OP is probably trying to say. But bands could easily avoid this, they would spend more money on more expensive amplifiers (such as made by Marshall) and thus get the desired loudness with less distortion.
For the CD "loudness wars" it is too late. You can't improve the result by buying a more expensive CD player. That is a big difference.
I apologize for not realizing the gp post was a joke.
I really thought he was saying that average Italians get some advantage of expensive Italian sports cars being designed in Italy, and that this shows how average Americans are better off due to the expensive health care here. I believe now he was joking in order to show the exact opposite.
all Italians start buying the hand-me-downs of what used to be the best cars in the world
Fail. Obviously you have never been on a road in Italy or you would know this is absolutely false.
Re:Engineers. They love to change things.
on
GNOME 3.4 Released
·
· Score: 1
I agree that is really stupid. Since you can double-click on the App in the folder and run it, Gnome obviously has all the information necessary to make it run from the dock. Just create the.desktop file with a pointer to the app and the same Icon the file browser is showing and it is done. This should be automatic.
There is 624/625 chance of it being reduced close to 0. There is a 1/625 chance of it being increased close to 1. Therefore "more observations will probably reduce the odds of impact to close to 0" is a perfectly correct statement.
Running your car inside a closed bar or restaurant is illegal. Your attempt to claim there is a double standard is incorrect.
Re:Let's rename Gnome -- how bout GnOSXme?
on
GNOME 3.4 Preview
·
· Score: 1
Interesting, I did not know that and use macs all the time, so it is apparently non-discoverable.
Does it act like a plain click, or like Command+click? In either case some set of possible actions are not possible.
I still feel that clicks should only raise the window if they otherwise serve no purpose (ie clicking the title bar or blank areas in the window). This would be easily discoverable, easy to use, and would not prevent any kind of interaction with a non-raised window.
Re:Let's rename Gnome -- how bout GnOSXme?
on
GNOME 3.4 Preview
·
· Score: 1
I believe the global menu bar can be made to work with point-to-type (what you call "sloppy focus"). The answer is to not switch the menubar except when an application is "activated", which involves mouse clicks that raise the windows (as well as a few other actions). Just pointing the mouse at a window moves the keyboard focus there and lets you type, but does not "activate" the application. Shortcuts I think should still go to the pointed-at window (so you can ctrl+c copy selected text).
More of a killer in Gnome-land is their inability to realize that they have screwed up point-to-type with their insistence on raising windows on click. This is WRONG. There is absolutely no argument for automatic raising windows on click, because an application that wants that can raise *itself* on click, therefore there is NO UI CHANGES!!!!!! However drag&drop will work, and the user can select text to paste into the foreground application.
Gnome has got to realize this and fix it. Removal of unavoidable raise-on-click I think will be *the* killer feature of Linux that will make the desktop much much more usable than Windows and OS/X. It worked this way 20 years ago in original X11 window managers and it was amazingly easy to use overlapping windows! Nowadays nobody uses overlapping windows because they are useless, since you cannot interact with the rear windows.
Actually a technique that works is not to encrypt large blocks.
Instead it is made fairly easy to patch out the check, and the software *appears* to work.
But then you sprinkle all through the code, with obfuscation as much as possible, *other* calls to decrypt information. If the wrong answer is returned, the software fails in subtle ways. It has to be non-obvious so the cracker does not see it right away. Even better you can just *claim* this was done, or claim far more hacks than really exist. The users will be nervous that their cracked copy is going to screw up just when they need it working...
I believe sophisticated crackers can detect all of this but the hope is that the p2p will be flooded with bad cracked versions, and the users cannot easily distinguish a good crack from a bad one. From what I have heard, you have to be fairly careful to make removal of the "main" DRM just hard enough. Too easy and they know it is a setup. Too hard and they will do enough work to find all the other breakage.
Finally somebody here who has some clue as to how this industry (FX and video production) works.
Yes, distribute a "demo" version that puts a watermark (visible text) over the output image. This lets people actually try your software and figure out what it does. Do NOT try to make it "phone home", you will be crucified if that is detected. Don't worry about people hacking out the watermark, as it is likely to be easier to hack out any DRM from the "real" version.
Do not use any DRM other than FlexLM with site licenses. The companies that may want your software need to have support to be trivial. They know how to deal with FlexLM even if it is ugly. Any other steps to "install" your software will kill any chances of your software being used.
Yes FlexLM is *trivial* for people to break. Too F***G bad, boo-hoo, you want the physically impossible. It will serve the purpose of keeping already-honest people honest. And it does prevent the *artists* (who don't have full root access) from breaking it to get extra copies for the render farm.
Do NOT make the DRM hard to remove. In fact if you don't see a cracked version, put one out on purpose (if you are really clever, make it crash occasionally or somehow screw up just enough to be mildly annoying). You have to face the fact that artists using cracked copies on their home computers is how people learn your software, and those artists are the ones who will tell the company they work for that they "need" this software, and that is how you make a sale.
Also to all the naysaysers, $10,000 per copy is not at all out of the question. Typically there are vast volume discounts to encourage customers to buy one copy for every desktop, or trades for other software, but none of that will work unless the initial price is set really high. I really do not think the price makes any difference to how much people crack the software. They are equally motivated whether it costs $1 or $10000.
You can sic the BSA on companies that are found to be running cracked copies for commercial purposes. But there is no need, what works is that the artists will know they are running cracked copies and this information will be leaked, and they will get bad publicity. You will have to accept the fact that this does not work for companies in China.
These are not hidden watermarks. These are blatently obvious text printed over the output image. You cannot remove them without generating the part of the image they obscure, which should require recreating the program itself. The purpose is so the output images are useless but still show what the software does, it is not to track users.
It would help if high-modded replies effectively forced the text being replied to to be shown.
So a well-worded reply to something I disagree with that gets modded up would also mod up the text being responded to.
Seems it would do a few things:
First it would fix the "mystery" high-modded replies by letting us see the replied-to text
It would fix Slashdot's broken reply-to system where the replies look like they are for unrelated articles.
It would (I hope) discourage people from responding to trolls.
If somebody with an opposing viewpoint makes a well-enough worded text that it is refuted by another text that is modded up, readers can see both opinions. If the original is factually wrong they will see the refutation.
Slashdot Mirror
Are you saying non-organic farmers inject their produce with preservatives?
They don't. In fact the product (for plants) is pretty much the same for both, something pointing out endlessly by anti-organic debaters.
Having read some more, I believe this hack does not allow anything other than 8-bit data to be used. The reason is that the actual pixels are still stored in the "old" gimp format, and GEGL is reading from this image. Anything not using the GEGL api actually will bypass this and directly interact with the gimp-storage, so it can't change.
However this is not a complete loss. With this change it is now physically possible to change *some* of the calls to GEGL. This is much better than having to change *all* the calls at once. The hope is that with this incremental ability, it gives a path to having *all* the calls replaced, by doing a few at a time. At that moment they can scrap the Gimp storage format and use what GEGL wants, which will allow data other than 8 bits.
Conversely I am suspicious that even if all the calls are changed to GEGL, that the calling code will not make assumptions that the data is 8 bit, since currently they cannot try any format other than 8 bit. I don't know how GEGL's api is designed, it may be abstract enough that code cannot actually make such assumptions?
It is absolutely amazing that there is a Slashdot poster who actually knows that "gimp" means "disabled".
There seems to be an incredible number of people who think the word was invented by the film "Pulp Fiction". Pretty depressing, actually.
Use of CMYK inks does not mean that RGB images cannot be printed. I think you will find that a vast amount of those images you are thinking about were never anything other than RGB before they were converted by a printer driver to CMYK.
CMYK is vaguely useful for exact control of a known output device. It is useless if you plan to print on more than one type of printer, or if your printer does not accept raw control of the CMYK guns (most every non-professional device will not print raw CMYK, doing things like turning on the black 100% will turn the others off). Modern software has floating point so mismatched gamuts are no longer a problem.
Extra points for complainers who believe the word "gimp" was first used in the movie Pulp Fiction and the use in that movie defines what the word means.
It would be funny if it was not such a sad comment on the intelligence level here.
It has not been solved. 16-bit integers are not the answer because you lose resolution when you multiply brightness levels. 16-bit integers are actually a huge impediment to doing things correctly but they were forced on us by people who did not know better, and for machines that were not as fast as current ones they did offer a bit of benefit.
The correct method is to use *floats*, and ideally a linear colorspace. There is even a 16-bit float so it takes no more memory than 16-bit integers. When you multiply a float by 2 you still have the same number of levels between the darkest and brightest visible colors.
I have no idea what GEGL does but I suspect it gets it wrong still...
I think you will find that unless you install Xlib and glx and Qt and a bunch of other libraries, your headless server will not run that remote display.
It certainly would be nice if a wayland client would look at an environment variable and set up a remote connection to a wayland server without having to pre-run any software on the client end. But considering this is *exactly* what Xlib clients do, I don't see this as being impossible to solve.
In Wayland the client draws the window borders (and before you blurt out "but they will be different from each other and 'confuse the user'" be aware that nothing on X makes anything other than the window borders draw identically, but somehow there are all these applications where they draw their own scrollbars and buttons and text editors and they all look alike and fail to "confuse the user".)
X ICCCM window management was invented before there were shared libraries, so now there is a huge messy complex api built on top of the limited atom+value and signalling that existed in X11. Having written a toolkit (fltk) I can confirm that talking to the window manager literally takes 10 to 20 times as much code as if I drew the window borders myself. And we still have horrific problems where various window managers disagree on whether a window should vanish when the app loses focus and how "stay on top" should work, and we can't put the most trivial buttons or items in the window pulldown menu, something Windows allows and is making it increasingly difficult to port applications from Windows.
Wayland wisely has decided to scrap this mess by having the clients draw the borders.
Emulating X is trivial if you just work with the windows the X client knows about and repliate them on Wayland. The problem is that all that ICCCM stuff will need to be interpreted by something and draw window borders as well. It is not clear if this should be done by a local "act like xlib" library, or by a fake X server, or by an actual X11 window manager running on the fake X server. That's why window management is currently a "hack" because this has not been decided.
Nor does it support modern stuff like drag-and-drop
Actually DnD support was added and works quite well. Much better than the cut & paste because they scrapped a lot of stupid complexity that nobody uses.
and cut-and-paste has always been inconsistent (highlight-middle-click not being the same as the desktop or application's cut-and-paste buffer)
Actually this is a requirement so that selecting text should not interfere with the most recent cut or copy command. But what X gets wrong is failing to unify this selection with DnD. In fact a design goal should be that middle-click does the same action as dragging the selection and dropping it at the point the middle-click was done. The original X clipboard design was actually equivalent to DnD, not cut & paste, but too many intermediate users and developers failed to realize this and made the current mess which is only now being cleaned up.
I believe Wayland is a chance to fix this. Last I looked they have only worked on DnD and there is no clipboard support yet. It would be good to point out that selection + middle click should be unified with the DnD, not the clipboard.
No, wayland uses a socket to communicate between the client and the compositor. It is not function calls. Many calls to the client library can be (and are) consolidated into a single block message sent to the compositor. Wayland was designed for this, by avoiding return values from the calls, so they can be asynchronous (this is where Windows fails badly, and Xlib (though not X itself) also did in many cases, because they failed to realize that some calls they thought would be rarely used and thus ok to stick a return value on are used extensively).
I suspect that if you turn an amplifier up a lot you will also get distortion, which is what the OP is probably trying to say. But bands could easily avoid this, they would spend more money on more expensive amplifiers (such as made by Marshall) and thus get the desired loudness with less distortion.
For the CD "loudness wars" it is too late. You can't improve the result by buying a more expensive CD player. That is a big difference.
I apologize for not realizing the gp post was a joke.
I really thought he was saying that average Italians get some advantage of expensive Italian sports cars being designed in Italy, and that this shows how average Americans are better off due to the expensive health care here. I believe now he was joking in order to show the exact opposite.
all Italians start buying the hand-me-downs of what used to be the best cars in the world
Fail. Obviously you have never been on a road in Italy or you would know this is absolutely false.
I agree that is really stupid. Since you can double-click on the App in the folder and run it, Gnome obviously has all the information necessary to make it run from the dock. Just create the .desktop file with a pointer to the app and the same Icon the file browser is showing and it is done. This should be automatic.
A population reduction - are you volunteering?
A large part of the Slashdot readership is doing exactly what is necessary for population reduction. Some of them even voluntarily.
No, it means there is a greater chance that more observations will reduce the probability to 0 than they will raise the probability toward 1.
There is still a 1/625 chance that a future observation will show that the asteroid is *more* likely to hit the earth.
There is 624/625 chance of it being reduced close to 0. There is a 1/625 chance of it being increased close to 1. Therefore "more observations will probably reduce the odds of impact to close to 0" is a perfectly correct statement.
Running your car inside a closed bar or restaurant is illegal. Your attempt to claim there is a double standard is incorrect.
Interesting, I did not know that and use macs all the time, so it is apparently non-discoverable.
Does it act like a plain click, or like Command+click? In either case some set of possible actions are not possible.
I still feel that clicks should only raise the window if they otherwise serve no purpose (ie clicking the title bar or blank areas in the window). This would be easily discoverable, easy to use, and would not prevent any kind of interaction with a non-raised window.
I believe the global menu bar can be made to work with point-to-type (what you call "sloppy focus"). The answer is to not switch the menubar except when an application is "activated", which involves mouse clicks that raise the windows (as well as a few other actions). Just pointing the mouse at a window moves the keyboard focus there and lets you type, but does not "activate" the application. Shortcuts I think should still go to the pointed-at window (so you can ctrl+c copy selected text).
More of a killer in Gnome-land is their inability to realize that they have screwed up point-to-type with their insistence on raising windows on click. This is WRONG. There is absolutely no argument for automatic raising windows on click, because an application that wants that can raise *itself* on click, therefore there is NO UI CHANGES!!!!!! However drag&drop will work, and the user can select text to paste into the foreground application.
Gnome has got to realize this and fix it. Removal of unavoidable raise-on-click I think will be *the* killer feature of Linux that will make the desktop much much more usable than Windows and OS/X. It worked this way 20 years ago in original X11 window managers and it was amazingly easy to use overlapping windows! Nowadays nobody uses overlapping windows because they are useless, since you cannot interact with the rear windows.
Is this a Meta-Whoosh?
You seem to have missed the fact that both the original poster and the responder are making jokes, which is a pretty amazing whoosh!
Actually a technique that works is not to encrypt large blocks.
Instead it is made fairly easy to patch out the check, and the software *appears* to work.
But then you sprinkle all through the code, with obfuscation as much as possible, *other* calls to decrypt information. If the wrong answer is returned, the software fails in subtle ways. It has to be non-obvious so the cracker does not see it right away. Even better you can just *claim* this was done, or claim far more hacks than really exist. The users will be nervous that their cracked copy is going to screw up just when they need it working...
I believe sophisticated crackers can detect all of this but the hope is that the p2p will be flooded with bad cracked versions, and the users cannot easily distinguish a good crack from a bad one. From what I have heard, you have to be fairly careful to make removal of the "main" DRM just hard enough. Too easy and they know it is a setup. Too hard and they will do enough work to find all the other breakage.
Finally somebody here who has some clue as to how this industry (FX and video production) works.
Yes, distribute a "demo" version that puts a watermark (visible text) over the output image. This lets people actually try your software and figure out what it does. Do NOT try to make it "phone home", you will be crucified if that is detected. Don't worry about people hacking out the watermark, as it is likely to be easier to hack out any DRM from the "real" version.
Do not use any DRM other than FlexLM with site licenses. The companies that may want your software need to have support to be trivial. They know how to deal with FlexLM even if it is ugly. Any other steps to "install" your software will kill any chances of your software being used.
Yes FlexLM is *trivial* for people to break. Too F***G bad, boo-hoo, you want the physically impossible. It will serve the purpose of keeping already-honest people honest. And it does prevent the *artists* (who don't have full root access) from breaking it to get extra copies for the render farm.
Do NOT make the DRM hard to remove. In fact if you don't see a cracked version, put one out on purpose (if you are really clever, make it crash occasionally or somehow screw up just enough to be mildly annoying). You have to face the fact that artists using cracked copies on their home computers is how people learn your software, and those artists are the ones who will tell the company they work for that they "need" this software, and that is how you make a sale.
Also to all the naysaysers, $10,000 per copy is not at all out of the question. Typically there are vast volume discounts to encourage customers to buy one copy for every desktop, or trades for other software, but none of that will work unless the initial price is set really high. I really do not think the price makes any difference to how much people crack the software. They are equally motivated whether it costs $1 or $10000.
You can sic the BSA on companies that are found to be running cracked copies for commercial purposes. But there is no need, what works is that the artists will know they are running cracked copies and this information will be leaked, and they will get bad publicity. You will have to accept the fact that this does not work for companies in China.
These are not hidden watermarks. These are blatently obvious text printed over the output image. You cannot remove them without generating the part of the image they obscure, which should require recreating the program itself. The purpose is so the output images are useless but still show what the software does, it is not to track users.
It would help if high-modded replies effectively forced the text being replied to to be shown.
So a well-worded reply to something I disagree with that gets modded up would also mod up the text being responded to.
Seems it would do a few things:
First it would fix the "mystery" high-modded replies by letting us see the replied-to text
It would fix Slashdot's broken reply-to system where the replies look like they are for unrelated articles.
It would (I hope) discourage people from responding to trolls.
If somebody with an opposing viewpoint makes a well-enough worded text that it is refuted by another text that is modded up, readers can see both opinions. If the original is factually wrong they will see the refutation.