Sure, this is clearly a shitty thing for an extension to do - but the real blame lies squarely with the FF devs. On what fscking planet is there justification for ALLOWING an extension to access history in the first place?!
Your criticism is misdirected. Stylish does not need to access your browsing history (something that Firefox can block). But Stylish is designed to be active on every page that you visit so that it can apply custom styles for that site or tell you if some user styles exist for that site, Stylish sees every page that you visit, so it can collect and transmit its own view of your history. And unfortunately, that history can include some sensitive information as explained in the article.
Maybe easier is to spot images where PS users kept exif or other information telling that it was PSed (personally I use Gimp)
Obviously, if you want to create a fake you should either remove all metadata (EXIF, IPTC, XMP and proprietary tags) or copy it from the original image. If you claim that you took an image straight from your camera and it contains Photoshop tags or a comment "Created with GIMP", then you will be busted.
Tampering with the metadata is an important step in creating good fakes. However, there is a lesser known property that can often identify the true source of a JPEG image: its quantization tables. The JPEG quantization tables are included in every JPEG file and determine how the image is compressed. GIMP and all other programs using IJG's libjpeg or variants such as libjpeg-turbo are using predefined quantization tables that can easily be recognized (each of the quality levels from 0 to 100 generates a fixed set of 64 integers for the luminance and chrominance quantization tables). Similarly, Photoshop has its own tables for each quality level. Most cameras also have their own quantization tables that are different from GIMP's and Photoshop's; they may even be generated or adjusted dynamically depending on the contents of the image.
I analyzed the quantization tables from GIMP (libjpeg), Photoshop and many cameras more than 10 years ago. I even wrote a blog post in 2007 doing a rough comparison of the quality levels of each program. Even if an image has no metadata or if its metadata has been tampered with, one can tell if it has been modified with GIMP or Photoshop by looking at its quantization tables. I found an interesting article published a year later at the Digital Forensics Research Conference 2008 that explains this clearly: "Using JPEG Quantization Tables to Identify Imagery Processed by Software" (also availble here).
If you use GIMP to save a fake image, then there is an advanced option in the JPEG Save dialog that is only available if you started from a JPEG image. That option is "Use quality settings from original image", which actually copies the quantization tables from the original image instead of letting libjpeg generate new tables based on the quality level that you selected. That would be one more step towards creating a perfect fake.
One more thing that could betray a fake image is the order of the markers and segments in the JPEG file. A JPEG file is made of several segments that are preceded by a two-bytes marker identifying the type of segment: start of image, quantization tables, etc. GIMP (libjpeg) and Photoshop store these segments in the file in a different order. They may also add some markers that are usually not present in the files saved by the cameras, or remove some of them (restart markers, proprietary APPn markers, etc.). The GIMP JPEG plug-in will not allow you to create a perfect fake because it will always save the markers and segments in the same order, but with the right tools it should be possible to re-order them like if the file had been created by a camera.
If you are good at it, you could modify all metadata so that it looks identical to what a camera would produce. Then the only things that could betray your fake image are the pixels of the image: local variations in noise, contrast, etc. This is what is explained in this article about Adobe using AI to detect these variations.
The problem with your step 3 (Scan or take photo of image) is that it is very hard to do it well. It is not trivial to take a photo of a printed image with uniform lighting, no glare, uniform focus, and generally no trace of the paper grain. Scanning could work, but then the image will not be coming from a camera.
Also, the new image from the camera or scanner will contain EXIF metadata that usually includes information about the focal distance, exposure, etc. They will not match the conditions under which the original photo was taken. And if you strip all metadata from the image, then it will look suspicious because nowadays almost all cameras include EXIF metadata in the files that they save.
Of course, if you have the right tools you can also edit the metadata or even merge the EXIF metadata from the original image into the new image. This could work, but then it is not so easy anymore.
.... did the court offer any suggestions as to how, technically speaking, Youtube was supposed to achieve this?
Technically, there are many ways to do this. For example, YouTube could only allow uploads from those whose identity has been verified (so that law enforcement can come and say hello to them if necessary), or YouTube could hire a huge team of moderators to review all videos before they are visible online, or they could combine both by introducing a collaborative pre-moderation system in which the users whose identity has been verified can approve a video posted by someone else (and share the liability for any copyright infringement), or they could enhance several mechanisms for automatic detection of known copyrighted works, etc.
Technically, this is not a problem. Of course, most of these solutions would significantly hurt YouTube's business model and could have a chilling effect on the users who might then refrain from posting anything if they fear that they would be sued. Finding a solution that works technically and that also makes sense from a business point of view is much more difficult. But it is not the role of the court to find a better business model for a company; their role is to ensure that YouTube and other video hosting platforms respect the law.
The very *best* case scenario here if Austria gets what they are asking for is that this is going to result in entirely legal videos which might contain parody, satire, or commentary on copyrighted works being blocked from being viewed in Austria, as well as any other entirely original works that might happen to have some superficial similarity to a copyrighted work. It only goes downhill from there.
I agree that there is a huge risk that pendulum swings too far in the opposite direction, which would result in misuse by the copyright holders targeting perfectly legal works (parody and other cases of fair use). But I doubt that we will see that anyway, because it is unlikely that this preliminary ruling will survive for a long time.
There is fairly good proof KDE is the more complete and better thought out desktop environment.
You are a rather successful troll because you comment was quickly moderated to "+5 Interesting" although it is just a rant without substance. Congratulations for that!
Regretfully no amount of money can make Gnome catch up, it was broken from the start.
When people call an OS by its kernel's name they're being remarkably inconsistent
Think about "Windows Subsystem for Linux", which contains no Linux code but is designed to run "Linux" programs on Windows 10.
That being said, I still have my Yggdrasil "Linux/GNU/X Fall 1993" CD at home. It is funny how this naming debate keeps coming back, with remarkably few new arguments.
The law should be ignored by all non-EU web sites.
That law can be ignored by non-EU web sites that are not doing any business with EU citizens or companies.
But if you are doing business with the EU, then you have to comply (as with many other laws that apply to international business, so this is not unique to the EU). Of course if you break the law it will be a bit more difficult for your victims to sue you if you do not have any presence in the EU, but it will still be possible.
Who does the GDPR affect?
The GDPR not only applies to organisations located within the EU but it will also apply to organisations located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location.
Although Marty it is a project that only started shipping recently after finishing its crowdfunding campaign, it is very interesting because it is fully open (you can even 3D print the parts yourself) and it can be programmed in Scratch, Phyton, Javascript or whatever language you want because the API is open and easy to implement. The robot comes as a kit, and once assembled it can be controlled over wifi. I got mine a few days ago and I am having fun with it.
Instead of teaching my kids to program, I would rather get them interested first. Do not teach them how a program works and how to write a program from scratch. Instead, start from an existing program that already does something useful and show them how they can change a few lines to get a different output from the program or a different behavior from the robot. Then let them play with it and experiment on their own without too much supervision. If they are curious and show interest in learning more, then explain the concepts and the basics of what they have been playing with. If they stop playing and think that it is boring, then do not force it on them but try something else instead (another type of program, another thing that is fun to modify). If you try to teach them how to program before they ask for it, then there is a risk that they will give up and stick to playing games or spending their time on social networks instead of discovering how much fun there is in programming.
A federal judge has set off a free speech tempest after shutting down a US website... Dynadot agreed to shut down the site and bar Wikileaks from transferring the domain name to another host.
When will people learn how the Internet actually works?
They do understand how the Internet actually works. The issue is that Wikileaks has servers in several countries. Countries that have laws protecting freedom of speech and legal procedures that prevent or slow down attempts at censorship.
The bank knew that trying to shut down or block all these servers would be very difficult, so they went for the weakest point: the domain name, which is controlled by the US company. As this case shows, it seems to be easier to restrict free speech in the US than in other countries (e.g., European countries like Sweden, which hosts the server with the IP address 88.80.13.160).
Of course, blocking the domain name will not make the information disappear: several links using IP addresses of the servers are already circulating, as well as alternate domain names hosted outside the US (e.g., wikileaks.be). But this is certainly good enough as a first step: this instantly breaks all direct links to wikileaks.org until these links are updated, and it makes it much harder for the average Internet user to access the site. The average user does not know how to work around these issues by finding out the IP addresses of the servers, finding mirrors or using alternate DNS providers. While the domain name is blocked, the bank can try to get the servers and mirrors shut down, a process that takes much longer than simply blocking the domain name.
The outcome will depend very much on how the press and other media talks about this case. If the reports about this censorship are published in the mainstream press during the next days and generate a lot of public discussion that lasts for several weeks, then it will be a net loss for the bank (the Streisand effect). On the other hand, if there are a few articles about this but no real discussion after a few days, then it will be a win for the bank because nobody will really pay attention to what is happening and the domain name will remain blocked. I hope that their cost/benefit analysis for this case was wrong and that the media will talk a lot about this. We will see...
Yes, you're correct, but as others pointed out, you already get that via the package system that comes with the CD. You don't need the MPAA to provide you what the CD already does.
This is only partially true. The software distributed by the MPAA uses specific versions of each package, while the Ubuntu repositories usually carry the latest version, which may be different than the one needed to rebuild the same versions of the packages as provided on the live CD. Many mirrors try to carry as many old versions as possible, but they do not have to.
The GPLv2 requires you to make the source code available "from the same place" as the binaries and it must be the exact same version as the one used to build the binaries. Unless they have made a deal with some Ubuntu mirrors to ensure that the version of the packages they are using will never be removed from the mirrors, then they are in violation of the GPL by not distributing the sources from their site.
All the tools for editing one image are in that image's window. If you are working on two images with one on each monitor, like you suggest, then you have two sets of tools, one for each image.
...which is a problem if you are working on 10 images (e.g., fine-tuning several icons) and you do not want to have 10 copies of all tools attached to each image.
Even when working with a single image (e.g., a large photograph), some designers prefer to use a whole screen for a single image with a minimal amount of decorations, so that they are not distracted by parasite colors from the GUI. Then the tools can be on one screen and the image on the other screen.
Maximizing the screen space available for the images is always useful for graphics designers. This often implies minimizing the space taken by the various widgets used by the application. One idea would be to let the tools follow the active image and move from one window to another, but there are many problems associated with that behavior. So there is no easy, one-size-fits-all solution.
But the GIMP user interface will improve in future versions. It may still take some time until we find the best set of options, though...
The real question is, what the heck is taking GEGL so long?!
The answer is unfortunately very simple: not enough contributions. The number of active GIMP and GEGL developers is probably much smaller than you think.
Most developers work on GEGL during their spare time and this is not always easy. When you only have a handful of active developers and they can only spend a few hours per week on improving the code or discussing enhancements, it is difficult to do everything quickly. Also, there was a gap of several years during which almost nobody worked on GEGL.
I think that if only a few percent of the people who complain about GIMP or GEGL would try to start contributing to the projects, then GIMP would have had perfect support for 16 bits per color channel since several years. Note that there are many ways to contribute and there is room for everybody. Besides programmers who help with the code, the contributions to the documentation, translations, bug reports, web site and tutorials are always appreciated.
Re:Ask artists, not geeks
on
GIMP 2.4 Released
·
· Score: 2, Informative
high-end photo manipulation
"High-end"? Without the ability to work in, or convert to, a printable color space, or without full support for ICC profiles? I'm not sure what your definition of "high-end" is.
Did you have a look at the release notes linked from the article? Did you see the section titled "Color Management and Soft-proofing"? There is even an extra page of the release notes that focuses only on color management in GIMP 2.4.
In case you did not read it, GIMP 2.4 does support ICC profiles and allows you to convert images to the appropriate color spaces. You can also identify the areas using colors that are outside your printable gamut, etc. It looks like GIMP is able to do more than you think.
Re:Most important thing
on
GIMP 2.4 Released
·
· Score: 4, Interesting
GIMP needs a GUI makeover to be more like Krita.
You might be surprised to learn that some GIMP developers and Krita developers have been talking with each other for a while.
While the interface used by Krita is interesting, it is not suitable for everybody. In particular, several artists and graphics professionals using GIMP want to be able to use their dual-screen setups in the most efficient way, by distributing the image windows and the docks (with the tool options and other tabs) freely over both screens. This is difficult to do when everything is embedded inside a single large window.
The current GIMP user interface is far from ideal and all developers know that. But it is not so easy to redesign it without breaking some of the features that some users came to rely on. Some major improvements to the user interface are planned for future versions, though.
Re:Ask artists, not geeks
on
GIMP 2.4 Released
·
· Score: 2, Insightful
it only takes a five-minute interview with a Photoshop user to understand what needs to be done
If you ask a Photoshop user, you will mostly get answers that suggest to copy Photoshop. GIMP is not trying to be a clone of Photoshop.
On the other hand, if you ask artists who have not been involved too much with Photoshop or graphics professionals who are able to dissociate the desired functionality from one implementation that they already know, then you can get a set of very useful ideas that can bring GIMP forward without being a copycat. Especially if these interviews and analysis of the user interaction are performed by experienced interaction architects.
And this is exactly what has been started for GIMP... Several professional artists, photographers and designers have been interviewed. Some of this analysis has already led to a redesign of the rectangle selection tool and crop tool in GIMP 2.4. Further changes will find their way into future GIMP versions.
If you want a program that behaves like Photoshop, then please use Photoshop. I am happy to point people towards Photoshop when it is obvious that what they need is Photoshop. But if you want a Free Software program that can be used for high-end photo manipulation and that is easily extensible with plug-ins and scripts in various languages, then maybe GIMP is the right choice for you. Different people have different needs, and GIMP does not try to please everybody.
The stable GIMP releases have even numbers. The last stable release before 2.4.x was GIMP 2.2.x, starting with 2.2.0 released in December 2004. So that was almost three years ago. There were several bug-fix releases in the meantime, up to 2.2.17.
The unstable 2.3.x releases ended with the last versions becoming release candidates for 2.4.
Also in the sample chapter, "Table 4-2. Compression sizes using gzip and deflate" shows that gzip performs better than deflate:
It's clear from Table 4-2 why gzip is typically the choice for compression. Gzip
reduces the response by about 66% overall, while deflate reduces the response by
60%. For these files, gzip compresses ~6% more than deflate.
Unfortunately, this table does not specify which compression settings were used for each method. Although both mod_gzip and mod_deflate should default to compression level 6 (the default in gzip and zlib), there can still be significant differences in the buffer size used and these can influence the results by more than the 6% quoted here. Also, some patched versions of the unofficial mod_gzip were using different defaults and some versions of mod_deflate defaulted to compression level 3 instead of 6.
The comparison would be much more useful if it would mention the exact configuration used for the comparison. In particular, the value of the mod_deflate options DeflateCompressionLevel, DeflateBufferSize, DeflateMemLevel and DeflateWindowSize can have a dramatic impact on the results. It would also be nice to mention what version of mod_gzip was used, since several unofficial versions were circulating and some of these modified versions came as standard in some Linux distributions.
I started reading the first chapter and I was surprised when I read the following paragraph:
Gzip is currently the most popular and effective compression method. It is a free for-
mat (i.e., unencumbered by patents or other restrictions) developed by the GNU
project and standardized by RFC 1952. The only other compression format you're
likely to see is deflate, but it's slightly less effective and much less popular. In fact, I
have seen only one site that uses deflate: msn.com. Browsers that support deflate also
support gzip, but several browsers that support gzip do not support deflate, so gzip is
the preferred method of compression.
Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:
This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents.
If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":
gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952.
deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951.
In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.
The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).
So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.
Is there a compelling reason that the default behavior is not 80% of your available memory?
There are several reasons, some of which are historical:
GIMP was designed 10 years ago for UNIX systems. Many of these systems were shared by multiple users from remote displays. On a multi-user system, you do not want any application to consume 80% of the memory shared by all users.
It is very difficult to have a portable way to know (or even guess) the amount of memory available on a machine. You need different bits of code for each operating system, and sometimes you even have to run external commands and parse their output because a non-privileged application is not allowed to get this information from the system.
What is "available memory" anyway? It this your total amount of RAM, the amount of RAM still unused after you boot your OS, or what is left after you start your browser and some other applications? In many cases, only the user knows in which context GIMP will be used.
Nobody bothered implementing good heuristics for setting the tile cache size automatically. I am sure that a patch improving the default behavior would be gladly accepted.
The Company reports a net loss of $840,446 for the six-month period ending June 30, 2007 [...]
For the six-month period ending June 30, 2007, total revenues were $2,673 compared to $9,705 for the six-month period ending June 30, 2006. As the Company is a Development Stage Company its revenue streams are not established and are not impacted by economic or market trends.
Recent Business Activities
On January 9, 2007 the Company announced it had developed a new text entry/text messaging input solution for cell phones utilizing the WordLogic's patent pending prediction engine. [...]
Plan of Operations
A critical component of our operating plan impacting our continued existence is the ability to obtain additional capital through additional equity and/or debt financing. We do not anticipate enough positive internal operating cash flow until such time as we can generate substantial revenues, which may take the next few years to fully realize. In the event we cannot obtain the necessary capital to pursue our strategic plan, we may have to cease or significantly curtail our operations. This would materially impact our ability to continue operations.
So it is a company that is making losses and focuses mainly on a single product. The success of this product depends on the licensing deals related to that patent. It looks like that company is betting a large part of its future on that single patent. So their best hope may be to become a patent troll. It may be a bit sad for the engineers working at that company, but I have serious doubts about their future business plans and methods.
Is it surprising that they issued a press release related to that patent a few days before issuing their quarterly report?
And, by what magic of the new HTTP 2.0 protocol are you running two different server software types on the same IP and on the same port?
Simple and no need for magic: have a single IP address and port that runs an accelerating proxy that is just a front-end for a pool of servers. This proxy forwards the requests to the appropriate server depending on the HTTP/1.1 request headers. It can cache some contents (that's the "accelerating" part) and can also filter the requests and provide some defense against some common types of attacks.
Behind the front-end proxy, you may have several boxes running Apache serving static pages, another box running Microsoft IIS for ASP pages, and yet another box running Tomcat or Glassfish for JSP pages. All of these are exposed to the outside world as a single IP address and port, although they may use different host names.
"Counterfeiter" is misleading too. After all, those are the real games; they're just illegally duplicated and distributed.
Sorry, but I disagree. "Counterfeiter" is appropriate. When I buy a commercial game, the software is only a part of what I buy. For me, a game is the software and the medium that carries it (CD or DVD), but also the box, the manuals, and any extra goodies included in the box.
Duplicating the software is a copyright infringment. But what about the box and the other stuff? Until we have a machine that can automagically replicate physical items, the best way to describe what this guy was doing is "counterfeiter".
You can obfuscate any code you writing, regardless of what licence(s) you use for distribution. N.B. Obscucation is likely to make your code much more difficult to debug. The only difference with GPL is that someone else can unofuscate it and distribute that version.
Wrong. The GPL does not allow you to obfuscate your code. Here is the relevant paragraph from section 3 or the GPL (emphasis mine):
"The source code for a work means the preferred form of the work for making modifications to it.For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
Obfuscated code would definitely not be the "preferred form of the work for making modifications to it" and is therefore not allowed by the GPL. This requirement is present in the GPLv2 and will also be present in the GPLv3. In the GPLv3 (current draft), check the definition of "Source Code" and "Corresponding Source" in section 1.
Slashdot Mirror
Sure, this is clearly a shitty thing for an extension to do - but the real blame lies squarely with the FF devs. On what fscking planet is there justification for ALLOWING an extension to access history in the first place?!
Your criticism is misdirected. Stylish does not need to access your browsing history (something that Firefox can block). But Stylish is designed to be active on every page that you visit so that it can apply custom styles for that site or tell you if some user styles exist for that site, Stylish sees every page that you visit, so it can collect and transmit its own view of your history. And unfortunately, that history can include some sensitive information as explained in the article.
Maybe easier is to spot images where PS users kept exif or other information telling that it was PSed (personally I use Gimp)
Obviously, if you want to create a fake you should either remove all metadata (EXIF, IPTC, XMP and proprietary tags) or copy it from the original image. If you claim that you took an image straight from your camera and it contains Photoshop tags or a comment "Created with GIMP", then you will be busted.
Tampering with the metadata is an important step in creating good fakes. However, there is a lesser known property that can often identify the true source of a JPEG image: its quantization tables. The JPEG quantization tables are included in every JPEG file and determine how the image is compressed. GIMP and all other programs using IJG's libjpeg or variants such as libjpeg-turbo are using predefined quantization tables that can easily be recognized (each of the quality levels from 0 to 100 generates a fixed set of 64 integers for the luminance and chrominance quantization tables). Similarly, Photoshop has its own tables for each quality level. Most cameras also have their own quantization tables that are different from GIMP's and Photoshop's; they may even be generated or adjusted dynamically depending on the contents of the image.
I analyzed the quantization tables from GIMP (libjpeg), Photoshop and many cameras more than 10 years ago. I even wrote a blog post in 2007 doing a rough comparison of the quality levels of each program. Even if an image has no metadata or if its metadata has been tampered with, one can tell if it has been modified with GIMP or Photoshop by looking at its quantization tables. I found an interesting article published a year later at the Digital Forensics Research Conference 2008 that explains this clearly: "Using JPEG Quantization Tables to Identify Imagery Processed by Software" (also availble here).
If you use GIMP to save a fake image, then there is an advanced option in the JPEG Save dialog that is only available if you started from a JPEG image. That option is "Use quality settings from original image", which actually copies the quantization tables from the original image instead of letting libjpeg generate new tables based on the quality level that you selected. That would be one more step towards creating a perfect fake.
One more thing that could betray a fake image is the order of the markers and segments in the JPEG file. A JPEG file is made of several segments that are preceded by a two-bytes marker identifying the type of segment: start of image, quantization tables, etc. GIMP (libjpeg) and Photoshop store these segments in the file in a different order. They may also add some markers that are usually not present in the files saved by the cameras, or remove some of them (restart markers, proprietary APPn markers, etc.). The GIMP JPEG plug-in will not allow you to create a perfect fake because it will always save the markers and segments in the same order, but with the right tools it should be possible to re-order them like if the file had been created by a camera.
If you are good at it, you could modify all metadata so that it looks identical to what a camera would produce. Then the only things that could betray your fake image are the pixels of the image: local variations in noise, contrast, etc. This is what is explained in this article about Adobe using AI to detect these variations.
The problem with your step 3 (Scan or take photo of image) is that it is very hard to do it well. It is not trivial to take a photo of a printed image with uniform lighting, no glare, uniform focus, and generally no trace of the paper grain. Scanning could work, but then the image will not be coming from a camera.
Also, the new image from the camera or scanner will contain EXIF metadata that usually includes information about the focal distance, exposure, etc. They will not match the conditions under which the original photo was taken. And if you strip all metadata from the image, then it will look suspicious because nowadays almost all cameras include EXIF metadata in the files that they save.
Of course, if you have the right tools you can also edit the metadata or even merge the EXIF metadata from the original image into the new image. This could work, but then it is not so easy anymore.
Technically, there are many ways to do this. For example, YouTube could only allow uploads from those whose identity has been verified (so that law enforcement can come and say hello to them if necessary), or YouTube could hire a huge team of moderators to review all videos before they are visible online, or they could combine both by introducing a collaborative pre-moderation system in which the users whose identity has been verified can approve a video posted by someone else (and share the liability for any copyright infringement), or they could enhance several mechanisms for automatic detection of known copyrighted works, etc.
Technically, this is not a problem. Of course, most of these solutions would significantly hurt YouTube's business model and could have a chilling effect on the users who might then refrain from posting anything if they fear that they would be sued. Finding a solution that works technically and that also makes sense from a business point of view is much more difficult. But it is not the role of the court to find a better business model for a company; their role is to ensure that YouTube and other video hosting platforms respect the law.
The very *best* case scenario here if Austria gets what they are asking for is that this is going to result in entirely legal videos which might contain parody, satire, or commentary on copyrighted works being blocked from being viewed in Austria, as well as any other entirely original works that might happen to have some superficial similarity to a copyrighted work. It only goes downhill from there.
I agree that there is a huge risk that pendulum swings too far in the opposite direction, which would result in misuse by the copyright holders targeting perfectly legal works (parody and other cases of fair use). But I doubt that we will see that anyway, because it is unlikely that this preliminary ruling will survive for a long time.
There is fairly good proof KDE is the more complete and better thought out desktop environment.
You are a rather successful troll because you comment was quickly moderated to "+5 Interesting" although it is just a rant without substance. Congratulations for that!
Regretfully no amount of money can make Gnome catch up, it was broken from the start.
And of course you have a proof of that as well?
Think about "Windows Subsystem for Linux", which contains no Linux code but is designed to run "Linux" programs on Windows 10.
That being said, I still have my Yggdrasil "Linux/GNU/X Fall 1993" CD at home. It is funny how this naming debate keeps coming back, with remarkably few new arguments.
The law should be ignored by all non-EU web sites.
That law can be ignored by non-EU web sites that are not doing any business with EU citizens or companies.
But if you are doing business with the EU, then you have to comply (as with many other laws that apply to international business, so this is not unique to the EU). Of course if you break the law it will be a bit more difficult for your victims to sue you if you do not have any presence in the EU, but it will still be possible.
As the FAQ says (italics mine):
I would add Marty the robot to this list : https://robotical.io/
Although Marty it is a project that only started shipping recently after finishing its crowdfunding campaign, it is very interesting because it is fully open (you can even 3D print the parts yourself) and it can be programmed in Scratch, Phyton, Javascript or whatever language you want because the API is open and easy to implement. The robot comes as a kit, and once assembled it can be controlled over wifi. I got mine a few days ago and I am having fun with it.
Instead of teaching my kids to program, I would rather get them interested first. Do not teach them how a program works and how to write a program from scratch. Instead, start from an existing program that already does something useful and show them how they can change a few lines to get a different output from the program or a different behavior from the robot. Then let them play with it and experiment on their own without too much supervision. If they are curious and show interest in learning more, then explain the concepts and the basics of what they have been playing with. If they stop playing and think that it is boring, then do not force it on them but try something else instead (another type of program, another thing that is fun to modify). If you try to teach them how to program before they ask for it, then there is a risk that they will give up and stick to playing games or spending their time on social networks instead of discovering how much fun there is in programming.
http://naapo.org/WOWCometRebuttal.html
Another detailed rebuttal on Reddit: https://www.reddit.com/r/Astro... Well worth reading. Also, take a look at this comment from last year that gives a bit more background info about the author of that study: https://www.theguardian.com/sc...
They do understand how the Internet actually works. The issue is that Wikileaks has servers in several countries. Countries that have laws protecting freedom of speech and legal procedures that prevent or slow down attempts at censorship.
The bank knew that trying to shut down or block all these servers would be very difficult, so they went for the weakest point: the domain name, which is controlled by the US company. As this case shows, it seems to be easier to restrict free speech in the US than in other countries (e.g., European countries like Sweden, which hosts the server with the IP address 88.80.13.160).
Of course, blocking the domain name will not make the information disappear: several links using IP addresses of the servers are already circulating, as well as alternate domain names hosted outside the US (e.g., wikileaks.be). But this is certainly good enough as a first step: this instantly breaks all direct links to wikileaks.org until these links are updated, and it makes it much harder for the average Internet user to access the site. The average user does not know how to work around these issues by finding out the IP addresses of the servers, finding mirrors or using alternate DNS providers. While the domain name is blocked, the bank can try to get the servers and mirrors shut down, a process that takes much longer than simply blocking the domain name.
The outcome will depend very much on how the press and other media talks about this case. If the reports about this censorship are published in the mainstream press during the next days and generate a lot of public discussion that lasts for several weeks, then it will be a net loss for the bank (the Streisand effect). On the other hand, if there are a few articles about this but no real discussion after a few days, then it will be a win for the bank because nobody will really pay attention to what is happening and the domain name will remain blocked. I hope that their cost/benefit analysis for this case was wrong and that the media will talk a lot about this. We will see...
This is only partially true. The software distributed by the MPAA uses specific versions of each package, while the Ubuntu repositories usually carry the latest version, which may be different than the one needed to rebuild the same versions of the packages as provided on the live CD. Many mirrors try to carry as many old versions as possible, but they do not have to.
The GPLv2 requires you to make the source code available "from the same place" as the binaries and it must be the exact same version as the one used to build the binaries. Unless they have made a deal with some Ubuntu mirrors to ensure that the version of the packages they are using will never be removed from the mirrors, then they are in violation of the GPL by not distributing the sources from their site.
For more information, see this section of the old GPL FAQ.
...which is a problem if you are working on 10 images (e.g., fine-tuning several icons) and you do not want to have 10 copies of all tools attached to each image.
Even when working with a single image (e.g., a large photograph), some designers prefer to use a whole screen for a single image with a minimal amount of decorations, so that they are not distracted by parasite colors from the GUI. Then the tools can be on one screen and the image on the other screen.
Maximizing the screen space available for the images is always useful for graphics designers. This often implies minimizing the space taken by the various widgets used by the application. One idea would be to let the tools follow the active image and move from one window to another, but there are many problems associated with that behavior. So there is no easy, one-size-fits-all solution.
But the GIMP user interface will improve in future versions. It may still take some time until we find the best set of options, though...
The answer is unfortunately very simple: not enough contributions. The number of active GIMP and GEGL developers is probably much smaller than you think.
Most developers work on GEGL during their spare time and this is not always easy. When you only have a handful of active developers and they can only spend a few hours per week on improving the code or discussing enhancements, it is difficult to do everything quickly. Also, there was a gap of several years during which almost nobody worked on GEGL.
I think that if only a few percent of the people who complain about GIMP or GEGL would try to start contributing to the projects, then GIMP would have had perfect support for 16 bits per color channel since several years. Note that there are many ways to contribute and there is room for everybody. Besides programmers who help with the code, the contributions to the documentation, translations, bug reports, web site and tutorials are always appreciated.
Did you have a look at the release notes linked from the article? Did you see the section titled "Color Management and Soft-proofing"? There is even an extra page of the release notes that focuses only on color management in GIMP 2.4.
In case you did not read it, GIMP 2.4 does support ICC profiles and allows you to convert images to the appropriate color spaces. You can also identify the areas using colors that are outside your printable gamut, etc. It looks like GIMP is able to do more than you think.
You might be surprised to learn that some GIMP developers and Krita developers have been talking with each other for a while.
While the interface used by Krita is interesting, it is not suitable for everybody. In particular, several artists and graphics professionals using GIMP want to be able to use their dual-screen setups in the most efficient way, by distributing the image windows and the docks (with the tool options and other tabs) freely over both screens. This is difficult to do when everything is embedded inside a single large window.
The current GIMP user interface is far from ideal and all developers know that. But it is not so easy to redesign it without breaking some of the features that some users came to rely on. Some major improvements to the user interface are planned for future versions, though.
If you ask a Photoshop user, you will mostly get answers that suggest to copy Photoshop. GIMP is not trying to be a clone of Photoshop.
On the other hand, if you ask artists who have not been involved too much with Photoshop or graphics professionals who are able to dissociate the desired functionality from one implementation that they already know, then you can get a set of very useful ideas that can bring GIMP forward without being a copycat. Especially if these interviews and analysis of the user interaction are performed by experienced interaction architects.
And this is exactly what has been started for GIMP... Several professional artists, photographers and designers have been interviewed. Some of this analysis has already led to a redesign of the rectangle selection tool and crop tool in GIMP 2.4. Further changes will find their way into future GIMP versions.
If you want a program that behaves like Photoshop, then please use Photoshop. I am happy to point people towards Photoshop when it is obvious that what they need is Photoshop. But if you want a Free Software program that can be used for high-end photo manipulation and that is easily extensible with plug-ins and scripts in various languages, then maybe GIMP is the right choice for you. Different people have different needs, and GIMP does not try to please everybody.
The stable GIMP releases have even numbers. The last stable release before 2.4.x was GIMP 2.2.x, starting with 2.2.0 released in December 2004. So that was almost three years ago. There were several bug-fix releases in the meantime, up to 2.2.17.
The unstable 2.3.x releases ended with the last versions becoming release candidates for 2.4.
Also in the sample chapter, "Table 4-2. Compression sizes using gzip and deflate" shows that gzip performs better than deflate:
Unfortunately, this table does not specify which compression settings were used for each method. Although both mod_gzip and mod_deflate should default to compression level 6 (the default in gzip and zlib), there can still be significant differences in the buffer size used and these can influence the results by more than the 6% quoted here. Also, some patched versions of the unofficial mod_gzip were using different defaults and some versions of mod_deflate defaulted to compression level 3 instead of 6.
The comparison would be much more useful if it would mention the exact configuration used for the comparison. In particular, the value of the mod_deflate options DeflateCompressionLevel, DeflateBufferSize, DeflateMemLevel and DeflateWindowSize can have a dramatic impact on the results. It would also be nice to mention what version of mod_gzip was used, since several unofficial versions were circulating and some of these modified versions came as standard in some Linux distributions.
I started reading the first chapter and I was surprised when I read the following paragraph:
Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:
If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":
In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.
The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).
So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.
There are several reasons, some of which are historical:
And even if they haven't been a patent troll in the past, they may be becoming one.
Let's look at their latest quarterly report (SEC filing) and pick a few bits:
So it is a company that is making losses and focuses mainly on a single product. The success of this product depends on the licensing deals related to that patent. It looks like that company is betting a large part of its future on that single patent. So their best hope may be to become a patent troll. It may be a bit sad for the engineers working at that company, but I have serious doubts about their future business plans and methods.
Is it surprising that they issued a press release related to that patent a few days before issuing their quarterly report?
It would be much more interesting if Novell would release that software under the GPLv3. Think about it.
Simple and no need for magic: have a single IP address and port that runs an accelerating proxy that is just a front-end for a pool of servers. This proxy forwards the requests to the appropriate server depending on the HTTP/1.1 request headers. It can cache some contents (that's the "accelerating" part) and can also filter the requests and provide some defense against some common types of attacks.
Behind the front-end proxy, you may have several boxes running Apache serving static pages, another box running Microsoft IIS for ASP pages, and yet another box running Tomcat or Glassfish for JSP pages. All of these are exposed to the outside world as a single IP address and port, although they may use different host names.
Sorry, but I disagree. "Counterfeiter" is appropriate. When I buy a commercial game, the software is only a part of what I buy. For me, a game is the software and the medium that carries it (CD or DVD), but also the box, the manuals, and any extra goodies included in the box.
Duplicating the software is a copyright infringment. But what about the box and the other stuff? Until we have a machine that can automagically replicate physical items, the best way to describe what this guy was doing is "counterfeiter".
Wrong. The GPL does not allow you to obfuscate your code. Here is the relevant paragraph from section 3 or the GPL (emphasis mine):
"The source code for a work means the preferred form of the work for making modifications to it.For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
Obfuscated code would definitely not be the "preferred form of the work for making modifications to it" and is therefore not allowed by the GPL. This requirement is present in the GPLv2 and will also be present in the GPLv3. In the GPLv3 (current draft), check the definition of "Source Code" and "Corresponding Source" in section 1.