Slashdot Mirror

ComputerWorld and Wired report that DejaNews is discontinuing its policy of tracking click throughs on mailto: links. Click throughs on http: links will apparently still be monitored, but DejaNews is revising its privacy policy statement to clarify just what data is being kept.

In his writeup in Risks 20.36 Richard Smith (one of the folks that reported the tracking policy) points out that keeping too much information poses a risk to the Website or ISP collecting the information as well as to the users who are being monitored. To summarize his argument, the more information these sites collect, the more likely they are to get dragged into a legal dispute that doesn't really involve them directly. So, an argument can be made that respecting users' privacy is beneficial for users and ISPs alike.

-r

From http://catless.ncl.ac.uk/Risks/17.4 3.html#subj5:

Focus: But it is a fact: if you buy a new version of a program to overcome faults of an old one, you unavoidably get more features and need more storage.
Gates: We have strong competitors and produce only products which we believe to be able to sell. New versions are not offered to cure faults. I have never heard of a less relevant reason to bring a new version on the market.

Focus: There are always bugs in programs.
Gates: No. There are no essential bugs ("keine bedeutenden Fehler") in our software which a significant number fo users might wish to be removed.

--

It may not be DirectX - but here's a great place for info on how to get started writing games for Linux/X11. Check out the Linux/X11 Game Writer's Page, maintained by Paul Coates. This page has lots of source code you can download and compile to show you how to do 2D graphics animation, mouse and keyboard input, and even digital audio. At the very least, download his demo programs, compile them and try them out. I've run them on my Intel P200 (running Linux) at home and an HP-UX workstation at work and they ran quite smoothly on both.

Also, download the source code to Maelstrom (a cool Asteroids-like game) and study carefully the source file x11_framebuf.cpp.

I've found these resources to be very helpful in my current effort to convert my own DirectX game project to Linux/X11. Give them a try, and let's get busy making games for Linux!

A good place to start here is to refer you to The Unix Haters Handbook which was compilled by Simson Garfinkel, Daniel Weise and Steven Strassman. Published by Programmer's Press/IDG Books in 1994. ISBN 1-56884-203-1. While some of it's complaints are about old version of unix and some are just nitpicking, there are a lot of valid points in there. Every serious unix user should read it. Here is a web page with some little excepts. It also has a link to some stuff with the blinking cursor thing.

I did have some good bookmarks here that would been good to include here, however I can't seem to find them. If you look arround the net you might find some of them. The sites are still probably out there. One site that occassionly has interesting unix problems is the Risks Digest. Occasionally security sites have stuff like this too.

Some quick points. There a lot more than I've got here and some things may be open to taste and religion. Other people have done a much better job than I'm doing here. Much of unix was written as series of quick and dirty hacks that worked for the simple case but does does not scale to the general case. Any way - some points

• A lot of the programs that come with it are inconsistent, they take different flags, take their input and output through different means, etc. This can be a real killer on occasion when you accidentally use the wrong flag and trash something. It also make using them more work, since you have to learn all the different flags and behaviours. Some programs even interperet them differently ie "foo -bar" may be the same as "foo -b -a -r" or it may be different. The pieces just don't always fit together.
• The unix shells intercept and expand all sorts of things like "*" and "~" rather than just passing them through to programs and letting them deal with it. (Really simple example: "rm * .o" -- "do you really want to remove all files?". You can't do this. This may seem like it's not all that important but there can be times when you really want to do it. Also if you want pass stuff like this down to say a lower shell script using say $1, then it's too late. Unless you make the user put quotes arround it. But then quotes get removed and it gets expanded at the next step if you not careful. and so on. All this is assuming that there are not so many files in a directory that your shell can't cope with the size of the strings produced when * is evaluated)
• Shells are a bastard crossbreed of command interperter and scripting language. And don't do a great job of either. Fortunately Larry Wall and Guido van Rossum wrote Perl and Python ;-)
• Relics like man (1) persist even though they suck for what they are supposed to do.
• BSD v System V incompatabilities.
• Really, really, inflexible file access control system. (ie rwxr-x--- type stuff). Sure it's easy to implement but there is just so much stuff you can't do. For example: people in group "coders" and group "testers" have access to this directory without having to make a new group "codersandtesters". Even windows NT has ACL's.
• Core files. Yeah, I really wanted a 20MB core file from an application that I an not devolping and don't even have the source code for. Unix treats everyone as if they are a developer.
• X windows, where widget chaos reigns. Different programs behave differently and "mode confusion" is a matter of course. And soooo much of it is ugly and tricky to use. GNOME and KDE may help, but there will always be apps that are exceptions.
• It's mostly built on C which is another area of serious brain damage (and is also talked about in the haters book). A lot of the standard libraries have serious safety problems.
• Curses and termcap/terminfo. Basically this involves moving the terminal driver into the application rather than having the operating system do it for you. Ditto for graphics. There should not be a program that is directly accessing the hardware (and thus can screw your whole machine if is crashes). GGI/KGI are fixing that.
• Unix style file systems including ext2 can be incredibly fragile. I had a flaky hard disk controller. Under windows individual files got corrupted. Under linux huge chunks of the file system failed. Sometimes fsck was like pouring petrol on a fire. (It did teach me to back up regularly ;-)

So many people don't even think about these things. Often they don't know anything else. There are some really cool things done under things like the Amiga etc, that are next to impossible under linux. But people who haven't used (or read about) these features don't miss them. I used the Mac a lot and while they were not power-user friendly they did have some features that I really miss. But by the same token there are a lot of cool things you can do under linux that you can't do under other operating systems. And for me the cool things you can do under linux outweigh the other systems and better enable me to do the things that I want to do. I would just like a new OS that had all the good stuff and I don't have time and patience to write it.