Adobe owns the Illustrator name. It's not "Adobe Illustrator", it's "Illustrator". It's been around for ages and while not the best product in my eyes it certainly is better at this point that the K-version.
The same trademark lawyers who are acting now have registered a German trademark (back in 1989, I think), not for 'Illustrator' but for 'Adobe Illustrator'. 'Illustrator' is a German word, too.
In Germany, you cannot register trademarks which are describing for the product or service being trademarked. Now 'Illustrator' is certainly not describing for computer programs in general (that's the class in which the trademark was registered, with an exception of computer programs for dispersing beryllium in the atmosphere, which is kind of funny), only if you look at drawing programs. So the trademark might be effective even if 'Illustrator' is a describing term for what the program does (or can be used to perform).
The main point, however, is that the people christening 'KIllustrator' were heading for trouble from the beginning, and they should have known it. This is not some obscure trademark appearing after years, but the KDE developers were certainly aware that a program of this name existed which did the same job, basically. Even if the 'Illustrator' trademark is invalid (nobody knows at this time...), it is still a very, very time-consuming and cost-intensitive process to get it canceled. Since Adobe's lawyers seem to have targeted the university, it's likely that the university will obey and pay the fine, and then threaten to sue the responsible member of the university, so it's a even more complicated situation.
Did van Gogh really paint tulips with ripples? It seems that the ripple effect used for the real ripples has a strong impact on the derived filter and dominates the result. In addition, the ripples do not follow the natural lines in the image.
I think manual filters are still much better, oops, I wanted to say: nothing can replace a real van Gogh.
This idea, together with its realisation, is much older than actual force-feedback joysticks because the implementation is so easy. IIRC, with a small and simple extra device, the line printer port can be abused to deliver electric shocks to computer users, and quite a few people used that to implement their perverted ideas.
(We probably won't see such a commercial product in Germany anyway because of strict consumer protection laws.;-)
I don't the people behind Google are just covering their asses. After all, a variation of this disclaimer which would limit the use of the postings to the Google Groups service (i.e. Usenet search and presentation over the Web) would do that as well, and the majority of postings served by Google Groups has not been posted through their interface. Perhaps they think that there might be an additional use of the postings injected through their infrastructure in the future, such as publishing a book. For postings of their customers, they would have the necessary license to do that, but I know of several people who would be very, very upset if their valueable Usenet postings show up in books without compensation for them.
Finally, it is quite customary to post copyrighted material for which one doesn't have the full rights under copyright, for example excerpts from GPLed source code written by other people or short quotes from your favorite novel.
If you rent software in some countries, you might be responsible for keeping it in good shape and fixing bugs. Maybe Microsoft has finally discovered this and reacted accordingly.
However, the current scheme of selling licenses without time limit can be extended to a subscription scheme without actually renting software: just release a new Office version every year, and make sure that it's slightly incompatible. In fact, Microsoft announced this kind of strategy back in 1995 or so (of course, not the incompatibility part), but they didn't manage to release their software more regularly for some reason.
I think a language should support enumeration types because they are such a handy abstraction and can be implemented efficiently. I know that using OO methods, you have replacements for them in some contexts.
However, if you're going to replace enumeration values with fully grown objects, you kill performance on most architectures. For example, the TeX Java reimplementation effort, NTS, replaces each enumeration type with a class (to achieve type safety), and this contributes to the phenomenon that NTS is about hundred times slower than the original.
So far, your proposal lacks enumeration types (which are essential for meaningfull case statements) and distinct scalar types (so that you can't exchange row and column indices without a type conversion).
In addition, in contrast to Ada, I think exceptions with a parameter (of scalar type) would be a good idea. The solution used by POSIX.5 to cope with the many POSIX error conditions is certainly not optimal.
And if you're going to make this an Open Source language, make sure that your implementation of it can't use libraries unless you've got complete source code for them, like GNAT does.
Actually, it's pretty easy to misuse a dangerous C++ feature accidentally. Many C++ programmers still use the low-level C arrays without proper bounds checking.
And BTW, if you're looking for a language which makes sure you don't do any dumb things during your regular work, but also lets you go down to the individual bits if you want to, check out Ada. It's quite a good compromise: the dangerous language elements mainly have "Unchecked_" in their names, and they're syntactically separated from the the ordinary stuff so that you don't use them accidentally.
This is wrong. My Usenet postings are certainly not public domain, even if I wished they were: according to German copyright law, a work cannot enter the public domain unless the author has been dead for 70 years.
Posting something on on Usenet probably shows your consent to some ways of distributing it. But people get rather upset if, for example, their work is used in a book without their permission. Some authors (e.g. of FAQs) even limit redistribution explicitely.
BTW: Does anybody know why about one third of the articles has a score of 4 and above? Is anybody an expert in Usenet matters nowadays?
Wasted memory bandwidth and SMP
on
Pentium IV study
·
· Score: 2
Hardly anybody cares about wasted memory bandwidth on a single processor machine, as long as it doesn't affect performance (and the data doesn't suggest this).
However, suppose you've got a SMP machine with four CPUs, I guess you'll get into big trouble. The Intel architectures are not really known for impressive I/O bandwidth, and if the memory subsystem has to deal with 1.6 GB/sec instead of 400 MB/sec, performance is probably affected.
So Intel should fix this rather quickly. May be this is thust an optimization issue, the 32 byte cache line is rather old and many programmers have adjusted their data structures accordingly because you can gain a few percents just by looking closely at the data access patterns. More recently, Intel has added explicit cache line prefetch instructions, and if these are used improperly (assuming 32 byte cache lines), the effect can be pretty devastating on the P4, I guess.
GVD, the GNU Visual Debugger,
is a graphical frontend for your favorite debugger (it comes with GDB support, but you can add other debuggers pretty easily, too). Written in Ada to debug Ada programs (where multitasking support have been part of the programming language for ages), GVD presents multiple threads of control in a usable manner. However, GVD is still quite young, so there might be some rough edges.
On the other hand, I've experienced that LinuxThreads (the thread implementation provided by GNU libc) and GDB don't mix too well. Maybe you can try another pthreads implementation, for example the one from Florida State University (FSU Threads).
A marginal speed increase in some benchmarks related to desktop applications is hardly significant and can easily be attributed to differences in the chipset, different BIOS settings for memory timing, and so on.
If RDRAMs are indeed faster than SRAMs, you'll see that in situations where high memory bandwidth is essential. For example, a comparison on a large SMP database server could be really interesting. Usually, desktop applications do not have these memory bandwidth requirements. Even for so-called multimedia applications, the PCI bus bandwidth is the limiting factor most of the time.
FTP servers have a long history of security issues, but they are still ubiquitous. For example, our university network consists of over 10,000 hosts, and approximately 2,000 of them is providing FTP services, of which a huge number even permits anonymous access. For several reasons, it wasn't possible to block incoming FTP connections at the main router in the past, but AFAIK there's a strong commitment to reduce the number of FTP hosts considerably (read: to 20 or so), which are well-maintained and cut off from the rest of the university network.
Telnet servers are even more widespread in our network. Unfortunately, telnet is completely insecure. Passwords and entire sessions can be eavesdropped quite easily, and it's even possible to hijack telnet sessions.
I think other universities have similar problems, and there for a cry for banning FTP and telnet seems reasonable.
De facto, you can patent anything as long as you state your claims in a way which is complicated enough.
For example, some guys filed a patent for the concept of standard byte order in the late 80s, although this concept has been used by the Internet Protocol for a long time. They even dared to cite the NFS specification as a reference!
I'm all for it if they block incoming and outgoing TCP port 25 traffic.
There are so many open relays and even UCE senders in China, and I'm sick of all the UCE from there. (Some sites do already block *.cn for mail.) Legitimate mail (no UCE) can probably be sent over other channels (even if it's a government proxy, which would mean that the government shows that it's watching it's netizens and people will know that they have to use media other than plain email for sensitive communication).
Some people use wildcard MX records to track the use of their addresses.
Quite frankly, I don't see what's so hot about this idea. It's not very important whether the session ID is in the domain name or not. You can always hack your web server and tell it to discard the session ID when translating URLs to file system references or similar things. Browsers would keep sending the session ID to the server as long as you use relative links.
In addition, you don't know what's really contained in these session IDs, and DNS requests aren't encrypted even if you use SSL...
Finally, it's said that a noticable portion of Internet traffic is already DNS traffic, and this technology, if widely adopted, is likely to increase DNS traffic for no good reason.
Remember that "Free Internet Access" in Germany means that you still have to pay for the phone line. Of course, even in Germany, there are Internet provider which offer access at rates well below those of ordinary city call, which means that this offer is not very interesting at all, it's just about marketing.
In the end, it's nothing that spectacular: it's about identifying public and and unencrypted secret key data in a stream of bits with lots of other data. Although it seems as if nobody has thought about this kind of attack before, other forms of attack, based on additional characteristics of the key (for example, that it is contained in an OpenPGP packet), were certainly known, and it is quite likely that systems designed to be immune against this kind of attack (i.e., by employing tamper-proof hardware or storing critical key material on a strongly protected separate server) will resist the new (old) one as well.
Of course, only few people in the modern e-commerce world care about security on their sites, so some media attention, although a bit late and a bit exaggerated, is always a good thing.
(The amount is an inside joke: 256 equals 2 to the 8th power-the number of values a byte can represent.)
This would be a nice analogy nowadays, but when Knuth started to write TAOCP, the equation `eight bits = byte' was far from being universally true. For example, a byte of the MIX computer must be able to hold a minimum of 64 distinct values and at most 100.
The same trademark lawyers who are acting now have registered a German trademark (back in 1989, I think), not for 'Illustrator' but for 'Adobe Illustrator'. 'Illustrator' is a German word, too. In Germany, you cannot register trademarks which are describing for the product or service being trademarked. Now 'Illustrator' is certainly not describing for computer programs in general (that's the class in which the trademark was registered, with an exception of computer programs for dispersing beryllium in the atmosphere, which is kind of funny), only if you look at drawing programs. So the trademark might be effective even if 'Illustrator' is a describing term for what the program does (or can be used to perform).
The main point, however, is that the people christening 'KIllustrator' were heading for trouble from the beginning, and they should have known it. This is not some obscure trademark appearing after years, but the KDE developers were certainly aware that a program of this name existed which did the same job, basically. Even if the 'Illustrator' trademark is invalid (nobody knows at this time...), it is still a very, very time-consuming and cost-intensitive process to get it canceled. Since Adobe's lawyers seem to have targeted the university, it's likely that the university will obey and pay the fine, and then threaten to sue the responsible member of the university, so it's a even more complicated situation.
Did van Gogh really paint tulips with ripples? It seems that the ripple effect used for the real ripples has a strong impact on the derived filter and dominates the result. In addition, the ripples do not follow the natural lines in the image.
I think manual filters are still much better, oops, I wanted to say: nothing can replace a real van Gogh.
This idea, together with its realisation, is much older than actual force-feedback joysticks because the implementation is so easy. IIRC, with a small and simple extra device, the line printer port can be abused to deliver electric shocks to computer users, and quite a few people used that to implement their perverted ideas.
;-)
(We probably won't see such a commercial product in Germany anyway because of strict consumer protection laws.
I don't the people behind Google are just covering their asses. After all, a variation of this disclaimer which would limit the use of the postings to the Google Groups service (i.e. Usenet search and presentation over the Web) would do that as well, and the majority of postings served by Google Groups has not been posted through their interface. Perhaps they think that there might be an additional use of the postings injected through their infrastructure in the future, such as publishing a book. For postings of their customers, they would have the necessary license to do that, but I know of several people who would be very, very upset if their valueable Usenet postings show up in books without compensation for them.
Finally, it is quite customary to post copyrighted material for which one doesn't have the full rights under copyright, for example excerpts from GPLed source code written by other people or short quotes from your favorite novel.
If you rent software in some countries, you might be responsible for keeping it in good shape and fixing bugs. Maybe Microsoft has finally discovered this and reacted accordingly.
However, the current scheme of selling licenses without time limit can be extended to a subscription scheme without actually renting software: just release a new Office version every year, and make sure that it's slightly incompatible. In fact, Microsoft announced this kind of strategy back in 1995 or so (of course, not the incompatibility part), but they didn't manage to release their software more regularly for some reason.
I think a language should support enumeration types because they are such a handy abstraction and can be implemented efficiently. I know that using OO methods, you have replacements for them in some contexts.
However, if you're going to replace enumeration values with fully grown objects, you kill performance on most architectures. For example, the TeX Java reimplementation effort, NTS, replaces each enumeration type with a class (to achieve type safety), and this contributes to the phenomenon that NTS is about hundred times slower than the original.
So far, your proposal lacks enumeration types (which are essential for meaningfull case statements) and distinct scalar types (so that you can't exchange row and column indices without a type conversion).
In addition, in contrast to Ada, I think exceptions with a parameter (of scalar type) would be a good idea. The solution used by POSIX.5 to cope with the many POSIX error conditions is certainly not optimal.
And if you're going to make this an Open Source language, make sure that your implementation of it can't use libraries unless you've got complete source code for them, like GNAT does.
Actually, it's pretty easy to misuse a dangerous C++ feature accidentally. Many C++ programmers still use the low-level C arrays without proper bounds checking.
And BTW, if you're looking for a language which makes sure you don't do any dumb things during your regular work, but also lets you go down to the individual bits if you want to, check out Ada. It's quite a good compromise: the dangerous language elements mainly have "Unchecked_" in their names, and they're syntactically separated from the the ordinary stuff so that you don't use them accidentally.
This is wrong. My Usenet postings are certainly not public domain, even if I wished they were: according to German copyright law, a work cannot enter the public domain unless the author has been dead for 70 years.
Posting something on on Usenet probably shows your consent to some ways of distributing it. But people get rather upset if, for example, their work is used in a book without their permission. Some authors (e.g. of FAQs) even limit redistribution explicitely.
BTW: Does anybody know why about one third of the articles has a score of 4 and above? Is anybody an expert in Usenet matters nowadays?
Hardly anybody cares about wasted memory bandwidth on a single processor machine, as long as it doesn't affect performance (and the data doesn't suggest this).
However, suppose you've got a SMP machine with four CPUs, I guess you'll get into big trouble. The Intel architectures are not really known for impressive I/O bandwidth, and if the memory subsystem has to deal with 1.6 GB/sec instead of 400 MB/sec, performance is probably affected.
So Intel should fix this rather quickly. May be this is thust an optimization issue, the 32 byte cache line is rather old and many programmers have adjusted their data structures accordingly because you can gain a few percents just by looking closely at the data access patterns. More recently, Intel has added explicit cache line prefetch instructions, and if these are used improperly (assuming 32 byte cache lines), the effect can be pretty devastating on the P4, I guess.
On the other hand, I've experienced that LinuxThreads (the thread implementation provided by GNU libc) and GDB don't mix too well. Maybe you can try another pthreads implementation, for example the one from Florida State University (FSU Threads).
Is it already suitable for production use? I think it was not mentioned in the FreeBSD 4.0 release notes for a reason.
What's the point? If a lake has a noticeable impact on weather, it's not very surprising a city of similar or bigger size does influence weather, too.
A marginal speed increase in some benchmarks related to desktop applications is hardly significant and can easily be attributed to differences in the chipset, different BIOS settings for memory timing, and so on.
If RDRAMs are indeed faster than SRAMs, you'll see that in situations where high memory bandwidth is essential. For example, a comparison on a large SMP database server could be really interesting. Usually, desktop applications do not have these memory bandwidth requirements. Even for so-called multimedia applications, the PCI bus bandwidth is the limiting factor most of the time.
FTP servers have a long history of security issues, but they are still ubiquitous. For example, our university network consists of over 10,000 hosts, and approximately 2,000 of them is providing FTP services, of which a huge number even permits anonymous access. For several reasons, it wasn't possible to block incoming FTP connections at the main router in the past, but AFAIK there's a strong commitment to reduce the number of FTP hosts considerably (read: to 20 or so), which are well-maintained and cut off from the rest of the university network.
Telnet servers are even more widespread in our network. Unfortunately, telnet is completely insecure. Passwords and entire sessions can be eavesdropped quite easily, and it's even possible to hijack telnet sessions.
I think other universities have similar problems, and there for a cry for banning FTP and telnet seems reasonable.
Don't run this script if you don't trust your local users. It can have some funny effects if they use file names with embedded spaces.
De facto, you can patent anything as long as you state your claims in a way which is complicated enough.
For example, some guys filed a patent for the concept of standard byte order in the late 80s, although this concept has been used by the Internet Protocol for a long time. They even dared to cite the NFS specification as a reference!
(The US patent number is 4,956,809, BTW.)
I'm all for it if they block incoming and outgoing TCP port 25 traffic.
There are so many open relays and even UCE senders in China, and I'm sick of all the UCE from there. (Some sites do already block *.cn for mail.) Legitimate mail (no UCE) can probably be sent over other channels (even if it's a government proxy, which would mean that the government shows that it's watching it's netizens and people will know that they have to use media other than plain email for sensitive communication).
Well, almost.
Some people use wildcard MX records to track the use of their addresses.
Quite frankly, I don't see what's so hot about this idea. It's not very important whether the session ID is in the domain name or not. You can always hack your web server and tell it to discard the session ID when translating URLs to file system references or similar things. Browsers would keep sending the session ID to the server as long as you use relative links.
In addition, you don't know what's really contained in these session IDs, and DNS requests aren't encrypted even if you use SSL...
Finally, it's said that a noticable portion of Internet traffic is already DNS traffic, and this technology, if widely adopted, is likely to increase DNS traffic for no good reason.
Remember that "Free Internet Access" in Germany means that you still have to pay for the phone line. Of course, even in Germany, there are Internet provider which offer access at rates well below those of ordinary city call, which means that this offer is not very interesting at all, it's just about marketing.
In the end, it's nothing that spectacular: it's about identifying public and and unencrypted secret key data in a stream of bits with lots of other data. Although it seems as if nobody has thought about this kind of attack before, other forms of attack, based on additional characteristics of the key (for example, that it is contained in an OpenPGP packet), were certainly known, and it is quite likely that systems designed to be immune against this kind of attack (i.e., by employing tamper-proof hardware or storing critical key material on a strongly protected separate server) will resist the new (old) one as well.
Of course, only few people in the modern e-commerce world care about security on their sites, so some media attention, although a bit late and a bit exaggerated, is always a good thing.