[...] the "splashwindow" would contain first the splashscreen (with a progress indication if possible) and then the application when it is ready to be used.
This would not work well for some applications such as the GIMP: currently, the "main" GIMP window is the toolbox. It can be resized to any shape (some people prefer to have it wider or taller) and these settings can be saved and restored for the next session. Note that you can close the "tool options" tab located below the toolbox and then resize the toolbox to be only two icons wide, for example. Some people like to have a tall and narrow toolbox near the edge of their screen.
It would be difficult to have a nice splash screen image that fits all possible shapes for the toolbox. In many cases, the image would be truncated and would lose most of its meaning.
An intermediate solution would be to keep the same window for the splash and for the toolbox but create it initially with a size that is appropriate for the splash screen and then resize it and move it to the appropriate position for the toolbox. I think that such a solution would create more problems than it would solve.
How often do you need to run an X app across the wire?
Every day. X needs better network transparancy, not less. Keep in mind that for local delivery, X uses unix domain sockets which impose no observable overhead.
I will grant to the grandparent post that X adds some overhead for the applications that have to send a large amount of rapidly-changing data to the display (e.g., games). The problem is that even if relatively efficient techniques such as unix domain sockets are used, updating the display frequently does require several context switches between the client application, the kernel and the X server.
But this only applies to a small number of applications. For most of them, the overhead is probably less than 1% of time taken by the application to do other stuff. And for the applications that require fast display updates, then there are several X extensions that have been specifically designed for that (e.g., DGA). Of course, using these extensions require more programming effort beyond what is provided by the common toolkits (Qt or GTK+) and you lose the cross-platform nature and network transparency of X, but it is possible to write fast applications based on X if you need to.
How often do you need to run an X app across the wire? How many times do you need to support multiple displays and screens (OK, this is slashdot, so I know some of you do -- I have myself, but it's very rare).
Let's see... Every day I have two or three XTerms on different machines from which I launch some editors (emacs, xemacs) and various graphical programs (purify, xcompare). Then I also have a mail client (sylpheed) running from yet another machine through ssh X forwarding and sometimes also a web browser (FireFox) running remotely from that machine. I even run the GIMP remotely at least once per week. And I do a lot of copy and paste between these applications running on different boxes. Basically, it would be hard for me to work without the network transparency offered by X. Should I also mention that these boxes run different operating systems (Linux, Solaris, FreeBSD) and use different processor architectures?
Granted, I may not be a typical user and as you pointed out, some Slashdot visitors are likely to do unusual things. But for me, relying on X to work accross the wire is not very rare - it's what I need every day.
So the fact that KDE and GNOME rely on X is a feature, from my point of view. I wouldn't mind if a replacement for X would be added as an option, but I don't think that I would use it.
when a patent with an overbroad claim 1 goes to court, the court might just choose to too cancel claim 1 and say the patent is valid starting from claim 2.
Yes. This is precisely why a patent application is divided into several claims: the first one is always as broad as possible, and the following ones are usually derived from the first one and get narrower and narrower in scope. There can be more than one independent claim in a patent application, but they are also usually followed by several other claims depending on them with a narrower scope.
The goal is that if one of your claims with a broad scope is rejected during the patent application process or invalidated later by a court, then the following ones will still be in full effect if a potential infringer is still within the scope of these dependent claims. If the broader claim is accepted, then you win big. If the broader claim is invalidated but a narrower one still applies, then you don't win as much (because there will be less potential infringers) but you can still get something out of the patent.
To put it simply, the game goes like this:
try first with claim 1.
If it is rejected, try again with claim 2.
If it is rejected, try again with claim 3.
And so on...
In this case, I doubt that the first claim would be accepted by the patent office because of extensive prior art. But the following ones might be accepted, although I have some serious doubts about the inventive step. But even if this patent application looks ridiculous, there is a chance that some of its claims might survive.
Yes, thanks for the explanation. This is exactly what I meant in my previous comment: the "details" can be a car or bike, the usual behavior of the person to be tracked or as a last resort some things that make that person stand out from a crowd such as a hat, suitcase,...
Anyway, even if a satellite could be used for tracking a single person, it is unlikely that any spy agency would waste its satellite budget on that. As you and others have correctly pointed out, it's just not worth it. It would be much more cost-efficient to use spy planes, balloons, drones or simply a bunch of people on the ground to do that.
I doubt that the resulution is sufficient to track individuals yet.
With a resolution of 5cm (2 inches) or 10cm (4 inches), the spy satellites can certainly track people. Source: Resolution of a Spy Satellite.
Note that a satellite does not have to be able to recognize your face to track you (it is hard to see it from the sky anyway). You can be identified by many other details.
Re:Good luck, but it will never happen
on
Replacing TCP?
·
· Score: 2, Insightful
First, the protocol is built on top of UDP, meaning that it can be implemented at the application layer.
Or rather: the protocol is built on top of UDP, meaning that it will only be implemented at the application layer. There are other fine protocols built on top of UDP, such as RTP/RTCP used for streaming. Are there any operating systems implementing these protocols in the kernel? I don't think so. Are there libraries providing a convenient API allowing application developers to use these protocols easily? A few, but not that many. It is likely that any other protocol implemented on top of UDP would have a similar fate.
TCP is cooperative - it will share 'fairly' any congested channel. It will lose to a more greedy protocol.
You don't seem to understand that most network operators (those who play with the routers at your ISP or somewhere else in the backbone) want protocols to be fair. If too many people start using a protocol that is unfair, then many ISPs will start tweaking their routers and firewalls in order to limit the bandwidth available to the unfair protocol. ISPs have to keep their customers happy (or at least happy enough to pay their bill) and an unfair protocol would make many other customers unhappy.
You are almost correct, except that doing the error correction on the whole file instead of a single (or a couple of) packets allows the file to be transmitted even if one or several packets are dropped.
However, this kind of error correction is only good if you are exchanging rather large files. They cannot claim to replace TCP if their protocol cannot be used for any kind of interactive work. Take for example SSH or HTTP (the protocol that we are using for reading Slashdot): they are both implemented on top of TCP and they require TCP to work equally well for exchanging small chunks of data (keypress in an SSH session, or HTTP GET request) and exchanging larger chunks of data (HTTP response).
While their new protocol would probably work well for the larger chunks of data, it is very likely to reduce the degrade the link performance for the smaller bits exchanged during an interactive session. So they are probably good for file sharing. But TCP has many other uses...
Also, they mention that they can be TCP-friendly by transmitting in "waves". I doubt that these "waves" can be very TCP-friendly if their time between peaks is too short. One thing that TCP does not do well is to adapt its transmission rate to fast-changing network conditions. So if they allow the user or the application designer to set the frequency of these waves, they could end up with a very TCP-unfriendly protocol.
does that mean we have to cater to the delusions of the Chinese (PRC) government?
Of course not. Unless you are interested in selling your products in China, that is.
The fact is that Microsoft (and many other companies, for that matter) would very much like to sell their products in China, so they have to please the Chinese government. Or at least not anger them.
In addition to the link in my previous comment, here is a convenient list of links to the very nice MEP analysis site created by Christian Beauprez. I hope that he will forgive me for any slashdotting:
Check how your elected representatives have supported patents so far, and decide how to vote in a few days.
Slashdot readers from countries such as UK, Germany or Spain have a lot of work to do! Talk to your friends, family, coworkers and MEPs and try to change the tide...
It would be nice to see something similar for the other countries.
There is a link to a list of other countries on the page that you linked to. It doesn't have a detailled commentary and analysis, but this is good enough to have an overview of who voted against patents.
If you are living in Europe, take a look at the chart for your country and see who you should vote for. Personally, I am glad that the MEPs that I voted for in the previous election have clearly voted in favor of the FFII and against patents (i.e., they got a high score in the chart). I will vote for them again in a few days.
The consumer magazine Test-Achats/Test-Aankoop in Belgium has reviewed this item in its current issue. You can find the full article on their web site, although it is only accessible for subscribers.
In summary, here is what the article says about this "robot" that irons your clothes: the quality of the results is not that good, there are still some wrinkles left in the shirts (this is OK if you wear them under something else, but not if you want to look smart wearing only a shirt). They gave it an "average" rating for the quality, while most of the traditional irons get a "good" or "very good". One of the main selling arguments for this expensive item is that it irons your shirts for you while you can do something else during the 10 minutes that it takes to do its work. But in practice, you need 2 minutes to put the shirt on and 2 minutes to remove it once it is ready. So if you have several shirts this device lets you do something else for one hour, but only in slices of 10 minutes so this is not ideal.
They are scammers, not legitimate businesses. They steal text and images from other sites. As others have already mentioned, you can use Google to search for some parts of the text on their pages and you will usually find the real source of the content.
It is also interesting to check where the images are coming from. For example, take a look at one of these fake sites: "Trust Meridien". The home page contains a link to the so-called professionals who are supposed to run this fake company: http://www.trustmeridien.com/directors.htm.
Take a look at the second picture. This woman is supposed to be called "Elizabeth Gideon". However, the name of the image file is: Kay_ivey1.gif. The name does not seem to match. Indeed, a little googling allowed me to find an identical copy of the image: Kay_ivey1.gif. That one is linked from the home page of http://www.kayivey.com/, who is the Alabama State Treasurer. The scammer did not even bother changing the name of the file!
I am sure that someone could find the source of the other images included in that page. Anyway, if you still had any doubt that the site is not a legitimate business, I suggest that you get in touch with Kay Ivey and ask her if she is really part of "Trust Meridien". Or maybe she has a twin sister?
This is the problem with religious blindness. Telling people they have to (or must not) do things a particular way or accept things in a particular way because "we know it's better", when in fact it's really a matter of preference. I have a preference for MDI for some tasks. Image editing is one.
Indeed, MDI for image editing can make sense. To some extent, this is already what many people are doing by dedicating a virtual desktop to the GIMP (except that the menu bar and status bar cannot be shared between all windows and other space-saving features of MDI are not available).
Most of the commercial image editors use some kind of MDI model becauses it makes sense: working with images often requires several images of different sizes to be visible at the same time and it should be easy to work on all of them without accidentally clicking on other windows. At the same time, most users prefer to avoid having dozens of "tasks" (windows) visible in the main task bar, so grouping all image windows into a single MDI container can help.
As a GIMP contributor and one of the few supporters of an MDI option for the GIMP, I encourage you to have a look at the lengthy discussions in Bug #7379. But please do not add comments to this bug report unless you really have something new to add because most of the issues have already been discussed for too long.
Yep. I still have several boxes full of them (in Belgium). Most of them are in good shape, although some metallic parts are a bit rusty now (damn wet cellar!).
These were wonderful toys. I started with the basic sets when I was rather young (I think it was in 1974 - I was 4) and then got the more advanced sets as I was growing. I eventually got several electronics sets and those that allowed me to play with some basic IC chips, such as the 7400, 7404 and others. That's probably what got me interested in electronics and computers.
I built several small robots with them (well, things that had blinking lights, motors and several switches and light sensors - nothing very complex on the logic side). I also built a rather dangerous thing with Fischertechnik and some rubberband: a crossbow that could fire small darts. It had three light sensors and it could rotate automatically if it detected a difference in lighting (e.g., shadow from someone or some object in front of it). It would orient itself towards the object and then fire. My parents were not amused, especially when they saw that it worked as advertised and needed a tool to remove a dart from the door frame... So I had to disassemble it quickly. I also built several more useful and more peaceful things with these great toys. I remember that I used them in a school project.
I thought that they had stopped producing them, but I see that there is a web site about Fischertechnik including a list of dealers, new products, etc.
Actually, there's a bunch of patents on CMYK->RGB conversion methods.
I am not aware of patents covering the CMYK->RGB conversion. There may be some patents about the RGB->CMYK conversion because it is not always easy to find the best way to generate the right amount of K (black), but even for this case I am not sure that any valid and relevant patents exist in that area.
As a software developer, it is better to ignore patents anyway: do not waste your time checking if an area is covered by patents, unless your lawyer tells you explicitely that some patents cannot be ignored. There are many reasons for that:
Checking for patents takes a lot of time that would be better spent coding.
If you do not have experience reading or writing patents, the finer details of the language of the claims can be confusing. You may think that a patent covers more or less than what it actually covers, so your conclusions about the applicability of a patent to your area may be wrong.
Even if a patent covers the area in which you are working, this does not mean that it is valid. A patent is granted because the (overworked) patent examiner at the EPO, USPTO or other local patent office could not find any prior art, but this does not mean that none exists. Ultimately, it will be up to the court to decide if the patent is valid and it is not rare for a patent (or at least some of its claims) to be invalidated because some prior art is discovered during trial.
If you are aware of the existence of some patents but you decide to write the code using similar techniques anyway, then you would be comitting willful infringment. Depending on the law in your country or state, this may put you in a much bigger trouble than if you could have a plausible denial of their knowledge.
So I doubt that there are any patents in this area that would prevent the GIMP from having a good CMYK support. And even if there are any, then I will not actively look for them and please do not tell me about them.
The answer to the grand-parent - no win32 gimp-2.0 available yet - unless you compile it and debug it yourself:)
<pedantic>Well, there is no gimp-2.0 for any platform yet. We are only talking about a pre-release here.</pedantic>
This pre-release version (2.0-pre1) is not very different from version 1.3.23, which is available for Windows in a convenient installer from Jernej Simoncic's page. The release of the source code is rather new and it will take a few days until binaries are available for all platforms, but you can probably expect a 2.0-pre version for Windows soon.
No, the plans have changed last year. There was a debate among the developers about whether the next stable release should be called 1.4 or 2.0, and the decision was to call it 2.0. It does not have the native CMYK support (only export), but it has many other new features. Also, the internal structure of the program has changed so much that a major change in the version number was considered useful. Even if the end users do not see some of these changes, they are very significant for script and plug-in authors and the improved structure and documentation of the code should make it easier for new developers to contribute to the GIMP.
A bit of background (if you are interested): after the GIMP developers' conference in 2000, the plans were to have CMYK support in GIMP 2.0. These plans for "the future of the GIMP" were published and were often refered to (in newsgroups, mailing lists and even here on Slashdot), until the middle of last year. At that time, the discussion started about how the new version should be called and it was decided to call it 2.0. This decision was confirmed at the 2003 edition of the GIMP developers' conference. Even if those who were expecting native CMYK in 2.0 will have to wait until the next release, I think that most users will be very happy with the new GIMP.
The "big difference" is that instead of oppening the whole program, images and sibblings in a single window, The GIMP opens the toolboxes and images in separate windows. This allows a serious user to make an optimal use of the multiple desktops avaliable in almost all window manager for X11 out there.
Yes, the current interface of the GIMP (already much improved since the GIMP 1.x days) is very nice if you have a window manager that provides multiple desktops or virtual workspaces. This is good for most Unix users with modern window managers. But it is not as easy to use under Windows because all applications have to share the same workspace. An option for some users is to install some third-party Windows software that provides multiple virtual workspaces, but some users cannot or do not want to install such software.
In any case, even if the current interface is still not ideal when you do not have multiple workspaces, it is easier to use than the 1.x versions. And the best way to know if The GIMP is difficult to use or not is to try it yourself! You may also want to read some books such as Grokking the GIMP. That book was written for GIMP 1.2 and the interface has changed since then, but most of the concepts are still valid so it provides a good introduction to the GIMP.
What GIMP is missing is native CMYK (ie. it's all still RGB for editing). Next version!
You are right. Supporting native CMYK (or L*a*b or HSV or CieXYZ or...) without conversion to/from RGB while editing requires the GIMP to support multiple color spaces and optionally multiple bit depths for higher precision. This will be done in the next major release of the GIMP by using GEGL, a library designed for supporting many different color spaces and transformations between them. It will take a while until all tools in the GIMP are converted to use GEGL, but this is what we are aiming for...
The current CMYK support in The GIMP 2.0 is rather basic, but it will hopefully already be sufficient for several GIMP users.
There are several reasons why the GPL is attacked by SCO:
The main reason is probably because they realized (a bit late) that the GPL forbids them from distributing Linux and at the same time requesting license fees from Linux users. So if the GPL is valid (and it is), then SCO is in big trouble.
In addition, if the GPL were not valid, SCO would probably be able to steal some code from Linux and put it in SCO UNIX, claiming that they do not have to give anything back because the "share alike" sections of the GPL would not be enforceable. Considering that Linux has several enterprise-grade features that are sorely missing in SCO UNIX, it would be interesting for SCO to be able to get that for free.
Another reason is that Microsoft is (directly or indirectly) pushing SCO in that direction. They are one of the few companies that gave some substantial amount of money to SCO this year.
There are probably many other reasons, but that does not really matter because I don't think that SCO stands a chance to convince anybody (especially the judges) that the GPL is invalid.
Slashdot Mirror
This would not work well for some applications such as the GIMP: currently, the "main" GIMP window is the toolbox. It can be resized to any shape (some people prefer to have it wider or taller) and these settings can be saved and restored for the next session. Note that you can close the "tool options" tab located below the toolbox and then resize the toolbox to be only two icons wide, for example. Some people like to have a tall and narrow toolbox near the edge of their screen.
It would be difficult to have a nice splash screen image that fits all possible shapes for the toolbox. In many cases, the image would be truncated and would lose most of its meaning.
An intermediate solution would be to keep the same window for the splash and for the toolbox but create it initially with a size that is appropriate for the splash screen and then resize it and move it to the appropriate position for the toolbox. I think that such a solution would create more problems than it would solve.
I will grant to the grandparent post that X adds some overhead for the applications that have to send a large amount of rapidly-changing data to the display (e.g., games). The problem is that even if relatively efficient techniques such as unix domain sockets are used, updating the display frequently does require several context switches between the client application, the kernel and the X server.
But this only applies to a small number of applications. For most of them, the overhead is probably less than 1% of time taken by the application to do other stuff. And for the applications that require fast display updates, then there are several X extensions that have been specifically designed for that (e.g., DGA). Of course, using these extensions require more programming effort beyond what is provided by the common toolkits (Qt or GTK+) and you lose the cross-platform nature and network transparency of X, but it is possible to write fast applications based on X if you need to.
Let's see... Every day I have two or three XTerms on different machines from which I launch some editors (emacs, xemacs) and various graphical programs (purify, xcompare). Then I also have a mail client (sylpheed) running from yet another machine through ssh X forwarding and sometimes also a web browser (FireFox) running remotely from that machine. I even run the GIMP remotely at least once per week. And I do a lot of copy and paste between these applications running on different boxes. Basically, it would be hard for me to work without the network transparency offered by X. Should I also mention that these boxes run different operating systems (Linux, Solaris, FreeBSD) and use different processor architectures?
Granted, I may not be a typical user and as you pointed out, some Slashdot visitors are likely to do unusual things. But for me, relying on X to work accross the wire is not very rare - it's what I need every day.
So the fact that KDE and GNOME rely on X is a feature, from my point of view. I wouldn't mind if a replacement for X would be added as an option, but I don't think that I would use it.
Yes. This is precisely why a patent application is divided into several claims: the first one is always as broad as possible, and the following ones are usually derived from the first one and get narrower and narrower in scope. There can be more than one independent claim in a patent application, but they are also usually followed by several other claims depending on them with a narrower scope.
The goal is that if one of your claims with a broad scope is rejected during the patent application process or invalidated later by a court, then the following ones will still be in full effect if a potential infringer is still within the scope of these dependent claims. If the broader claim is accepted, then you win big. If the broader claim is invalidated but a narrower one still applies, then you don't win as much (because there will be less potential infringers) but you can still get something out of the patent.
To put it simply, the game goes like this:
In this case, I doubt that the first claim would be accepted by the patent office because of extensive prior art. But the following ones might be accepted, although I have some serious doubts about the inventive step. But even if this patent application looks ridiculous, there is a chance that some of its claims might survive.
Yes, thanks for the explanation. This is exactly what I meant in my previous comment: the "details" can be a car or bike, the usual behavior of the person to be tracked or as a last resort some things that make that person stand out from a crowd such as a hat, suitcase, ...
Anyway, even if a satellite could be used for tracking a single person, it is unlikely that any spy agency would waste its satellite budget on that. As you and others have correctly pointed out, it's just not worth it. It would be much more cost-efficient to use spy planes, balloons, drones or simply a bunch of people on the ground to do that.
With a resolution of 5cm (2 inches) or 10cm (4 inches), the spy satellites can certainly track people. Source: Resolution of a Spy Satellite.
Note that a satellite does not have to be able to recognize your face to track you (it is hard to see it from the sky anyway). You can be identified by many other details.
Congratulations, you have just re-invented TCP with selective acknowledgments (a.k.a. SACK, RFC 2018, published in October 1996).
For more discussion on this topic, see also: http://www.icir.org/floyd/sacks.html.
Or rather: the protocol is built on top of UDP, meaning that it will only be implemented at the application layer. There are other fine protocols built on top of UDP, such as RTP/RTCP used for streaming. Are there any operating systems implementing these protocols in the kernel? I don't think so. Are there libraries providing a convenient API allowing application developers to use these protocols easily? A few, but not that many. It is likely that any other protocol implemented on top of UDP would have a similar fate.
You don't seem to understand that most network operators (those who play with the routers at your ISP or somewhere else in the backbone) want protocols to be fair. If too many people start using a protocol that is unfair, then many ISPs will start tweaking their routers and firewalls in order to limit the bandwidth available to the unfair protocol. ISPs have to keep their customers happy (or at least happy enough to pay their bill) and an unfair protocol would make many other customers unhappy.
You are almost correct, except that doing the error correction on the whole file instead of a single (or a couple of) packets allows the file to be transmitted even if one or several packets are dropped.
However, this kind of error correction is only good if you are exchanging rather large files. They cannot claim to replace TCP if their protocol cannot be used for any kind of interactive work. Take for example SSH or HTTP (the protocol that we are using for reading Slashdot): they are both implemented on top of TCP and they require TCP to work equally well for exchanging small chunks of data (keypress in an SSH session, or HTTP GET request) and exchanging larger chunks of data (HTTP response).
While their new protocol would probably work well for the larger chunks of data, it is very likely to reduce the degrade the link performance for the smaller bits exchanged during an interactive session. So they are probably good for file sharing. But TCP has many other uses...
Also, they mention that they can be TCP-friendly by transmitting in "waves". I doubt that these "waves" can be very TCP-friendly if their time between peaks is too short. One thing that TCP does not do well is to adapt its transmission rate to fast-changing network conditions. So if they allow the user or the application designer to set the frequency of these waves, they could end up with a very TCP-unfriendly protocol.
I'm sorry, but according to the linked page, the correct distance is is about 35,800 km. Which means about 22,000 miles.
The funny thing is that you can get the answer straight out of the Google calculator:
Or if you want the answer in miles:
See how the Google calculator is useful? In this case, I just had to type Kepler's formula given on the page that you linked to and I got the answer!
So they were just 22,265 miles off...
Of course not. Unless you are interested in selling your products in China, that is.
The fact is that Microsoft (and many other companies, for that matter) would very much like to sell their products in China, so they have to please the Chinese government. Or at least not anger them.
It is easier to remember that a standard piece of paper is 21 cm by 29.7 cm.
In addition to the link in my previous comment, here is a convenient list of links to the very nice MEP analysis site created by Christian Beauprez. I hope that he will forgive me for any slashdotting:
Check how your elected representatives have supported patents so far, and decide how to vote in a few days.
Slashdot readers from countries such as UK, Germany or Spain have a lot of work to do! Talk to your friends, family, coworkers and MEPs and try to change the tide...
There is a link to a list of other countries on the page that you linked to. It doesn't have a detailled commentary and analysis, but this is good enough to have an overview of who voted against patents.
If you are living in Europe, take a look at the chart for your country and see who you should vote for. Personally, I am glad that the MEPs that I voted for in the previous election have clearly voted in favor of the FFII and against patents (i.e., they got a high score in the chart). I will vote for them again in a few days.
The consumer magazine Test-Achats/Test-Aankoop in Belgium has reviewed this item in its current issue. You can find the full article on their web site, although it is only accessible for subscribers.
In summary, here is what the article says about this "robot" that irons your clothes: the quality of the results is not that good, there are still some wrinkles left in the shirts (this is OK if you wear them under something else, but not if you want to look smart wearing only a shirt). They gave it an "average" rating for the quality, while most of the traditional irons get a "good" or "very good". One of the main selling arguments for this expensive item is that it irons your shirts for you while you can do something else during the 10 minutes that it takes to do its work. But in practice, you need 2 minutes to put the shirt on and 2 minutes to remove it once it is ready. So if you have several shirts this device lets you do something else for one hour, but only in slices of 10 minutes so this is not ideal.
So it does not beat the good old low-tech iron...
They are scammers, not legitimate businesses. They steal text and images from other sites. As others have already mentioned, you can use Google to search for some parts of the text on their pages and you will usually find the real source of the content.
It is also interesting to check where the images are coming from. For example, take a look at one of these fake sites: "Trust Meridien". The home page contains a link to the so-called professionals who are supposed to run this fake company: http://www.trustmeridien.com/directors.htm.
Take a look at the second picture. This woman is supposed to be called "Elizabeth Gideon". However, the name of the image file is: Kay_ivey1.gif. The name does not seem to match. Indeed, a little googling allowed me to find an identical copy of the image: Kay_ivey1.gif. That one is linked from the home page of http://www.kayivey.com/, who is the Alabama State Treasurer. The scammer did not even bother changing the name of the file!
I am sure that someone could find the source of the other images included in that page. Anyway, if you still had any doubt that the site is not a legitimate business, I suggest that you get in touch with Kay Ivey and ask her if she is really part of "Trust Meridien". Or maybe she has a twin sister?
Indeed, MDI for image editing can make sense. To some extent, this is already what many people are doing by dedicating a virtual desktop to the GIMP (except that the menu bar and status bar cannot be shared between all windows and other space-saving features of MDI are not available).
Most of the commercial image editors use some kind of MDI model becauses it makes sense: working with images often requires several images of different sizes to be visible at the same time and it should be easy to work on all of them without accidentally clicking on other windows. At the same time, most users prefer to avoid having dozens of "tasks" (windows) visible in the main task bar, so grouping all image windows into a single MDI container can help.
As a GIMP contributor and one of the few supporters of an MDI option for the GIMP, I encourage you to have a look at the lengthy discussions in Bug #7379. But please do not add comments to this bug report unless you really have something new to add because most of the issues have already been discussed for too long.
Yep. I still have several boxes full of them (in Belgium). Most of them are in good shape, although some metallic parts are a bit rusty now (damn wet cellar!).
These were wonderful toys. I started with the basic sets when I was rather young (I think it was in 1974 - I was 4) and then got the more advanced sets as I was growing. I eventually got several electronics sets and those that allowed me to play with some basic IC chips, such as the 7400, 7404 and others. That's probably what got me interested in electronics and computers.
I built several small robots with them (well, things that had blinking lights, motors and several switches and light sensors - nothing very complex on the logic side). I also built a rather dangerous thing with Fischertechnik and some rubberband: a crossbow that could fire small darts. It had three light sensors and it could rotate automatically if it detected a difference in lighting (e.g., shadow from someone or some object in front of it). It would orient itself towards the object and then fire. My parents were not amused, especially when they saw that it worked as advertised and needed a tool to remove a dart from the door frame... So I had to disassemble it quickly. I also built several more useful and more peaceful things with these great toys. I remember that I used them in a school project.
I thought that they had stopped producing them, but I see that there is a web site about Fischertechnik including a list of dealers, new products, etc.
I am not aware of patents covering the CMYK->RGB conversion. There may be some patents about the RGB->CMYK conversion because it is not always easy to find the best way to generate the right amount of K (black), but even for this case I am not sure that any valid and relevant patents exist in that area.
As a software developer, it is better to ignore patents anyway: do not waste your time checking if an area is covered by patents, unless your lawyer tells you explicitely that some patents cannot be ignored. There are many reasons for that:
So I doubt that there are any patents in this area that would prevent the GIMP from having a good CMYK support. And even if there are any, then I will not actively look for them and please do not tell me about them.
<pedantic>Well, there is no gimp-2.0 for any platform yet. We are only talking about a pre-release here.</pedantic>
This pre-release version (2.0-pre1) is not very different from version 1.3.23, which is available for Windows in a convenient installer from Jernej Simoncic's page. The release of the source code is rather new and it will take a few days until binaries are available for all platforms, but you can probably expect a 2.0-pre version for Windows soon.
No, the plans have changed last year. There was a debate among the developers about whether the next stable release should be called 1.4 or 2.0, and the decision was to call it 2.0. It does not have the native CMYK support (only export), but it has many other new features. Also, the internal structure of the program has changed so much that a major change in the version number was considered useful. Even if the end users do not see some of these changes, they are very significant for script and plug-in authors and the improved structure and documentation of the code should make it easier for new developers to contribute to the GIMP.
A bit of background (if you are interested): after the GIMP developers' conference in 2000, the plans were to have CMYK support in GIMP 2.0. These plans for "the future of the GIMP" were published and were often refered to (in newsgroups, mailing lists and even here on Slashdot), until the middle of last year. At that time, the discussion started about how the new version should be called and it was decided to call it 2.0. This decision was confirmed at the 2003 edition of the GIMP developers' conference. Even if those who were expecting native CMYK in 2.0 will have to wait until the next release, I think that most users will be very happy with the new GIMP.
Yes, the current interface of the GIMP (already much improved since the GIMP 1.x days) is very nice if you have a window manager that provides multiple desktops or virtual workspaces. This is good for most Unix users with modern window managers. But it is not as easy to use under Windows because all applications have to share the same workspace. An option for some users is to install some third-party Windows software that provides multiple virtual workspaces, but some users cannot or do not want to install such software.
In any case, even if the current interface is still not ideal when you do not have multiple workspaces, it is easier to use than the 1.x versions. And the best way to know if The GIMP is difficult to use or not is to try it yourself! You may also want to read some books such as Grokking the GIMP. That book was written for GIMP 1.2 and the interface has changed since then, but most of the concepts are still valid so it provides a good introduction to the GIMP.
You are right. Supporting native CMYK (or L*a*b or HSV or CieXYZ or ...) without conversion to/from RGB while editing requires the GIMP to support multiple color spaces and optionally multiple bit depths for higher precision. This will be done in the next major release of the GIMP by using GEGL, a library designed for supporting many different color spaces and transformations between them. It will take a while until all tools in the GIMP are converted to use GEGL, but this is what we are aiming for...
The current CMYK support in The GIMP 2.0 is rather basic, but it will hopefully already be sufficient for several GIMP users.
There are several screenshots of version 1.3 (pre-2.0) of the GIMP on the developer's site: http://developer.gimp.org/screenshots.html.
Other screenshots of version 2.0 will be available later, when the new GIMP web site goes live.
There are several reasons why the GPL is attacked by SCO: