One of the articles says the "domes" were already constructed and used to cap shallow-water wells that were broken during Katrina. So they already existed and the engineers already knew what shape they were. "Dome" is just a convienent way of describing it, in particular it makes it clear that the bottom is open.
Actually it really is a siphon. Oil is lighter than water and therefore a pan only a bit below the surface of the ocean is "lower" than the interior of an oil-filled container under water pressure at the bottom. The oil will flow up, through a tube over the edge of a ship, and into a container below sea level. Also I suspect all the pressure of the well is going to help too.
Content-aware fill has been around in this form for 10 years or more. Early versions were being used to paint out wires in film 17 years ago (I know because I worked with people writing the software).
The fact that there is a GIMP plugin to do this is absolutely no surprise. I also expect there are dozens of Photoshop plugins that do this as well, some of which predate the GIMP plugin by many years.
The fact that Adobe felt that it was useful enough to stick in the base program is mildly interesting. But they could have done this 10 years ago. The rest is hype, and now some GIMP people are trying to jump on that same hype bandwagon.
Your original image has some very odd small rectangular artifacts, seeming the result of some bad previous scale-up or maybe bad jpeg compression. This seems to be the only unique thing about it. It is also really high contrast.
Still I don't see how that could cause Gimp to do any different than any other program. It is using absolutely standard cubic filtering to do the downrez.
May help if you posted your Gimp scaled result and a result that you agree with. Also make sure the scale is exactly the same in both pictures.
As others have suggested you may have accidentally selected the sync or other sharpening filter.
Damn right, people are completely unaware of exactly what increasing the number of bits in a fixed-point format will do. They are assigning magical properties to it. It does nothing except make the problems a bit smaller and harder to see, possibly hiding them until it is too late and they bite you.
If you are using 16 bits on modern processors you should be using half floats, representing the linear value of the color (ie double the value makes the image twice as bright or doubles the exposure). Using integers means you are living in the past, floating point has been faster than integers on modern CPUs for 10 years or more now, and hardware support for half floats is on most GPUs now and will probably appear in CPUs very soon.
I have no idea what GECL (sp?) does but I do hope they have seen the light and support half and full float data as linear.
8 bits encoded as sRGB is a nice compression format and there is nothing wrong with supporting that. But taking this flawed format and pretending that wasting more memory on it will "fix" it is stupid and shows that you have not studied the problem at all. But photo professionals have proven to be stupid over and over again, just look at them regugitating the same junk right here, whether they want to insult Gimp or Photoshop.
If you think 12 bit will give you HDR then you are not aware of how things work.
What 12 bits gives you is 4096 levels between 0 and 1 instead of 256. Okay, you can instead claim the '1' is not '1' but instead '4' or some larger value. That kind of gives you a bit of HDR, though it is making the shadow end an awful lot worse. Also the programs are going to be very screwed up in deciding the meaning of gamma. If you try to make 12 bits linear then your shadows are going to be TERRIBLE, actually worse that 8-bit sRGB.
You need a floating point format, such as 16-bit float. Trying to increase integer formats past 8 bits is a big waste of time, in many ways Gimp is probably better off that they never got this working, they can instead use 16 bits for floating point the way it should be done.
I agree with several other posters that I do not see what shape you traced there. It looks like you traced the shadow of the clouds mostly, and some effects of the silt from the Mississippi.
The spill is quite huge without you exaggerating it.
It is safe to compare to any small integer, not just zero, as long as you are checking if the the value came from an assignment. It is also safe to use small negative powers of two.
One big problem I have is with programmers who religiously add these epsilon functions and screw up algorithms. In my experience, about 99% of the == statements with floating point are explicitly testing "did the assignment to the same value earlier get executed?" Comparing the bit patterns is exactly what is wanted, stop messing it up!
No, I don't feel you can choose any song. You could make up a flimsy excuse as to how it is "appropriate satire" and then you could ignore copyright on any song for any video. I guess you are saying that all Rolling Stones songs are fair game because Microsoft used one, but it just does not seem right. If perhaps Microsoft made a whole series of ads with different Rolling Stones songs, then maybe you could make a parody that used another Rolling Stones song they did not use, as it would be more clearly a parody of the "Rolling Stones Songs Ad Series". But not a single one.
After reading a bit more about this I suprised myself by changing my mind. My first knee-jerk reaction was that the videos were ok because they were parodys/satire.
But basically if this was allowed, you could use any music for any video you make whatsoever, and claim it is a satire/parody. Maybe you are required to insert at least one insult, about a random subject, into the video, so it is a "satire or parody". This would completely defeat copyright and certainly is not a good idea.
However that if Boxer had officially used one of these songs in their own videos (after paying for the rights, as required), somebody parodying the Boxer ad can use a parody version of that same song. I believe this was done by conservatives on some Obama attacks. More to the point here, a joke video about Windows using a Rolling Stones "start it up" parody would be allowed, since that was part of the Windows advertisement, but use of a different Rolling Stones song that Microsoft did not use is not allowed.
I think a far more common exploit would be to place a copy of a structure the kernel expects to reference at 0 and trigger some bug so it uses a null pointer to such a structure. If that structure contains a pointer to a function that the kernel calls you put the pointer to your code there. Probably more likely the structure just contains a pointer to some location the kernel will write, you change this to point at something in the kernel you want to overwrite, and also work on getting the kernel to write exactly the data you want. After it does that you have patched the kernel to do your bidding.
One thing I think is very misleading is that the title should be changed to read "use of a NULL pointer *BY THE KERNEL* can be exploited". To the casual observer this sounds like NULL pointers in user programs are dangerous.
Just want to point out that #define is NOT the main reason you "have to look in.h files every 3 seconds" in many languages. Certainly I have often had to look up plenty of perfectly legal non-preprocessor code in.h files in order to figure out an API. Especially tracking down "what the hell is this type really" in C/C++.
That was very interesting, and it points out mathematical problems with approval voting which I was unaware of. I thought it was actually pretty good. However apparently IRV is even worse as well as having the technical problem of having to remember the exact contents of every ballot, rather than just some totals. I think it would be safe to go to a real concordant (sp?) system and let people rank their preferences.
We were not using MFC or anything, and I agree I can't see how anything in windows.h would be a problem (a for loop would have to be a macro and we could then avoid calling that macro most likely).
We certainly stayed with this behavior until long after they had added the switch to the compiler, some of that may have been intertia and an unwillingness to modify the rather complex and error-prone makefiles. I do remember it being the primary problem when we tried to port software from Linux to Windows and that in a few cases the hurried editing to fix it would break, mostly by hiding a parameter with a local variable with the same name.
1. Make it possible to hide the taskbar/panel/whatever. In every version of Gnome for years now the best you could do is make it hide to 1 pixel tall, and this requires gconf. The default "hide" is an incredibly stupid looking thick 6 pixels. PS: KDE has had this working for about 10 years now, so you can't claim it is some technical defect in X or some other excuse.
2. Fix the setting so that clicking in windows does not raise them. Apparently this configuration option causes it to ignore ALL attempts to raise the window, including the program itself calling XRaiseWindow()! This is completely broken. What we want the configuration option to do is stop clicks inside the window from raising it, NOTHING ELSE!!!
Of course I am wondering if they are purposely leaving these things broken so that they can later claim "nobody uses those options so we will remove them".
Before that, you could control it with a switch, though default was non-standards compliant, and MFC headers wouldn't compile if you turned it on - which shouldn't really concern you if you're compiling portable code, right?
I have to strongly object to this phony argument. Too bad because most of your posts are quite good!
You seem to think "portable" means "it does not contain any calls that don't work on both platforms". This is an artificial description purposely designed so that "portable" is equivalent to "useless", which does sound like typical Microsoft word twisting.
Note that "xxxxx" will certainly require the windows.h header file to be included!
This is no joke, for many years I had to keep fixing for loops because they would not compile on Windows. In most cases this was by far the most likely reason the code would fail to compile. So I think your attempt to defend Microsoft's old behavior is rather dubious.
The problem is that for many people, there are two big parties, one they HATE, and the other which they just feel is incompetent or they only disagree with on a few points. Voting for a third party may mean they have thrown away their ability to try to stop the party they HATE from getting office.
I think this is cutting the voting for third parties by a far greater factor than people deciding not to vote.
What is needed is approval voting. Then you could vote for both the third parties you like and for the less-hideous of the main parties.
I (and I assume a lot of other programmers) use an editor with auto indentation so this is almost impossible to edit. What I usually do is surround the temporary code with "#if 1" and "#endif" which can be left at the left margin.
I do admit that Python, though much more readable, is a bit harder to write. I use auto-indentation for both.
It is true that the normal POSIX api does not have async methods. I am unsure if Linux offers any. However on both Linux and Windows you nowadays get better performance by using multiple threads and having one of them do the synchronous calls.
Also that gun in your home always defeats the gun the perp has. It has something to do with ballistics, somehow the bullets can only fly away from your bedstand.
It would be really nice if they could figure out how to hide the task bar so it takes ZERO pixels. In every version for years "hide" has meant a huge 6 pixel grey border, which you can at best reduce to 1 pixel by using gconf. Since KDE has been doing this for years you can't blame some X defect for this.
Also they need to fix damn click to raise. I want to turn it off, but those idiots doing the window manager somehow wrote this option so it ignores the *programs* attempt to raise the windows. This is USELESS and breaks lots of software that assumes that raising and mapping a window will make it visible. Comon, get your f**king act together and fix this!
It certainly does send to Google first, it would not work if it had to wait for a web server to say that a page does not exist or for DNS to say a site does not exist.
An easy fix would be for it to stop sending data once there is a single or no matches for what is typed already. It might also make sense to not send any data if what has been typed matches something in a local history. Both of these would make it better than IE because far too many users type URLs into IE's search box.
I seem to remember Larry Niven saying in response to "will somebody ever make a Ringworld movie?" something like "I hope not. Right now I get a big payment every time one studio sells the rights to another, and that would stop if the movie ever got made".
Slashdot Mirror
One of the articles says the "domes" were already constructed and used to cap shallow-water wells that were broken during Katrina. So they already existed and the engineers already knew what shape they were. "Dome" is just a convienent way of describing it, in particular it makes it clear that the bottom is open.
Actually it really is a siphon. Oil is lighter than water and therefore a pan only a bit below the surface of the ocean is "lower" than the interior of an oil-filled container under water pressure at the bottom. The oil will flow up, through a tube over the edge of a ship, and into a container below sea level. Also I suspect all the pressure of the well is going to help too.
Content-aware fill has been around in this form for 10 years or more. Early versions were being used to paint out wires in film 17 years ago (I know because I worked with people writing the software).
The fact that there is a GIMP plugin to do this is absolutely no surprise. I also expect there are dozens of Photoshop plugins that do this as well, some of which predate the GIMP plugin by many years.
The fact that Adobe felt that it was useful enough to stick in the base program is mildly interesting. But they could have done this 10 years ago. The rest is hype, and now some GIMP people are trying to jump on that same hype bandwagon.
Your original image has some very odd small rectangular artifacts, seeming the result of some bad previous scale-up or maybe bad jpeg compression. This seems to be the only unique thing about it. It is also really high contrast.
Still I don't see how that could cause Gimp to do any different than any other program. It is using absolutely standard cubic filtering to do the downrez.
May help if you posted your Gimp scaled result and a result that you agree with. Also make sure the scale is exactly the same in both pictures.
As others have suggested you may have accidentally selected the sync or other sharpening filter.
Damn right, people are completely unaware of exactly what increasing the number of bits in a fixed-point format will do. They are assigning magical properties to it. It does nothing except make the problems a bit smaller and harder to see, possibly hiding them until it is too late and they bite you.
If you are using 16 bits on modern processors you should be using half floats, representing the linear value of the color (ie double the value makes the image twice as bright or doubles the exposure). Using integers means you are living in the past, floating point has been faster than integers on modern CPUs for 10 years or more now, and hardware support for half floats is on most GPUs now and will probably appear in CPUs very soon.
I have no idea what GECL (sp?) does but I do hope they have seen the light and support half and full float data as linear.
8 bits encoded as sRGB is a nice compression format and there is nothing wrong with supporting that. But taking this flawed format and pretending that wasting more memory on it will "fix" it is stupid and shows that you have not studied the problem at all. But photo professionals have proven to be stupid over and over again, just look at them regugitating the same junk right here, whether they want to insult Gimp or Photoshop.
If you think 12 bit will give you HDR then you are not aware of how things work.
What 12 bits gives you is 4096 levels between 0 and 1 instead of 256. Okay, you can instead claim the '1' is not '1' but instead '4' or some larger value. That kind of gives you a bit of HDR, though it is making the shadow end an awful lot worse. Also the programs are going to be very screwed up in deciding the meaning of gamma. If you try to make 12 bits linear then your shadows are going to be TERRIBLE, actually worse that 8-bit sRGB.
You need a floating point format, such as 16-bit float. Trying to increase integer formats past 8 bits is a big waste of time, in many ways Gimp is probably better off that they never got this working, they can instead use 16 bits for floating point the way it should be done.
I agree with several other posters that I do not see what shape you traced there. It looks like you traced the shadow of the clouds mostly, and some effects of the silt from the Mississippi.
The spill is quite huge without you exaggerating it.
It is safe to compare to any small integer, not just zero, as long as you are checking if the the value came from an assignment. It is also safe to use small negative powers of two.
One big problem I have is with programmers who religiously add these epsilon functions and screw up algorithms. In my experience, about 99% of the == statements with floating point are explicitly testing "did the assignment to the same value earlier get executed?" Comparing the bit patterns is exactly what is wanted, stop messing it up!
No, I don't feel you can choose any song. You could make up a flimsy excuse as to how it is "appropriate satire" and then you could ignore copyright on any song for any video. I guess you are saying that all Rolling Stones songs are fair game because Microsoft used one, but it just does not seem right. If perhaps Microsoft made a whole series of ads with different Rolling Stones songs, then maybe you could make a parody that used another Rolling Stones song they did not use, as it would be more clearly a parody of the "Rolling Stones Songs Ad Series". But not a single one.
It sounds like the trojan is completely generic. It does not do anything about the iPad at all, it is designed to spy on the user's Windows use.
After reading a bit more about this I suprised myself by changing my mind. My first knee-jerk reaction was that the videos were ok because they were parodys/satire.
But basically if this was allowed, you could use any music for any video you make whatsoever, and claim it is a satire/parody. Maybe you are required to insert at least one insult, about a random subject, into the video, so it is a "satire or parody". This would completely defeat copyright and certainly is not a good idea.
However that if Boxer had officially used one of these songs in their own videos (after paying for the rights, as required), somebody parodying the Boxer ad can use a parody version of that same song. I believe this was done by conservatives on some Obama attacks. More to the point here, a joke video about Windows using a Rolling Stones "start it up" parody would be allowed, since that was part of the Windows advertisement, but use of a different Rolling Stones song that Microsoft did not use is not allowed.
The article was trying to show a simple example.
I think a far more common exploit would be to place a copy of a structure the kernel expects to reference at 0 and trigger some bug so it uses a null pointer to such a structure. If that structure contains a pointer to a function that the kernel calls you put the pointer to your code there. Probably more likely the structure just contains a pointer to some location the kernel will write, you change this to point at something in the kernel you want to overwrite, and also work on getting the kernel to write exactly the data you want. After it does that you have patched the kernel to do your bidding.
One thing I think is very misleading is that the title should be changed to read "use of a NULL pointer *BY THE KERNEL* can be exploited". To the casual observer this sounds like NULL pointers in user programs are dangerous.
Just want to point out that #define is NOT the main reason you "have to look in .h files every 3 seconds" in many languages. Certainly I have often had to look up plenty of perfectly legal non-preprocessor code in .h files in order to figure out an API. Especially tracking down "what the hell is this type really" in C/C++.
That was very interesting, and it points out mathematical problems with approval voting which I was unaware of. I thought it was actually pretty good. However apparently IRV is even worse as well as having the technical problem of having to remember the exact contents of every ballot, rather than just some totals. I think it would be safe to go to a real concordant (sp?) system and let people rank their preferences.
We were not using MFC or anything, and I agree I can't see how anything in windows.h would be a problem (a for loop would have to be a macro and we could then avoid calling that macro most likely).
We certainly stayed with this behavior until long after they had added the switch to the compiler, some of that may have been intertia and an unwillingness to modify the rather complex and error-prone makefiles. I do remember it being the primary problem when we tried to port software from Linux to Windows and that in a few cases the hurried editing to fix it would break, mostly by hiding a parameter with a local variable with the same name.
1. Make it possible to hide the taskbar/panel/whatever. In every version of Gnome for years now the best you could do is make it hide to 1 pixel tall, and this requires gconf. The default "hide" is an incredibly stupid looking thick 6 pixels. PS: KDE has had this working for about 10 years now, so you can't claim it is some technical defect in X or some other excuse.
2. Fix the setting so that clicking in windows does not raise them. Apparently this configuration option causes it to ignore ALL attempts to raise the window, including the program itself calling XRaiseWindow()! This is completely broken. What we want the configuration option to do is stop clicks inside the window from raising it, NOTHING ELSE!!!
Of course I am wondering if they are purposely leaving these things broken so that they can later claim "nobody uses those options so we will remove them".
Before that, you could control it with a switch, though default was non-standards compliant, and MFC headers wouldn't compile if you turned it on - which shouldn't really concern you if you're compiling portable code, right?
I have to strongly object to this phony argument. Too bad because most of your posts are quite good!
You seem to think "portable" means "it does not contain any calls that don't work on both platforms". This is an artificial description purposely designed so that "portable" is equivalent to "useless", which does sound like typical Microsoft word twisting.
"portable" code looks like this:
portable-code;
#ifdef _WIN32
xxxxx
#else
yyyyy
#endif
more-portable-code;...
Note that "xxxxx" will certainly require the windows.h header file to be included!
This is no joke, for many years I had to keep fixing for loops because they would not compile on Windows. In most cases this was by far the most likely reason the code would fail to compile. So I think your attempt to defend Microsoft's old behavior is rather dubious.
Approval voting also does not require the voting machines to be altered (for the common ink-dot ones).
The problem is that for many people, there are two big parties, one they HATE, and the other which they just feel is incompetent or they only disagree with on a few points. Voting for a third party may mean they have thrown away their ability to try to stop the party they HATE from getting office.
I think this is cutting the voting for third parties by a far greater factor than people deciding not to vote.
What is needed is approval voting. Then you could vote for both the third parties you like and for the less-hideous of the main parties.
I (and I assume a lot of other programmers) use an editor with auto indentation so this is almost impossible to edit. What I usually do is surround the temporary code with "#if 1" and "#endif" which can be left at the left margin.
I do admit that Python, though much more readable, is a bit harder to write. I use auto-indentation for both.
Don't Linux drivers work this way as well?
It is true that the normal POSIX api does not have async methods. I am unsure if Linux offers any. However on both Linux and Windows you nowadays get better performance by using multiple threads and having one of them do the synchronous calls.
Also that gun in your home always defeats the gun the perp has. It has something to do with ballistics, somehow the bullets can only fly away from your bedstand.
It would be really nice if they could figure out how to hide the task bar so it takes ZERO pixels. In every version for years "hide" has meant a huge 6 pixel grey border, which you can at best reduce to 1 pixel by using gconf. Since KDE has been doing this for years you can't blame some X defect for this.
Also they need to fix damn click to raise. I want to turn it off, but those idiots doing the window manager somehow wrote this option so it ignores the *programs* attempt to raise the windows. This is USELESS and breaks lots of software that assumes that raising and mapping a window will make it visible. Comon, get your f**king act together and fix this!
It certainly does send to Google first, it would not work if it had to wait for a web server to say that a page does not exist or for DNS to say a site does not exist.
An easy fix would be for it to stop sending data once there is a single or no matches for what is typed already. It might also make sense to not send any data if what has been typed matches something in a local history. Both of these would make it better than IE because far too many users type URLs into IE's search box.
I seem to remember Larry Niven saying in response to "will somebody ever make a Ringworld movie?" something like "I hope not. Right now I get a big payment every time one studio sells the rights to another, and that would stop if the movie ever got made".
Anybody know if this quip is true?