Of course, there's the obvious argument that folks could not use drugs, which would produce even an even more efficient system than simply eliminating the enforcement side of things.
I had a friend that was really into organic food and claimed that it tasted much better.
I tried his food on numerous occasions, and couldn't ever taste a difference. There definitely was a cost difference, though.
I suppose that, whatever makes him happy was fine for him, though. Even if it was entirely psychological, he still enjoyed it more, which is what ultimately matters.
I would advocate a middleman. However, other folks prefer the recipient (which avoids the political problems of creating another Verisign-like monster).
Why should I pay you to send you email that isn't spam?
Because doing so means that globally, spam goes away. The primary network-visible differentiator between spammers and nonspammers is that spammers send vast quantities of email for which they are willing to pay almost nothing.
Would you pay, say, a tenth of a cent, or perhaps even a cent per first email to a person you send? I really think that, for most people, this is not financially stressful. In my entire time on the Internet, I believe that I have probably directly emailed fewer than three hundred people, which comes out to three dollars or thirty cents, depending upon which of those two pricing things you're using, for years and years of spam-free email.
Would you give me the cash back?
This could be implemented, yes. In the case of a middleman, I suspect that they'd want to make some fee, and would probably want to keep at least some percentage.
You say that SPF works against the way the internet works, well, the internet is a free-for-all, so why is paying per email NOT against the way the internet works?
Well, you're right about that much.:-) Because it allows peer-to-peer connectivity, which I view as the fundamental feature of the way the Internet works. There are no "special" hosts. The reason I think that pay-per-email is justified in only the case of email is that email is a very unique service, different from almost everything (with a possible exception of instant messaging) in that it allows anonymous people, anyone on the Internet, to grab your resources in the form of human time and storage space. Web servers and anonymous FTP servers mostly only provide resources in the form of connections (and most sysops have some sort of system to prevent folks from eating up connections like mad...you can't grab all 1000 or so of ftp.apple.com's connections) and bandwidth. Bandwidth (except in the case of zombies, which are dealt with in their own way) costs an attacker as much as it costs a defender, which generally is acceptable on the Internet. The Internet has many places where an attacker can cost a defender an equivalent amount of resources -- this is generally considered acceptable. Anyway, I'm rambling a bit. Email allows *anonymous* people to get at your time (which is extremely expensive relative to computing resources) and storage space (still somewhat expensive, since mostly people only have mailboxes of a few megs).
PKI? If Computer A trusts Computer B, does that mean Computer B gets a high ranking? What if Computer A is a spammer? Computer C, which nobody knows, and therefore nobody trusts, how do they get email out to people? They may be the next Slashdot, or have something earth-shatteringly important to say. Are you going to reject their messages because nobody trusts them? If they spam, presumably they get a negative score. But what if someone who has an axe to grind says they've spammed when they haven't?
These are all pretty general PKI/trust issues. There are plenty of proposals to deal with drawbacks. The thing is that trust networks aren't fundamentally flawed on multiple levels, as SPF is. There are *pages* of obvious solutions for each point you listed above -- deciding on a particular one takes thinking and hammering on, but I don't think it's unreasonable to claim that something generally acceptable to Internet folks can be settled upon.
How do PKI/Pay-for deal with throwaway domains, or compromised machines?
Well, *I* tend to favor pay-for-initial-email, using a middleman, which certainly do not encompass all pay-for systems. Middlemen would probably be accredited by ICANN, as they've done for the existing name registrar system. It's a business much like name reg
I get quite a few (perhaps not hundreds) of spams a week. SpamAssassin does pretty well at it. However, I'm not advocating SA as a long term solution. What I am concerned about is increasingly poorly built stopgap solutions that are going to cause nastier and nastier side effects.
If we're talking about something as significant as deployment of SPF, we can also deploy one of the systems that works and can be used long-term (whitelisting, pay-per-initial-email, PKI trust web, etc). All have their own disadvantages, but they can clearly be used in the long term, while SPF clearly has a number of fatal security issues that will be exploited via tools in short order.
Yeah, that is a problem. I can see spam-hat hackers attacking widely used DNS caches in order to poison them. But that would make SPAM even more illegal, and lots you could seriously get a fraud charge by doing that.
But, be honest. Do you really think that will stop, or even significantly dissuade spammers from spamming? Spam is, at the very least, very hard to trace and prosecute, and already frequently illegal. Any US spammer with a false From address (i.e. almost everything that hits my inbox) in the US is already breaking federal law. Sometimes you have a "legitimate" company hiring a spamming marketing company to market for them -- the companies hiring spamming marketing companies don't care, because they just claim "no knowledge of the marketer's activities". The spammers just sink out of sight. It's just too easy to produce tools to bypass current blocks, just as has been done for other stopgap technical measures.
Another good point. Perhaps in the future, if SPF on IP isn't enough, we could move to have mail servers automatically sign all mail that comes out of them. Check the signature with the ISP. It would be resource intensive. But if SPF doesn't do what we hope based on IP we might need to do that.
Frankly, I think that it's pretty likely that going to have to ultimately have PKI of some sort in place, potentially just supporting another scheme...but it needs to be done. The authors of SPF even admit that a trust system needs to be in place for SPF to work with to avoid severe and obvious flaws. But if you're using PKI, you're 95% of the way to doing per-user PKI, which is an infinitely superior solution. You can even transition folks not using PKI-enabled email clients by having your mail servers handle signing and auth.
Wrong, SPF can easily be implemented at the mail client site.
It *can* be, in theory, yes. The problem is that it *isn't*. The big ISPs are going to start blocking at the server. Most ISPs currently do extensive server-level mail-related blocking. Once you have an ISP doing blocking at the server, while it's technically possible for them to provide per account exemptions, it's also technically possible for them to provide per account exemptions for all kinds of existing blocks -- and they don't.
Everyone should be running their own mail server anyway.
Hear, hear. However, it doesn't do a thing if everything has to be relayed through your ISP's mail servers (inbound and out). Many, many ISPs do not allow inbound or outbound SMTP other than to their own server (or run a transparent proxy if you try to go outbound).
It does. It will be impossible to send mail from a compromised host without 'claming' those hosts as part of your SPF record.
You're a spammer. You compromise a host. You send mail via the server it would normally send outbound mail by. SPF does nothing.
And at any rate, most domains that claim spam will quickly be blacklisted.
Already, today, there are a lot of folks with that are upset (justifiably or not) about unfair blacklisting for open relays. Think about how much easier it is to ensure that there are no open relays on a network than it is to ensure that no hosts get compromis
Oooh, wow. I didn't even think of that. You're right. That's *incredibly* nasty -- someone spoofing DNS responses containing SPF records could take down, say, all AOL to MSN email for however long the SPF records stay cached. With one packet. Without even needing to flood any system, since we're talking UDP, not TCP.
Agreed. I'm going to cut-and-paste the set of flaws I was talking about *last* time SPF came up on Slashdot: First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
I was one of those people who could point at real, concrete acomplishments and say 'We made $xxx,xxx,xxx.xx because of my contribution.'
To be honest, unless you're a one man operation, rarely can one person point at something and say "We made N dollars because of me." Usually there's a sales guy involved, at least one other person producing profit, some guy handling finances, maybe someone doing secretarial work, someone ensuring that the computer you're using works and does what you want, etc.
The freelance artist, the indepedent contractor...these folks can say "We made N dollars because of me". Few employed folks can truthfully say this, though. The guy that sold the product to the customer wants to take credit, the guy that made the product wants to take credit, and the guy that designed the product wants to take credit. To say nothing of each guy's manager.
Miracle of miracles, within 10 minutes he gets in! Stupidity overtakes me and for some reason I still don't quite understand, I decided it was then necessary to confirm he had the right password, so logged back out. No, I can't think why either. It's at this point that he reveals he'd been guessing and typing so fast he hasn't got any clue what password actually got him in.........
Actually, IIRC, you need your current password to change/reset a password on NT.
Which means that the mistake was on his part -- you *still* couldn't have fixed the problem without knowing what he had typed.
You know, while that had bad consequences, it also isn't something that I'd call your mistake. Your CO asked you to kill the network, you did so. The issue that came up wasn't a technical one specific to the issue, so you weren't in a position where I'd expect you to be able to advise your CO using specialty information. This wasn't something unethical, where you might have taken another course of action, or illegal, where you should have refused to follow an order. You did exactly what your orders stipulated that you do.
Frankly, from the post, I doubt that the person dying could have been saved if the radio had been active.
Furthermore, unless the Army has rules requiring that personnel on training exercises have a comm system always up, I'm not sure that even your CO made a poor decision. There is such a thing as tragedy -- where everyone really did do the right thing, and someone still gets hurt as a result.
It's kind of like deciding to drive down Main Street in a town instead of Lambert Street and hitting and killing a kid that ran out into the street. Yes, had you taken the other road, the kid would have been alive. However, you can't be expected to or be *able* to always make the decision that produces the best outcome, or you'd be the best gambler in the world. The only thing that you can do is what seems the most sensible thing given the information that you have at the time. You did that, and nobody could ask for more.
It should unlink() the device file. However, the thing is already mounted. So all you have to do is recreate the device file with mknod and reboot and everything is back to normal.
Aliasing rm to rm -i will do nothing if you use the -f flag, as you did. -f overrides -i.
However, accidentally separating a wildcard from text is an infrequent mistake that can cause much pain. For example, typing rm -rf *.jpg
Zsh, by default, will complain at you and ask you if you *really* mean it if you use a bare wildcard with an rm command. Invaluable, and has saved my ass a few times.
If you had read my original post (which was the grandfather of what I was posting here) you'd notice that what I'm irritated about is the "single button only" mindset on their laptops, where you *can't* just replace the trackpad with a three button trackpad.
Representing in memory object sizes with "long int" *sigh*.
FWIW, this is not as trivial as one might think (from your project, I suspect you're aware of the issues involved).
I've been working on a program that ptrace()s another program and has to keep track of ranges of memory. Just because I like doing things properly, I figured that using a void * to store memory range offsets would be sufficient. Problem is, C doesn't define some operations that I needed to do (like modulus) on pointers. So I get the possibility of casting to...an int of some sort. Grr. It took me quite some time to run across intptr_t, which is an integer type guaranteed to be able to hold a pointer.
Not only is it not new or interesting -- it's effectively already present in pretty much all general purpose systems.
On my Linux box, if I malloc() a megabyte buffer, but only ever write to the first page of that buffer, the VM system will only ever hand me a page or so to use.
Probably a bit oversimplified, since overcommits might cause pressure to write out buffer data, but still...WTF is this guy thinking?
1. Take X11 and throw it out of the window. Build a FB acceled interface and make Qt/GTK use it. There already are some viable projects like DirectFB so IBM can simply inject some cash into it and strongarm the HW makers into more collaborative driver efforts.
For most operations, a FB will be significantly more CPU intensive than what is done now (and is hardware accelerated).
2. Offer X11 as an add on like Apple; it's too useful for interoperability and compat but keeping it as a modified & bloated primary interface would make it too complicated for developers. Building a least-resistance clear cut route for them... they're lazy!
True. Which is why nobody writes to Xlib. Xlib was nicely designed to build toolkits on top of. And GTK+ and Qt (which you are advocating using) *are* written to, which lets you use X11 for free.
I did mention PowerPoint. I hate it (I *love* the Getysburg Address reduce to a PowerPoint). It dumbs down everything. But we can not get away from the fact that business wants it, it speaks to the PHBs like the Bible.
I've pretty much decided that the reason we have Powerpoint is becuause we have people that are deadwood at companies. They literally do nothing but reformat and polish Powerpoint presentations. It offers vast amounts of work to do, with no necessity of actually producing anything useful.
Slashdot Mirror
Of course, there's the obvious argument that folks could not use drugs, which would produce even an even more efficient system than simply eliminating the enforcement side of things.
Break in and install a tiny wireless bug next to your PC...
Actually, that's preferable. It moves things back to the days where you had to be pretty sure that someone was suspicious before tapping them.
Currently, with computers and the phone systems of today, you can monitor just about everything.
I don't want preemptive wiretaps, thank you very much.
Parabolic microphones are another option -- again, it's not cheap, which means someone really has to be suspicious before they get tapped.
SSH is TCP-based.
Most VoIP is UDP-based.
The problem is if laws come about prohibiting programmers from writing software that encrypts audio data and places it on the network.
God, I hate legal types hitting the network.
I think the grandparent intended that NOTA == Abstain.
I had a friend that was really into organic food and claimed that it tasted much better.
I tried his food on numerous occasions, and couldn't ever taste a difference. There definitely was a cost difference, though.
I suppose that, whatever makes him happy was fine for him, though. Even if it was entirely psychological, he still enjoyed it more, which is what ultimately matters.
I'm a little unsure what "deconvolved" means.
It seems that this sentence means, using more conventional parlance, they sharpened the brightness without altering the colors to get more contrast.
Pay per email? Pay whom, precisely?
:-)
I would advocate a middleman. However, other folks prefer the recipient (which avoids the political problems of creating another Verisign-like monster).
Why should I pay you to send you email that isn't spam?
Because doing so means that globally, spam goes away. The primary network-visible differentiator between spammers and nonspammers is that spammers send vast quantities of email for which they are willing to pay almost nothing.
Would you pay, say, a tenth of a cent, or perhaps even a cent per first email to a person you send? I really think that, for most people, this is not financially stressful. In my entire time on the Internet, I believe that I have probably directly emailed fewer than three hundred people, which comes out to three dollars or thirty cents, depending upon which of those two pricing things you're using, for years and years of spam-free email.
Would you give me the cash back?
This could be implemented, yes. In the case of a middleman, I suspect that they'd want to make some fee, and would probably want to keep at least some percentage.
You say that SPF works against the way the internet works, well, the internet is a free-for-all, so why is paying per email NOT against the way the internet works?
Well, you're right about that much.
Because it allows peer-to-peer connectivity, which I view as the fundamental feature of the way the Internet works. There are no "special" hosts. The reason I think that pay-per-email is justified in only the case of email is that email is a very unique service, different from almost everything (with a possible exception of instant messaging) in that it allows anonymous people, anyone on the Internet, to grab your resources in the form of human time and storage space. Web servers and anonymous FTP servers mostly only provide resources in the form of connections (and most sysops have some sort of system to prevent folks from eating up connections like mad...you can't grab all 1000 or so of ftp.apple.com's connections) and bandwidth. Bandwidth (except in the case of zombies, which are dealt with in their own way) costs an attacker as much as it costs a defender, which generally is acceptable on the Internet. The Internet has many places where an attacker can cost a defender an equivalent amount of resources -- this is generally considered acceptable. Anyway, I'm rambling a bit. Email allows *anonymous* people to get at your time (which is extremely expensive relative to computing resources) and storage space (still somewhat expensive, since mostly people only have mailboxes of a few megs).
PKI? If Computer A trusts Computer B, does that mean Computer B gets a high ranking? What if Computer A is a spammer? Computer C, which nobody knows, and therefore nobody trusts, how do they get email out to people? They may be the next Slashdot, or have something earth-shatteringly important to say. Are you going to reject their messages because nobody trusts them? If they spam, presumably they get a negative score. But what if someone who has an axe to grind says they've spammed when they haven't?
These are all pretty general PKI/trust issues. There are plenty of proposals to deal with drawbacks. The thing is that trust networks aren't fundamentally flawed on multiple levels, as SPF is. There are *pages* of obvious solutions for each point you listed above -- deciding on a particular one takes thinking and hammering on, but I don't think it's unreasonable to claim that something generally acceptable to Internet folks can be settled upon.
How do PKI/Pay-for deal with throwaway domains, or compromised machines?
Well, *I* tend to favor pay-for-initial-email, using a middleman, which certainly do not encompass all pay-for systems. Middlemen would probably be accredited by ICANN, as they've done for the existing name registrar system. It's a business much like name reg
Less annoying then hundreds of SPAMs a week.
I get quite a few (perhaps not hundreds) of spams a week. SpamAssassin does pretty well at it. However, I'm not advocating SA as a long term solution. What I am concerned about is increasingly poorly built stopgap solutions that are going to cause nastier and nastier side effects.
If we're talking about something as significant as deployment of SPF, we can also deploy one of the systems that works and can be used long-term (whitelisting, pay-per-initial-email, PKI trust web, etc). All have their own disadvantages, but they can clearly be used in the long term, while SPF clearly has a number of fatal security issues that will be exploited via tools in short order.
Yeah, that is a problem. I can see spam-hat hackers attacking widely used DNS caches in order to poison them. But that would make SPAM even more illegal, and lots you could seriously get a fraud charge by doing that.
But, be honest. Do you really think that will stop, or even significantly dissuade spammers from spamming? Spam is, at the very least, very hard to trace and prosecute, and already frequently illegal. Any US spammer with a false From address (i.e. almost everything that hits my inbox) in the US is already breaking federal law. Sometimes you have a "legitimate" company hiring a spamming marketing company to market for them -- the companies hiring spamming marketing companies don't care, because they just claim "no knowledge of the marketer's activities". The spammers just sink out of sight. It's just too easy to produce tools to bypass current blocks, just as has been done for other stopgap technical measures.
Another good point. Perhaps in the future, if SPF on IP isn't enough, we could move to have mail servers automatically sign all mail that comes out of them. Check the signature with the ISP. It would be resource intensive. But if SPF doesn't do what we hope based on IP we might need to do that.
Frankly, I think that it's pretty likely that going to have to ultimately have PKI of some sort in place, potentially just supporting another scheme...but it needs to be done. The authors of SPF even admit that a trust system needs to be in place for SPF to work with to avoid severe and obvious flaws. But if you're using PKI, you're 95% of the way to doing per-user PKI, which is an infinitely superior solution. You can even transition folks not using PKI-enabled email clients by having your mail servers handle signing and auth.
Wrong, SPF can easily be implemented at the mail client site.
It *can* be, in theory, yes. The problem is that it *isn't*. The big ISPs are going to start blocking at the server. Most ISPs currently do extensive server-level mail-related blocking. Once you have an ISP doing blocking at the server, while it's technically possible for them to provide per account exemptions, it's also technically possible for them to provide per account exemptions for all kinds of existing blocks -- and they don't.
Everyone should be running their own mail server anyway.
Hear, hear. However, it doesn't do a thing if everything has to be relayed through your ISP's mail servers (inbound and out). Many, many ISPs do not allow inbound or outbound SMTP other than to their own server (or run a transparent proxy if you try to go outbound).
It does. It will be impossible to send mail from a compromised host without 'claming' those hosts as part of your SPF record.
You're a spammer. You compromise a host. You send mail via the server it would normally send outbound mail by. SPF does nothing.
And at any rate, most domains that claim spam will quickly be blacklisted.
Already, today, there are a lot of folks with that are upset (justifiably or not) about unfair blacklisting for open relays. Think about how much easier it is to ensure that there are no open relays on a network than it is to ensure that no hosts get compromis
Oooh, wow. I didn't even think of that. You're right. That's *incredibly* nasty -- someone spoofing DNS responses containing SPF records could take down, say, all AOL to MSN email for however long the SPF records stay cached. With one packet. Without even needing to flood any system, since we're talking UDP, not TCP.
...SPF technically wise sucks
Agreed. I'm going to cut-and-paste the set of flaws I was talking about *last* time SPF came up on Slashdot:
First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
I was one of those people who could point at real, concrete acomplishments and say 'We made $xxx,xxx,xxx.xx because of my contribution.'
To be honest, unless you're a one man operation, rarely can one person point at something and say "We made N dollars because of me." Usually there's a sales guy involved, at least one other person producing profit, some guy handling finances, maybe someone doing secretarial work, someone ensuring that the computer you're using works and does what you want, etc.
The freelance artist, the indepedent contractor...these folks can say "We made N dollars because of me". Few employed folks can truthfully say this, though. The guy that sold the product to the customer wants to take credit, the guy that made the product wants to take credit, and the guy that designed the product wants to take credit. To say nothing of each guy's manager.
The pie is nearly always growing.
:-)
Folks just don't want their piece to get smaller faster than the pie is growing.
If you can look at these numbers, they're very likely to be the exact same numbers that your ISP is looking at.
I dunno whether they'd trust these. It seems awfully easy to hack these and have whatever you want be reported back.
Naw, diversity is good. I don't really want a Linux, Inc. composed of all folks involved with Linux. Linux is too big for that.
Miracle of miracles, within 10 minutes he gets in! Stupidity overtakes me and for some reason I still don't quite understand, I decided it was then necessary to confirm he had the right password, so logged back out. No, I can't think why either. It's at this point that he reveals he'd been guessing and typing so fast he hasn't got any clue what password actually got him in.........
Actually, IIRC, you need your current password to change/reset a password on NT.
Which means that the mistake was on his part -- you *still* couldn't have fixed the problem without knowing what he had typed.
You know, while that had bad consequences, it also isn't something that I'd call your mistake. Your CO asked you to kill the network, you did so. The issue that came up wasn't a technical one specific to the issue, so you weren't in a position where I'd expect you to be able to advise your CO using specialty information. This wasn't something unethical, where you might have taken another course of action, or illegal, where you should have refused to follow an order. You did exactly what your orders stipulated that you do.
Frankly, from the post, I doubt that the person dying could have been saved if the radio had been active.
Furthermore, unless the Army has rules requiring that personnel on training exercises have a comm system always up, I'm not sure that even your CO made a poor decision. There is such a thing as tragedy -- where everyone really did do the right thing, and someone still gets hurt as a result.
It's kind of like deciding to drive down Main Street in a town instead of Lambert Street and hitting and killing a kid that ran out into the street. Yes, had you taken the other road, the kid would have been alive. However, you can't be expected to or be *able* to always make the decision that produces the best outcome, or you'd be the best gambler in the world. The only thing that you can do is what seems the most sensible thing given the information that you have at the time. You did that, and nobody could ask for more.
Actually, that's a good way to get smacked down when the prof goes to the dean and complains.
He just checks "w" and "last" output.
I wouldn't think that would cause a problem.
It should unlink() the device file. However, the thing is already mounted. So all you have to do is recreate the device file with mknod and reboot and everything is back to normal.
Aliasing rm to rm -i will do nothing if you use the -f flag, as you did. -f overrides -i.
.jpg
However, accidentally separating a wildcard from text is an infrequent mistake that can cause much pain. For example, typing rm -rf *
Zsh, by default, will complain at you and ask you if you *really* mean it if you use a bare wildcard with an rm command. Invaluable, and has saved my ass a few times.
If you had read my original post (which was the grandfather of what I was posting here) you'd notice that what I'm irritated about is the "single button only" mindset on their laptops, where you *can't* just replace the trackpad with a three button trackpad.
Representing in memory object sizes with "long int" *sigh*.
FWIW, this is not as trivial as one might think (from your project, I suspect you're aware of the issues involved).
I've been working on a program that ptrace()s another program and has to keep track of ranges of memory. Just because I like doing things properly, I figured that using a void * to store memory range offsets would be sufficient. Problem is, C doesn't define some operations that I needed to do (like modulus) on pointers. So I get the possibility of casting to...an int of some sort. Grr. It took me quite some time to run across intptr_t, which is an integer type guaranteed to be able to hold a pointer.
Not only is it not new or interesting -- it's effectively already present in pretty much all general purpose systems.
On my Linux box, if I malloc() a megabyte buffer, but only ever write to the first page of that buffer, the VM system will only ever hand me a page or so to use.
Probably a bit oversimplified, since overcommits might cause pressure to write out buffer data, but still...WTF is this guy thinking?
1. Take X11 and throw it out of the window. Build a FB acceled interface and make Qt/GTK use it. There already are some viable projects like DirectFB so IBM can simply inject some cash into it and strongarm the HW makers into more collaborative driver efforts.
For most operations, a FB will be significantly more CPU intensive than what is done now (and is hardware accelerated).
2. Offer X11 as an add on like Apple; it's too useful for interoperability and compat but keeping it as a modified & bloated primary interface would make it too complicated for developers. Building a least-resistance clear cut route for them... they're lazy!
True. Which is why nobody writes to Xlib. Xlib was nicely designed to build toolkits on top of. And GTK+ and Qt (which you are advocating using) *are* written to, which lets you use X11 for free.
I did mention PowerPoint. I hate it (I *love* the Getysburg Address reduce to a PowerPoint). It dumbs down everything. But we can not get away from the fact that business wants it, it speaks to the PHBs like the Bible.
I've pretty much decided that the reason we have Powerpoint is becuause we have people that are deadwood at companies. They literally do nothing but reformat and polish Powerpoint presentations. It offers vast amounts of work to do, with no necessity of actually producing anything useful.
Hold the thought for a minute -- you're advocating *Perl* to promote replaceability and maintainability?