Comment Re:Simple solution (Score 1) 408
Because +@domain.com is not easy to figure out? I'd be very surprised if a spammer that acquires your garbage email address can't obtain your actual email address.
Because +@domain.com is not easy to figure out? I'd be very surprised if a spammer that acquires your garbage email address can't obtain your actual email address.
$ man date
[...]
%S second (00..60)
[...]
Oh, maybe when you use that (or strftime).
If that's megaBIT then it's more like 10 GB.
Gasoline emissions, in contrast, are very healthful.
Because the EPA has made it so Diesel is ridiculously expensive.
It is common knowledge. How it works is not.
I can't find any links to the "released" papers. No fanfare on http://www.gchq.gov.uk/.
Anyone?
From the article:
> Mosh is a replacement for SSH.
It might not fork the code but it forks the concept.
> Hate to say it, but.... RTFA.
Not an article.
Nothing in that page for mosh did I get the impression it could not be ported to OpenSSH.
Because writing a new RFC for the SSH protocol and then improving the current ubiquitous OpenSSH is an unheard of undertaking.
> It's kind of hard to do things like roaming using TCP because endpoint IPs can change.
Bullshit. With UDP you have to abstract the connection so that the source IP can change. With TCP you can do the exact same fucking thing. Close the old socket when you get a connection attempt from a new client with the right handshake.
I see no rationale for not helping to improve SSH. This shit shouldn't be encouraged.
Python being the poorer choice because it is not designed to be an extension (scripting) language.
Well somebody needs to tell CCP of Eve-Online they're doing it wrong, same goes for Stackless Python project, and the authors who wrote the official Python documentation that they were wrong to document Embedding Python in Another Application. Because batrick on Slashdot said it wasn't designed for that...
If you go back to the history of Python you'll see that it wasn't originally designed with embedding in mind. As a consequence, many of its features and choices make it very difficult to do [1]. Keep drinking the Koolaid. If you hammer on a screw enough times, it will eventually sink into the wood.
[1] http://developers.slashdot.org/comments.pl?sid=2406518&cid=37267170
I just lost everything I was writing because Slashdot discarded my post when changing to plain text. I'm not going to hunt down references again. Google yourself.
Here's the rundown:
[I'm talking about the difficult in embedding Python in an application (extending the application. This is the usual domain of a scripting language.]
1) Python is huge. It is improper for small devices like FPGAs. Python weighs in at multiple megabytes.
2) Python is very difficult to sandbox.
3) It is difficult to have multiple independent Python instances running concurrently (GIL).
4) It is difficult to have multiple contexts. Python lacks proper coroutines.
5) Python is built with the extend rather than embed mindset e.g. [1].
6) Python is whitespace sensitive. It is unnecessarily difficult to write small embedded scripts or macros for your application (see WoW).
7) Python libraries make it difficult to embed in e.g. an ANSI C only environment.
[1] http://www.twistedmatrix.com/users/glyph/rant/extendit.html
Anyone can make an omelet with eggs. The trick is to make one with none.