As far as I know, there are still no quadband phones (800MHz/850MHz/1800MHz/1900MHz), although I'm sure that that will be simply a matter of time. Those would be the ultimate roaming phones for frequent transatlantic travellers.:-)
As a matter of fact, two phones offered by AT&T Wireless do just that: the NEC 515 and the NEC 525. They aren't so highly priced as the Motorola phone mentioned in a sibling to this post(though the 525 is still a fairly high-end phone), unless the sibling poster was talking about $Cdn or something like that.
GSM is, as mentioned elsewhere, a TDMA standard; that commonly referred to as TDMA in the US is known as D-AMPS or IS-136. 850 MHz was indeed around with the earlier analog phones; 1900 opened up to alleviate signal congestion(which was also certainly helped by the triplex inherent in the IS-136 standard itself).
Then don't complain when the people with "insanely cheap" phones have better coverage when you're wrestling with fast busies and dropped calls. There are only so many channels in the 1900 MHz band, so they're going to have to open up the 850 for GSM(which is relatively recent for AWS) in more places - and in some cases it might supplant, rather than work alongside, the 1900. As much as I dislike corporate politics, in this case the company gave you the means to keep your service running optimally - you just pissed on it.
I don't suppose you considered the fact that you can move your SIM between two different phones?
As this and the next earlier sibling post point out, the commodity here isn't just the software - it's the time and effort that went into developing the software. That cannot be recovered - whereas sugar(consumed, broken down, exhaled as, largely, carbon dioxide and water, both of which are taken up by plants and put back together) works its way back into the ecosystem, and thus, is just as copyable as time and effort, which are ongoing without the steps in the middle.
Getting off topic here, but the point is, just because software can be copied quickly doesn't make it any less valuable to produce, and that value to the consumers is what defines a commodity.
If someone is capable of signing the forms but refuses to do so, that strikes me as a bad sign right there.
It's not without some cause - people in that condition wouldn't want to spend the time reading the forms in detail even if they are able to make sense of them - but that person, by the sound of it, was being as obnoxious as she possibly could. She turned "I'm a lawyer" into an implied threat.
"Richard, a former reserve deputy in the sheriff's marine division, more than three years ago offered to provide the Web site at no cost to the county as an in-kind contribution. Hackel, who enthusiastically supported it, said Richard agreed to operate it in exchange for publicity for his company." [emphasis mine]
If that is accurate, then the guy tried to retroactively change the fee, exploiting the fact that there wasn't a written contract. The response is definitely extreme, though; it could probably have been settled with much less drastic measures.
FreeBSD's handbook does a fair job. The chapter synopses state at the beginning what you should know / be able to do before reading, and what you WILL know / be able to do when you're done. It also has a reasonably extensive and thought-out bibliography, divided into overall categories(users vs. administrators vs. developers, etc). Also, its mailing lists are, in my experience, populated by quite friendly people - even if they don't have information that helps me(which they generally do), I don't feel like I'm being looked down upon for asking, even for the basics.
Its installation can be a little hard for new users to grasp, especially the bit near the beginning about hard drive slices, but the information in the handbook helps ameliorate this. About the only thing I really miss from the install is a time estimate/percentage complete/whatever.
Getting X set up correctly is the first major hurdle I run into, but now I more or less know how to work around my computer's instabilities and get things running.
The issue, I think, is when it's not useful enough to justify the expense. A person might think a certain song is okay, but if it's just "okay", will they want to buy the entire overpriced CD just for that song? The priority might rank as rather low on the list of "Things To Get", because they can live without that particular song if need be. On the other hand, if that person knows of five or six fantastic songs on a similarly-priced CD, they'd be much more favourably inclined toward purchasing it(though they still might not count it as quite good enough, that's their own priority).
It comes down, for a number of people, to that limited resource which is money. Mind you, if they buy a super-expensive computer and get a T1 line just to do some petty file sharing, things start to make less sense.
Now, granted, I'd hope any university-level assignment is much more complicated, but that also means you're going to find a lot more "almost, but not quite" hits relative to the number of hits overall, so your signal to noise ratio remains impractically small.
Still an apostrophe issue, which is also seen in "didnt"[sic]. Occam's razor steps in: "wifes" meaning the plural would require two errors(spelling and punctuation) as opposed to just one(punctuation alone).
Now, plainly, people can screw up many times in a row, but let's give a little bit of room here.
Back in my earlier(i.e. naive) computing days, I got hit with a Maltese Amoeba. The device never actually went active.
In that case, it would've been bad if it had, since it would've overwritten system files, but I got an antivirus before that happened.
Some other time, I got hit with an IP attack virus. Regular virus scanning caught it soon after, and though the virus itself didn't SEEM to do much(that I remember; it could've been a backdoor), that was around the time I got interested in firewalls.
Entities should not be multiplied except when necessary.
For a pine cone to fall from a tree requires three things: the pine cone, the tree, and something to pull the former from the latter.
The other hypothesis still involves those three factors(they are all observable), but dismisses the force as irrelevant to this situation and replaces it with aliens(1), the Illuminati(2), and Masonic doctrine(3). Each of those three things is itself highly intricate(but then, gravity can be as well).
You are presented with three entities versus six or more. That, from what I understand, is one of the more common applications of Occam's razor: the answer that involves the least number of factors is more likely to be correct.
That assumes that your printer's method works with the ink in question. To take a somewhat unrelated example, I'm not sure your typical ink would be good to put into a bubble-jet and apply by boiling. Non-native ink could fail to dispense properly, clog nozzles, or dispense TOO readily compared to the ink for which a printer is designed(or vice versa).
Similar printer ink is a lot more likely to work in another printer than ink which was never intended for that purpose.
The software might have to be written to only use a single port, perhaps? i.e. if a port stays open, wait for it to close/force it to close before proceeding. I can see this causing problems if multiple attempts collide, though.
Of course, this might be because I just don't know how the TCP stack actually works deep down. But so long as the connection attempts are in series rather than in parallel...
Perhaps a program that acts as a proxy, then? Anything you need to have knock elsewhere, you tell to connect to your local proxy, with the information required to knock. It would try connecting to the remote server, and return some sort of failure - connection refused would be closest to the literal truth, authentication failed would be what it actually means...
Anything I try to think of would be a hack. And while there's nothing wrong with that in the short term, it's looking like it'd be much more reliable to write a knocking SSH (or whatever) client that expected you to have a particular service or daemon running, and attempted to communicate with it. Thus there would be some resistance to implementing this mechanism.
For those who want the additional (NOT replacement) layer of security, it might be worthwhile to overcome that resistance. Someone could write the "listening" routine and a compatible "knocking" daemon, and a man page detailing how to communicate with the daemon is all developers for it need to know if they only want to make programs to call this daemon. I daren't go into further detail until I actually know something about how processes communicate beyond "kill (PID)" (kill -s KILL if it's sticky, kill -s HUP if I'm getting inetd to reload its.conf).
Maybe it would be an option to have the program connect to the daemon, give the details, and the daemon would tell the program when to actually try connecting to the server(via a "done" message and disconnect)?
As I am not a developer, I realise I've probably bent the accepted syntax to hell and back, but if the meat of my post is unclear, I'll definitely try to clarify(with better syntax if I get suggestions on same).
Ah, good point. Being a purely workstation user myself it's easy to lose sight of such constraints. Routing everything through a daemon that enforces a delay(or even sequence) would quickly result in huge performance losses on a busy server, I can see that now. It also might not be enough if the server being knocked just drops the packets, rather than sending back a refusal.
Having the port "time out" and lock with respect to the source IP only after a specific time(it need not be long, depending on turnaround time) might help to fix this, but results in decreased security.
So this might only be useful for things that don't make so many requests - like SSH. HTTP, SQL, even e-mail might overload it. (SMTP, at least - retrieval mechanisms like IMAP or POP would be more likely to run workstation-server instead of server-server, and note that I don't mean server vs client here.)
A number of audiophiles have also told me that well-maintained vinyl has much better fidelity than tapes and CDs - which are digital formats. Vinyl records are the only analog audio format that I'm personally familiar with. When you don't have to break sound down into little bits, you're going to get as much of the sound as the recorder was able to pick up - but try finding needles these days.
"If you're not on-site" should be "If you're not in the office" or "If you're on-site". Wires crossed, my mistake, etc.
Courier companies would be sacrificing precious space for packages if they had a xerox in the van. It also still takes more time than copy paper, so long as it's well perforated, but speaking personally, I don't mind using a stylus and waiting a few seconds for a printed receipt. That in itself raises the question, though, of what's "original" - if you accept the digitised signature, fine, otherwise you need to sign on paper and deal with either the copy paper or the time/equipment requirements.
If you're not on-site and need to give a copy to the customer, for instance, carbon paper is a lot more portable than a copy machine, and much faster than taking it back to home base, so to speak, and running back with a copy.
Carbonless paper, as others have pointed out, offers the same advantage, but in my experience, is also easy to mark without meaning to. Carbon paper, once it's done, you can remove the carbon sheets - and once you've separated the copies, that's probably going to be done already.
Obviously it does have its limits - I, too, hate using carbon(less) paper for more than three copies, if that. This is another reason that signature tablets are nice - but they aren't as good for a self-serve situation.
In theory, a system could be tolerant of (or even expect) a number of false knocks to unrelated ports.
Let's say the key sequence is 30, 32, 31. What if it actually expects 30, 1-3 random knocks(but not 32), 32, 0-1 random knocks(but not 31), 31?
No single security option is likely to be enough, of course, but if the knock string is seemingly of varying length, it would certainly provide another layer.
What would be so critical that you need to open two connections to the same host at the exact same time? Open one, then open another if you need to.
For an automated system, enforce a wait time(possibly small) between requests - or ensure that another application cannot access the same resource until the first is done; subsequent attempts would be queued. This notion of mine would imply that requests are actually being routed through a single local process and not directly by the accesesing application, so is probably impractical, but nevertheless, why do you need to open two connections to the same place at once?
Even if it's to two different ports on the target machine, you should be able to wait for the knock sequence to be completed and the first connection opened before starting the second knock.
The article summary states that the ports involved are closed, including those knocked on. I cannot read the article itself from work, so can't personally verify the validity of that summary at this time.
This statement at the end doesn't keep people from being swayed by what came before.
Reaching waaaaaaay, back, Antony in Shakespeare's "Julius Caesar" used such rhetoric to get the citizens of Rome enraged by Brutus and the other conspirators against Caesar, while constantly mentioning how honourable Brutus was.
Slashdot Mirror
As far as I know, there are still no quadband phones (800MHz/850MHz/1800MHz/1900MHz), although I'm sure that that will be simply a matter of time. Those would be the ultimate roaming phones for frequent transatlantic travellers. :-)
As a matter of fact, two phones offered by AT&T Wireless do just that: the NEC 515 and the NEC 525. They aren't so highly priced as the Motorola phone mentioned in a sibling to this post(though the 525 is still a fairly high-end phone), unless the sibling poster was talking about $Cdn or something like that.
GSM is, as mentioned elsewhere, a TDMA standard; that commonly referred to as TDMA in the US is known as D-AMPS or IS-136. 850 MHz was indeed around with the earlier analog phones; 1900 opened up to alleviate signal congestion(which was also certainly helped by the triplex inherent in the IS-136 standard itself).
Then don't complain when the people with "insanely cheap" phones have better coverage when you're wrestling with fast busies and dropped calls. There are only so many channels in the 1900 MHz band, so they're going to have to open up the 850 for GSM(which is relatively recent for AWS) in more places - and in some cases it might supplant, rather than work alongside, the 1900. As much as I dislike corporate politics, in this case the company gave you the means to keep your service running optimally - you just pissed on it.
I don't suppose you considered the fact that you can move your SIM between two different phones?
As this and the next earlier sibling post point out, the commodity here isn't just the software - it's the time and effort that went into developing the software. That cannot be recovered - whereas sugar(consumed, broken down, exhaled as, largely, carbon dioxide and water, both of which are taken up by plants and put back together) works its way back into the ecosystem, and thus, is just as copyable as time and effort, which are ongoing without the steps in the middle.
Getting off topic here, but the point is, just because software can be copied quickly doesn't make it any less valuable to produce, and that value to the consumers is what defines a commodity.
If someone is capable of signing the forms but refuses to do so, that strikes me as a bad sign right there.
It's not without some cause - people in that condition wouldn't want to spend the time reading the forms in detail even if they are able to make sense of them - but that person, by the sound of it, was being as obnoxious as she possibly could. She turned "I'm a lawyer" into an implied threat.
Winamp(like who knows how many other programs) seems to have issues with my computer, so yes, I actually do use a video player to play my videos.
Trillian, on the other hand, I do use(and Gaim when I'm running under FreeBSD).
Mind you, with WMP having more and more issues, that point might just become moot.
From the article(as quoted above):
"Richard, a former reserve deputy in the sheriff's marine division, more than three years ago offered to provide the Web site at no cost to the county as an in-kind contribution. Hackel, who enthusiastically supported it, said Richard agreed to operate it in exchange for publicity for his company." [emphasis mine]
If that is accurate, then the guy tried to retroactively change the fee, exploiting the fact that there wasn't a written contract. The response is definitely extreme, though; it could probably have been settled with much less drastic measures.
Donning my flame-retardant suit right now, but:
FreeBSD's handbook does a fair job. The chapter synopses state at the beginning what you should know / be able to do before reading, and what you WILL know / be able to do when you're done. It also has a reasonably extensive and thought-out bibliography, divided into overall categories(users vs. administrators vs. developers, etc). Also, its mailing lists are, in my experience, populated by quite friendly people - even if they don't have information that helps me(which they generally do), I don't feel like I'm being looked down upon for asking, even for the basics.
Its installation can be a little hard for new users to grasp, especially the bit near the beginning about hard drive slices, but the information in the handbook helps ameliorate this. About the only thing I really miss from the install is a time estimate/percentage complete/whatever.
Getting X set up correctly is the first major hurdle I run into, but now I more or less know how to work around my computer's instabilities and get things running.
The issue, I think, is when it's not useful enough to justify the expense. A person might think a certain song is okay, but if it's just "okay", will they want to buy the entire overpriced CD just for that song? The priority might rank as rather low on the list of "Things To Get", because they can live without that particular song if need be. On the other hand, if that person knows of five or six fantastic songs on a similarly-priced CD, they'd be much more favourably inclined toward purchasing it(though they still might not count it as quite good enough, that's their own priority).
It comes down, for a number of people, to that limited resource which is money. Mind you, if they buy a super-expensive computer and get a T1 line just to do some petty file sharing, things start to make less sense.
Three minutes? For a "hello world"?
Now, granted, I'd hope any university-level assignment is much more complicated, but that also means you're going to find a lot more "almost, but not quite" hits relative to the number of hits overall, so your signal to noise ratio remains impractically small.
I really, really wish more people were this thorough.
I, however, don't have any links to support my own statement. Grain of salt time.
In that case, it'd be "wives'".
Still an apostrophe issue, which is also seen in "didnt"[sic]. Occam's razor steps in: "wifes" meaning the plural would require two errors(spelling and punctuation) as opposed to just one(punctuation alone).
Now, plainly, people can screw up many times in a row, but let's give a little bit of room here.
Back in my earlier(i.e. naive) computing days, I got hit with a Maltese Amoeba. The device never actually went active.
In that case, it would've been bad if it had, since it would've overwritten system files, but I got an antivirus before that happened.
Some other time, I got hit with an IP attack virus. Regular virus scanning caught it soon after, and though the virus itself didn't SEEM to do much(that I remember; it could've been a backdoor), that was around the time I got interested in firewalls.
Entities should not be multiplied except when necessary.
For a pine cone to fall from a tree requires three things: the pine cone, the tree, and something to pull the former from the latter.
The other hypothesis still involves those three factors(they are all observable), but dismisses the force as irrelevant to this situation and replaces it with aliens(1), the Illuminati(2), and Masonic doctrine(3). Each of those three things is itself highly intricate(but then, gravity can be as well).
You are presented with three entities versus six or more. That, from what I understand, is one of the more common applications of Occam's razor: the answer that involves the least number of factors is more likely to be correct.
That assumes that your printer's method works with the ink in question. To take a somewhat unrelated example, I'm not sure your typical ink would be good to put into a bubble-jet and apply by boiling. Non-native ink could fail to dispense properly, clog nozzles, or dispense TOO readily compared to the ink for which a printer is designed(or vice versa).
Similar printer ink is a lot more likely to work in another printer than ink which was never intended for that purpose.
The software might have to be written to only use a single port, perhaps? i.e. if a port stays open, wait for it to close/force it to close before proceeding. I can see this causing problems if multiple attempts collide, though.
Of course, this might be because I just don't know how the TCP stack actually works deep down. But so long as the connection attempts are in series rather than in parallel...
Perhaps a program that acts as a proxy, then? Anything you need to have knock elsewhere, you tell to connect to your local proxy, with the information required to knock. It would try connecting to the remote server, and return some sort of failure - connection refused would be closest to the literal truth, authentication failed would be what it actually means...
.conf).
Anything I try to think of would be a hack. And while there's nothing wrong with that in the short term, it's looking like it'd be much more reliable to write a knocking SSH (or whatever) client that expected you to have a particular service or daemon running, and attempted to communicate with it. Thus there would be some resistance to implementing this mechanism.
For those who want the additional (NOT replacement) layer of security, it might be worthwhile to overcome that resistance. Someone could write the "listening" routine and a compatible "knocking" daemon, and a man page detailing how to communicate with the daemon is all developers for it need to know if they only want to make programs to call this daemon. I daren't go into further detail until I actually know something about how processes communicate beyond "kill (PID)" (kill -s KILL if it's sticky, kill -s HUP if I'm getting inetd to reload its
Maybe it would be an option to have the program connect to the daemon, give the details, and the daemon would tell the program when to actually try connecting to the server(via a "done" message and disconnect)?
As I am not a developer, I realise I've probably bent the accepted syntax to hell and back, but if the meat of my post is unclear, I'll definitely try to clarify(with better syntax if I get suggestions on same).
Ah, good point. Being a purely workstation user myself it's easy to lose sight of such constraints. Routing everything through a daemon that enforces a delay(or even sequence) would quickly result in huge performance losses on a busy server, I can see that now. It also might not be enough if the server being knocked just drops the packets, rather than sending back a refusal.
Having the port "time out" and lock with respect to the source IP only after a specific time(it need not be long, depending on turnaround time) might help to fix this, but results in decreased security.
So this might only be useful for things that don't make so many requests - like SSH. HTTP, SQL, even e-mail might overload it. (SMTP, at least - retrieval mechanisms like IMAP or POP would be more likely to run workstation-server instead of server-server, and note that I don't mean server vs client here.)
A number of audiophiles have also told me that well-maintained vinyl has much better fidelity than tapes and CDs - which are digital formats. Vinyl records are the only analog audio format that I'm personally familiar with. When you don't have to break sound down into little bits, you're going to get as much of the sound as the recorder was able to pick up - but try finding needles these days.
"If you're not on-site" should be "If you're not in the office" or "If you're on-site". Wires crossed, my mistake, etc.
Courier companies would be sacrificing precious space for packages if they had a xerox in the van. It also still takes more time than copy paper, so long as it's well perforated, but speaking personally, I don't mind using a stylus and waiting a few seconds for a printed receipt. That in itself raises the question, though, of what's "original" - if you accept the digitised signature, fine, otherwise you need to sign on paper and deal with either the copy paper or the time/equipment requirements.
If you're not on-site and need to give a copy to the customer, for instance, carbon paper is a lot more portable than a copy machine, and much faster than taking it back to home base, so to speak, and running back with a copy.
Carbonless paper, as others have pointed out, offers the same advantage, but in my experience, is also easy to mark without meaning to. Carbon paper, once it's done, you can remove the carbon sheets - and once you've separated the copies, that's probably going to be done already.
Obviously it does have its limits - I, too, hate using carbon(less) paper for more than three copies, if that. This is another reason that signature tablets are nice - but they aren't as good for a self-serve situation.
In theory, a system could be tolerant of (or even expect) a number of false knocks to unrelated ports.
Let's say the key sequence is 30, 32, 31. What if it actually expects 30, 1-3 random knocks(but not 32), 32, 0-1 random knocks(but not 31), 31?
No single security option is likely to be enough, of course, but if the knock string is seemingly of varying length, it would certainly provide another layer.
Use an OTKS to open the port for a specific user, perhaps, and then expire that sequence, as with a one-time password?
I'll shut up about it now, though, since I can't even get OPIE running right on my FreeBSD box.
What would be so critical that you need to open two connections to the same host at the exact same time? Open one, then open another if you need to.
For an automated system, enforce a wait time(possibly small) between requests - or ensure that another application cannot access the same resource until the first is done; subsequent attempts would be queued. This notion of mine would imply that requests are actually being routed through a single local process and not directly by the accesesing application, so is probably impractical, but nevertheless, why do you need to open two connections to the same place at once?
Even if it's to two different ports on the target machine, you should be able to wait for the knock sequence to be completed and the first connection opened before starting the second knock.
The article summary states that the ports involved are closed, including those knocked on. I cannot read the article itself from work, so can't personally verify the validity of that summary at this time.
This statement at the end doesn't keep people from being swayed by what came before.
Reaching waaaaaaay, back, Antony in Shakespeare's "Julius Caesar" used such rhetoric to get the citizens of Rome enraged by Brutus and the other conspirators against Caesar, while constantly mentioning how honourable Brutus was.