My problem with Rational: Anything they haven't bought (they bought purify and clearcase) doesn't exist for non-windows platforms. There will never be a linux purify, clearcase, or rose. Therefore, one can conclude there will never be a linux j++.
Minor correction: Rational has announced that they will release ClearCase for Linux. However, it won't be the full ClearCase, but only "ClearCase Attache", which is a client that allows you to get a view of the ClearCase VOB but not the full thing. You will still need a commercial UN*X server or Windows NT server to run ClearCase. That may be better than nothing, but not good enough. And anyway, it is not available yet.
I make extensive use of ClearCase, Purify and Quantify while writing software (at work). These are very useful tools, but unfortunately they are not available for Linux. Since the programs I write must run on several systems including Linux (the list includes Solaris, Windows 95/98/NT, Windows CE, EPOC), I ended up having to set up a cross-compiler to compile the Linux programs from a Solaris host that can use ClearCase. This still doesn't give me Purify and Quantify, but fortunately Linux and Solaris are similar enough to give me a reasonable confidence that something that has been Purify'ed under Solaris will also work well under Linux. But I digress...
Coming back to the main topic, I agree that Rational has not done much to support non-Windows platforms. On the contrary, they have almost stopped improving the UN*X version of the tools that they bought from Atria and Pure Software, while putting most of their efforts on the Windows versions. This does not look good for those who are expecting to see J++ for Linux...
As the article says, the next version of M$ Visual Studio will rely heavily on XML and will probably forget about Java.
At first, I didn't think much about this. But now I have bad feelings about M$ using XML. Sure, XML is a nice standard and I like many of its applications. But XML is only a markup language; this is not a real programming language. You can use standards such as the Document Object Model DOM (not to be confused with M$'s proprietary COM) to describe in XML (or in an XML derivative) how some actions should be performed on a document, but this is a limited kind of programming.
So if a programmer wants to get something powerful out of XML, the best solution is to define a XML-based markup language that allows you to embed calls to some system-specific components into your documents. And then you can say: "Look at this great set of applications that I just released! They are all based on XML, which is an open standard." That's nice, except that the XML derivative used by these applications is nothing but a glue around some proprietary components that will not work on any other system.
I don't know what M$ is planning when they are focusing on XML and dropping Java. But it could very well be that they use an open standard as a cover for producing more non-portable stuff that will run on nothing else but Windows (because their XML derivative will require Active X, DCOM, and so on). At least with Java, there was some hope to have portable applications, even if M$ tried to lock the developers into Windows-specific Java extensions...
A more troubling question is if the minors who've contributed code can even license it at all without their parent's consent.
This is a very interesting question, indeed. The answer may vary from country to country, but I expect that in most cases it will be simply: no.
In many countries, minors do not legally own anything. Everything belongs to their parents until they grow up and reach the age of 18 or so. So if you are a minor and you write a book, a musical masterpiece, or a very clever program, they all belong to your parents. From a legal point of view (this is all theoretical anyway), your parents are the only ones who have the rights to decide if the software should be released under the GPL or any other license.
Also, a license is a kind of contract, and both parties (the owner and the end user) have to agree to that contract before using or distributing the software. And that cannot be done by a minor.
Does this mean that if a kid buys MS Windows, or any other proprietary program, he/she is not bound by it's EULA?
No. The EULA gives you the rights to use the software and specifies under which conditions you are allowed to do that. Theoretically, you must agree on the EULA before using the software. Since the law in most countries does not allow kids to be bound by a contract (the EULA), then the kids are not allowed to use the program.
But of course, the parents of the kid can be bound by the EULA and allow her to use the program. Then the parents are responsible for letting the kid do whatever she wants with the program.
According to the law, there are many things that minors cannot do on their own. Agreeing on a EULA is just one of these things that require parental approval. Actually, now that I think about it, even agreeing on the GPL is something that a minor is not supposed to do.
That's right. Many countries have laws stating that minors cannot be bound by a contract. So a minor is not supposed to agree on the EULA - that's something that her parents should do.
I see no malice there - Corel is simply trying to be as careful as possible (too much, maybe?). They are not trying to prevent people from using Linux. I'm sure that some people at Corel do know that parts of the code on their CD has been written by minors.
If we used (for example) Red Hat Linux, it is my understanding that we can not just link to the source on the Red Hat website, as Red Hat is a "commercial" distribution. Is this correct?
No, it's not at all correct. The problem is that it is woefully insufficient because you are not distributing it. The fact that someone else has the source on a public ftp site doesn't exhonerate you from your obligation to make the source available.
There is another reason why you should always supply the source code (on a CD or from a ftp/www site) instead of linking to someone else's site: you must supply the source as it was used to build your system. If you made any modifications to some packages, then you have to make sure that your customers can get a copy of the source that includes all these modifications.
Also, if you link to someone else's site, you cannot be sure that all packages will remain there for the next three years (as required by the GPL). The other company (RedHat in this case) is free to change the layout of their site, or to simply stop distributing some packages (because they already supply the sources on CD, so they are not required to distribute them via ftp/www). Or RedHat could also replace these packages by newer versions. In most cases, the users would be happy to get the latest version, but what if the new version of some package is incompatible with some of the other packages that come pre-installed on the system that you are selling?
For all these reasons, it is important that you provide the sources on your own ftp/www site or on a CD.
I will leave the GNOME vs. KDE flamebait aside, because my comment was not about the desktop environment, but about the widget library only. Locking your application into a specific desktop environment is even worse for its portability than using a widget library that is not freely available for all major operating systems. Please, let's stick to the Qt issue without involving KDE.
Qt has some nice widgets that GTK+ does not have yet; I will not debate that. GTK+ also has some nice widgets that Qt does not have yet, but that is not the point. My main gripe against Qt is that it is not free enough if you want to port your applications to Windows or to other operating systems. GTK+ offers something more than Qt: its portability. Some major applications based on GTK+ (e.g. The GIMP) have been successfully ported to Windows (and even OS/2 and BeOS). If the GIMP had been built on top of Qt, that would not have been possible.
Since QCAD is built on top of Qt, I doubt that we will see a Windows version soon. Or at least not a free version. Not to mention other (more exotic) operating systems. If you are writing some code based on Qt, then some people will not be able to use it, and may not even be able to port it to their system if they have some coding skills. Some of the small tools that I wrote a few years ago were ported to other OS'es by various people, and some of these became more popular than the original version that I developed. This is the power of OpenSource. Alas, QCAD and other applications requiring libraries that are not available on all platforms will suffer from this and will not be available to everybody.
Hi! Here is the point of view from a random developer who has also decided to remove Qt from his PC...
The license in Qt 2.0 is much better than in the previous version (and accepted as being OpenSource) but the previous license caused me to dislike Qt very much and I would need a good reason to get back to it. "Once bitten, twice shy."
Also, there is no free version of Qt 2.0 for Windows. This is very important from my point of view: even if the license for the Linux version of Qt is good, the only version available for Win32 is rather expensive and prevents most developers from porting their applications to both systems. Of course, someone could develop a free Qt for Windows, but that does not exist yet. I do not want to install a library on my system if I know that any application that I write using this library (free under Linux) would become non-free under Windows.
In the meantime, GTK+ has reached its maturity level and I consider it to be superior to Qt (on a feature level). And GTK+ is available for free on several platforms, including Windows and OS/2. Another reason why I like GTK+ is that it does not tie the developer to C++. GTK+ can be used with C, C++, Perl, Python and other languages, while the support for other languages in Qt has been lacking for a long time (only partial implementations). So if I can do more with GTK+ than with Qt, why would I re-install Qt on my system?
Sorry, but for the moment Qt is still on my black list. In order for me to adopt Qt, it would need to be available for free (speech and beer) under Windows and to provide good bindings for ANSI C (not C++) and Perl.
The distributed attacks are certainly not a new phenomenon. ICMP smurfing is probably the best example of a distributed attack that is entirely automated and usually not detected by the third parties that are unvoluntarily involved in the attack.
However, the distributed attacks are becoming increasingly easy to perform, mostly because it is easier for script kiddies to get access to hundreds of poorly protected home computers from which they can launch their attacks. This happens because more and more computers are "always connected" (thanks to cable modems) and because most software vendors do not educate their users with some basic security hints. They do not want their customers to be scared away when they discover that the security issues on a computer are more complex than they thought. So it is usually in the vendor's best interest to ignore the risks of connecting a computer to the Internet.
Anyway, the article should not present this as something new. Something that becomes more frequent or harder to detect, maybe. But new, certainly not.
Of course, one could also wonder why these articles about cyberterrorism and various kinds of attacks involving the Internet are becoming more frequent in the mainstream press. As one of the talkback comments mentioned, maybe some people or some government agencies would like to use these reports to justify the need for stronger control over what is exchanged on the Internet.
After reading the MainWin overview on MainSoft's site, it is obvious that it is just another Win32 emulation layer, similar to Wine for Linux or Wabi for Solaris. Of course, they state on their page that MainWin is not an emulator. But all it does is to translate Win32 API calls to something that runs under Linux. The calls are executed in the MainWin layer (thanks to the Windows source code that they can use) or translated to Linux system calls. By the way, MainWin is already available for many UNIX systems, and they are just adding Linux to their list.
How is this different from Wine? On the negative side, it is closed source and probably quite expensive. On the positive side, the fact that they have access to the Windows source code means that they might be more compatible with all the undocumented Win32 features that are used by some MS applications.
I don't think that there is anything really exciting about this announcement. Win32 emulators have existed for quite a while on various UNIX systems, and all of them have their drawbacks. This one might be better in some areas and worse in some others, but it will never replace a native port of the applications to Linux.
If MicroSoft (not MainSoft) starts publishing press releases encouraging developers to work only on Win32 because it is portable to all environments including Linux, then we may have something to respond to. But I don't think that any serious company would stop porting their products to Linux because some small company provides a (closed and expensive) emulation layer for Win32 apps.
A link to that very interesting site was posted in July 1998, so this is not really new for those who have been on/. for more than a year.
Several interesting links were posted among the replies to that story. I will re-post a few of them here, so that you do not have to browse through the old messages:
Follow these links if you are interested in user interfaces (mostly for GUI). There is no lack of good advice on the net. This makes me wonder why we still see so many bad user interfaces in the latest programs (even in GNOME and KDE).
Use trial and error, compare input and output.
on
Reverse Engineering?
·
· Score: 5
There are at least two things that you can do when attempting to reverse engineer a piece of software. The first one (not legal in several countries) is to decompile the code: take a debugger or decompiler and check what instructions are executed. The second one (legal in most countries) is the "blackbox" approach: consider the software as something that produces some output(s) depending on its input(s), and try to guess what is inside.
This second approach is the "real" reverse engineering. By carefully crafting some inputs and observing the outputs, you can often draw some conclusions about how the software behaves. With some patience and a lot of trial and error on simple inputs, you can find some patterns in the software: stuff that does not change, stuff that changes depending only on one of the inputs, and so on.
In the good old days (well, five years ago), I was the author of DEU (Doom Editing Utilties), the first program that was able to create new levels for Doom. I also contributed to Matt Fell's Unofficial Doom Specs and Olivier Montannuy's Unofficial Quake Specs, the documents that describe the WAD and PAK file formats and other internal details about Doom and Quake. Almost everything in the Unofficial Doom Specs was gathered by reverse-engineering. It was only later (with the release of Doom II) that id Software released some information to the community, presumably after they saw that editing Doom levels was a very popular activity. I am grateful for id Software's support of the editing community in their later games, but the first informations about Doom had to be found the hard way.
Most of my efforts in decoding Doom's WAD file format (and later Quake's PAK file format) involved an hex editor for viewing and editing the raw files, and custom tools that I built along the way for making editing easier (or tools that I received from other people, like DEU 3.0 from Brendon Wyber). A key thing is also to share as much information as possible with other people who are progressing on the same front because you often get more in return than what you found by yourself. For WAD files, it was easy to find that the file was organized a bit like a tar archive: a header, a directory containing names of objects and offsets within the file, and the data for the objects. Then the trial and error starts: try to guess what an object might be, modify a few bytes, run the game and see what happens. If your changes produced something useful, write it down and share the info with others. If the game crashed, try again. Repeat until you have understood everything.
Sometimes, you will find data structures that you do not understand. That was the case for Doom's NODES, SEGS and SSECTORS data. If you share enough information with others, maybe someone will have an idea and find that the data structures are related to something that they know. This is exactly what happened for Doom: Alistair Brown and a group of students from Bradford suggested that the unknown data might be a BSP tree. After reading some papers on that topic (I didn't know anything about BSP trees), I was able to implement a first BSP builder in DEU. And then it became possible to create brand new levels for Doom, instead of only changing the textures and location of the monsters as we did in the first few months. Releasing the source code for the tools has probably helped a lot. Other people were able to create their own tools based on that, and then the next reverse-engineering steps became much easier when the other games based on the same engine were released (Doom II, Heretic, Hexen, Strife,...)
When you are given the opportunity to moderate, it would be nice to be also allowed to moderate the main story.
If a story gets moderated down as redundant by too many people, it would be removed from the main page (but still accessible from the search page or other cross-references). That could help a bit in reducing the duplicates that pop up from time to time on/.
For the main story, the effect of moderation would only be to hide the story if it gets many negative points. The score would not be displayed on the main page. Positive points would be ignored (except for cancelling the negative ones).
does anybody know of anything similar that will go in an x86 pc? By similar, I mean cool like AirPort, especially the 11mbs part.
For the 11 Mbps part, I'm not sure. There are some wireless LAN solutions available for PCs, but as far as I know they all require you to install a base station. The nice thing about AirPort is the ad-hoc networking: minimal setup, any machine can talk to any other machine without having to install extra hardware.
There are some rumours that some motherboards of x86 PCs may integrate BlueTooth chips in a few months. BlueTooth does not provide the same bandwidth as AirPort (100 times less), but it also provides the ad-hoc networking and it is supposed to be integrated in all kinds of devices, so that you could have your phone, your keyboard, your mouse, or any other device connected to your PC without wires and without requiring a line-of-sight like the IrDa stuff.
Now, what I'd like to see is someone running an operating system *entirely* out of cache. 8Mb should easily be enough to run a cut-down Linux, and definitely enough for the earlier MS operating systems...
It would certainly be possible to run Linux entirely in a 8Mb cache, since I have a PC that has only 8Mb of RAM (no swap, no disk) and runs Linux and some non-graphical applications smoothly.
But running the operating system at high speed is not enough: you need some applications too. Unless you have a way to lock the OS memory pages in the cache, they will not stay there for long because the cache will be used by the applications. And if you lock some pages in the cache, I expect that you will get a significant loss in performance if you have some applications doing a lot of non-localized memory accesses.
Conclusion: yes, it would be cool to be able to run the OS entirely out of cache, but that alone will not be very useful. Still, having a large cache for the OS + applications is a good thing.
And what about firewalls? The company I work for has about 20000 people all using the same external IP address.
Same for me. The company I work for has a bit more than 100,000 employees whose requests are distributed over a few proxies (2 in Europe, 1 in the US, 1 in Australia, and maybe one or two other proxies that I do not know).
It would be easy for anyone to abuse Slashdot and immediately prevent all others who have to go through the same proxy to post on the same day. Using the IP address for identifying the bad guys is not a good idea when some people have to share a proxy.
But on the other hand, it looks like the IP address is the only reliable way to stop the current abuses. Although it would be possible to be fair to the proxy users by checking the HTTP headers and looking for Via fields or modifications of the User-Agent field, these could unfortunately be faked by some script kiddies.
Maybe it would be possible to find a compromise: if some IP addresses are known to be used by many people using separate accounts (or Anonymous Cowards), then after a few weeks these IP addresses could be put on a special "proxy list". The threshold for banning posts from these proxies would be higher than the threshold used for single-user addreses. Or for these addresses, the rule would be different: it would prevent posting from ACs and any account that has a "bad karma" but not from the other accounts. So the registered users who contribute regularly to Slashdot would not be banned because of the wrongdoings of someone who happens to share the same proxy.
Sure, they have to find a fresh body without a head in order to perform the operation. I would not be surprised to see some surgeons suggesting that the airbags must be removed from all cars. That would provide them with an endless supply of bodies.
But what will they do with the old body once the head has been moved to the new one? Should it be buried (funeral, grave, and so on) or should it be dumped as waste?
I wonder if the information about the compromised accounts will ever be mentioned on the HotMail pages...
In the meantime, does anyone have more details about this? Specifically, I would like to know if the crackers stole a list of passwords or if they found a way to enter the site without using a password. In the former case, you would only have to change your password to be safe. In the latter case, you could hope that the HotMail staff would patch the hole quickly.
Considering the fact that a typical compurer becomes almost useless after three years, having yours seized for five years means that you will probably not be very interested in getting it back, except maybe for selling the metal.
Fortunately, Linux does not suffer from the same bloat factors as other operating systems, which means that you can run an up-to-date version of Linux on a computer that is more than five years old. But still...
Here are some ways to prevent people from abusing your site:
Have your server check the HTTP "Referer" field (in a CGI script, this is the HTTP_REFERER variable). If this field exists, is not empty, does not point to a file, and does contain the address of a site that is not yours, then reply with a HTTP redirection (301) message so that people are sent to your home page.
Use cookies. Your home page sets a cookie, and other pages check if it is valid. Note that you should set a persistent cookie, so that people who bookmark your pages can still access them later. If the cookie is not set, the user is redirected to your home page.
Change your URLs daily. This is easy to do for database-driven sites. It is also easy to do for static pages, if you have a script that renames the directories from time to time. But this will annoy the users who will not be able to bookmark your pages.
Use dynamic URLs that contain some information about the user (e.g. IP address) and a timestamp so that the URLs are only valid for one user during a limited time. But as with the previous solution, this will also prevent your users from bookmarking your site.
Require a password for accessing your site. This can be a free registration, like the New York Times.
Use JavaScript to check if your page has been included in another frame. This will not prevent "deep linking", but it will stop the abuse that you describe.
There are probably many other solutions to this problem, but this is what I was able to think about right now.
Note that some of these solutions (cookies, JavaScript) are not supported by all browsers or can be disabled by the user. But as long as the trick works for the majority and does not block the other users, your ad revenues are safe.
If you want to be able to share love letters with your girlfriend but not with the spies, you could have a look at RFC 1149 which suggest a solution that might be immune to the usual packet filters (or at least it makes the filtering a bit harder for the spies). I recommend that you have a look at the "Security Considerations" chapter in that RFC, for potential risks of that solution.
Note that RFC 1149 has recently been updated by RFC 2549 which provides additional Quality of Service considerations. This is something that you should care about if you want to be sure that your message is delivered before you have switched to another girlfriend.
"The fight over this could make the fight over encryption look like nothing," said Mary Culnan, an professor at Georgetown University who served on a Presidential commission whose work led to the May 1998 directive on infrastructure protection.
Actually, it seems that encryption would not help a lot in protecting your privacy. The first thing that the F.B.I. will do is to monitor "patterns" and check for unusual stuff. In other words, it does not matter much if you are sending encrypted e-mails to someone. If that someone is being closely monitored by the F.B.I., then the simple fact of sending some messages to that person will trigger some alarms. The contents of the messages are not so important.
Tracking "patterns" is not only about e-mail (which is one of the first things that people think about when encryption is mentioned), but also about all other kinds of traffic. So the spooks could also be alerted if you are accessing some suspicious web servers frequently. It does not matter if you are doing a secure transaction or not, because the first thing that they are interested in is your (IP) address. And this is not limited to web traffic either. They could also check if you are trying to connect to non-standard TCP or UDP ports on some computers.
The latter case is probably what the draft plan intends to make easier to detect, in the case of governement computers. Detecting suspicious accesses to governement computers is not a bad idea in itself. But it would be far too easy for the F.B.I. to abuse this power.
There is one thing that your report does not mention about the gcc vs. bcc comparison: was there any way to compare the speed of the compiled code?
It is nice to know that bcc compiles faster than gcc. This is interesting for those of us who are writing code and compiling all day. But when the end users install the software on their machines, they mostly care about the speed of the executable (compilation time does not matter much).
Slashdot Mirror
I know, it's a bit off-topic, but am I the only one who saw this note at the bottom of the New Scientist article?
How did they manage to quote an article that will be written the day after tomorrow?
Minor correction: Rational has announced that they will release ClearCase for Linux. However, it won't be the full ClearCase, but only "ClearCase Attache", which is a client that allows you to get a view of the ClearCase VOB but not the full thing. You will still need a commercial UN*X server or Windows NT server to run ClearCase. That may be better than nothing, but not good enough. And anyway, it is not available yet.
I make extensive use of ClearCase, Purify and Quantify while writing software (at work). These are very useful tools, but unfortunately they are not available for Linux. Since the programs I write must run on several systems including Linux (the list includes Solaris, Windows 95/98/NT, Windows CE, EPOC), I ended up having to set up a cross-compiler to compile the Linux programs from a Solaris host that can use ClearCase. This still doesn't give me Purify and Quantify, but fortunately Linux and Solaris are similar enough to give me a reasonable confidence that something that has been Purify'ed under Solaris will also work well under Linux. But I digress...
Coming back to the main topic, I agree that Rational has not done much to support non-Windows platforms. On the contrary, they have almost stopped improving the UN*X version of the tools that they bought from Atria and Pure Software, while putting most of their efforts on the Windows versions. This does not look good for those who are expecting to see J++ for Linux...
As the article says, the next version of M$ Visual Studio will rely heavily on XML and will probably forget about Java.
At first, I didn't think much about this. But now I have bad feelings about M$ using XML. Sure, XML is a nice standard and I like many of its applications. But XML is only a markup language; this is not a real programming language. You can use standards such as the Document Object Model DOM (not to be confused with M$'s proprietary COM) to describe in XML (or in an XML derivative) how some actions should be performed on a document, but this is a limited kind of programming.
So if a programmer wants to get something powerful out of XML, the best solution is to define a XML-based markup language that allows you to embed calls to some system-specific components into your documents. And then you can say: "Look at this great set of applications that I just released! They are all based on XML, which is an open standard." That's nice, except that the XML derivative used by these applications is nothing but a glue around some proprietary components that will not work on any other system.
I don't know what M$ is planning when they are focusing on XML and dropping Java. But it could very well be that they use an open standard as a cover for producing more non-portable stuff that will run on nothing else but Windows (because their XML derivative will require Active X, DCOM, and so on). At least with Java, there was some hope to have portable applications, even if M$ tried to lock the developers into Windows-specific Java extensions...
This is a very interesting question, indeed. The answer may vary from country to country, but I expect that in most cases it will be simply: no.
In many countries, minors do not legally own anything. Everything belongs to their parents until they grow up and reach the age of 18 or so. So if you are a minor and you write a book, a musical masterpiece, or a very clever program, they all belong to your parents. From a legal point of view (this is all theoretical anyway), your parents are the only ones who have the rights to decide if the software should be released under the GPL or any other license.
Also, a license is a kind of contract, and both parties (the owner and the end user) have to agree to that contract before using or distributing the software. And that cannot be done by a minor.
Disclaimer: IANAL.
No. The EULA gives you the rights to use the software and specifies under which conditions you are allowed to do that. Theoretically, you must agree on the EULA before using the software. Since the law in most countries does not allow kids to be bound by a contract (the EULA), then the kids are not allowed to use the program.
But of course, the parents of the kid can be bound by the EULA and allow her to use the program. Then the parents are responsible for letting the kid do whatever she wants with the program.
According to the law, there are many things that minors cannot do on their own. Agreeing on a EULA is just one of these things that require parental approval. Actually, now that I think about it, even agreeing on the GPL is something that a minor is not supposed to do.
That's right. Many countries have laws stating that minors cannot be bound by a contract. So a minor is not supposed to agree on the EULA - that's something that her parents should do.
I see no malice there - Corel is simply trying to be as careful as possible (too much, maybe?). They are not trying to prevent people from using Linux. I'm sure that some people at Corel do know that parts of the code on their CD has been written by minors.
There is another reason why you should always supply the source code (on a CD or from a ftp/www site) instead of linking to someone else's site: you must supply the source as it was used to build your system. If you made any modifications to some packages, then you have to make sure that your customers can get a copy of the source that includes all these modifications.
Also, if you link to someone else's site, you cannot be sure that all packages will remain there for the next three years (as required by the GPL). The other company (RedHat in this case) is free to change the layout of their site, or to simply stop distributing some packages (because they already supply the sources on CD, so they are not required to distribute them via ftp/www). Or RedHat could also replace these packages by newer versions. In most cases, the users would be happy to get the latest version, but what if the new version of some package is incompatible with some of the other packages that come pre-installed on the system that you are selling?
For all these reasons, it is important that you provide the sources on your own ftp/www site or on a CD.
I will leave the GNOME vs. KDE flamebait aside, because my comment was not about the desktop environment, but about the widget library only. Locking your application into a specific desktop environment is even worse for its portability than using a widget library that is not freely available for all major operating systems. Please, let's stick to the Qt issue without involving KDE.
Qt has some nice widgets that GTK+ does not have yet; I will not debate that. GTK+ also has some nice widgets that Qt does not have yet, but that is not the point. My main gripe against Qt is that it is not free enough if you want to port your applications to Windows or to other operating systems. GTK+ offers something more than Qt: its portability. Some major applications based on GTK+ (e.g. The GIMP) have been successfully ported to Windows (and even OS/2 and BeOS). If the GIMP had been built on top of Qt, that would not have been possible.
Since QCAD is built on top of Qt, I doubt that we will see a Windows version soon. Or at least not a free version. Not to mention other (more exotic) operating systems. If you are writing some code based on Qt, then some people will not be able to use it, and may not even be able to port it to their system if they have some coding skills. Some of the small tools that I wrote a few years ago were ported to other OS'es by various people, and some of these became more popular than the original version that I developed. This is the power of OpenSource. Alas, QCAD and other applications requiring libraries that are not available on all platforms will suffer from this and will not be available to everybody.
Hi! Here is the point of view from a random developer who has also decided to remove Qt from his PC...
The license in Qt 2.0 is much better than in the previous version (and accepted as being OpenSource) but the previous license caused me to dislike Qt very much and I would need a good reason to get back to it. "Once bitten, twice shy."
Also, there is no free version of Qt 2.0 for Windows. This is very important from my point of view: even if the license for the Linux version of Qt is good, the only version available for Win32 is rather expensive and prevents most developers from porting their applications to both systems. Of course, someone could develop a free Qt for Windows, but that does not exist yet. I do not want to install a library on my system if I know that any application that I write using this library (free under Linux) would become non-free under Windows.
In the meantime, GTK+ has reached its maturity level and I consider it to be superior to Qt (on a feature level). And GTK+ is available for free on several platforms, including Windows and OS/2. Another reason why I like GTK+ is that it does not tie the developer to C++. GTK+ can be used with C, C++, Perl, Python and other languages, while the support for other languages in Qt has been lacking for a long time (only partial implementations). So if I can do more with GTK+ than with Qt, why would I re-install Qt on my system?
Sorry, but for the moment Qt is still on my black list. In order for me to adopt Qt, it would need to be available for free (speech and beer) under Windows and to provide good bindings for ANSI C (not C++) and Perl.
The distributed attacks are certainly not a new phenomenon. ICMP smurfing is probably the best example of a distributed attack that is entirely automated and usually not detected by the third parties that are unvoluntarily involved in the attack.
However, the distributed attacks are becoming increasingly easy to perform, mostly because it is easier for script kiddies to get access to hundreds of poorly protected home computers from which they can launch their attacks. This happens because more and more computers are "always connected" (thanks to cable modems) and because most software vendors do not educate their users with some basic security hints. They do not want their customers to be scared away when they discover that the security issues on a computer are more complex than they thought. So it is usually in the vendor's best interest to ignore the risks of connecting a computer to the Internet.
Anyway, the article should not present this as something new. Something that becomes more frequent or harder to detect, maybe. But new, certainly not.
Of course, one could also wonder why these articles about cyberterrorism and various kinds of attacks involving the Internet are becoming more frequent in the mainstream press. As one of the talkback comments mentioned, maybe some people or some government agencies would like to use these reports to justify the need for stronger control over what is exchanged on the Internet.
After reading the MainWin overview on MainSoft's site, it is obvious that it is just another Win32 emulation layer, similar to Wine for Linux or Wabi for Solaris. Of course, they state on their page that MainWin is not an emulator. But all it does is to translate Win32 API calls to something that runs under Linux. The calls are executed in the MainWin layer (thanks to the Windows source code that they can use) or translated to Linux system calls. By the way, MainWin is already available for many UNIX systems, and they are just adding Linux to their list.
How is this different from Wine? On the negative side, it is closed source and probably quite expensive. On the positive side, the fact that they have access to the Windows source code means that they might be more compatible with all the undocumented Win32 features that are used by some MS applications.
I don't think that there is anything really exciting about this announcement. Win32 emulators have existed for quite a while on various UNIX systems, and all of them have their drawbacks. This one might be better in some areas and worse in some others, but it will never replace a native port of the applications to Linux.
If MicroSoft (not MainSoft) starts publishing press releases encouraging developers to work only on Win32 because it is portable to all environments including Linux, then we may have something to respond to. But I don't think that any serious company would stop porting their products to Linux because some small company provides a (closed and expensive) emulation layer for Win32 apps.
A link to that very interesting site was posted in July 1998, so this is not really new for those who have been on /. for more than a year.
Several interesting links were posted among the replies to that story. I will re-post a few of them here, so that you do not have to browse through the old messages:
Follow these links if you are interested in user interfaces (mostly for GUI). There is no lack of good advice on the net. This makes me wonder why we still see so many bad user interfaces in the latest programs (even in GNOME and KDE).
There are at least two things that you can do when attempting to reverse engineer a piece of software. The first one (not legal in several countries) is to decompile the code: take a debugger or decompiler and check what instructions are executed. The second one (legal in most countries) is the "blackbox" approach: consider the software as something that produces some output(s) depending on its input(s), and try to guess what is inside.
This second approach is the "real" reverse engineering. By carefully crafting some inputs and observing the outputs, you can often draw some conclusions about how the software behaves. With some patience and a lot of trial and error on simple inputs, you can find some patterns in the software: stuff that does not change, stuff that changes depending only on one of the inputs, and so on.
In the good old days (well, five years ago), I was the author of DEU (Doom Editing Utilties), the first program that was able to create new levels for Doom. I also contributed to Matt Fell's Unofficial Doom Specs and Olivier Montannuy's Unofficial Quake Specs, the documents that describe the WAD and PAK file formats and other internal details about Doom and Quake. Almost everything in the Unofficial Doom Specs was gathered by reverse-engineering. It was only later (with the release of Doom II) that id Software released some information to the community, presumably after they saw that editing Doom levels was a very popular activity. I am grateful for id Software's support of the editing community in their later games, but the first informations about Doom had to be found the hard way.
Most of my efforts in decoding Doom's WAD file format (and later Quake's PAK file format) involved an hex editor for viewing and editing the raw files, and custom tools that I built along the way for making editing easier (or tools that I received from other people, like DEU 3.0 from Brendon Wyber). A key thing is also to share as much information as possible with other people who are progressing on the same front because you often get more in return than what you found by yourself. For WAD files, it was easy to find that the file was organized a bit like a tar archive: a header, a directory containing names of objects and offsets within the file, and the data for the objects. Then the trial and error starts: try to guess what an object might be, modify a few bytes, run the game and see what happens. If your changes produced something useful, write it down and share the info with others. If the game crashed, try again. Repeat until you have understood everything.
Sometimes, you will find data structures that you do not understand. That was the case for Doom's NODES, SEGS and SSECTORS data. If you share enough information with others, maybe someone will have an idea and find that the data structures are related to something that they know. This is exactly what happened for Doom: Alistair Brown and a group of students from Bradford suggested that the unknown data might be a BSP tree. After reading some papers on that topic (I didn't know anything about BSP trees), I was able to implement a first BSP builder in DEU. And then it became possible to create brand new levels for Doom, instead of only changing the textures and location of the monsters as we did in the first few months. Releasing the source code for the tools has probably helped a lot. Other people were able to create their own tools based on that, and then the next reverse-engineering steps became much easier when the other games based on the same engine were released (Doom II, Heretic, Hexen, Strife,...)
Ah well... The good old times... Sigh!
When you are given the opportunity to moderate, it would be nice to be also allowed to moderate the main story.
If a story gets moderated down as redundant by too many people, it would be removed from the main page (but still accessible from the search page or other cross-references). That could help a bit in reducing the duplicates that pop up from time to time on /.
For the main story, the effect of moderation would only be to hide the story if it gets many negative points. The score would not be displayed on the main page. Positive points would be ignored (except for cancelling the negative ones).
You could also add the following features:
I know for sure that such a device exists, but I don't know when it will become available.
For the 11 Mbps part, I'm not sure. There are some wireless LAN solutions available for PCs, but as far as I know they all require you to install a base station. The nice thing about AirPort is the ad-hoc networking: minimal setup, any machine can talk to any other machine without having to install extra hardware.
There are some rumours that some motherboards of x86 PCs may integrate BlueTooth chips in a few months. BlueTooth does not provide the same bandwidth as AirPort (100 times less), but it also provides the ad-hoc networking and it is supposed to be integrated in all kinds of devices, so that you could have your phone, your keyboard, your mouse, or any other device connected to your PC without wires and without requiring a line-of-sight like the IrDa stuff.
It would certainly be possible to run Linux entirely in a 8Mb cache, since I have a PC that has only 8Mb of RAM (no swap, no disk) and runs Linux and some non-graphical applications smoothly.
But running the operating system at high speed is not enough: you need some applications too. Unless you have a way to lock the OS memory pages in the cache, they will not stay there for long because the cache will be used by the applications. And if you lock some pages in the cache, I expect that you will get a significant loss in performance if you have some applications doing a lot of non-localized memory accesses.
Conclusion: yes, it would be cool to be able to run the OS entirely out of cache, but that alone will not be very useful. Still, having a large cache for the OS + applications is a good thing.
Same for me. The company I work for has a bit more than 100,000 employees whose requests are distributed over a few proxies (2 in Europe, 1 in the US, 1 in Australia, and maybe one or two other proxies that I do not know).
It would be easy for anyone to abuse Slashdot and immediately prevent all others who have to go through the same proxy to post on the same day. Using the IP address for identifying the bad guys is not a good idea when some people have to share a proxy.
But on the other hand, it looks like the IP address is the only reliable way to stop the current abuses. Although it would be possible to be fair to the proxy users by checking the HTTP headers and looking for Via fields or modifications of the User-Agent field, these could unfortunately be faked by some script kiddies.
Maybe it would be possible to find a compromise: if some IP addresses are known to be used by many people using separate accounts (or Anonymous Cowards), then after a few weeks these IP addresses could be put on a special "proxy list". The threshold for banning posts from these proxies would be higher than the threshold used for single-user addreses. Or for these addresses, the rule would be different: it would prevent posting from ACs and any account that has a "bad karma" but not from the other accounts. So the registered users who contribute regularly to Slashdot would not be banned because of the wrongdoings of someone who happens to share the same proxy.
Sure, they have to find a fresh body without a head in order to perform the operation. I would not be surprised to see some surgeons suggesting that the airbags must be removed from all cars. That would provide them with an endless supply of bodies.
But what will they do with the old body once the head has been moved to the new one? Should it be buried (funeral, grave, and so on) or should it be dumped as waste?
Yummy!
I wonder if the information about the compromised accounts will ever be mentioned on the HotMail pages...
In the meantime, does anyone have more details about this? Specifically, I would like to know if the crackers stole a list of passwords or if they found a way to enter the site without using a password. In the former case, you would only have to change your password to be safe. In the latter case, you could hope that the HotMail staff would patch the hole quickly.
Considering the fact that a typical compurer becomes almost useless after three years, having yours seized for five years means that you will probably not be very interested in getting it back, except maybe for selling the metal.
Fortunately, Linux does not suffer from the same bloat factors as other operating systems, which means that you can run an up-to-date version of Linux on a computer that is more than five years old. But still...
Here are some ways to prevent people from abusing your site:
There are probably many other solutions to this problem, but this is what I was able to think about right now.
Note that some of these solutions (cookies, JavaScript) are not supported by all browsers or can be disabled by the user. But as long as the trick works for the majority and does not block the other users, your ad revenues are safe.
If you want to be able to share love letters with your girlfriend but not with the spies, you could have a look at RFC 1149 which suggest a solution that might be immune to the usual packet filters (or at least it makes the filtering a bit harder for the spies). I recommend that you have a look at the "Security Considerations" chapter in that RFC, for potential risks of that solution.
Note that RFC 1149 has recently been updated by RFC 2549 which provides additional Quality of Service considerations. This is something that you should care about if you want to be sure that your message is delivered before you have switched to another girlfriend.
The NYT article contains the following quote:
Actually, it seems that encryption would not help a lot in protecting your privacy. The first thing that the F.B.I. will do is to monitor "patterns" and check for unusual stuff. In other words, it does not matter much if you are sending encrypted e-mails to someone. If that someone is being closely monitored by the F.B.I., then the simple fact of sending some messages to that person will trigger some alarms. The contents of the messages are not so important.
Tracking "patterns" is not only about e-mail (which is one of the first things that people think about when encryption is mentioned), but also about all other kinds of traffic. So the spooks could also be alerted if you are accessing some suspicious web servers frequently. It does not matter if you are doing a secure transaction or not, because the first thing that they are interested in is your (IP) address. And this is not limited to web traffic either. They could also check if you are trying to connect to non-standard TCP or UDP ports on some computers.
The latter case is probably what the draft plan intends to make easier to detect, in the case of governement computers. Detecting suspicious accesses to governement computers is not a bad idea in itself. But it would be far too easy for the F.B.I. to abuse this power.
There is one thing that your report does not mention about the gcc vs. bcc comparison: was there any way to compare the speed of the compiled code?
It is nice to know that bcc compiles faster than gcc. This is interesting for those of us who are writing code and compiling all day. But when the end users install the software on their machines, they mostly care about the speed of the executable (compilation time does not matter much).