Must be a very long time since you looked at a grammar book. Saying "as are" does not link or imply that Chechnya is [or is not] a former Soviet Bloc country.

Examples:
- The city of Anytown, USA is having financial difficulties, as are state governments and many corporations.
- The Australian government is having financial difficulties, as are European governments, notably France, Belgium, and Spain.

For your correction to be valid there would have to be something like:
- The city of Anytown, USA is having financial difficulties, as are OTHER state governments and many corporations.
- The Australian government is having financial difficulties, as are OTHER European governments, notably France, Belgium, and Spain.

Perhaps one or more governments have already been doing this in various forms. While quasi-legal for a government to do it [some have done far worse], this might be a case of the private sector cutting into the margin ... Last time I looked, wasn't the Chechnyan government hard up for cash [as are a lot of former Soviet Bloc countries, notably Russia]? Just sayin' ...

In all seriousness, this ISIS catfishing could easily be subverted along the lines of the Nigerian oil minister scam: "Hi, you don't know us, but we'd like to scam ISIS and fight terrorism. Would you like to help? If so, just send us some money so we can bait them into sending us some money ..."

There are many uses for drones and some of them are to save a life. See http://www.cnn.com/2015/08/01/...

Scroll through the videos and you'll see:
- Drone assists in river rescue
- Firefighters hope drones will save lives
- This drone could save your life

The last one is a drone that delivers a cardiac defibrillator to a heart attack victim, during the first few crucial minutes. That is, a person has a heart attack, someone calls it in to 911, they dispatch the drone, and the helper uses the defibrillator to keep the person alive, until the medical team arrives.

They're going to send the drone along the fastest possible path. They aren't going to check whether it flies over your property or not [just like they wouldn't for a medical helicopter].

Okay, so you shoot it down. I'd be willing to bet that you'd have more legal liability than a fine. More like criminal liability, just as if you tried to interfere with paramedics at the scene of an accident. Not to mention causing a person's death in a case where they would otherwise have been saved.

Uh, not quite the same era. "Steamboat Willie" was 1927, but "The Birthday Song" was originally penned by [attributed to] Patty and Mildred J Hill in 1893.

Disney has always renewed copyrights, but only so many can be granted. Hence, the Sonny Bono Copyright Act.

Birthday song is different [I'll try to summarize the legal brief found in the article]:

Warner/Chappell's response is that the 1922 songbook was an "unauthorized" and/or "piratical" copy. See http://arstechnica.com/tech-po...

In a Skinner box, the lab rat pushes a button and gets a food pellet ... Or, an electric shock... With WinX, pressing the start button has never caused the computer to dispense food, but often the user is shocked by the results ...

Thanks for the info. Honestly, I can't remember where I got the 2ms figure [even though it was within a day or so--sigh]. It may have been from somebody else's post, or I misread a wikipedia entry, or another article (e.g. arstechnica, or [gasp] cnn).

This is even better. 1000x faster than flash (at 5us) means 5ns which brings 3D/XPoint into the realm of DRAM [or beyond]. I've done a quick check and at least two different pages peg DRAM at 50ns [don't quote me--obviously :-)]. In fact, I just found another page that pegs DRAM at 10ns. This is still 25x slower than a 2.5 GHz processor, which is enough to justify the internal cache.

Most DRAM memory systems (e.g. DDR2, DDR3, etc.) take X time to produce the first cache line, but can produce the next N cache lines (from different interleaved banks) in short order as they've been fetched in parallel (they assume a linear access pattern as for a simple loop through an array). This makes it harder to compare apples-to-apples given the sketchy info Intel has released at this point.

I reread the fine print on one of Intel's slides and it just says that XPoint has negligible endurance problems. So, no wear leveling needed. I've refrained from buying laptops that have SSDs (based on flash) because of this. I was an engineer in a company where the marketing dept pushed for flash instead of hard drive (some 10+ years ago). They wanted it because it was sexy and fewer systems arrived at the customer with DOA hard drives due to jostling in shipment. But, these systems would fail at random times due to wearout (despite wear leveling and some additional mitigation we were doing). Eventually, the CEO said to me: "I guess we made a mistake using flash". I said: "Yup, you should have listened to your engineers" [our attitude was flash will be the choice but not now].

Since the cost hinted at [between DRAM and flash] means that XPoint will have a lower cost than DRAM [at higher density]. So, if the access times are at DRAM or better [or even slightly slower], XPoint will make a DRAM replacement. Since DRAM/flash cost differences are something on the order of 10x per bit, if XPoint's cost is closer to flash, it's also a flash replacement, even if it's a bit more expensive.

XPoint seems to be much simpler/smaller in cell design [no transistor in the cell], no complex timing sequences as in DRAM, no complex wear leveling or block access as in flash. The simplicity of designing a system around XPoint can make it very attractive in a variety of use cases. The claim that this will open up design of systems we haven't thought of yet isn't mere hype.

In short, if only half of what they've said about XPoint is true, it is a big deal.

A friend of mine said that W10 will remove apps that are not "W10 compatible". I thought this was an exaggeration but according to http://www.microsoft.com/en-us... it may:

Normally, I'm not overly paranoid, but that last paragraph is a bit troublesome. Is there a list of such incompatible apps? Even though the get W10 app is supposed to flag them ahead of time, I'd be more comforted if there was also a list [that also explained why], in addition to [and before] having to run the probe app.

For example, I've got 5+ years of TurboTax. Each [year's] version does its own update when you invoke it. You need to keep all versions around [just in case you need to look at an older tax form you filed]. If the oldest version was not W10 compatible, would you need to invoke it (under Win7/Win8) to get it to update/upgrade before installing W10?

What about self updating apps in general? Adobe Acrobat Reader and Flash, as well as [yecch] Java come to mind. Or, Firefox, cygwin, vlc, handbrake?

NAND will eventually hit the "die shrink" wall. Since this new Intel memory apparently fits nine cells in the same die area as a NAND cell, it will eventually take over from NAND.

As a side note [to show I'm not totally against NAND flash], a Japanese researcher found, about a year ago, that if you add a heating element to a NAND cell [similar to the one in ferroelectric memory], you can "boil off" the excess trapped charge and eliminate the "wear out". He believed that this was a trivial addition to existing NAND process tech [and could have been done five years earlier] and would take less than a year to enter full production. Note further, that the "boil off" operation only needs to be done periodically, say once every six months or so [it resets the "wear out" cycle].

Intel, historically, charges through the nose for new tech like this [they certainly charged a lot for NAND when it came out], then eventually drops the price. When the 80386 came out, they were charging $750 per chip, even though the chip was designed to be sold at a handsome profit at $35/chip. So, I suspect they will keep the price high, serve the market high end, and then drop the price, increase the speed, etc. if other competing technologies look like they'd overtake it [and when their own NAND factories reach EOL, etc.]

My long term bet is [still] on Hewlett Packards's [or others] memristor memory. Back in Oct 2011, they were planning an SSD replacement within 18 months, followed by a DRAM replacement in another 18, and then on board CPU memory later. They've since dialed that back to 2018 for SSD. See http://www.theregister.co.uk/2... (Also, wikipedia on memristor). They must believe that they can compete effectively with flash, even with projected NAND advances. Meg Whitman recently got a presentation on memristor from the engineering team, and when it was all over, she said to the finance VP [I'm paraphrasing] "Find them whatever money they need".

Disclaimer: I have a special fondness for memristor because the guy who first postulated its existence was Leon Chua [at Perdue]. My EE professor was one of Chua's students [and used to tell amusing anecdotes about Chua].

This memory is byte addressable (e.g. RAM-->random access memory), so no "block erasure" needed in the write cycle as in NAND flash. It's also 1000x faster than NAND flash (at 2ms), so access time should be about 2us, and no wear leveling needed. It also has a higher memory density--9x if you believe the block diagram. It can also be stacked 3D, which, IIRC, flash can't [or hasn't been] up to this point.

There are a number of other non-volatile "solid state" memory technologies in the works: magneto-resistive (memrister) RAM (with an access time of L2 cache), ferroelectric RAM and carbon nanotube memory (with a switching time on the order of picoseconds).

These are a few years off--depending. But, this new memory is slated to go into full production in 2016. Cost is a bit more than DRAM, but less than flash.

With regard to SSDs, we're at a similar point just before core memory got replaced by DRAM, some 30 years ago. It should also be noted that Intel is a major NAND flash developer/manufacturer/proponent, so if they're coming out with this in production volume, it will [quickly] erode the market for their own NAND flash business and they seem to be happy to do this.

SATA 3.2 (aka SATA Express) is a connector change, but is actually PCIe. PCIe is already fast enough. IIRC, Apple hooks up some SSDs directly through PCIe.

And, PCIe can actually go "off board" via a cable (since PCIe is based on separate upstream/downstream lanes and differential line drivers). Also, PCIe 4.0 will have a transfer rate of 31.5 GB/s, yet be fully backward/forward compatible.

Intel already has a CPU package that has two substrates wire bonded together, one for CPU and one for memory. When I saw this, I assumed it would be to accomodate HP's memrister memory. But, now, it's [obviously] been planned for this new type of memory.

Okay, just answered my own question. I also had "ChallengeResponseAuthentication no" in my sshd_config. When I changed this to "yes", I was able to reproduce the bug. In the original article, I had done a /. post with a link to a redhat page explaining why they used "no" and it is because of keyboard interactive [which tracks CRA].

My original slashdot post, with additional security I use and the logging of script kiddies I've been doing for years: http://slashdot.org/comments.p...

The redhat page: https://access.redhat.com/solu...

I just tested this (I've got UsePAM yes in sshd_config) on fedora 21 and I only get three tries before disconnect. So, what's special about freebsd?

I never did post anything back to an ISP. I assumed the result would be what you saw in practice. Also, if it were "state sponsored", they would ignore it. If it were somebody trying to find a portal that would circumvent the "Great Firewall of China" [which I'd be in favor of], posting back might just "out" them [to the government].

I just got sshd patched/reinstalled. I just reverified that it disallows login/pw from public IP but allows login from local LAN on accounts that have no pubkey. So, I opened the firewall for sshd [it had been firewalled for two days]. It took exactly five hours for the first script kiddie to show up.

No, you're not crazy. If you are, then I am, too. People that say that are usually uninformed/unaware of what truly constitutes good security. IMO, security is relative to what you're trying to protect. Good security should be minimally intrusive to authorized users. People who bandy about the "crazy card" are most likely to implement systems that regular users try to circumvent (e.g. mandating a 30 character password with funky chars will just cause users to put the password on post-it notes). Note that for website logins, I use a different login for each site, and different funky password. Most of the time, the browser password manager takes care of the pain.

I have [being a systems/kernel programmer] have worked on some "security" projects, and some of the people I worked with were "crazy". By that I mean, they locked down the development environment to the point where it was almost unusable and productivity suffered. In addition to genuine security, they also subscribed to the "security through obscurity" doctrine. This seems to be typical, based on my experience, and what I've read about what Linus [Torvalds] has to say about them.

OTOH, I worked on a realtime broadcast quality realtime H.264 encoder. While everybody had a personal login, the lab encoders' root password were "password". We made this decision from day one that the test encoders were "test equipment", just like an oscilloscope. This was fine, because the entire lab subnet was triple firewalled and even if somebody had logged into root on the encoder, it would let them roach it, but not get access to anything that mattered like the CVS server, etc.

Here's a different type of "crazy" ...

Ironically, the only place where we had to use high security was in product shipments to our principal customer. Updates had both software changes and firmware changes [to custom hardware], which were QA'ed as a unit. But, this customer felt that software updates were okay, but that firmware updates were too "risky" [and that they knew better than we did]. So, they would apply the software changes but not the firmware ones, and then complain to customer support that "things were broken".

We were providing "enterprise grade" customer support [including onsite visits] and even after telling the customer to update the firmware they wouldn't do it. To solve this, we [engineering] made it [had to make it] impossible to do a piecemeal upgrade [with a nearly impossible to remember root password and disabling any override to the boot process].

Also, we had a rev numbering scheme that was X.Y.Z where Z was for simple/minor bug fixes. That same customer balked, thinking any change to Z was "a major change" [based on number of "dots"]. We solved this by shipping them the revs as 1.X.Y.Z and they were happy once again [blissfully unaware].

I'm probably going to be labelled crazy for what I say below. It's a rant about selinux in "targeted" mode, so you can skip it if you want.

selinux was designed [by the NSA] to provide security for gov't systems that have multiple levels and classifications. Confidential, secret, top secret, most secret, etc. And, need to know classifications like "noforn" [no foreign], "five eyes" [US, Canada, England, Australia, ???], etc. This is useful. An example would be applying this to the FBI. Not every FBI agent has need-to-know about every ongoing investigation.

But, nobody would use that stuff outside a government. So, selinux has the targeted mode. It is supposed to prevent access to things that can't be codified in ordinary file rwx permissions [owner, group, other] or ACLs. It is proffered as "you get better protection", but the real reason is to justify its inclusion in the mainline kernel.

But, selinux in targeted mode is: dumb, annoying, useless. For example, it has a specific rule to deny /home to apache [on the assumption that a web server should not have access to user home directories]. But, on my system, /home is the mount point for a separate large disk. Some of the subdirectories are just to hold large data (e.g. /home/database). I tried doing this with /bigdisk as the mount point, with /home as a loop mount [or symlink] to /bigdisk/home, but this created even more problems. I actually put the apache directories under /home/apache and selinux complained. I had to write a script to change selinux permissions to allow this. It was arcane/insane what needed to be done.

During my recent fedora upgrade [done via "fedup"], after reboot into the "install mode", selinux was there, but it was run in "permissive" mode. It was complaining at various points, but still allowed the action. To me, this is a scathing indictment if something like fedup feels the need to tell selinux to [effectively] STFU.

Honestly, I've never [personally] seen a single targeted mode selinux denial that wasn't a false positive [and couldn't be covered just as well with standard POSIX permissions or ACLs].

How about you?

Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.

For a while, I've been considering paring down and packaging up my scripting environment for this and publishing it on github. The sshd patch and setup/modification of the config files [including changing the selinux attributes :-(] is all done by a perl script (as is the logger).

The only wrinkle is that all users have to have set things up to use pubkey via ssh-keygen. For example, the public keys for my laptop and smartphone are entered into my .ssh/authorized_keys file on my desktop [and vice-versa]. Easy for me, since I'm the only user. Harder, if you've got an installed user base that may not have done this.

My desktop system uses two dictionary words for the password to my personal account and root account. I've grepped the log, and the kiddies never even came close. However, because I am using these words, that's why I added pubkey only for ssh access--just to be safe.

I had to firewall ssh because I just went from fedora 20 to 21 and would have been running an unpatched sshd. I just completed a reposync, so now I have the correct openssh sources and can rebuild/reactivate

Interestingly, although the kiddie attacks can come from anywhere in the world, they are predominantly from China. The whois info for non-Chinese IP's is somewhat spotty, but the ones in China have full/accurate information. Seems like the Chinese government wants to track everything back to a name.

I was considering adding automatic whois lookup, with abuse@blah.com scraping, and then send the applicable part of the logs automatically [with a copy to the FBI :-) :-) :-)]

Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop]. More on this logger and my security config below.

Apparently, the keyboard interactive problem has been known [by Redhat] since at least July 2013, see https://access.redhat.com/solu... and it sets ChallengeResponseAuthentication to "no" to specifically disable keyboard interactive.

I added a line to /etc/pam.d/xsshd with pam_exec.so so I could invoke a custom logger I wrote. I also have CRA set to "no" [I can't remember where I found this originally]. The logger also adds a random delay, to slow down the script kiddies. Although not required, I've patched sshd to post the real bad password to the logger. The default action is to use a standard junk one if the username is invalid [to prevent timing attacks]. Since I add a random delay, the pw obliteration isn't required.

I've also use /etc/security/access.conf [used by PAM] to allow password logins from the local console or virtual terminal, X11, and local LAN. All else is denied.

Thus, ssh can only use pubkey authentication, so even if a valid login/pw combo is presented, it will fail.

From what I've seen in the logs, it isn't just common/simple passwords that get tried. It becomes obvious that some systems have been hacked, the /etc/passwd and /etc/shadow files have been taken, and the passwords cracked offline [e.g. via rainbow tables, etc.]. They are now being replayed from a database of known/valid combos. I've seen certain user/pw combos from years ago that show up again recently. Not just a single combo, but an entire sequence of them in the same exact order.

This actually provides a signature of the attacker that can be tracked. It appears there is some black market for these databases as they're too specific to be just "let's come up with a list of most probable common passwords". They're hoping that person A (using password B) created a login on system C and the person reused the login/pw on other systems (e.g. D)

The [Chinese] script kiddies are getting dumber [or smarter]. My logger used to do random delay of up to 40 seconds. This slowed them down and because they can only attack so many systems in parallel, this helped the victim community at large. It also prevented them from trying thousands of passwords/second on my system [which they did by having hundreds of separate ssh sessions].

Eventually, the "replay" list gets exhausted and the attacker moves on [possibly showing up years later, sometimes from a different IP address]. But, lately, if the delay is over a certain amount, the request gets timed out by the attacker and they will repeat the same login/pw in an infinite loop. This prevents them from progressing through their list, but it also means they will never stop hammering my system [because the list never gets exhausted]. So, now, I've set the delay to a smaller value, that still delays, but doesn't trigger the infinite loop.