Unlike other active queue management (AQM) algorithms, CoDel is not interested in the sizes of the queues. Instead, it measures how long packets are buffered. Specifically, CoDel looks at the minimum time that packets spend in the queue. The maximum time relates to good queues which resolve quickly, but if the minimum is high, this means that all packets are delayed and a bad queue has built up. If the minimum is above a certain threshold—the authors propose 5 milliseconds—for some time, CoDel will drop (discard) packets. This is a signal to TCP to reduce its transmission rate. If the minimum delay experienced by buffered packets is 5ms or less, CoDel does nothing.
I've been programming for 40+ years and how I analyze code [and hence, my "eye track"] varies, depending upon what I'm looking for. If I need to know one thing, I'll tend to zero in quickly. If I'm going to make changes, I'll scan over everything [at least] once to try to glean the overall style so I'll know what I'm up against when/before I start to make the changes.
Not only that, but the article's last line is about "joining the experiment" if you're in the Bloomington, IN area [*].
Indiana? Indiana??? A fine state for many things [America's home for auto racing--the sport of kings:-)]...
But, how about choosing a place noted for its programming talent (e.g. Silicon Valley, Boston/128, Los Angeles, San Diego, Research Triangle Park, NC, NYC, etc.)?
[*] Also, is there some special camera setup required that only the author has? Couldn't this be done by downloading the eye track software and programming examples onto any computer [anywhere] that has a builtin webcam? With a questionnaire about one's programming background? That way, data on thousands of people could be correlated.
I'm sure you will be careful with this but I just want to post a friendly reminder.
Yes, one of the reasons that I haven't done it until now. My system has a dynamic IP and no DNS entry, so it's hardly a high profile target. Since 12/22/11 I have some 32,000 entries.
Depending on how you organize your script and how often the same person hits your network, there's a chance you'll end up flooding the abuse contact with email. Not only will they not appreciate that, but there is a chance of amplification and bogging down their abuse handling process.
I was considering a builtin delay. Delay until the volume reaches a certain number of attempts or enough time has elapsed that it indicates a one off attempt. One instance originated from Bangkhok and would do an attempt every 20 minutes. This went on for weeks.
Yes, you're correct. Clearly a balance between excessive volume and hyper-reaction vs. timeliness must be struck. That is, for example, if the "perp" is roaming [betweeen internet cafes] to avoid detection/capture, being able to nab the person "in the act" would require frequent live updates of the abuse info.
In addition to the abuse-mailbox field you mention, it would be nice to standardize on an abuse report format, too. That way we could be confident that abuse reports can be properly fed into a system without depending on a human reading them directly.
I was thinking a.csv: YYMMDD-HHMMSS.uuuuuu,IP,login,pw
This needn't actually go through email if we were to collectively come up with a dynamic system to handle such things. Either a spamhaus type organization or some decentralized database. Remember the recent [similar] attack against wordpress sites? Having dynamic abuse info passed around in realtime [via some "abuse report" protocol], would allow backbones to start dropping/blocking the traffic [near the source]. This could mitigate such an attack before it had a chance to get going.
It would need some "web of trust" aspects to validate the abuse reports [vs. someone sending false ones just to blackball the IP of someone they didn't like].
Actually, now that I think of it, IIRC, there are some sites that take such info already.
Also, while some attack combos have been scattershot (e.g. login: mary, pw: mary) or dictionary (root/a, root/aa,...), some are so obscure/unique (e.g. root/a3da50fb67a6ae5a06eca1364e2356a9) that the only explanation is that there has been a crack of a pw database somewhere and they are replaying everywhere.
I have a honeypot on my home server to collect phony/random/orchestrated login/breakin attempts. A log entry has time, IP, username, pw. Eventually, I'd like to do further automated scripting. Namely, take the IP address, do a whois on it, look for the abuse contact email at the ISP, and email them the relevant log entries, with a polite request to investigate.
If they're legit, they may want to take action against one of their users who is doing massive attempts at system breakins. That is, such attempted login/breakin activity is against the law in certain countries. It's also [probably] a violation of the ISP's TOS. I've read that many ISPs don't even know that their customers are doing such things and welcome being told because the customer activity can expose the ISP to a degree of legal liability [safe harbor notwithstanding].
Currently, in whois data, there is no [universally used] standard for the abuse mailbox. It can be:
abuse-mailbox:...
Remarks: Send abuse email to...
% Remarks...
# Send abuse reports to... So, standardization would be nice.
However, an interesting wrinkle. Although I get attempts from all over the world, most of the breakin attempts I get come from.cn hosts [just sayin...]. The whois data from these is _always_ 100% complete and well organized. I guess they're compelled to do this by the gov't there. If, as proposed, the information goes to a central repository in [presumably] another country, there would be no way to compel an ISP to provide accurate/complete information cross-border.
So, how does this shape up under the new proposal? Which country's laws would govern this? Per-country top level domains like.cn and.uk present fewer problems. But, what about the more generic.com,.org, etc.?
No court is ever going to say that someone is required to perform some service (like release a new version of MySQL under GPL), when there is no benefit to them to doing so.
If they were under contract to do so, they would.
Sorry, but one cannot bind themselves to slavery (which is basically what you are asking for) just by issuing a statement or 'promise'.
Try doing a bit of [legal] reading/research:
Promissory estoppel is a contract law doctrine. It occurs when a party reasonably relies on the promise of another party, and because of the reliance is injured or damaged.
In the law of contracts, the doctrine that provides that if a party changes his or her position substantially either by acting or forbearing from acting in reliance upon a gratuitous promise, then that party can enforce the promise although the essential elements of a contract are not present.
You might want to read more arstechnica, which frequently gets cited on slashdot. They've done numerous articles (vs. blogs) on all aspects of this. They're a Conde Nast publication [as is Wired, IIRC] and are usually pretty credible. I tend to follow (and bookmark) articles on this. The two I posted were taken [quickly] from about 100 I've amassed and they all pretty much say the same thing.
[*] If you dispute the data/conclusions, take it up with the authors.
There are other articles, from various publications, that talk about the disincentive for telcos to provide higher speeds.
If you want to know how easy it is to roll out fiber, check out sonic.net. They're a regional telco and ISP based in Santa Rosa, CA. They provide ADSL2+ throughout California at 3x the speed of AT&T's elite service at half the price ($40/month) with no data caps.
They're also rolling out fiber to the home as fast as they can and will provide their subscribers with that higher speed, at the same price, and, again, no data caps.
I don't think the existence of MariaDB lets Oracle off the hook for a couple of reasons:
MariaDB doesn't change the fact that Oracle is reneging on its [implied] promises.
The harm is real. If a developer/company continues development on mysql (e.g. spends real money) continuing with mysql, based upon the assurances, vs. pulling the plug on all such devel activity immediately [when Oracle first acquired Sun].
In absence of the Oracle roadmap, the other company's choice might have been to spend that [wasted] capital on doing a Postgres port right away. Not only money wasted, but time as well, and business decisions about what markets to stay in/get out of. All of these could affect a company's competitiveness, market share, and profitability. Hence the harm.
If Oracle had said at time of acquisition that mysql was being closed [made no public promises to the contrary], there would be nothing to litigate about. Others are correct about being able to change licensing in general.
But, if Oracle had said that then [people were plenty steamed up], there would have been an immediate code fork [ala LibreOffice] or mass migration to Postgres [IIRC, MariaDB didn't exist then]. So, if Oracle had this latest action in mind all along [after the brouhaha dies down], then they seem truly duplicitous [and vulnerable in a court of law].
However, when Oracle took over Sun, it made public statements to the effect that the open version would remain that. If users/consumers took actions [to stay with mysql vs. bolting to Postgres], based on these statements, they may have suffered [actionable] harm.
Reading further down the [wiki] page, under the "reliance-based estoppels" section, Oracle's statements seem to be a "promissory estoppel".
However, the code/doc could probably be forked from the prior version. I believe that would be similar to the LibreOffice fork of OpenOffice (nee StarOffice). It's an open question whether that's worth it vs. putting the effort into MariaDB.
Personally, I don't use full featured databases other than the occasional hookup to an sqlite one. However, based on the last description of features, development model/roadmap, licensing, etc. for MariaDB I've read, I'd vote for it.
Perhaps folks that rely on mysql (e.g. the Wordpress community) could weigh in on the technical merits/difficulties of switching.
This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.
Sharing of this information has long been rumored (IIRC, in one or more of James Bamford's books/articles [who has been writing about this for decades]). Long before PRISM, there was http://en.wikipedia.org/wiki/ECHELON It has a common database amongst all participating countries.
The political hand waving that the U.S. (or England) "doesn't spy on its citizens" is gotten around by having another country do it for them (e.g. England/Canada is free to intercept U.S. citizen communications (e.g. they're "foreigners" to Canada) and vice-versa). It all goes into a common database and/or is shared.
Now, given that as a pretext, there is no way to tell if the data was gleaned by Canada on U.S. citizens [or U.S. on Canadian citizens] or was truly domestic spying on one's own citizens. As a convenience, just do it yourself, but if you get caught, claim it was put in the database by another country.
In the end, does that technicality really matter that much when discussing the merits vs. ethics?
Actually, as Zzzoom pointed out http://hardware.slashdot.org/comments.pl?sid=3853421&cid=43981983, the SATA committee has already got a spec for this, it's SATA Express aka SATA 6.2. It will use straight up PCIe out with some slightly different [but still compatible] connectors. But, it is true, 100% PCIe, and was specifically designed to increase the speed for SSD's. IIRC, it's also backward compatible with pre-6.2 drives, just like USB 3.0 will still accept older USB 2.0 and adjust accordingly.
Too underpowered to be your desktop, that is. Or mine. Or most of Slashdot's. (But then, so are basically all All-In-Ones and pre-builts.) But to the "average" home user who only uses a computer for email and web browsing, it'll be sufficient.
A lot of home users expect to be able to play video games. After the email/web is done for the day, they turn the system over to their children. A friend of mine recently wanted to purchase a desktop. His personal requirements were modest [as you mentioned], but he wanted his 8 year old son to enjoy/use the system. So, we had to go up a notch or two to get a gaming system.
The Dell system is too bulky relative to its power. The detached keyboard is just an extra item to lug around. Because it's running Win8, the keyboard is pretty necessary despite the attempts to make it touch friendly. Win8 still isn't a true tablet OS ala iOS or Android.
Because the system specs in like a laptop, and a laptop is more convenient, there isn't any advantage to it. As the article mentioned, the real differentiator is the touch screen display [which, at 18" could go into a laptop]. If they had made the display 24", they might have something.
This whole thing smacks of a laptop design that was hurriedly modified to get this unit to market to stop the perceived bloodbath relative to tablets.
It's an interesting idea, but not practical for my use and costs more than I'd be willing to pay for such a thing.
Yes, and I believe just about anybody would say it's too pricey for what it offers. I know my aforementioned friend would.
And with Haswell based laptops already coming out this month [which use far less power], the i5 in this system is already obsolete.
Portable desktop? Just a marketing gimmick. It's too underpowered to be a desktop. It's more of a laptop rigged to look like a tablet with a keyboard because that's currently "sexy".
My present/aging desktop 12GB of RAM, 8 cores, clocks at 2.5 GHz, has 6 TB of SATA hard disk, and 20 TB of USB 3.0 backup disks. I plan to replace this with a top end Haswell soon with 48+ GB of RAM, 8 TB of hard disk (raid 10(?)--striped and mirrored).
I plan to replace my 5 year old laptop with a Haswell based laptop.
Both of these will probably outperform the Dell system and the Haswell's low power will probably beat the pants off it in a laptop in terms of battery life.
Conversely, don't even think about offering a feature or capability that will be useful and easy to implement but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.
Amen.
Once upon a time [20+ years ago] the Air Force wanted "some Macs + software [written by somebody with an "in"]". But, they had to open it up to the RFQ process. They added a raft of requirements custom tailored to this "insider" system to try to guarantee that no other combination could match the RFQ.
However, the company I worked for met all the specs using a completely different system, even adding a "sweetener" such as you describe. The Air Force made it a requirement of my company, but not of the original competitor.
The Air Force awarded the contract to the original bidder. That is, until the GSA reviewed things and ordered the Air Force to award it to the company I was working for [we had the better system]. Rather than comply, the Air Force cancelled the entire project.
That was my first exposure to government contracting (and my last;-)
Whenever someone on on/. likens Google's network to a supercomputer God kills a Pokemon.
Who kills a what?
But honestly: the reason why Google can cope with these massive outages is that they're doing totally different computations from supercomputers. Google's compute jobs are losely coupled. They do data mining. That is fundamentally different from supercomputing where all compute jobs are tightly coupled.
The architecture of a Google data center is virtually identical to a supercomputer. In Google parlance, "The data center is the computer." Racks and racks with interconnect. All are using Xeon-like chips [IBM does too, but some are based on their Power series chips]. The only difference in usage might be problem space. But, Google runs plenty of jobs internally that aren't data mining. Video processing for one. But, while search can be split up more effectively than some job mixes, it benefits just as much with advances that are supercomputer-like. So, you can bet Google is working just as hard on that angle as Cray. And Google has much more money to invest in research than Cray [see below].
Cray's "secret sauce" is its Gemini interconnect, but it's still laid over the top of Xeon-like chips. Architecturally, it's difficult to get true fine grained on top of an x86 arch. The tricks used to make the single core fast: out-of-order execution, multiple execution units, etc. make multicore coordination beyond the occasional SMP lock primitive difficult.
Intel was trying to address this with Larabee's ring bus architecture. Similar, to Kendall Square Research's "all cache" architecture. But Larabee got shelved [it's dandy for compute intensive mixes but fell short as a GPU]. Some of the concepts got folded into Haswell.
One might have better luck with some of the "mesh" RISC chips that have have exact/precise instruction times and crossbar interconnect on die. The latter have a much better chance of running cycle-by-cycle lock step. An early forerunner of this approach was the Inmos Transputer.
But, still, eventually you have to go off die, off chip, off board, off rack, off room, off building. This boils down to interconnect. While you might be able to have a special backplane parallel interconnect for the near nodes, eventually, as a matter of practicality [expense], you're going to end up with a serial [fiber] interconnect (e.g. 100G Ethernet, Thunderbolt, etc). This is the data movement problem that the article mentioned.
Thus, everybody has access to the same building blocks to build a supercomputer or data center. When Cray comes up with their own graphene based CPU chip (e.g. 100x the electron mobility), running at 100 GHz, they might do better. IBM is more likely to come up with this than Cray.
But, this won't help without faster memory than DRAM. Hewlett Packard is working on putting magneto-resistive memory on die. MR, in addition to being persistent, is as fast as level 2 cache and [I believe] the cell size is smaller than DRAM.
Perhaps, it's time for the supercomputer community to look beyond tightly coupled as a requirement, if it's to scale.
Also, as the slide show presentation in the article pointed out, the future of reliability is to not rely on the hardware to provide it. The software will have to provide it. The software knows when it's reached a checkpoint. IBM is deploying a system [based on Power] that has transactional memory support built in. They have 16 cores/die [one is a spare]. Intel's Haswell has transactional memory support with commits and lock elision.
To give you a car analogy:
In the Google case millions of mechanics fix millions of cars in parallel. This is more or less trivial. If one of the mechanics is ill, another one can take over his task, or they simply wait until a replacement arrives.
In supercomputing your try to assign millions of mechanics to fix a
You might need to broaden your research beyond what is available in the academic literature. Google handles redundancy. When they do a map/reduce, the clusters are self forming. If a cluster leader/master goes down, the cluster reelects a new master. They trust the integrity of nothing. Not even DRAM. They checksum everything. The actual architecture of Google's data centers is a closely guarded trade secret, but from what [little] I've been able to glean, they're light years ahead of "big iron" vendors such as Cray. Likewise for Amazon and [even] Facebook.
Also, there are some systems in development where the individual compute cells are modeled on neural networks. This is in relation to the power consumed. The cells use a bare fraction of the most low power cores (even Intel's Haswell/trigate), something like 100x or higher.
You might be astonished by this, but you're not alone. Students that do PhD's in information search get to Google. They find out that the best knowledge they have is 10 years out-of-date compared to what Google does internally.
Yep, adguy is a bit moronic. However, nurses do need technical skills. I have a friend who is a nurse. She is also a manager of a department of 100 nurses. They have to train the older nurses how to use email, spreadsheets, etc. because a lot of the data is automated/online.
My friend had to extract data from a database to make a presentation related to future planning. The data extraction necessary was not one of the database's standard reports, so she was doing it manually [cut-and-paste] (e.g. no scripting possible). It would have been trivial to do a database dump in whatever format (e.g. XML--yecch) and write a perl/whatever script to munch the data. Getting her IT department [prodding/cajoling them] to do it would take longer than the time she had. Because I'm a programmer, she asked me if I could help, but immediately after her voicing the question, she and I both realized I couldn't help her because of patient confidentiality restrictions.
If she had been able to program, it would have saved her considerable time.
I'm a [linux] kernel programmer. I write device drivers. I haven't used a goto in 30 years [not one!]. I've also written code to do realtime processing of broadcast quality HD video on a linux platform in conjunction with specialized hardware.
You're assuming that to make code fast, it's done [has to be done] by doing insane hacks [or the bad practices that you mentioned]. This [usually] only produces modest speedups on the order of a few percent. Most really fast code is highly modular and just uses a better algorithm (e.g. instead of linear search, use binary or RB tree, etc.).
As the simplest example I can think of:
If you use:
int a[100];
int idx;
int sum;
sum = 0;
for (idx = 0; idx < 100; ++idx)
sum += a[idx];
You're better off with:
int a[100];
int *ptr;
int *ep;
int sum;
ptr = a;
ep = ptr + 100;
sum = 0;
for (; ptr < ep; ++ptr)
sum += *ptr;
When such loops become slightly more complex, the latter will optimize better and run 2x faster. That's [culled] from a real world example, where I recoded along those lines. And the resulting code was simpler. I also moved out loop-invariant expressions that the optimizer didn't catch. No "tricks" [if you will] were needed.
At the video company, we had to load firmware into an FPGA. The original loader program [written by the FPGA company] took 15 minutes. That was intolerable for our customers. But, I discovered it was using fscanf on the input file for each and every input byte (e.g. fscanf, send to device, repeat). This was grossly inefficient, but was never changed because the code was originally designed for very small FPGAs that were only sparsely filled (e.g. the slow code would take about 2-3 minutes for most of the FPGA company's customer use cases). However, we were using the largest FPGA possible and filling it to capacity.
I recoded this by preloading the entire file into a memory array, transforming it, so that it became:
for (all_bytes_in_array)
sendbyte(); This reduced the load time from the 15 minutes to 90 seconds [a 10x speedup]. Once again, the resulting code was far simpler than the original. Oh, and the original code was sparsely commented. I added comments to virtually every section [as part of my original investigation, before changing any code--so I could understand things well enough to change the parts that I did change]. In so doing, I found multiple redundancies that could be eliminated. This is more Occam's Razor than anything else.
I've got a friend at a company that is using Scala ("Java done right" (tm):-). Based on the horror stories he's told me, the programmers there that have the most bugs filed against them are the ones that are the strongest proponents/users of Scala's "functional programming" features. Ironic to say the least.
On the academic front, Carnegie Mellon [arguably one of the top three schools for computer science], is changing its freshman curriculum. They will no longer introduce Java, will eschew OO and functional programming in favor of a more [traditional] imperative programming approach [with increased emphasis on performance analysis and details of algorithm implementation]. Historically, CM has usually been a trend setter, so that should give one some food for thought.
Slashdot Mirror
Admittedly, I've bookmarked this article for later perusal. That said, it strikes me that the following might already foot the bill:
http://arstechnica.com/information-technology/2012/05/codel-buffer-management-could-solve-the-internets-bufferbloat-jams/
Unlike other active queue management (AQM) algorithms, CoDel is not interested in the sizes of the queues. Instead, it measures how long packets are buffered. Specifically, CoDel looks at the minimum time that packets spend in the queue. The maximum time relates to good queues which resolve quickly, but if the minimum is high, this means that all packets are delayed and a bad queue has built up. If the minimum is above a certain threshold—the authors propose 5 milliseconds—for some time, CoDel will drop (discard) packets. This is a signal to TCP to reduce its transmission rate. If the minimum delay experienced by buffered packets is 5ms or less, CoDel does nothing.
Yes, complete [and utter] ...
I've been programming for 40+ years and how I analyze code [and hence, my "eye track"] varies, depending upon what I'm looking for. If I need to know one thing, I'll tend to zero in quickly. If I'm going to make changes, I'll scan over everything [at least] once to try to glean the overall style so I'll know what I'm up against when/before I start to make the changes.
Not only that, but the article's last line is about "joining the experiment" if you're in the Bloomington, IN area [*].
Indiana? Indiana??? A fine state for many things [America's home for auto racing--the sport of kings :-)] ...
But, how about choosing a place noted for its programming talent (e.g. Silicon Valley, Boston/128, Los Angeles, San Diego, Research Triangle Park, NC, NYC, etc.)?
[*] Also, is there some special camera setup required that only the author has? Couldn't this be done by downloading the eye track software and programming examples onto any computer [anywhere] that has a builtin webcam? With a questionnaire about one's programming background? That way, data on thousands of people could be correlated.
I'm sure you will be careful with this but I just want to post a friendly reminder.
Yes, one of the reasons that I haven't done it until now. My system has a dynamic IP and no DNS entry, so it's hardly a high profile target. Since 12/22/11 I have some 32,000 entries.
Depending on how you organize your script and how often the same person hits your network, there's a chance you'll end up flooding the abuse contact with email. Not only will they not appreciate that, but there is a chance of amplification and bogging down their abuse handling process.
I was considering a builtin delay. Delay until the volume reaches a certain number of attempts or enough time has elapsed that it indicates a one off attempt. One instance originated from Bangkhok and would do an attempt every 20 minutes. This went on for weeks.
Yes, you're correct. Clearly a balance between excessive volume and hyper-reaction vs. timeliness must be struck. That is, for example, if the "perp" is roaming [betweeen internet cafes] to avoid detection/capture, being able to nab the person "in the act" would require frequent live updates of the abuse info.
In addition to the abuse-mailbox field you mention, it would be nice to standardize on an abuse report format, too. That way we could be confident that abuse reports can be properly fed into a system without depending on a human reading them directly.
I was thinking a .csv: YYMMDD-HHMMSS.uuuuuu,IP,login,pw
This needn't actually go through email if we were to collectively come up with a dynamic system to handle such things. Either a spamhaus type organization or some decentralized database. Remember the recent [similar] attack against wordpress sites? Having dynamic abuse info passed around in realtime [via some "abuse report" protocol], would allow backbones to start dropping/blocking the traffic [near the source]. This could mitigate such an attack before it had a chance to get going.
It would need some "web of trust" aspects to validate the abuse reports [vs. someone sending false ones just to blackball the IP of someone they didn't like].
Actually, now that I think of it, IIRC, there are some sites that take such info already.
Also, while some attack combos have been scattershot (e.g. login: mary, pw: mary) or dictionary (root/a, root/aa, ...), some are so obscure/unique (e.g. root/a3da50fb67a6ae5a06eca1364e2356a9) that the only explanation is that there has been a crack of a pw database somewhere and they are replaying everywhere.
What constitutes an authorized user?
I have a honeypot on my home server to collect phony/random/orchestrated login/breakin attempts. A log entry has time, IP, username, pw. Eventually, I'd like to do further automated scripting. Namely, take the IP address, do a whois on it, look for the abuse contact email at the ISP, and email them the relevant log entries, with a polite request to investigate.
If they're legit, they may want to take action against one of their users who is doing massive attempts at system breakins. That is, such attempted login/breakin activity is against the law in certain countries. It's also [probably] a violation of the ISP's TOS. I've read that many ISPs don't even know that their customers are doing such things and welcome being told because the customer activity can expose the ISP to a degree of legal liability [safe harbor notwithstanding].
Currently, in whois data, there is no [universally used] standard for the abuse mailbox. It can be: ... ... ... ...
abuse-mailbox:
Remarks: Send abuse email to
% Remarks
# Send abuse reports to
So, standardization would be nice.
However, an interesting wrinkle. Although I get attempts from all over the world, most of the breakin attempts I get come from .cn hosts [just sayin ...]. The whois data from these is _always_ 100% complete and well organized. I guess they're compelled to do this by the gov't there. If, as proposed, the information goes to a central repository in [presumably] another country, there would be no way to compel an ISP to provide accurate/complete information cross-border.
So, how does this shape up under the new proposal? Which country's laws would govern this? Per-country top level domains like .cn and .uk present fewer problems. But, what about the more generic .com, .org, etc.?
No court is ever going to say that someone is required to perform some service (like release a new version of MySQL under GPL), when there is no benefit to them to doing so.
If they were under contract to do so, they would.
Sorry, but one cannot bind themselves to slavery (which is basically what you are asking for) just by issuing a statement or 'promise'.
Try doing a bit of [legal] reading/research:
Promissory estoppel is a contract law doctrine. It occurs when a party reasonably relies on the promise of another party, and because of the reliance is injured or damaged.
In the law of contracts, the doctrine that provides that if a party changes his or her position substantially either by acting or forbearing from acting in reliance upon a gratuitous promise, then that party can enforce the promise although the essential elements of a contract are not present.
You might want to read more arstechnica, which frequently gets cited on slashdot. They've done numerous articles (vs. blogs) on all aspects of this. They're a Conde Nast publication [as is Wired, IIRC] and are usually pretty credible. I tend to follow (and bookmark) articles on this. The two I posted were taken [quickly] from about 100 I've amassed and they all pretty much say the same thing.
But, you wanted an actual "study".
For example, this article is based on a study:
http://arstechnica.com/business/2012/12/report-data-caps-just-a-cash-cow-for-internet-providers/
The actual study [linked within the article] is:
http://www.newamerica.net/publications/policy/capping_the_nation_s_broadband_future [*]
[*] If you dispute the data/conclusions, take it up with the authors.
There are other articles, from various publications, that talk about the disincentive for telcos to provide higher speeds.
If you want to know how easy it is to roll out fiber, check out sonic.net. They're a regional telco and ISP based in Santa Rosa, CA. They provide ADSL2+ throughout California at 3x the speed of AT&T's elite service at half the price ($40/month) with no data caps.
They're also rolling out fiber to the home as fast as they can and will provide their subscribers with that higher speed, at the same price, and, again, no data caps.
I don't think the existence of MariaDB lets Oracle off the hook for a couple of reasons:
MariaDB doesn't change the fact that Oracle is reneging on its [implied] promises.
The harm is real. If a developer/company continues development on mysql (e.g. spends real money) continuing with mysql, based upon the assurances, vs. pulling the plug on all such devel activity immediately [when Oracle first acquired Sun].
In absence of the Oracle roadmap, the other company's choice might have been to spend that [wasted] capital on doing a Postgres port right away. Not only money wasted, but time as well, and business decisions about what markets to stay in/get out of. All of these could affect a company's competitiveness, market share, and profitability. Hence the harm.
If Oracle had said at time of acquisition that mysql was being closed [made no public promises to the contrary], there would be nothing to litigate about. Others are correct about being able to change licensing in general.
But, if Oracle had said that then [people were plenty steamed up], there would have been an immediate code fork [ala LibreOffice] or mass migration to Postgres [IIRC, MariaDB didn't exist then]. So, if Oracle had this latest action in mind all along [after the brouhaha dies down], then they seem truly duplicitous [and vulnerable in a court of law].
In general, perhaps.
However, when Oracle took over Sun, it made public statements to the effect that the open version would remain that. If users/consumers took actions [to stay with mysql vs. bolting to Postgres], based on these statements, they may have suffered [actionable] harm.
Reading further down the [wiki] page, under the "reliance-based estoppels" section, Oracle's statements seem to be a "promissory estoppel".
They might be held to it under the principle of estoppel. See http://en.wikipedia.org/wiki/Estoppel in particular, the Overview section, example 2.
However, the code/doc could probably be forked from the prior version. I believe that would be similar to the LibreOffice fork of OpenOffice (nee StarOffice). It's an open question whether that's worth it vs. putting the effort into MariaDB.
Personally, I don't use full featured databases other than the occasional hookup to an sqlite one. However, based on the last description of features, development model/roadmap, licensing, etc. for MariaDB I've read, I'd vote for it.
Perhaps folks that rely on mysql (e.g. the Wordpress community) could weigh in on the technical merits/difficulties of switching.
From the blog, the old documentation said:
This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.
IANAL, but it looks like a GPL violation to me.
Perhaps. But, IIRC, the same complaints/problems happened with Netflix, Level 3 Communications, and Comcast.
http://finance.yahoo.com/blogs/daily-ticker/why-phone-cable-internet-bills-cost-much-130914030.html
http://www.bloomberg.com/news/2012-12-27/u-s-internet-users-pay-more-for-slower-service.html
Sharing of this information has long been rumored (IIRC, in one or more of James Bamford's books/articles [who has been writing about this for decades]). Long before PRISM, there was http://en.wikipedia.org/wiki/ECHELON It has a common database amongst all participating countries.
The political hand waving that the U.S. (or England) "doesn't spy on its citizens" is gotten around by having another country do it for them (e.g. England/Canada is free to intercept U.S. citizen communications (e.g. they're "foreigners" to Canada) and vice-versa). It all goes into a common database and/or is shared.
Now, given that as a pretext, there is no way to tell if the data was gleaned by Canada on U.S. citizens [or U.S. on Canadian citizens] or was truly domestic spying on one's own citizens. As a convenience, just do it yourself, but if you get caught, claim it was put in the database by another country.
In the end, does that technicality really matter that much when discussing the merits vs. ethics?
Actually, as Zzzoom pointed out http://hardware.slashdot.org/comments.pl?sid=3853421&cid=43981983, the SATA committee has already got a spec for this, it's SATA Express aka SATA 6.2. It will use straight up PCIe out with some slightly different [but still compatible] connectors. But, it is true, 100% PCIe, and was specifically designed to increase the speed for SSD's. IIRC, it's also backward compatible with pre-6.2 drives, just like USB 3.0 will still accept older USB 2.0 and adjust accordingly.
Too underpowered to be your desktop, that is. Or mine. Or most of Slashdot's. (But then, so are basically all All-In-Ones and pre-builts.) But to the "average" home user who only uses a computer for email and web browsing, it'll be sufficient.
A lot of home users expect to be able to play video games. After the email/web is done for the day, they turn the system over to their children. A friend of mine recently wanted to purchase a desktop. His personal requirements were modest [as you mentioned], but he wanted his 8 year old son to enjoy/use the system. So, we had to go up a notch or two to get a gaming system.
The Dell system is too bulky relative to its power. The detached keyboard is just an extra item to lug around. Because it's running Win8, the keyboard is pretty necessary despite the attempts to make it touch friendly. Win8 still isn't a true tablet OS ala iOS or Android.
Because the system specs in like a laptop, and a laptop is more convenient, there isn't any advantage to it. As the article mentioned, the real differentiator is the touch screen display [which, at 18" could go into a laptop]. If they had made the display 24", they might have something.
This whole thing smacks of a laptop design that was hurriedly modified to get this unit to market to stop the perceived bloodbath relative to tablets.
It's an interesting idea, but not practical for my use and costs more than I'd be willing to pay for such a thing.
Yes, and I believe just about anybody would say it's too pricey for what it offers. I know my aforementioned friend would.
And with Haswell based laptops already coming out this month [which use far less power], the i5 in this system is already obsolete.
Portable desktop? Just a marketing gimmick. It's too underpowered to be a desktop. It's more of a laptop rigged to look like a tablet with a keyboard because that's currently "sexy".
My present/aging desktop 12GB of RAM, 8 cores, clocks at 2.5 GHz, has 6 TB of SATA hard disk, and 20 TB of USB 3.0 backup disks. I plan to replace this with a top end Haswell soon with 48+ GB of RAM, 8 TB of hard disk (raid 10(?)--striped and mirrored).
I plan to replace my 5 year old laptop with a Haswell based laptop.
Both of these will probably outperform the Dell system and the Haswell's low power will probably beat the pants off it in a laptop in terms of battery life.
In the UK, isn't that what rugby players do and football hooligans are?
Conversely, don't even think about offering a feature or capability that will be useful and easy to implement but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.
Amen.
Once upon a time [20+ years ago] the Air Force wanted "some Macs + software [written by somebody with an "in"]". But, they had to open it up to the RFQ process. They added a raft of requirements custom tailored to this "insider" system to try to guarantee that no other combination could match the RFQ.
However, the company I worked for met all the specs using a completely different system, even adding a "sweetener" such as you describe. The Air Force made it a requirement of my company, but not of the original competitor.
The Air Force awarded the contract to the original bidder. That is, until the GSA reviewed things and ordered the Air Force to award it to the company I was working for [we had the better system]. Rather than comply, the Air Force cancelled the entire project.
That was my first exposure to government contracting (and my last ;-)
From the paritynews article:
He also noted that another working exploit may already be circulating in the wild.
Whether this means before he posted or not?
Whenever someone on on /. likens Google's network to a supercomputer God kills a Pokemon.
Who kills a what?
But honestly: the reason why Google can cope with these massive outages is that they're doing totally different computations from supercomputers. Google's compute jobs are losely coupled. They do data mining. That is fundamentally different from supercomputing where all compute jobs are tightly coupled.
The architecture of a Google data center is virtually identical to a supercomputer. In Google parlance, "The data center is the computer." Racks and racks with interconnect. All are using Xeon-like chips [IBM does too, but some are based on their Power series chips]. The only difference in usage might be problem space. But, Google runs plenty of jobs internally that aren't data mining. Video processing for one. But, while search can be split up more effectively than some job mixes, it benefits just as much with advances that are supercomputer-like. So, you can bet Google is working just as hard on that angle as Cray. And Google has much more money to invest in research than Cray [see below].
Cray's "secret sauce" is its Gemini interconnect, but it's still laid over the top of Xeon-like chips. Architecturally, it's difficult to get true fine grained on top of an x86 arch. The tricks used to make the single core fast: out-of-order execution, multiple execution units, etc. make multicore coordination beyond the occasional SMP lock primitive difficult.
Intel was trying to address this with Larabee's ring bus architecture. Similar, to Kendall Square Research's "all cache" architecture. But Larabee got shelved [it's dandy for compute intensive mixes but fell short as a GPU]. Some of the concepts got folded into Haswell.
One might have better luck with some of the "mesh" RISC chips that have have exact/precise instruction times and crossbar interconnect on die. The latter have a much better chance of running cycle-by-cycle lock step. An early forerunner of this approach was the Inmos Transputer.
But, still, eventually you have to go off die, off chip, off board, off rack, off room, off building. This boils down to interconnect. While you might be able to have a special backplane parallel interconnect for the near nodes, eventually, as a matter of practicality [expense], you're going to end up with a serial [fiber] interconnect (e.g. 100G Ethernet, Thunderbolt, etc). This is the data movement problem that the article mentioned.
Thus, everybody has access to the same building blocks to build a supercomputer or data center. When Cray comes up with their own graphene based CPU chip (e.g. 100x the electron mobility), running at 100 GHz, they might do better. IBM is more likely to come up with this than Cray.
But, this won't help without faster memory than DRAM. Hewlett Packard is working on putting magneto-resistive memory on die. MR, in addition to being persistent, is as fast as level 2 cache and [I believe] the cell size is smaller than DRAM.
Perhaps, it's time for the supercomputer community to look beyond tightly coupled as a requirement, if it's to scale.
Also, as the slide show presentation in the article pointed out, the future of reliability is to not rely on the hardware to provide it. The software will have to provide it. The software knows when it's reached a checkpoint. IBM is deploying a system [based on Power] that has transactional memory support built in. They have 16 cores/die [one is a spare]. Intel's Haswell has transactional memory support with commits and lock elision.
To give you a car analogy:
In the Google case millions of mechanics fix millions of cars in parallel. This is more or less trivial. If one of the mechanics is ill, another one can take over his task, or they simply wait until a replacement arrives.
In supercomputing your try to assign millions of mechanics to fix a
You might need to broaden your research beyond what is available in the academic literature. Google handles redundancy. When they do a map/reduce, the clusters are self forming. If a cluster leader/master goes down, the cluster reelects a new master. They trust the integrity of nothing. Not even DRAM. They checksum everything. The actual architecture of Google's data centers is a closely guarded trade secret, but from what [little] I've been able to glean, they're light years ahead of "big iron" vendors such as Cray. Likewise for Amazon and [even] Facebook.
Also, there are some systems in development where the individual compute cells are modeled on neural networks. This is in relation to the power consumed. The cells use a bare fraction of the most low power cores (even Intel's Haswell/trigate), something like 100x or higher.
You might be astonished by this, but you're not alone. Students that do PhD's in information search get to Google. They find out that the best knowledge they have is 10 years out-of-date compared to what Google does internally.
Yep, adguy is a bit moronic. However, nurses do need technical skills. I have a friend who is a nurse. She is also a manager of a department of 100 nurses. They have to train the older nurses how to use email, spreadsheets, etc. because a lot of the data is automated/online.
My friend had to extract data from a database to make a presentation related to future planning. The data extraction necessary was not one of the database's standard reports, so she was doing it manually [cut-and-paste] (e.g. no scripting possible). It would have been trivial to do a database dump in whatever format (e.g. XML--yecch) and write a perl/whatever script to munch the data. Getting her IT department [prodding/cajoling them] to do it would take longer than the time she had. Because I'm a programmer, she asked me if I could help, but immediately after her voicing the question, she and I both realized I couldn't help her because of patient confidentiality restrictions.
If she had been able to program, it would have saved her considerable time.
What about sonic.net? They may not be what you want, but they seem to come close:
http://boingboing.net/2012/06/25/sonic-net-stopped-saving-logs.html
arstechnica has a more in-depth look [including architectural details] at:
http://arstechnica.com/gadgets/2013/05/a-look-at-haswell/
I'm a [linux] kernel programmer. I write device drivers. I haven't used a goto in 30 years [not one!]. I've also written code to do realtime processing of broadcast quality HD video on a linux platform in conjunction with specialized hardware.
You're assuming that to make code fast, it's done [has to be done] by doing insane hacks [or the bad practices that you mentioned]. This [usually] only produces modest speedups on the order of a few percent. Most really fast code is highly modular and just uses a better algorithm (e.g. instead of linear search, use binary or RB tree, etc.).
As the simplest example I can think of:
If you use:
int a[100];
int idx;
int sum;
sum = 0;
for (idx = 0; idx < 100; ++idx)
sum += a[idx];
You're better off with:
int a[100];
int *ptr;
int *ep;
int sum;
ptr = a;
ep = ptr + 100;
sum = 0;
for (; ptr < ep; ++ptr)
sum += *ptr;
When such loops become slightly more complex, the latter will optimize better and run 2x faster. That's [culled] from a real world example, where I recoded along those lines. And the resulting code was simpler. I also moved out loop-invariant expressions that the optimizer didn't catch. No "tricks" [if you will] were needed.
At the video company, we had to load firmware into an FPGA. The original loader program [written by the FPGA company] took 15 minutes. That was intolerable for our customers. But, I discovered it was using fscanf on the input file for each and every input byte (e.g. fscanf, send to device, repeat). This was grossly inefficient, but was never changed because the code was originally designed for very small FPGAs that were only sparsely filled (e.g. the slow code would take about 2-3 minutes for most of the FPGA company's customer use cases). However, we were using the largest FPGA possible and filling it to capacity.
I recoded this by preloading the entire file into a memory array, transforming it, so that it became:
for (all_bytes_in_array)
sendbyte();
This reduced the load time from the 15 minutes to 90 seconds [a 10x speedup]. Once again, the resulting code was far simpler than the original. Oh, and the original code was sparsely commented. I added comments to virtually every section [as part of my original investigation, before changing any code--so I could understand things well enough to change the parts that I did change]. In so doing, I found multiple redundancies that could be eliminated. This is more Occam's Razor than anything else.
I've got a friend at a company that is using Scala ("Java done right" (tm) :-). Based on the horror stories he's told me, the programmers there that have the most bugs filed against them are the ones that are the strongest proponents/users of Scala's "functional programming" features. Ironic to say the least.
On the academic front, Carnegie Mellon [arguably one of the top three schools for computer science], is changing its freshman curriculum. They will no longer introduce Java, will eschew OO and functional programming in favor of a more [traditional] imperative programming approach [with increased emphasis on performance analysis and details of algorithm implementation]. Historically, CM has usually been a trend setter, so that should give one some food for thought.