A lot of spam does in fact have your correct e-mail address in the To: header. The spammers know the address; how do you think you got the spam?
My procmail filter does reject a big portion of spam by your simple rule, but not all.
Here, let's grep through my current junk log. There are 72 spams in it. Eighteen of them have the correct address. So your rule would have been only 75% effective on that set. That isn't bad, but not good enough for me.
Of the remaining 25%, many were caught by consulting the ORBS and RBL databases. A few were from connections with no reverse DNS so were rejected for that reason even before my filter got to them (the SMTP server added an X-Reject: line). And some were caught due to using an internal-looking From: address, or an internal-looking message ID. Many were rejected based on more than one of these rules.
That still leaves the very few that got through despite the filtering.
I can think of some reasons why Hotmail wouldn't make use of the RBL a per-user option.
For one thing, it would require some programming in order to make a hotmail configuration web UI affect the back-end. The SMTP servers that handle incoming mail would actually have to accept connections from spammers, take the envelope address, resolve it to a user profile, retrieve the preferences and then make a decision whether to drop the connection or accept the mail. This is extra overhead that could perhaps impact the existing scalability of Hotmail.
Anything is doable with software, it's just a question of time, money and overall feasability. Would the cost of adding frills to the service be justified, given that it is already free? Another aspect of development is the management of risks; hotmail is a live operation. Any fundamental changes have to be thoroughly tested before being deployed, even though this is being run by Microsoft. Someone also has to estimate the performance impact that the change might have.
It's easy to forget that the function of Hotmail is to spam its users anyway---with advertisements. The real clients of Hotmail are the people that pay to have their crap appear on your Hotmail page. Thus it would probably be necessary to convince these clients that giving users extra frills would bring in enough additional revenues to justify the development costs and risks.
That's not mis-use; it's one of the ways in which the RBL was meant to be used. The B stands for ``black hole''. That means creating black hole route entries for the rogue networks so to deny them access to your network.
Kudos to Teleglobe for having the courage to take action against spammer infested cesspools like home.com.
The RBL is far from being for blocking e-mails only. Ultimately, MAPS wants to cut off spammers from all services that they rely on. That means networks which host spammer web sites are blacklisted as well, not just networks that originate spam e-mail. In other words, the networks that Teleglobe is denying access to don't even originate spam e-mail; some of them just host spammer sites.
There may be legitimate web sites alongside spammer websites under these networks. The idea is to exert pressure on the operators of these networks to crack down on the spammers, and get themselves un-blackholed so that access to their site is restored.
There is no easy technological measure to block out only the spammers, and retain access to legitimate sites. Heck, a spammer site and a legitimate site could even be on the same web server machine. That sort of scalpel precision would require URL filtering, which is difficult to implement at the IP forwarding level. Doing that would also remove a lot of the incentive for the spammer-friendly operators to change their ways, and the expense of fighting spam would be absorbed entirely by the people doing the costly filtering. Such filtering at the TCP stream level would likely reduce bandwidth and require more hardware.
The problem is that the toll free numbers might be legit, but belong to someone other than the spammer. So first you would have to do a careful check to find out that the operation behind the toll free number does in fact correspond to what is advertized in the spam.
Secondly, by doing the auto-dialing, you are participating in criminal activity. The means by which you got the phone number does not clear you of wrongdoing. The spammers could find out who you are and take some sort of civil action against you, for the amount racked up by the automatic calls and possibly other damages.
And, of course, you have to watch out that you don't call numbers which cost YOU money.
... because some people can't use procmail or hit the delete key when they get UCE, I can't send e-mail.
How do you think the procmail filter is going to recognize SPAM? Mine pings the anti-spam databases using nslookup.
Instead of complaining, you should switch to a site that has responsible administrators, not some lackeys that can't fix a simple mail server configuration problem.
By staying with this ISP, you are endorsing their spam-friendly attitude, and their relaxed hiring policy toward incompetent sysadmins. Your continued support is giving them one less reason to modify their behavior.
When my ISP's mail machine was found by ORBS to have a hole, I sent mail to the operator and he fixed it within hours, and then thanked me for giving him a heads-up on the problem. By the way, you could always send Mom a nice snail-mail letter.;)
The number one reason is administrator cluelessness. Mail servers don't relay because their admins want them to, but because the admins who set them up don't have a freaking clue on how to operate a secure mail site. At least, these are the ones who have ``wide open relays''.
Even admins who think they have closed their relays often have left some obscure hole, due to bugs or quirks of programs like sendmail.
For example, some sendmail servers will properly refuse to forward a mail with the envelope recipient address like but if it's wrapped in quotes, like they forward it, thinking it's a local address. The deeper rule that operates after the quote stripping doesn't enforce the no relay policy or something like that.
The ORBS system performs about a dozen or so different tests involving various obscure holes that permit mail to be routed. If you want more information, surf www.orbs.org.
The delay won't help against spread spectrum attacks, whereby the spammer sends a small number of messages to a large number of servers.
Also, you are forgetting that spammers don't send to your ISP directly; they usually get someone's insecure relay to do the dirty work of delivery. The relay has all that time in the world.
A one or two second delay wouldn't be enough anyway; a spammer could send mail to two hundred people in just over three minutes. That's enough to bother a small ISP.
The delays imposed by distinct mail servers are going to be consumed in parallel, so your scheme would not do anything to stop the overall spamming. In three minutes, the spammer could send a hundred messages to a hundred different ISP's in parallel, even if each of those ISP's had the delay mechanism in place.
For effective anti-spam measures, they should not only use MAPS, but also the ORBS database and the Radcliffe database as well.
ORBS is effective at fighting spam. And the nice feature, compared to MAPS, is that it's automated. ORBS automatically tests an SMTP server to determine whether it has known holes. If a hole is found, that server is blackballed right away by the software; the only way to get out of ORBS is to fix the problem. A convenient web sumission form lets you report suspected open relays, and you can track the progress that it's making in probing the site.
To protect myself from spam, I use a procmail filter that pings *four* databases.
The only rare spam I get nowadays is from the true ``whack-a-mole'' spammers: mostly amateurs who spam directly from dial-up accounts. The last time that happened, I complained to the ISP in question and they supposedly took action. Additionally, very rarely, I get a spam through a hitherto unknown open relay, which I promptly report to ORBS.
Nice to see free software, once again, as part of the back-end middleware solution, but how about supporting wireless *clients* using Linux?
There is a driver for Mobitex modems(*) that gives you datalink through network layer capabilities; so we at least have the hardware support. --- * written by guess who.;)
Yes, I've read the paper by Schneier. IIRC, they claimed that the bug is in the Microsoft implementation of PPTP, not in PPTP itself. It's possible that the freeware implementations of it don't have the problem, though in what combinations with Windows clients or server I can't guess. In particular, I don't know whether the server implementation has to reproduce Microsoft's security bugs in order to be compatible with Windows clients.
True, ipchains doesn't do those things you describe. It's not supposed to; but some of them are done by advanced routing. Advanced routing gives you a way to manage more than one routing table with different rules, and translation of netblocks is supported. I doubt that checkpoint can do more in the IP forwarding arena than ipchains + advanced routing.
``Antivirus'' at the firewall level is ridiculous to me. Good operating systems don't suffer from viruses anyway.;) If you want to filter what external URL's your users access, the place for that is the proxy server, not IP routing.
That leaves VPNs: bit out of my area. But aren't there IPsec solutions for Linux? Someone also wrote open source PPTP client and server software, so you can support the native Windows VPN mechanism.
A good hacker should be able to do with just a register dump, stack trace and some program text surrounding the instruction pointer where things went belly up.
Hacking the kernel is supposed to be hard and tracing crashes given minimal information is a big part of the fun and attraction of ``iron man'' programming.
Then again, having a full dump doesn't necessarily make debugging that much easier. It's an incremental improvement over oops text.
Here is the real advantage: a dump is good from the point of view of users who need to report crashes to developers. I think that even a hack to get oops text (rather than a full dump) written to a partition would be better than asking the poor user to copy the oops text appearing on the frozen console down on a piece of paper! Forget it!
forgot to support bitmap and vector graphics, frames, etc.
The team who developed Mosaic gave allowed others to embrace and extended to do the obvious things that were missing, instead of putting the software under the GPL. Both Netscape and Explorer have roots in Mosaic. The base code for Explorer came from Spyglass whom Microsoft cannibalized. Spyglass' wares were derived from Mosaic, IIRC. So you can thank the bungled handling of the Mosaic codebase for the current situation, at least partially.
The W3C guys haven't learned any lessons from all this. They still offer source code that can be embraced, extended and locked away into proprietary machine code. Here is a link to the license for libwww and other w3c freeware like the Amaya browser. Their FAQ says this: Yes, we want people to experiment with and improve our software. It can even be used in commercial software. If you make changes for the better, we encourage you to contact its authors. You may not make changes and continue to call it by a trademarked term or misrepresent the origin, capabilities, or liabilities associated with its use. You may make valid assertions, such that it is based on Amaya code, or that it is compliant with a Recommended Specification of the W3C.
They want everyone to follow the standard, yet they purvey reference implementations that can be molded into whatever proprietary shape that the Microsofts or Netscapes of this world care to dream up. It comes to reason that a reference implementation of a standard should have a license that promotes compliance and prevents it from being used as a basis for proprietary extensions.
You pay a hundred bucks and can't use it for commercial purposes? I suppose that running a commrecial website off it, for instance, would be out.
They seem to be forgetting that the competitive free UNIX operating systems are long out of the toy stage. Why pay all that for something whose license not only restricts distribution, reverse engineering and all the usual stuff, but also restricts the product to a hobby horse.
The question I would ask is, does this offer actually contain $100 worth of hobby value? I can see it as being useful to someone who wants to learn the idiosynchrasies of setting up and administering Tru64 for the sake of getting a job, and just knowing the things that are different about product but that's not a pure hobbyist motivation.
I guess what I'm trying to say is that if I'm going to run a POSIX shell and play with vi, I can get cheaper satisfaction.;)
It's true that Perl has a lot of intrinsic features geared toward the mainpulation of text. However, C++ has a lot better support for constructing new library features that integrate nicely into the language. With suitable classes and templates, you should be able to manipulate text just as easily. (Getting your hands on, and deciding what is suitable is another matter). The standard C++ string class already hides the clumsy storage managment chores associated with classic char * strings so you can do stupid things like add two strings together using + without caring how the memory is managed: the objects take care of it. A string class like that could be extended to have features such as the ability to snarf whole files, do regexp substitutions and whatnot. Problem is that it takes a lot of expertise to develop a good library.
The primary (only?) advantage of perl is that the extended support for text mangling is intrinsic to the language. Wherever perl is used, the perl coder can use the same skills to do the same basic tasks. You don't have to learn yet another class for doing regex substitutions. You could make the argument that a good interpreted language is better than a score of poorly designed C++ classes.
What about robustness? How do you handle out of memory conditions in a perl program? Part of the perceived ease of programming in perl is that perl programs don't do sufficient error checking. C is also easy to use if you don't bother with the little details, like handing null returns from malloc() or error indications from fprintf(). What if a memory allocation request fails inside the perl interpreter? Can the script recover, or will the whole thing just die at some arbitrary point in the execution? In C++ you can use exception handling to implement a sensible strategy for such conditions and construct fault-tolerant programs without littering them with explicit conditional checks everywhere. It's often not acceptable for some low level module to turf the program in response to an error. Bad C and C++ programs are peppered with calls to exit() which make them difficult to extend or incorporate as subsystems into a larger fault-tolerant application. In Perl, this is the modus operandi. Not everyone writes fault tolerant C++ programs, but the support is there if you want to use it.
I don't buy ease of use arguments in favor of Perl. The ease is largely a myth perpetrated by people who use it to write compact utility programs that don't have to be robust against failures. There is a very low startup cost to making such programs with perl, and they can be written tersely, so it looks deceptively easy. But try maintaining any significantly large perl program. Programming is more than just stringing clever operators and subroutines together. That is really sub-programming; solving a small subproblem that is part of a larger whole. Perl falls down when it comes to engineering that larger whole. Features like classes and function prototypes are pathetic in perl; it's painfully clear that they were horribly hacked in as an afterthought.
About your reference to slashdot: would slashdot be so slow if it was written in C++? Those delays can't be entirely network related.
What does slashdot do anyway? It's basically a glorified BBS. In the 80's, kids used to write predecessors to slashdot in BASIC (the kind with line numbers) with a dash of machine language. These things had e-mail, discussions, voting booths, user profiles with preferences, anonymous cowards, etc.
There is no big deal. It's just that TeX has been around for a very long time (nearly 20 years in what is largely its present form and longer if you count the pre-1980 versions.) and has a loyal following and surrounding culture. Some of these people might enjoy having a calendar that displays ``TeX pride''.
Printing on demand, to me means, for instance, ``tex foo.tex'' followed by ``dvips foo.dvi''. Where is the TeX source? How about a calendar of which you can roll your own DVI, adjusted to whatever paper size you wish, featuring unencumbered images? Who cares about Bibby drawings? Maybe some nice mathematical formulas, graphs and diagrams would do instead.;) Or each page featuring some different area of typesetting that one can engage in: music, organic chemistry, mathematics, Klingon, etc. Or some way out there things done up in MetaPost.
I guess we have two months to cook up a freeware TeX calendar.
Basically the same old worn out Microsoft bashing trying to come off as humor. What's missing is that essential dash of wit and the slightest hint of originality.
I wonder, did someone purposely set this up to make Linux advocates look like twits?
Far from being contrary to the ``way UNIX operates'', a lot of the things you describe are actually not all that far off.
In UNIX-like environments, you can move programs around and they still work. Programs tend not to be sensitive to their own location. There isn't even a standard API function in POSIX or the UNIX specification for a program to find the location of its own excecutable. In fact, such a function would have to lie, because the executable can be unlinked or renamed while the program is running. What usually matters is that your program's preferences are in some dot-rc file in your home directory or in/etc, and these things can't be moved around without telling the program. (But could you move your Mac application preference settings anywhere?) Now in Windows, on the other hand, there are interfaces to explicitly support the idea of making a program sensitive to its own place in the filesystem. Moreover, there is the concept of putting a program's DLL's in the same directory as the program, so if you don't move all of the components together, it breaks. The registry often contains path names of executables and objects. Sometimes applicatiosn register their own components, and then cannot be moved without reinstallation which will reregister the components.
About the drivers: installing drivers in Linux is not quite as easy as dragging something to a folder, but it's almost there. Drivers are just files that are typically kept in some special directory structure. If you wanted to, you could set up your system so that you put all your desired drivers into some driver directory, and some script running in the background just loads (via insmod) whatever is in there, and periodically checks for stuff to be removed so that it can do the rmmod---without ever rebooting. A little design would have to go into storing the driver-specific configuration. So you are basically talking about a feature that can be hacked up in half a screenful of a bash script. I wouldn't want to do this because it would be inferior to setting up aliases in/etc/conf.modules.
It boils down to the remainder of your points which are still true as ever: namely the lack of UI integration for ``dumb'' users. But I suspect it's partly due to the fact that once the difficult systems programming work has been done to the point that someone can hack up some easy script to accomplish something, there is little incentive to sweat out a graphical interface that will in the end be less flexible and therefore less satisfying. That doesn't mean that there is some deep ``UNIX principle'' if you will which rules out the possibility of making graphical interfaces for system configuration and other things.
Problem with your analogy is that there is a precedent for the term cracker that predates computer technology. Figuring out a cipher is called cracking, and so is breaking into a safe (as in ``safe cracker''). So you can't object to the term cracker being applied to someone who breaks computer security on the grounds that the term already refers to a kind of food. Moreover, the two meanings are distant, so there is no confusion. Hackers and crackers are not as distant, so there is significant confusion. People who use hacker in the explorative computer programmer sense can be easily misunderstood to be referring to the security cracker meaning.
When you say ``I'm a hacker'', some people may think that you break into computers, even though you mean that you like to work on neat programs. When you say ``I'm eating a cracker'', nobody thinks that you are munching on the remains a stereotypical masked guy who blows up metal boxes (or worse, performing some indecency).;)
If the government specifies that they want source code from everyone they deal with, then they shall have source code. If the developer doesn't like it, they are free to bid for work in the private sector.
It sounds like Senator Pierre Laffitte might be confusing the free software service model with software renting (that whole business of application service providers).
Providing services to customers is one thing. Providing source code and letting someone else provide the services is quite another.;)
They make it sound like someone is jumping out of an airplane on a motorcycle or something.
So what if TurboLinux forks the kernel? They will either die out or have to keep a parallel development stream whereby they keep taking mainstream kernels and patch their changes onto them. No big deal. There are nice tools for this, like CVS update -j or GNU patch. Eventually, their stuff will mature and may be accepted into the mainstream.
Forking happened before (anyone remember SLS?).
I think that for any significant feature to be added by an independent software team, forking *has* to take place. In fact, Linux is continuously sprouting many short-lived forks. Any time a hacker unpacks a kernel and does anything to it, wham, you have a tiny fork. Then when it becomes part of the stream, the fork goes away. To create a significant feature, you may have to have branch a much longer-lived fork. And to let a community of users test that feature, you *have* to release from that branch. Now crap: you are ostracized by the idiot industry journalists who will accuse you of fragmenting the OS.
Linus *can't* integrate Turbo's changes until those changes are thoroughly hammered on by Turbo users, so a fork is required. The only kinds of changes that Linus can accept casually are ones that do not impact the core codebase. For example, if someone develops a driver for hitherto unsupported device, great. The driver can only screw up kernels that are built with it, or into which it is loaded. Just mark the driver as very experimental and that's it.
Slashdot Mirror
Stability? Performance?
Get real!
Get Realistic OS!
;)
A lot of spam does in fact have your correct e-mail address in the To: header. The spammers know the address; how do you think you got the spam?
My procmail filter does reject a big portion of spam by your simple rule, but not all.
Here, let's grep through my current junk log. There are 72 spams in it. Eighteen of them have the correct address. So your rule would have been only 75% effective on that set. That isn't bad, but not good enough for me.
Of the remaining 25%, many were caught by consulting the ORBS and RBL databases. A few were from connections with no reverse DNS so were rejected for that reason even before my filter got to them (the SMTP server added an X-Reject: line). And some were caught due to using an internal-looking From: address, or an internal-looking message ID. Many were rejected based on more than one of these rules.
That still leaves the very few that got through despite the filtering.
I can think of some reasons why Hotmail wouldn't make use of the RBL a per-user option.
For one thing, it would require some programming in order to make a hotmail configuration web UI affect the back-end. The SMTP servers that handle incoming mail would actually have to accept connections from spammers, take the envelope address, resolve it to a user profile, retrieve the preferences and then make a decision whether to drop the connection or accept the mail. This is extra overhead that could perhaps impact the existing scalability of Hotmail.
Anything is doable with software, it's just a question of time, money and overall feasability. Would the cost of adding frills to the service be justified, given that it is already free? Another aspect of development is the management of risks; hotmail is a live operation. Any fundamental changes have to be thoroughly tested before being deployed, even though this is being run by Microsoft. Someone also has to estimate the performance impact that the change might have.
It's easy to forget that the function of Hotmail is to spam its users anyway---with advertisements. The real clients of Hotmail are the people that pay to have their crap appear on your Hotmail page. Thus it would probably be necessary to convince these clients that giving users extra frills would bring in enough additional revenues to justify the development costs and risks.
That's not mis-use; it's one of the ways in which the RBL was meant to be used. The B stands for ``black hole''. That means creating black hole route entries for the rogue networks so to deny them access to your network.
Kudos to Teleglobe for having the courage to take action against spammer infested cesspools like home.com.
The RBL is far from being for blocking e-mails only. Ultimately, MAPS wants to cut off spammers from all services that they rely on. That means networks which host spammer web sites are blacklisted as well, not just networks that originate spam e-mail. In other words, the networks that Teleglobe is denying access to don't even originate spam e-mail; some of them just host spammer sites.
There may be legitimate web sites alongside spammer websites under these networks. The idea is to exert pressure on the operators of these networks to crack down on the spammers, and get themselves un-blackholed so that access to their site is restored.
There is no easy technological measure to block out only the spammers, and retain access to legitimate sites. Heck, a spammer site and a legitimate site could even be on the same web server machine. That sort of scalpel precision would require URL filtering, which is difficult to implement at the IP forwarding level. Doing that would also remove a lot of the incentive for the spammer-friendly operators to change their ways, and the expense of fighting spam would be absorbed entirely by the people doing the costly filtering.
Such filtering at the TCP stream level would likely reduce bandwidth and require more hardware.
The problem is that the toll free numbers might be legit, but belong to someone other than the spammer. So first you would have to do a careful check to find out that the operation behind the toll free number does in fact correspond to what is advertized in the spam.
Secondly, by doing the auto-dialing, you are participating in criminal activity. The means by which you got the phone number does not clear you of wrongdoing. The spammers could find out who you are and take some sort of civil action against you, for the amount racked up by the automatic calls and possibly other damages.
And, of course, you have to watch out that you don't call numbers which cost YOU money.
How do you think the procmail filter is going to recognize SPAM? Mine pings the anti-spam databases using nslookup.
Instead of complaining, you should switch to a site that has responsible administrators, not some lackeys that can't fix a simple mail server configuration problem.
By staying with this ISP, you are endorsing their spam-friendly attitude, and their relaxed hiring policy toward incompetent sysadmins. Your continued support is giving them one less reason to modify their behavior.
When my ISP's mail machine was found by ORBS to have a hole, I sent mail to the operator and he fixed it within hours, and then thanked me for giving him a heads-up on the problem. By the way, you could always send Mom a nice snail-mail letter. ;)
The number one reason is administrator cluelessness. Mail servers don't relay because their admins want them to, but because the admins who set them up don't have a freaking clue on how to operate a secure mail site. At least, these are the ones who have ``wide open relays''.
Even admins who think they have closed their relays often have left some obscure hole, due to bugs or quirks of programs like sendmail.
For example, some sendmail servers will properly refuse to forward a mail with the envelope recipient address like but if it's wrapped in quotes, like they forward it, thinking it's a local address. The deeper rule that operates after the quote stripping doesn't enforce the no relay policy or something like that.
The ORBS system performs about a dozen or so different tests involving various obscure holes that permit mail to be routed. If you want more information, surf www.orbs.org.
The delay won't help against spread spectrum attacks, whereby the spammer sends a small number of messages to a large number of servers.
Also, you are forgetting that spammers don't send to your ISP directly; they usually get someone's insecure relay to do the dirty work of delivery. The relay has all that time in the world.
A one or two second delay wouldn't be enough anyway; a spammer could send mail to two hundred people in just over three minutes. That's enough to bother a small ISP.
The delays imposed by distinct mail servers are going to be consumed in parallel, so your scheme would not do anything to stop the overall spamming. In three minutes, the spammer could send a hundred messages to a hundred different ISP's in parallel, even if each of those ISP's had the delay mechanism in place.
For effective anti-spam measures, they should not only use MAPS, but also the ORBS database and the Radcliffe database as well.
ORBS is effective at fighting spam. And the nice feature, compared to MAPS, is that it's automated. ORBS automatically tests an SMTP server to determine whether it has known holes. If a hole is found, that server is blackballed right away by the software; the only way to get out of ORBS is to fix the problem. A convenient web sumission form lets you report suspected open relays, and you can track the progress that it's making in probing the site.
To protect myself from spam, I use a procmail filter that pings *four* databases.
The only rare spam I get nowadays is from the true ``whack-a-mole'' spammers: mostly amateurs who spam directly from dial-up accounts. The last time that happened, I complained to the ISP in question and they supposedly took action. Additionally, very rarely, I get a spam through a hitherto unknown open relay, which I promptly report to ORBS.
Nice to see free software, once again, as part of the back-end middleware solution, but how about supporting wireless *clients* using Linux?
;)
There is a driver for Mobitex modems(*) that gives you datalink through network layer capabilities; so we at least have the hardware support.
---
* written by guess who.
Yes, I've read the paper by Schneier. IIRC, they claimed that the bug is in the Microsoft implementation of PPTP, not in PPTP itself. It's possible that the freeware implementations of it don't have the problem, though in what combinations with Windows clients or server I can't guess. In particular, I don't know whether the server implementation has to reproduce Microsoft's security bugs in order to be compatible with Windows clients.
True, ipchains doesn't do those things you describe. It's not supposed to; but some of them are done by advanced routing. Advanced routing gives you a way to manage more than one routing table with different rules, and translation of netblocks is supported. I doubt that checkpoint can do more in the IP forwarding arena than ipchains + advanced routing.
;) If you want to filter what external URL's your users access, the place for that is the proxy server, not IP routing.
``Antivirus'' at the firewall level is ridiculous to me. Good operating systems don't suffer from viruses anyway.
That leaves VPNs: bit out of my area. But aren't there IPsec solutions for Linux? Someone also wrote open source PPTP client and server software, so you can support the native Windows VPN mechanism.
A good hacker should be able to do with just a register dump, stack trace and some program text surrounding the instruction pointer where things went belly up.
Hacking the kernel is supposed to be hard and tracing crashes given minimal information is a big part of the fun and attraction of ``iron man'' programming.
Then again, having a full dump doesn't necessarily make debugging that much easier. It's an incremental improvement over oops text.
Here is the real advantage: a dump is good from the point of view of users who need to report crashes to developers. I think that even a hack to get oops text (rather than a full dump) written to a partition would be better than asking the poor user to copy the oops text appearing on the frozen console down on a piece of paper! Forget it!
The team who developed Mosaic gave allowed others to embrace and extended to do the obvious things that were missing, instead of putting the software under the GPL. Both Netscape and Explorer have roots in Mosaic. The base code for Explorer came from Spyglass whom Microsoft cannibalized. Spyglass' wares were derived from Mosaic, IIRC. So you can thank the bungled handling of the Mosaic codebase for the current situation, at least partially.
The W3C guys haven't learned any lessons from all this. They still offer source code that can be embraced, extended and locked away into proprietary machine code. Here is a link to the license for libwww and other w3c freeware like the Amaya browser. Their FAQ says this: Yes, we want people to experiment with and improve our software. It can even be used in commercial software. If you make changes for the better, we encourage you to contact its authors. You may not make changes and continue to call it by a trademarked term or misrepresent the origin, capabilities, or liabilities associated with its use. You may make valid assertions, such that it is based on Amaya code, or that it is compliant with a Recommended Specification of the W3C.
They want everyone to follow the standard, yet they purvey reference implementations that can be molded into whatever proprietary shape that the Microsofts or Netscapes of this world care to dream up. It comes to reason that a reference implementation of a standard should have a license that promotes compliance and prevents it from being used as a basis for proprietary extensions.
You pay a hundred bucks and can't use it for commercial purposes? I suppose that running a commrecial website off it, for instance, would be out.
;)
They seem to be forgetting that the competitive free UNIX operating systems are long out of the toy stage. Why pay all that for something whose license not only restricts distribution, reverse engineering and all the usual stuff, but also restricts the product to a hobby horse.
The question I would ask is, does this offer actually contain $100 worth of hobby value? I can see it as being useful to someone who wants to learn the idiosynchrasies of setting up and administering Tru64 for the sake of getting a job, and just knowing the things that are different about product but that's not a pure hobbyist motivation.
I guess what I'm trying to say is that if I'm going to run a POSIX shell and play with vi, I can get cheaper satisfaction.
It's true that Perl has a lot of intrinsic features geared toward the mainpulation of text. However, C++ has a lot better support for constructing new library features that integrate nicely into the language. With suitable classes and templates, you should be able to manipulate text just as easily. (Getting your hands on, and deciding what is suitable is another matter). The standard C++ string class already hides the clumsy storage managment chores associated with classic char * strings so you can do stupid things like add two strings together using + without caring how the memory is managed: the objects take care of it. A string class like that could be extended to have features such as the ability to snarf whole files, do regexp substitutions and whatnot. Problem is that it takes a lot of expertise to develop a good library.
The primary (only?) advantage of perl is that the extended support for text mangling is intrinsic to the language. Wherever perl is used, the perl coder can use the same skills to do the same basic tasks. You don't have to learn yet another class for doing regex substitutions. You could make the argument that a good interpreted language is better than a score of poorly designed C++ classes.
What about robustness? How do you handle out of memory conditions in a perl program? Part of the perceived ease of programming in perl is that perl programs don't do sufficient error checking. C is also easy to use if you don't bother with the little details, like handing null returns from malloc() or error indications from fprintf(). What if a memory allocation request fails inside the perl interpreter? Can the script recover, or will the whole thing just die at some arbitrary point in the execution? In C++ you can use exception handling to implement a sensible strategy for such conditions and construct fault-tolerant programs without littering them with explicit conditional checks everywhere. It's often not acceptable for some low level module to turf the program in response to an error. Bad C and C++ programs are peppered with calls to exit() which make them difficult to extend or incorporate as subsystems into a larger fault-tolerant application. In Perl, this is the modus operandi. Not everyone writes fault tolerant C++ programs, but the support is there if you want to use it.
I don't buy ease of use arguments in favor of Perl. The ease is largely a myth perpetrated by people who use it to write compact utility programs that don't have to be robust against failures. There is a very low startup cost to making such programs with perl, and they can be written tersely, so it looks deceptively easy. But try maintaining any significantly large perl program. Programming is more than just stringing clever operators and subroutines together. That is really sub-programming; solving a small subproblem that is part of a larger whole. Perl falls down when it comes to engineering that larger whole. Features like classes and function prototypes are pathetic in perl; it's painfully clear that they were horribly hacked in as an afterthought.
About your reference to slashdot: would slashdot be so slow if it was written in C++? Those delays can't be entirely network related.
What does slashdot do anyway? It's basically a glorified BBS. In the 80's, kids used to write predecessors to slashdot in BASIC (the kind with line numbers) with a dash of machine language. These things had e-mail, discussions, voting booths, user profiles with preferences, anonymous cowards, etc.
There is no big deal. It's just that TeX has been around for a very long time (nearly 20 years in what is largely its present form and longer if you count the pre-1980 versions.) and has a loyal following and surrounding culture. Some of these people might enjoy having a calendar that displays ``TeX pride''.
Printing on demand, to me means, for instance, ``tex foo.tex'' followed by ``dvips foo.dvi''. Where is the TeX source? How about a calendar of which you can roll your own DVI, adjusted to whatever paper size you wish, featuring unencumbered images? Who cares about Bibby drawings? Maybe some nice mathematical formulas, graphs and diagrams would do instead. ;) Or each page featuring some different area of typesetting that one can engage in: music, organic chemistry, mathematics, Klingon, etc. Or some way out there things done up in MetaPost.
I guess we have two months to cook up a freeware TeX calendar.
Basically the same old worn out Microsoft bashing trying to come off as humor. What's missing is that essential dash of wit and the slightest hint of originality.
I wonder, did someone purposely set this up to make Linux advocates look like twits?
Far from being contrary to the ``way UNIX operates'', a lot of the things you describe are actually not all that far off.
/etc, and these things can't be moved around without telling the program. (But could you move your Mac application preference settings anywhere?) Now in Windows, on the other hand, there are interfaces to explicitly support the idea of making a program sensitive to its own place in the filesystem. Moreover, there is the concept of putting a program's DLL's in the same directory as the program, so if you don't move all of the components together, it breaks. The registry often contains path names of executables and objects. Sometimes applicatiosn register their own components, and then cannot be moved without reinstallation which will reregister the components.
/etc/conf.modules.
In UNIX-like environments, you can move programs around and they still work. Programs tend not to be sensitive to their own location. There isn't even a standard API function in POSIX or the UNIX specification for a program to find the location of its own excecutable. In fact, such a function would have to lie, because the executable can be unlinked or renamed while the program is running. What usually matters is that your program's preferences are in some dot-rc file in your home directory or in
About the drivers: installing drivers in Linux is not quite as easy as dragging something to a folder, but it's almost there. Drivers are just files that are typically kept in some special directory structure. If you wanted to, you could set up your system so that you put all your desired drivers into some driver directory, and some script running in the background just loads (via insmod) whatever is in there, and periodically checks for stuff to be removed so that it can do the rmmod---without ever rebooting. A little design would have to go into storing the driver-specific configuration. So you are basically talking about a feature that can be hacked up in half a screenful of a bash script. I wouldn't want to do this because it would be inferior to setting up aliases in
It boils down to the remainder of your points which are still true as ever: namely the lack of UI integration for ``dumb'' users. But I suspect it's partly due to the fact that once the difficult systems programming work has been done to the point that someone can hack up some easy script to accomplish something, there is little incentive to sweat out a graphical interface that will in the end be less flexible and therefore less satisfying. That doesn't mean that there is some deep ``UNIX principle'' if you will which rules out the possibility of making graphical interfaces for system configuration and other things.
Problem with your analogy is that there is a precedent for the term cracker that predates computer technology. Figuring out a cipher is called cracking, and so is breaking into a safe (as in ``safe cracker''). So you can't object to the term cracker being applied to someone who breaks computer security on the grounds that the term already refers to a kind of food. Moreover, the two meanings are distant, so there is no confusion. Hackers and crackers are not as distant, so there is significant confusion. People who use hacker in the explorative computer programmer sense can be easily misunderstood to be referring to the security cracker meaning.
;)
When you say ``I'm a hacker'', some people may think that you break into computers, even though you mean that you like to work on neat programs. When you say ``I'm eating a cracker'', nobody thinks that you are munching on the remains a stereotypical masked guy who blows up metal boxes (or worse, performing some indecency).
So ``rooting'' is gaining access to the root directory on a server. Got it!
If the government specifies that they want source code from everyone they deal with, then they shall have source code. If the developer doesn't like it, they are free to bid for work in the private sector.
It sounds like Senator Pierre Laffitte might be confusing the free software service model with software renting (that whole business of application service providers).
;)
Providing services to customers is one thing. Providing source code and letting someone else provide the services is quite another.
They make it sound like someone is jumping out of an airplane on a motorcycle or something.
So what if TurboLinux forks the kernel? They will either die out or have to keep a parallel development stream whereby they keep taking mainstream kernels and patch their changes onto them. No big deal. There are nice tools for this, like CVS update -j or GNU patch. Eventually, their stuff will mature and may be accepted into the mainstream.
Forking happened before (anyone remember SLS?).
I think that for any significant feature to be added by an independent software team, forking *has* to take place. In fact, Linux is continuously sprouting many short-lived forks. Any time a hacker unpacks a kernel and does anything to it, wham, you have a tiny fork. Then when it becomes part of the stream, the fork goes away. To create a significant feature, you may have to have branch a much longer-lived fork. And to let a community of users test that feature, you *have* to release from that branch. Now crap: you are ostracized by the idiot industry journalists who will accuse you of fragmenting the OS.
Linus *can't* integrate Turbo's changes until those changes are thoroughly hammered on by Turbo users, so a fork is required. The only kinds of changes that Linus can accept casually are ones that do not impact the core codebase. For example, if someone develops a driver for hitherto unsupported device, great. The driver can only screw up kernels that are built with it, or into which it is loaded. Just mark the driver as very experimental and that's it.