search for: coopted

On Tue, July 28, 2015 19:46, Warren Young wrote: > > iPads can???t be coopted into a botnet. The rules for iPad passwords > must necessarily be different than for CentOS. > http://www.tomsguide.com/us/ios-botnet-hacking,news-19253.html -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne...

On Jul 28, 2015, at 2:46 PM, Chris Murphy <lists at colorremedies.com> wrote: > > My dad will absolutely stop using his iPad if it ever > requires him to use anything more than 4 numeric digits for his > password. The iPad never leaves the house. iPads can?t be coopted into a botnet. The rules for iPad passwords must necessarily be different than for CentOS. > the Mac has SSH PKA required. True, but more on-point here is that OS X ships with sshd disabled by default. You have to dig into the pref panes and tick an obscurely-named checkbox to enable it. &g...

> On Jul 28, 2015, at 11:27, Warren Young <wyml at etr-usa.com> wrote: > > On Jul 25, 2015, at 6:22 PM, Bob Marcan wrote: >> >> 1FuckingPrettyRose >> "Sorry, you must use no fewer than 20 total characters." >> 1FuckingPrettyRoseShovedUpYourAssIfYouDon'tGiveMeAccessRightFuckingNow! >> "Sorry, you cannot use punctuation."

...badly designed and that we need to rip it up and replace it before we can address DDoSes, you?re trying to boil the ocean. We have real-world practical solutions available to us that do not require a complete redesign of the Internet. One of those is to tighten down CentOS boxes so they don?t get coopted into botnets. If instead you?re saying that DDoSes are solvable with ?just? a bit of engineering, then that?s wrong, too. It takes a really big, expensive slice of a CDN or similar to choke down a large DDoS attack. I do not accept that as a necessary cost of doing business. That?s like a 1665...

On 5 May 2016 at 13:23, C Bergström <cbergstrom at pathscale.com> wrote: > Is the list PG, PG-13, R or at what level do "we" adults all consider > "ok". Even on broadcast tv (in the US) you'll hear some profanity. > (context) > https://www.fcc.gov/consumers/guides/obscene-indecent-and-profane-broadcasts Excellent context! > Some people have pointed

>After off list discussions with Jonathan Carrol and with >Michael Lawrence I think it's doable, unambiguous, >and even imo pretty intuitive for an "unquote" operator. For those of us who are not CS/Lisp mavens, what is an "unquote" operator? Can you expression quoting and unquoting in R syntax and show a few examples where is is useful, intuitive, and fits in to

The unquoting discussion is IMHO separate from this proposal and as you noted probably better served by a native operator with different precedence. I think the main benefit to providing user defined prefix operators is it allows package authors to experiment with operator ideas and gauge community interest. The current situation means any novel unary semantics either need to co-opt existing

I agree there is no reason they _need_ to be the same precedence, but I think SPECIALS are already have the proper precedence for both unary and binary calls. Namely higher than all the binary operators (except for `:`), but lower than the other unary operators. Even if we gave unary specials their own precedence I think it would end up in the same place. `%l%` <- function(x) tail(x, n =

Jim, One more note about precedence. It prevents a solution like the one you proposed from solving all of the problems you cited. By my reckoning, a "What comes next is for NSE" unary operator needs an extremely low precedence, because it needs to greedily grab "everything" (or a large amount) that comes after it. Normal-style unary operators, on the other hand, explicitly

Your example x = 5 exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z do_unquote(expr) # -> the language object f(5) + y + z could be done with the following wrapper for bquote my_do_unquote <- function(language, envir = parent.frame()) { if (is.expression(language)) { # bquote does not go into expressions, only calls

Hi folks, I've got this funny problem with R's foreign library when reading stata files. One file consistently produces vector out of memory errors after gobbling up 2.7G of memory. I parsed through the read.dta function and figured out where the error occurs and the description is below. I am running R-1.8.1 on Debian stable system glibc2.2 kernel 2.4.24. R is is compiled from source

William, Unbeknownst to me when I sent this, Jonathon Carrol started a specific thread about unquoting and a proposal for supporting it at the language level, which I think is a better place to discuss unquoting specifically. That said, the basics as I understand them in the context of non-standard evaluation, unquoting (or perhaps interpolation) is essentially substituting part of an unevaluated

...badly designed and that we need to rip it up and replace it before we can address DDoSes, you?re trying to boil the ocean. We have real-world practical solutions available to us that do not require a complete redesign of the Internet. One of those is to tighten down CentOS boxes so they don?t get coopted into botnets. > > If instead you?re saying that DDoSes are solvable with ?just? a bit of engineering, then that?s wrong, too. It takes a really big, expensive slice of a CDN or similar to choke down a large DDoS attack. I do not accept that as a necessary cost of doing business. That?s li...

Bill, Right. My example was the functional form for clarity. There is a desire for a unary-operator form. (rlang's !! and !!! operators described in the comments in the file I linked to). I can't really make that argument because I'm not one of the people who wanted that. You'd have to talk to the authors of the rlang package to find out their reasons for thinking that is

Once upon a time, Warren Young <wyml at etr-usa.com> said: > Much of the evil on the Internet today ? DDoS armies, spam spewers, phishing botnets ? is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords. Since most of that crap comes from Windows hosts, the security of Linux SSH passwords seems hardly relevant. > Your freedom to use