The problem seems to be that uTP, which uses UDP instead of TCP, was created because when torrents used TCP, they had the same priority as TCP packets for things like web browsing. Going back to TCP would seem to ameliorate at least one form of attack mentioned. Why reinvent the wheel by enhancing uTP to the point where its virtually indistinguishable from TCP when the priority problem can be solved another way?
How about an "internal" QoS parameter, set as a socket option call, that sets a QoS within a given system/node for the given socket, but is not the classic QoS packet parameter? That is, a web browser sets a lower QoS for its download manager so that a lengthy download doesn't slow down new http/html traffic. The OS's network stack layer uses this to prioritize requests, but this is purely internal (e.g. no packet gets a QoS value). In other words, it's not a protocol extension, just an OS network stack enhancement.
I've had cases where I'm downloading a lot of stuff (either in the browser's download manager or something external like fedora's yum reposync) and foreground web browsing slows to a crawl.
This is more akin to lowering a process scheduling priority below "normal". I use this if I'm running a heavy compute job in the background, but I still want my web browser, email, editor, etc. to have reasonable responsiveness.
The most efficient way to implement this would be through a socket option, which would require a kernel change.
Linux has a cgroup for something similar (/sys/fs/cgroup/net_prio) but creating a subdir under this and attaching a process to it usually requires root access. It's baroque. I tried to use the cgroup fs to implement a limit on a process resident set size because the syscall for RLIMIT_RSS isn't connected to anything. I got it to work, but the mechanism was far more complex than the equivalent for lowering process priority via setpriority. Hence, the "clean" solution for socket/connection priority would be a socket option.
Applications could do this with minimal system support by getting stats on all connections (e.g. via netstat, etc.), calculating what their load is, and throttling themselves if they see they're using more than X percentage of the current total usage. Torrent clients already have this (e.g. one can set a parameter that limits the upstream bitrate used by a given torrent). But, there is no global limit or mechanism that says "How much bandwidth am I hogging?" and do a backoff.
Thanks for mentioning this. [My mea culpa]: I was unaware of the mandated reductions to farmers [which I'm in favor of, obviously]. I read a lot about a wide variety of topics and I missed this one, partly, because most of the followup buzz [news stories] surrounding this has been about how such-and-such movie star waters their lawn too much. After a while, my eyes started glazing over. Headlines like "Movie Star is Water Pig" are more likely to show up [because they're more sensational] than "California's Comprehensive Water Reduction Regulations Explained" [I would prefer the latter].
Because I've lived in CA for 30+ years, I'm keenly aware of the water supply issues. I had been aware of the almond/walnut thing long before Jerry Brown started the regulations, and when things starting looking bad, I cut my consumption of almonds [now down to zero--and I love almonds]. By my estimate, by eliminating almonds, I'm saving 50+ gallons per day. This is good, because I live in an apartment, and don't have a lawn that I can stop watering to conserve.
As the actor Ricardo Montalban once said in an interview: "If you're [currently] not acting [in some play/movie], you're not an actor".
So, if a farmer isn't growing crops, he's not a farmer. So, he'd probably lose whatever special pricing on water he has [as well as any raising of the limit on how much water he gets], so he wouldn't be able to make a profit because he'd be buying the water at the same price he could sell it for. And, such profiteering would probably be prohibited.
From the wiki, California grows some 350 different crops. Planting more of the more efficient ones [with regulations to back that up] is no more onerous than imposing regulations on residential usage. These crops will still turn a profit, perhaps not as much as almonds/walnuts. Cutting down on [say] the top 50 water waster crops will not bankrupt farmers, but might cut agricultural water usage in [say] half.
There are times when the practical necessity of a crisis [and the market regulation that goes with it] needs to trump the free market economy [for which the purist (non-Keynesian) economic models don't account for].
We all need to sacrifice a bit. That includes everybody.
From this [see "uses of water" section]: - Agriculture uses 39% of the water vs. 11% for residential use - A typical household uses 170 gallons/day - It takes 4.9 gallons to grow one walnut, almost as much as a head of broccoli at 5.4 [but with much less food value] - It takes 1.1 gallons to make an almond, so a small jar of them uses more water than a household does per day.
Most of the regulations [and hoopla] so far are about getting residents to use less water, but their usage is a drop in the proverbial ocean. Where are the regulations to get farms to plant water efficient crops that have high food value instead of water thirsty crops that, effectively, waste water?
Producing crops that have good nutrition, use less water, and provide lower prices to consumers would seem to be the responsible thing to do during a prolonged drought. If farmers can't see the logic of this, then, if regulation comes, they would only have themselves to blame.
Seems to me that datacaps facilitate the surveillance.
The published/public reasons for datacaps are to "reduce network congestion" and that various telcos would like to charge [gouge] their customers more money.
Many articles have debunked the "network congestion" argument. But, telcos would like to charge higher prices so they continue to float the myth ad naseum. It's also a great cover.
Maybe the only "congestion" is that while it would be relatively easy/inexpensive to build out networks to handle it [routers, etc.], it would be prohibitively more expensive to add the requisite amount of surveillance equipment to handle the load [if they could]. Otherwise, the "secret room" inside a telco's CO would have to become the "secret floor" and eventually the "secret building".
Charging customers higher prices for congestion is a misnomer. But, instead of using this capital [or any capital for that matter] to build out networks to accommodate legitimate internet traffic increases, like any reasonably/responsibly managed company, diverting it to a telco's "black budget" would be harder to justify [even internally] to an auditor.
In a recent story, a university installed ad blocking at their edge router. They saw their total Internet usage drop by 30%. Since, they were probably also doing non-web traffic (e.g. software updates, dropbox, etc.), this means that the actual percentage of website content that is ads is probably higher.
Are companies who inject ads going to compensate the recipient for the bandwidth usage? Will such usage push the subscriber over their datacap?
I installed ad blocking early, because, back then, the flash video ad was more likely to hang the flash player.
And, I used to have a datacap [Note: I'm in California, and I switched to sonic.net, one of the few ISPs that have no datacap], but now the load time with the ads would still be too great.
And, I'm not against ads in general, but, the privilege [of sending me an ad] has been abused. Obnoxiousness, malware vector, delaying page load until the ad is dynamically selected in a back haul bidding network. The list just keeps going.
At lunch, a man complains to his co-workers that all he ever gets in his lunch box are PB&J sandwiches. They say: "Why don't you get your wife to make you a ham sandwich?". He replies: "No, I couldn't do that. I pack my lunch myself".
Good suggestions. In addition to Ablock Plus, I've got Ghostery instead of Privacy Badger [which is new]. Any thoughts regarding the last two?
Most web designers assume javascript is available, so disabling it completely probably will cripple most [even legit] websites. For example, my HMO's website uses javascript to do the patient login. Disabling it would make the site unusable.
Maybe what's needed is something similar to ABP for scripts (e.g. a tunable NoScript with blocklist subscription). Something more fine grained that site whitelisting. Just block the nasty [parts of] scripting. But, this is much trickier to do and not break things. A website dynamically obfuscating the JS would probably be able to get around any smart filter.
Thanks for the cite. Trying to get the full text of the law can be exhausting. I found PLAW-105publ304.pdf but the indents make it hard to find things. Cornell law publishes an html variant that is a bit easier to find things in.
Most action is about proving infringement. But, in the sentence it also talks about ownership [and being an authorized agent for the owner]. In certain cases, people have tried to claim ownership of something they didn't actually own (e.g. tried to [re]copyright something that was in the public domain). So, in that case, infringement or not, the question is did the filer actually own the work at all. Since the affirmation is about "owner" rather than "alleged owner", misrepresentation of ownership seems [to me] to be clear cut.
There are other parts of that apply: DMCA 17 U.S.C. 512(c)(3)(A)(v)
Sorry to hear about your difficulties. Although, I didn't mention it in my original post, I'm not surprised to hear about such a scenario playing out that way, as I'm sure it's been done countless times to other people in similar circumstances.
Although the DMCA provides for some degree of dispute resolution, ultimately, it often boils down to having the money to spend on the legal process. Thus, even if you're in the right, you're forced to go to court. No doubt one of the "maneuvers" was getting the venue to be CA (vs. GA where you live and might have had a reasonable chance of showing up for your day in court).
As an intermediate step, I might have kept the legal papers, asked for a one hour consult with an attorney of your choice [or a legal aid rep, which is usually free]. Then, the attorney can usually tell you whether you have standing, what your realistic chances of success would be, how much process might cost, and you can both decide if it's worth it for you to pursue it in court or get the case dropped.
Note that when you get a legal consult, some less ethical lawyers will try to steer you to going through the full process, because, win or lose, they will make more money. But, ethical ones [they do exist] will be happy to give you their best advice for the one hour they will charge you for and not recommend that you go to court unless they're reasonably sure you have a winnable case.
Of course, finding an ethical attorney [and one that you trust] can be problematic. That's why legal aid might be the easiest/best first step. They usually have some good attorneys and usually don't have a [profit] axe to grind.
IANAL, so all of the above is just my layman's opinion, but I hope you find it useful in the future when youtube unlocks your account and you can create some unique videos and try to monetize them.
IIRC, if someone files a takedown notice under the DMCA for a given work at a given website, the author of the work can file a counter notice under the DMCA with the website. Unless the original filer is willing to sue, the work can be restored. The DMCA does provide penalties for filing baseless/frivolous DMCA notices. And, the author can sue the filer.
The reason for the "hair trigger" effect is that if a DMCA notice is filed with a website, the website must remove the work quickly, or risk losing its "safe harbor" protections. To restore the work, the takedown must be withdrawn or the counter filed with the website.
In this case, if the Sandler film is too similar to the 2010 short film, it could be considered a derived work. That is, violates the copyright of the 2010 work. That would mean boatloads of cash for Patrick Jean.
Thanks for posting the link. It's so good, IMO, that I had it in my bookmarks. It points out that the entropy is fed to the CSPRNG.
Disclaimer: I'm not a crypto guy, but I do read a fair amount about it.
One CSPRNG algorithm is to use a CBC cipher in "counting mode". That is, run 1, 2, 3,... through the CBC and use the output of that. You start with a random key. But, the security of the CSPRNG is based on breaking the CBC (e.g. finding the key) from the output of the CSPRNG/CBC that is the "random" that/dev/random gets. Later, as some true entropy bits arrive, the key is periodically refreshed/modified.
Thus, the CSPRNG can "free run" for quite a while before needing the key to be refreshed (e.g for an N bit CBC, it's 2**(N/2)). So, it provides plenty of random bits. And, because the key is changed randomly, based on the entropy bits, it's changed long before someone watching the output of the CSPRNG has enough data to get the key used.
There are a number of different entropy sources. Timer interrupts, disk interrupts, network card interrupts, rdrand instruction, etc. Even for something that seems highly predictable/periodic such as a timer interrupt at 1000 Hz, it still adds some entropy because if you take an [x86] TSC upon entry to the timer ISR [the TSC has a resolution of better than 1ns], you'll still get some variation in the deltas for this, because you won't always enter the ISR in exactly the same amount of time.
So, if you take TSCs at entry/exit of ISRs for timer, disks, network, etc. (or TSCs in other parts of the kernel) even for fixed/predictable data rates for these devices, the actual TSC deltas will vary a bit, enough to provide some entropy. This doesn't even include gleaning entropy from TSC deltas between these various sources.
So, IMO, Potter et. al. is assuming a fairly naive way to get entropy bits and is underestimating the number of reliable entropy bits you can use if you really look at how Linux derives them.
And, some of the entropy can be used to decide how and how often the CBC key is modified.
Thus, just looking at the absolute raw entropy sources and saying they don't provide enough entropy (vs. a pure hardware white noise source) isn't really true in practice.
I've been a kernel developer for 40 years [and when you can top that, you can mouth off]. And, I have plenty of experience with diagnosis, bug fixes, patches, multiple supported revs in the field, and automated build and testing. And, have created tools to do all that.
When Linus gave his original talk on git, he said it was all about merging. git has powerful branching [everything is a branch], but what really sets it apart is its merging.
Recommended best practice is to enable automatic rebasing on a pull. That really increases the chances that it will apply cleanly.
The actual updater may git, or git + something google has cooked up to ensure the patch will work (e.g. repo or "android security updater").
Let's say there are 100 different versions in the field. If you patch one, it may apply to all. Fine and good. Or, you might have to manually apply it, starting with some cherrypicking, to a subset (e.g. 2.0.0 tree, 3.0.0, etc.). After that, it will apply cleanly to derivatives of the "top" rev. That's because the point revs [probably] don't change the file in the exact area that the patch needs to change.
This is exactly what core kernel developers do. If the patch applies, they test it [which can be automated].
Google makes the generic changes to the kernel to suit Android needs. The vendors usually just add their platform specific device drivers. So, after Google patches all revs, there's a good chance that when they push, the changes will apply cleanly.
BTW, RHEL doesn't just package things. They do active primary kernel development. So, no RHEL developer need fear for his/her job.
git is even powerful enough to create a temporary branch just to merge in the patch. If applying the patch doesn't work because the existing changes cause conflicts, you can find the common starting point and apply the new patch before the others that already exist [out of chronological order] and then replay the existing patches from the history. That is, you're doing "Back To The Future" style change. The tail of the temp branch is added as the new tail to the original branch.
The better analogy. The FTC/FCC have the authority to fine a company up to $11,000 per device in the field. Given 100 million phones, that's a trillion dollars.
Google also announced changes to the way the company distributes Nexus security updates. Starting Wednesday, Nexus devices will receive regular monthly security updates.
There is already a mechanism to push full Android updates. That's been the problem. It's all or nothing [if the vendor doesn't want to re-QA the entire update] (e.g. going from 4.0.0 to 5.0.0).
It may involve sending a full load [if that makes sense]. But, with just the necessary patches. It will be done monthly and not just when a new version [with new features] is stable and available. Since Android already does a.b.c versioning for features/fixes, we may see a.b.c.d versions for the monthly updates.
Just like Windows update, if there's a security flaw in [say] IE, a patch to IE is sent. If the IE fix involves fixes to five underlying DLLs, they will be part of the update. But, all of WinX doesn't get updated. Current Android updates are like going from Win7 to Win8. The new update process will be more like Windows update for a given version.
This new mechanism should have [and could have] been done years ago. There wasn't as much incentive.
The MMS security flaw is so dangerous that it forced this. It is so bad that the FTC [and/or FCC] might fine Google, vendors, and carriers. Under its authority, the FTC can issue fines of up to $11,000 per device in the field. With 100 million [or more] phones in the field, this total fine can be one trillion dollars.
Recently, IIRC, either Chrysler/Fiat [for failing to implement a recall], or AT&T [for misrepresenting "unlimited" plans] got a $100M fine. The agency said [effectively] "large enough to be painful, but not enough to do serious harm to [bankrupt] the company.".
This is a new update mechanism for security updates [and bug fixes, hopefully] for the device firmware (e.g. kernel) that makes it less painful for phone vendors and carriers to implement.
A few things to note [most of this is conjecture on my part, as software engineer, until the details emerge]:
- Android source code (e.g. kernel, dalvik, etc.) is maintained via git (with a Google wrapper program called "repo"). I regularly update a source tree via this.
- git has extremely powerful branching and merging capabilities. Thus, it's very easy to create a fix in one version and get git to apply the resulting patch/delta to other branches of the tree. That is git's forte. For example, do the security fix in the latest under development branch and then propagate it to all older branches [can be automated easily].
- Because you're just changing a small portion [we hope that the bug fix is only a hundred lines of code or so], the patch can easily be applied.
- Because the change is relatively small (e.g. 4.4.2 to 4.4.2.1) vs. going from 4.4.x to 5.0.0, it's far less QA testing as the old rev has been extensively QA'ed as a whole.
- This will encourage vendors/carriers to adopt this, even for old phones, because it's just a bug fix and not feature creep that might require more powerful hardware.
- This mechanism won't cut into margins because it is [will be] an automated way to apply just security updates (e.g. [gasp] Windows update). This could still have been done in the past, but it wasn't as easy [as Google seems to want to make it].
- Vendors/carriers will still be able to "up sell" to the latest and greatest for new features. So, no conflict/disincentive.
- Vendors/carriers will be encouraged because it's now easy to do, everybody will be doing it, and [a serious] black eye for any vendor/carrier that doesn't [far more so than in the past].
- And the legal liability for Google, vendors, and carriers for the MMS vulnerability is so severe, that any company that does not implement this could be sued into oblivion. For example, in the PC world, would any motherboard vendor decide they would prohibit critical security bug fixes via Windows update?
When I first saw this bug, I changed my Galaxy S3 [running 4.4.2] to disallow MMS from unknown senders. Start the [default] Messaging app, click the left soft key, select "Settings", scroll to bottom and click the check box for "Block unknown senders". I don't know if this actually will provide a true workaround, but it's the only thing I could find.
Reportedly, Google Hangouts has a similar option. In short, whatever app you're using for messaging might/should have this option.
Because English is your 4th language, I'd be more circumspect about interpreting it. Your whole "must be a long time since..." is condescending. I only added "must be a long time since..." because you did. I would still have given the explanation about the grammar, but it might have seemed to be instructive and beneficial.
And the history is quite murky.
Chechnya declared independence in 1917. Was invaded by Russia in 1921 and reabsorbed. After the collapse of the Soviet Union, Chechnya declared independence in 1991. Russia killed the Chechen president in 1996. Yeltzin withdrew Russian troops in 1996. So, it wasn't 150 years. At best, 94 years (from 1921).
But, the modern interpretation is from 1991/1996 going forward where Chechnya is an independent state. Except... for those Russian assassinations of Chechen presidents, invasions, border skirmishes...
The cycle seems to go like this: Chechnya wants independence and Russia invades. So, are you condoning/supporting Russia's invasion by force policies?
The mention of Russia in my original post was more of a direct dig at Russia, Putin's failed policies, and his attempts to divert attention from that with the militarism.
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..."
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]:
- In 1922, "The Cable Company" published the "The Everyday Songbook". It had "Good Morning and Birthday Song" [aka "Happy Birthday"] in it, with "Special permission through courtesy of Clayton F Summy Co." under the title. Note that the song above it on the page had a copyright notice.
- Modern copyright law is different than it was in 1922, which was governed by the Copyright Act of 1909. Under this act, a work must have an explicit "Copyright", "(C)", or "Copr." in it.
- Under the 1909 act, if a compilation of various works is published, and a work does not have an explicit copyright, the original author loses their copyright to that work.
- The "special permission" probably means that the work was already in the public domain.
- Even if the "special permission" notice could be construed as a copyright, it would have to be renewed in 25 years [the copyright term in those days]. Thus, copyright would have to be renewed no later than 1949, either by Summy or Cable. Neither of them did so.
- Even if Summy and/or Cable had renewed in 1949, the work would still have become public domain in 1997.
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:
If your antimalware subscription is not current (expired), Windows will uninstall your application and enable Windows Defender.
Some applications that came from your OEM may be removed prior to upgrade.
For certain third party applications, the Get Windows 10 app will scan for application compatibility. If there is a known issue that will prevent the upgrade, you will be notified of the list of applications with known issues. You can choose to accept and the applications will be removed from the system prior to upgrade. Please be sure to copy the list before you accept the removal of the application.
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].
Slashdot Mirror
The problem seems to be that uTP, which uses UDP instead of TCP, was created because when torrents used TCP, they had the same priority as TCP packets for things like web browsing. Going back to TCP would seem to ameliorate at least one form of attack mentioned. Why reinvent the wheel by enhancing uTP to the point where its virtually indistinguishable from TCP when the priority problem can be solved another way?
How about an "internal" QoS parameter, set as a socket option call, that sets a QoS within a given system/node for the given socket, but is not the classic QoS packet parameter? That is, a web browser sets a lower QoS for its download manager so that a lengthy download doesn't slow down new http/html traffic. The OS's network stack layer uses this to prioritize requests, but this is purely internal (e.g. no packet gets a QoS value). In other words, it's not a protocol extension, just an OS network stack enhancement.
I've had cases where I'm downloading a lot of stuff (either in the browser's download manager or something external like fedora's yum reposync) and foreground web browsing slows to a crawl.
This is more akin to lowering a process scheduling priority below "normal". I use this if I'm running a heavy compute job in the background, but I still want my web browser, email, editor, etc. to have reasonable responsiveness.
The most efficient way to implement this would be through a socket option, which would require a kernel change.
Linux has a cgroup for something similar (/sys/fs/cgroup/net_prio) but creating a subdir under this and attaching a process to it usually requires root access. It's baroque. I tried to use the cgroup fs to implement a limit on a process resident set size because the syscall for RLIMIT_RSS isn't connected to anything. I got it to work, but the mechanism was far more complex than the equivalent for lowering process priority via setpriority. Hence, the "clean" solution for socket/connection priority would be a socket option.
Applications could do this with minimal system support by getting stats on all connections (e.g. via netstat, etc.), calculating what their load is, and throttling themselves if they see they're using more than X percentage of the current total usage. Torrent clients already have this (e.g. one can set a parameter that limits the upstream bitrate used by a given torrent). But, there is no global limit or mechanism that says "How much bandwidth am I hogging?" and do a backoff.
Thanks for mentioning this. [My mea culpa]: I was unaware of the mandated reductions to farmers [which I'm in favor of, obviously]. I read a lot about a wide variety of topics and I missed this one, partly, because most of the followup buzz [news stories] surrounding this has been about how such-and-such movie star waters their lawn too much. After a while, my eyes started glazing over. Headlines like "Movie Star is Water Pig" are more likely to show up [because they're more sensational] than "California's Comprehensive Water Reduction Regulations Explained" [I would prefer the latter].
Because I've lived in CA for 30+ years, I'm keenly aware of the water supply issues. I had been aware of the almond/walnut thing long before Jerry Brown started the regulations, and when things starting looking bad, I cut my consumption of almonds [now down to zero--and I love almonds]. By my estimate, by eliminating almonds, I'm saving 50+ gallons per day. This is good, because I live in an apartment, and don't have a lawn that I can stop watering to conserve.
As the actor Ricardo Montalban once said in an interview: "If you're [currently] not acting [in some play/movie], you're not an actor".
So, if a farmer isn't growing crops, he's not a farmer. So, he'd probably lose whatever special pricing on water he has [as well as any raising of the limit on how much water he gets], so he wouldn't be able to make a profit because he'd be buying the water at the same price he could sell it for. And, such profiteering would probably be prohibited.
From the wiki, California grows some 350 different crops. Planting more of the more efficient ones [with regulations to back that up] is no more onerous than imposing regulations on residential usage. These crops will still turn a profit, perhaps not as much as almonds/walnuts. Cutting down on [say] the top 50 water waster crops will not bankrupt farmers, but might cut agricultural water usage in [say] half.
There are times when the practical necessity of a crisis [and the market regulation that goes with it] needs to trump the free market economy [for which the purist (non-Keynesian) economic models don't account for].
We all need to sacrifice a bit. That includes everybody.
See https://en.wikipedia.org/wiki/...
From this [see "uses of water" section]:
- Agriculture uses 39% of the water vs. 11% for residential use
- A typical household uses 170 gallons/day
- It takes 4.9 gallons to grow one walnut, almost as much as a head of broccoli at 5.4 [but with much less food value]
- It takes 1.1 gallons to make an almond, so a small jar of them uses more water than a household does per day.
Most of the regulations [and hoopla] so far are about getting residents to use less water, but their usage is a drop in the proverbial ocean. Where are the regulations to get farms to plant water efficient crops that have high food value instead of water thirsty crops that, effectively, waste water?
Producing crops that have good nutrition, use less water, and provide lower prices to consumers would seem to be the responsible thing to do during a prolonged drought. If farmers can't see the logic of this, then, if regulation comes, they would only have themselves to blame.
Seems to me that datacaps facilitate the surveillance.
The published/public reasons for datacaps are to "reduce network congestion" and that various telcos would like to charge [gouge] their customers more money.
Many articles have debunked the "network congestion" argument. But, telcos would like to charge higher prices so they continue to float the myth ad naseum. It's also a great cover.
Maybe the only "congestion" is that while it would be relatively easy/inexpensive to build out networks to handle it [routers, etc.], it would be prohibitively more expensive to add the requisite amount of surveillance equipment to handle the load [if they could]. Otherwise, the "secret room" inside a telco's CO would have to become the "secret floor" and eventually the "secret building".
Charging customers higher prices for congestion is a misnomer. But, instead of using this capital [or any capital for that matter] to build out networks to accommodate legitimate internet traffic increases, like any reasonably/responsibly managed company, diverting it to a telco's "black budget" would be harder to justify [even internally] to an auditor.
In a recent story, a university installed ad blocking at their edge router. They saw their total Internet usage drop by 30%. Since, they were probably also doing non-web traffic (e.g. software updates, dropbox, etc.), this means that the actual percentage of website content that is ads is probably higher.
Are companies who inject ads going to compensate the recipient for the bandwidth usage? Will such usage push the subscriber over their datacap?
I installed ad blocking early, because, back then, the flash video ad was more likely to hang the flash player.
And, I used to have a datacap [Note: I'm in California, and I switched to sonic.net, one of the few ISPs that have no datacap], but now the load time with the ads would still be too great.
And, I'm not against ads in general, but, the privilege [of sending me an ad] has been abused. Obnoxiousness, malware vector, delaying page load until the ad is dynamically selected in a back haul bidding network. The list just keeps going.
At lunch, a man complains to his co-workers that all he ever gets in his lunch box are PB&J sandwiches. They say: "Why don't you get your wife to make you a ham sandwich?". He replies: "No, I couldn't do that. I pack my lunch myself".
Good suggestions. In addition to Ablock Plus, I've got Ghostery instead of Privacy Badger [which is new]. Any thoughts regarding the last two?
Most web designers assume javascript is available, so disabling it completely probably will cripple most [even legit] websites. For example, my HMO's website uses javascript to do the patient login. Disabling it would make the site unusable.
Maybe what's needed is something similar to ABP for scripts (e.g. a tunable NoScript with blocklist subscription). Something more fine grained that site whitelisting. Just block the nasty [parts of] scripting. But, this is much trickier to do and not break things. A website dynamically obfuscating the JS would probably be able to get around any smart filter.
Thanks for the cite. Trying to get the full text of the law can be exhausting. I found PLAW-105publ304.pdf but the indents make it hard to find things. Cornell law publishes an html variant that is a bit easier to find things in.
Most action is about proving infringement. But, in the sentence it also talks about ownership [and being an authorized agent for the owner]. In certain cases, people have tried to claim ownership of something they didn't actually own (e.g. tried to [re]copyright something that was in the public domain). So, in that case, infringement or not, the question is did the filer actually own the work at all. Since the affirmation is about "owner" rather than "alleged owner", misrepresentation of ownership seems [to me] to be clear cut.
There are other parts of that apply: DMCA 17 U.S.C. 512(c)(3)(A)(v)
Also, consider "Lenz v. Universal Music Corp" https://en.wikipedia.org/wiki/....
This is currently under appeal at the 9th circuit appeals court, but the 2008 ruling was that filers must consider "fair use" before filing.
Sorry to hear about your difficulties. Although, I didn't mention it in my original post, I'm not surprised to hear about such a scenario playing out that way, as I'm sure it's been done countless times to other people in similar circumstances.
Although the DMCA provides for some degree of dispute resolution, ultimately, it often boils down to having the money to spend on the legal process. Thus, even if you're in the right, you're forced to go to court. No doubt one of the "maneuvers" was getting the venue to be CA (vs. GA where you live and might have had a reasonable chance of showing up for your day in court).
As an intermediate step, I might have kept the legal papers, asked for a one hour consult with an attorney of your choice [or a legal aid rep, which is usually free]. Then, the attorney can usually tell you whether you have standing, what your realistic chances of success would be, how much process might cost, and you can both decide if it's worth it for you to pursue it in court or get the case dropped.
Note that when you get a legal consult, some less ethical lawyers will try to steer you to going through the full process, because, win or lose, they will make more money. But, ethical ones [they do exist] will be happy to give you their best advice for the one hour they will charge you for and not recommend that you go to court unless they're reasonably sure you have a winnable case.
Of course, finding an ethical attorney [and one that you trust] can be problematic. That's why legal aid might be the easiest/best first step. They usually have some good attorneys and usually don't have a [profit] axe to grind.
IANAL, so all of the above is just my layman's opinion, but I hope you find it useful in the future when youtube unlocks your account and you can create some unique videos and try to monetize them.
IIRC, if someone files a takedown notice under the DMCA for a given work at a given website, the author of the work can file a counter notice under the DMCA with the website. Unless the original filer is willing to sue, the work can be restored. The DMCA does provide penalties for filing baseless/frivolous DMCA notices. And, the author can sue the filer.
The reason for the "hair trigger" effect is that if a DMCA notice is filed with a website, the website must remove the work quickly, or risk losing its "safe harbor" protections. To restore the work, the takedown must be withdrawn or the counter filed with the website.
In this case, if the Sandler film is too similar to the 2010 short film, it could be considered a derived work. That is, violates the copyright of the 2010 work. That would mean boatloads of cash for Patrick Jean.
That all said, DMCA abuse is obviously rampant.
Thanks for posting the link. It's so good, IMO, that I had it in my bookmarks. It points out that the entropy is fed to the CSPRNG.
Disclaimer: I'm not a crypto guy, but I do read a fair amount about it.
One CSPRNG algorithm is to use a CBC cipher in "counting mode". That is, run 1, 2, 3, ... through the CBC and use the output of that. You start with a random key. But, the security of the CSPRNG is based on breaking the CBC (e.g. finding the key) from the output of the CSPRNG/CBC that is the "random" that /dev/random gets. Later, as some true entropy bits arrive, the key is periodically refreshed/modified.
Thus, the CSPRNG can "free run" for quite a while before needing the key to be refreshed (e.g for an N bit CBC, it's 2**(N/2)). So, it provides plenty of random bits. And, because the key is changed randomly, based on the entropy bits, it's changed long before someone watching the output of the CSPRNG has enough data to get the key used.
There are a number of different entropy sources. Timer interrupts, disk interrupts, network card interrupts, rdrand instruction, etc. Even for something that seems highly predictable/periodic such as a timer interrupt at 1000 Hz, it still adds some entropy because if you take an [x86] TSC upon entry to the timer ISR [the TSC has a resolution of better than 1ns], you'll still get some variation in the deltas for this, because you won't always enter the ISR in exactly the same amount of time.
So, if you take TSCs at entry/exit of ISRs for timer, disks, network, etc. (or TSCs in other parts of the kernel) even for fixed/predictable data rates for these devices, the actual TSC deltas will vary a bit, enough to provide some entropy. This doesn't even include gleaning entropy from TSC deltas between these various sources.
So, IMO, Potter et. al. is assuming a fairly naive way to get entropy bits and is underestimating the number of reliable entropy bits you can use if you really look at how Linux derives them.
And, some of the entropy can be used to decide how and how often the CBC key is modified.
Thus, just looking at the absolute raw entropy sources and saying they don't provide enough entropy (vs. a pure hardware white noise source) isn't really true in practice.
I've been a kernel developer for 40 years [and when you can top that, you can mouth off]. And, I have plenty of experience with diagnosis, bug fixes, patches, multiple supported revs in the field, and automated build and testing. And, have created tools to do all that.
When Linus gave his original talk on git, he said it was all about merging. git has powerful branching [everything is a branch], but what really sets it apart is its merging.
Recommended best practice is to enable automatic rebasing on a pull. That really increases the chances that it will apply cleanly.
The actual updater may git, or git + something google has cooked up to ensure the patch will work (e.g. repo or "android security updater").
Let's say there are 100 different versions in the field. If you patch one, it may apply to all. Fine and good. Or, you might have to manually apply it, starting with some cherrypicking, to a subset (e.g. 2.0.0 tree, 3.0.0, etc.). After that, it will apply cleanly to derivatives of the "top" rev. That's because the point revs [probably] don't change the file in the exact area that the patch needs to change.
This is exactly what core kernel developers do. If the patch applies, they test it [which can be automated].
Google makes the generic changes to the kernel to suit Android needs. The vendors usually just add their platform specific device drivers. So, after Google patches all revs, there's a good chance that when they push, the changes will apply cleanly.
BTW, RHEL doesn't just package things. They do active primary kernel development. So, no RHEL developer need fear for his/her job.
git is even powerful enough to create a temporary branch just to merge in the patch. If applying the patch doesn't work because the existing changes cause conflicts, you can find the common starting point and apply the new patch before the others that already exist [out of chronological order] and then replay the existing patches from the history. That is, you're doing "Back To The Future" style change. The tail of the temp branch is added as the new tail to the original branch.
The better analogy. The FTC/FCC have the authority to fine a company up to $11,000 per device in the field. Given 100 million phones, that's a trillion dollars.
From the first line of my post:
This is a new update mechanism for security updates [and bug fixes, hopefully]
Also, see http://arstechnica.com/securit...
Google also announced changes to the way the company distributes Nexus security updates. Starting Wednesday, Nexus devices will receive regular monthly security updates.
There is already a mechanism to push full Android updates. That's been the problem. It's all or nothing [if the vendor doesn't want to re-QA the entire update] (e.g. going from 4.0.0 to 5.0.0).
It may involve sending a full load [if that makes sense]. But, with just the necessary patches. It will be done monthly and not just when a new version [with new features] is stable and available. Since Android already does a.b.c versioning for features/fixes, we may see a.b.c.d versions for the monthly updates.
Just like Windows update, if there's a security flaw in [say] IE, a patch to IE is sent. If the IE fix involves fixes to five underlying DLLs, they will be part of the update. But, all of WinX doesn't get updated. Current Android updates are like going from Win7 to Win8. The new update process will be more like Windows update for a given version.
This new mechanism should have [and could have] been done years ago. There wasn't as much incentive.
The MMS security flaw is so dangerous that it forced this. It is so bad that the FTC [and/or FCC] might fine Google, vendors, and carriers. Under its authority, the FTC can issue fines of up to $11,000 per device in the field. With 100 million [or more] phones in the field, this total fine can be one trillion dollars.
Recently, IIRC, either Chrysler/Fiat [for failing to implement a recall], or AT&T [for misrepresenting "unlimited" plans] got a $100M fine. The agency said [effectively] "large enough to be painful, but not enough to do serious harm to [bankrupt] the company.".
This is a new update mechanism for security updates [and bug fixes, hopefully] for the device firmware (e.g. kernel) that makes it less painful for phone vendors and carriers to implement.
A few things to note [most of this is conjecture on my part, as software engineer, until the details emerge]:
- Android source code (e.g. kernel, dalvik, etc.) is maintained via git (with a Google wrapper program called "repo"). I regularly update a source tree via this.
- git has extremely powerful branching and merging capabilities. Thus, it's very easy to create a fix in one version and get git to apply the resulting patch/delta to other branches of the tree. That is git's forte. For example, do the security fix in the latest under development branch and then propagate it to all older branches [can be automated easily].
- Because you're just changing a small portion [we hope that the bug fix is only a hundred lines of code or so], the patch can easily be applied.
- Because the change is relatively small (e.g. 4.4.2 to 4.4.2.1) vs. going from 4.4.x to 5.0.0, it's far less QA testing as the old rev has been extensively QA'ed as a whole.
- This will encourage vendors/carriers to adopt this, even for old phones, because it's just a bug fix and not feature creep that might require more powerful hardware.
- This mechanism won't cut into margins because it is [will be] an automated way to apply just security updates (e.g. [gasp] Windows update). This could still have been done in the past, but it wasn't as easy [as Google seems to want to make it].
- Vendors/carriers will still be able to "up sell" to the latest and greatest for new features. So, no conflict/disincentive.
- Vendors/carriers will be encouraged because it's now easy to do, everybody will be doing it, and [a serious] black eye for any vendor/carrier that doesn't [far more so than in the past].
- And the legal liability for Google, vendors, and carriers for the MMS vulnerability is so severe, that any company that does not implement this could be sued into oblivion. For example, in the PC world, would any motherboard vendor decide they would prohibit critical security bug fixes via Windows update?
A possible workaround ...
When I first saw this bug, I changed my Galaxy S3 [running 4.4.2] to disallow MMS from unknown senders. Start the [default] Messaging app, click the left soft key, select "Settings", scroll to bottom and click the check box for "Block unknown senders". I don't know if this actually will provide a true workaround, but it's the only thing I could find.
Reportedly, Google Hangouts has a similar option. In short, whatever app you're using for messaging might/should have this option.
Because English is your 4th language, I'd be more circumspect about interpreting it. Your whole "must be a long time since ..." is condescending. I only added "must be a long time since ..." because you did. I would still have given the explanation about the grammar, but it might have seemed to be instructive and beneficial.
And the history is quite murky.
Chechnya declared independence in 1917. Was invaded by Russia in 1921 and reabsorbed. After the collapse of the Soviet Union, Chechnya declared independence in 1991. Russia killed the Chechen president in 1996. Yeltzin withdrew Russian troops in 1996. So, it wasn't 150 years. At best, 94 years (from 1921).
But, the modern interpretation is from 1991/1996 going forward where Chechnya is an independent state. Except ... for those Russian assassinations of Chechen presidents, invasions, border skirmishes ...
The cycle seems to go like this: Chechnya wants independence and Russia invades. So, are you condoning/supporting Russia's invasion by force policies?
The mention of Russia in my original post was more of a direct dig at Russia, Putin's failed policies, and his attempts to divert attention from that with the militarism.
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]:
- In 1922, "The Cable Company" published the "The Everyday Songbook". It had "Good Morning and Birthday Song" [aka "Happy Birthday"] in it, with "Special permission through courtesy of Clayton F Summy Co." under the title. Note that the song above it on the page had a copyright notice.
- Modern copyright law is different than it was in 1922, which was governed by the Copyright Act of 1909. Under this act, a work must have an explicit "Copyright", "(C)", or "Copr." in it.
- Under the 1909 act, if a compilation of various works is published, and a work does not have an explicit copyright, the original author loses their copyright to that work.
- The "special permission" probably means that the work was already in the public domain.
- Even if the "special permission" notice could be construed as a copyright, it would have to be renewed in 25 years [the copyright term in those days]. Thus, copyright would have to be renewed no later than 1949, either by Summy or Cable. Neither of them did so.
- Even if Summy and/or Cable had renewed in 1949, the work would still have become public domain in 1997.
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:
If your antimalware subscription is not current (expired), Windows will uninstall your application and enable Windows Defender.
Some applications that came from your OEM may be removed prior to upgrade.
For certain third party applications, the Get Windows 10 app will scan for application compatibility. If there is a known issue that will prevent the upgrade, you will be notified of the list of applications with known issues. You can choose to accept and the applications will be removed from the system prior to upgrade. Please be sure to copy the list before you accept the removal of the application.
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].