This struck me as well. In the original article, they put a bound of 100 milliseconds as counting as "low latency" in their book, but Wikipedia's article on algorithmic stock trading puts it in the microseconds instead:
"Low-latency traders depend on ultra-low latency networks. They profit by providing information, such as competing bids and offers, to their algorithms microseconds faster than their competitors."
100 milliseconds is about 10,000 times too slow, even if we are talking in the neighborhood of "tens of microseconds faster", rather than just "microseconds faster".
The reality is if the Nuclear power industry was forced to cover it's own liability and fund itself it would cease to exist.
Unless they were permitted to reprocess fuel as well as building breeder reactors, at which point there's be near zero waste to be subsidizing the storage on, and you'd practically eliminate the need to mine and refine pitchblende in order to obtain Uranium from the yellowcake. Win-win.
Also Hitachi tried to *give* a U.S. town in Alaska a pebble bed reactor in order to prove the technology, and they wouldn't take the thing.
Almost everything you are describing is a productization issue. These types of issues exist, randomly, from phone to phone, because each phone is separately productized by the partner vendor. Generally, the productization, even between single letter/digit hardware versions from the same vendor, end up being handled by different teams, so there is typically not a lot of consistency here. There are vendors who are exceptions, but they are rather rare. Samsung is not one of those vendors.
Certainly be careful about search strings which have no other determinable purpose than terrorism. A search for "chainsaw" could imply running a muck thru a bus station but might also relate to tree clearance. "Shot gun" might mean references to hunting or skeet shooting. But what would someone use a pressure cooker bomb or a ammonium nitrate bomb for other than blowing up people. Its not like one would run around the woods with a pressure cooker bomb to hunt deer or a car bomb as a party favorite.
The pressure cooker is out in left field, unless you are a curious person who follows current events and wants to know what the government is doing with Dzhokhar Tsarnaev these days (he pleaded not guilty on July 10th, is being represented by the Federal Public Defender's office, and is in solitary confinement for 23 hours a day to segregate him from the rest of the population at FMC Devens, a federal prison medical facility).
For ammonium nitrate, and nitrogen-phosphorus fertilizer + diesel fuel explosives, both of which were used during WWII, they were commonly used to remove tree stumps when clearing farmland. Typically, you either rent heavy equipment, have a large tractor, or call in someone with a stump grinder these days, unless you can wait 2 weeks and are willing to drill a bunch of holes straight down and poison the root-ball with Round-Up(tm) and pull it out two weeks later.
PS: Stump grinders were invented in 1956 by Vermeer, so before that time, they weren't an option for removing stumps; Round-Up(tm) wasn't invented until 1970, so that wasn't an option. So you either got hold of heavy equipment, used a machine called a "Back Breaker", burnt them down to as much nothing as you could (generally a very risky proposition), or blew them up.
If a company is popular and thinking of floating you're too late to get rich signing up. Chances are if you get shares they'll already have been diluted and you'll only get them if you stay there for a set number of years AND they don't get further diluted. If you're in the first 50 or so employees in a company that becomes a large multinational AND you play your cards right you MIGHT make some real money.
Depends on their valuation and exit strategy; if they plan to sell out to someone like Facebook or Yahoo, instead of an actual IPO, the options are going to be worth a lot less. If they are going to have a 35% loss like Facebook had, then it's not going to go well for the AMT charges for the people who exercise at the price they'd like to have, compared to the price they actually end up getting after whoever their makers are are done floating the stock to the first third party sell off prior to the employee lockup lifting. Facebook barely hit their ask in the past couple of days, and that was due to projected Ad revenue. Meanwhile everyone already had to pay their 2012 tax bill on their locked up shares for their RSUs and ISO early exercises at the "realized" value, which is much less than the actual.
You are unlikely to get ISOs, unless they've worked a deal with the VCs, or have done the Google-thing, and made the ISOs non-voting stock to avoid control equity dilution.
If they don't ask for too high a valuation, it could be a good deal, but it would have to be a grant price of something like at least 15% lower than the IPO value, assuming they wait a year after the grant, and long term gain it with a target between January and April, for you to break even on the taxes. That would mean waiting at least to Jan/Apr for the IPO so that you can sell long term stock in the tax gap to pay your tax bill. If they pull the trigger between now and the end of the year, instead, then it's a short term capitol gain and subject to AMT unless you come out of lockup before the end of the year, and can successfully sell. At that point, it's basically regular income, and if you're in California, that 15% for break even moves to 45% lower, since between the state and fed, that's what they're going to be billing you.
Either way, you pay gains on your grant price as your basis price, and from $0-basis amount is considered income in the grant year (usually, there is a 4 year vesting with a 1 year cliff before you can touch any of it, at which point it goes month to month on availability for sale). This is no longer pre-dot.bomb, given Sarbanes-Oxley. If you actually think it's imminent IPO, you would probably be better of getting bonused, unless they start low, have a quick ramp, a quick vesting cliff, and give you a great deal.
Anyway, anyone entering into ISO or RSU agreements pre-IPO these days would be well advised to talk to a tax accountant before taking an offer.
I would be interested in an approval rating poll comparing Obama, Snowden, and the current frontrunners for the Democratic and Republican nominations for the next election.
I wonder if any candidate has run for the U.S. presidency from outside the U.S., perhaps in the early history of the country?
The promise is a specific stipulation. Article 3 of the European Convention on Human Rights bars Britain and the other signatories from extraditing prisoners if they could face capital punishment. There is no death penalty in any of the 15 member nations of the European Union.
This is an attempt to eliminate willing participation of these 15 EU member states, and other states with similar laws and policies, as potential havens for Snowden on the basis of a possible U.S. death penalty or torture of the extradited person.
Sure, Android devices vary a little bit... but why would HTC worry about what screen size Samsung has?
COGS - Cost Of Goods Sold. To get the best volume pricing on screens, you buy screens that your competitor isn't buying. Otherwise, you end up in a fight like the one where anyone else trying to buy an iPhone comparable screen out of LG ends up in: Apple simply buys all available stock, and then gets an exclusive contract for all future stock from that screen manufacturer. Apple does exactly the same thing with 5-7 parts in all the iPhone models so that no one else can buy them. It has the added benefit that it stops "Third Shift" production runs of iPhones at the factories of "iPhone clones" built on the same assembly lines that build the iPhones.
To avoid this situation, HTC has to buy the parts that Apple and Samsung are not buying, and which are availalble in manufacturing quantities, for the cheapest pricing. This usually means "in stok" parts, which in turn means you don't get to pick your screen resolution.
So in fact HTC has a *very big* interest in Samsung's screen size, because if the parts were drop in replacements for the Samsung device screens, HTC risks having its supply stolen out from under it, and coming up short on a manufacturing run.
The only device the manufacturer has to worry about is their own, and they KNOW exactly what type of hardware it has.
And that's what they do, and that's what makes it impossible to do what Apple does, and have the Apps run exactly the same across all Android devices, without at least having display scaling artifacts - artifacts which Apple Apps do not have; even on the changes iPhone 5 aspect ratio and therefore resolution not being an even multiple, the default for App store apps is to put up black bars, rather than making than making all the cowboys (for example) look short and fat in order to fit the screen.
Specific Android version features are identical. None are removed, but features can be / are added (see IR Blaster on the GS4 and HTC One).
This is called a "minimal spanning set". And yes, you can write your App to the least common denominator (LCD) for hardware features, but if you do, be prepared to have your lunch eaten by the company that writes their clone of your App, but uses all the available features of the hardware - unlike your App.
You also point out: "people will buy new devices anyway, as soon as they come out, all things being equal"... well, you could do that on Android too.
But people don't! What's the consumer incentive? If all the Apps I have are built to work on any Android phone, then they are written to the LCD, then I don't get any new benefits from the new hardware, except for one or two partner supplied Apps that probably come with the phone -- what most people would call "crApps" or "crapware". With Apple (until the iPhone 5), I always get more/better/faster.
How compatible is the hardware profile across even just the Samsung Galaxy line of devices?
You'd actually be better off not paying for upgrades to ancient devices to boot.
And the vendors aren't paying for it, and neither are the carriers. So you're agreeing with my original argument, it seems: if you have Android version number envy, buy a new device.
Android also has baseline support for GPS, accelerometer/gyros, etc., so again, no clue what you're talking about.
Yes, but you can't depend on them being there in the most cheap-ass Android phone out there, and when they are there, with parts sourced from different suppliers, you can't depend on the behaviour being identical, for the same App, on differrent Android platforms, even if you as an App vendor were willing to lock yourself out of the segment of the market that doesn't have the hardware feature by making your App dependent on the feature.
So Nokia builds a smartphone instead of a feature phone (FINALLY!), they don't have an OS for the thing, they license the Windows phone OS so that they at least have something to run on their first real Smart Phone they've ever built.
Then the thing flops.
This is Microsoft's problem how? Why weren't you doing Smart phones, or at least getting into them in the last near-decade like everyone else, Nokia?
How can you expect your first time to market with something you've never built before, and have a demonstrated historical inability to build at all, to be a success or failure based on a third party OS license?
So how does Apple do it? The iPhone 3gs released in 2009 can run the latest iOS 6.
The Apple monetization model for carriers is not based on carrier lock-in, and hasn't been since they changed the FAS (Federal Accounting Standards) rules under which they operate. These are the same rules that disallowed them from offering the 802.11n firmware upgrade to iPod users for free, but allowed them to give it away to iPhone users. The particular FAS rules they were using would have caused the firmware giveaway on iPods to be a Sarbanes-Oxley Act violation, and under the new rules, by realizing their revenue up front, they are now permitted to upgrade everything.
Apple also has a high enough profit margin on iPhones to pay for the carrier qual out of petty cash, plus it has had special contracts with the carriers which force them to certain infrastructure requirements, including updates. One of the deal-breakers for the first iPhone release not being on Verizon was that AT&T was willing to bend to Apple demands that they integrate web access for their voicemail system in order to implement the "Visual Voicemail" feature of the iPhome, while Verizon didn't want to bend. The reason Verizon didn't want to bend is that they wanted to be able to charge for a call completion, as well as charging for connected minutes, while you listed to the voicemails on the customer account; web access would not have given them that. In other words, Verizon was not willing to cave on monetizing their customers voice mail accesses. If you used a phone on Verizon prior to them releasing the iPhone on that network, the reason the voice mail access was such a twisty and time consuming maze was to increase customer usage of minutes to access it.
Finally, there's actually a monetary advantage to Apple for having everyone running the same version of the OS, and it's tied directly to having a single, central App store. With a single, central App store, it's important to Apple to have all the devices in the field present the same binary APIs to the Apps obtained from the store, in order to increase monetization of the App store. This doesn't exist with Android devices, both because there is not a single manufacturer of Android phones, as there is with iPhones, but also because your "Android 4.1.2" on one device can be slightly different than the "Android 4.1.2" on another device.
In simple terms, the Android model is that Google publishes an Android tree to all partners, and the partners duplicate the repo at some point and code freeze it. The only thing that goes in the partner repo after that point is the code necessary to productize the device based on that code base. This is also why the partners do not like to revisit a device, and why they can't just carry around changes for the device on top of a top-of-tree Android repository snapshot as local branches.
The breakdown works out to:
Source tree: - iOS: version branch tag (all APIs the same) - Android: version that was in the tree at the time of the snapshot (APIs may vary, even for different devices from the same partner)
Tablet vs. phones: - iOS: from the same tree, maintained by the same company - Android: from different trees per device, within the same company; Samsung laptops and phones: different divisions, don't talk much
Aspect ratio: - iOS: same on all devices (4x5) except iPhone 5 (5 was a bean-counting decision on screen cost and remonitization of Apps and content) - Android: varies widely between devices
App store: - iOS: centralized, controlled by an entity that benefits from uniform APIs and versions - Android: split, usually one Google, one vendor, per version
App store content: - iOS: shared by all devices - Android: can't be shared by all devices; each App on a new device is potentially a new port
Productization: - iOS: handled by the seller of the device, who runs the App store, and who enforces uniform versions and APIs - Android: handled b
It's been used in medical devices since the late 90's, shortly after it was invented.
For those applications, Java is purpose built.
This PDF is Oracle's "Markitecture" -- it's how they want things to work. They have not certified and indemnified their embedded JVM for use in life support systems. Don't expect them to. Don't expect a device manufacturer to bear the costs of certifying both the JVM and their application specific code, as a combination, for that use. IT's not going to happen.
Yes, my Java ring is in a box in my workroom... I do not wear it every day and do Green Lantern-ish stuff with it, like Sun was predicting would happen when they gave them away at Java One.
S3, what used to be their flagship a month ago is still running 4.1.2.
This is an incredibly dumb argument.
(1) How does updating a phone you've already paid for to the latest OS sell more phones, if you don't need a new phone to get the latest OS?
(2) How does updating an old phone lock you into the carrier for another 18 months so that the carrier is willing to subsidize the cost, instead of you just letting your updated phone fall off contract, and then go pay-as-you-go, or contract with the cheapest carrier, which isn't the one that subsidized your phone?
(3) How do they monetize to pay the development costs, which might be better spent on newer hardware, since yours already works?
(4) How do they monetize to pay the FCC and other regulatory recertifications, since an SDR is defined as a combination of software and hardware, for certification purposes?
(5) How do they monetize to pay for the the carrier qual process, especially if you won't end up locked back into the carrier?
It's good money after bad, and what's actually pissing you off is that you don't get new software for your old phone, and YOU get to pay the monetization costs, even if they are a break-even, by having a carrier contract with termination fees so that these things get paid, even if you decide you don't like your carrier.
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway. What really sets languages apart is the tooling that's built up around them. The debuggers, the IDE, the profilers, etc. Also, the consistency and extent of the standard API plays a huge role in how useful a language is. I would rather use Brainfuck with an amazing tools and a rich API than use Java, Python, or Ruby with bad tools and an inconstent and incomplete API.
I think it would be very difficult to convince Terumo Cardiovascular Systems to build their next blood gas monitor system, or any of their medical devices, on a Java substrate. I think it would be difficult to convince Radiometer Inc. to base their next portable point of care immunoassay system on a Java substrate. I will go further: I doubt you could get any company working on life support systems of any type to trust Java enough to use it as a substrate.
Java is not suitable for a great number of applications, and, indeed, any language that uses a runtime system, and is either interpreted or JIT'ed, or not, is unsuitable for those applications.
For those applications, you need a language that compiles to ROMable machine code.
For applications like industrial control systems, both in manufacturing, and, again in life support, such as the control systems in nuclear facilities - or even coal-fired facilities, if they happen to have their output powering a pediatric ICU, any garbage collected language is unsuitable, since there is very little control, without infinite memory available, on when a GC will run. You can not implement hard real time in a GC'ed language.
For those applications, Java is unsuitable.
There are some languages suitable for those applications: assembly, C, Ada, FORTRAN, C++ (if you disable RTTI and certain aspects of polymorphism, and use an older version, rather than the current draft standard version). There are others, but they are infrequently enough practiced that they would be suspect, both in their mathematical provability, and in their ability to be audited for coding errors.
So No, any language is NOT as good as any other. Not even close.
This is a 50 billion dollar (or yen equivalent) public relations exercise. The government wants to look like it is actually doing something about an issue it has zero control over now.
The Japanese government doesn't want to admit the truth that these areas are going to remain uninhabitable for hundreds, if not, thousands of years - because it promised the Japanese people that they would be able to return to their homes. The technology doesn't exist to clean up all this contaminated land.
$50B will buy an awful lot of concrete. Concrete plains are rather habitable when you cover them with dirt.
I think it would be great to start equipping all motor vehicles with (well-designed, forwards-compatible) systems like this so that in 20-30 years when driverless cars are a viable option on the road, there's the infrastructure in place to support it.
You are aware that there is not a car manufactured after 1981 which does not have an Oxygen sensor, and therefore does not need reformulated gasoline with MTBE or, now, other additives, to keep it from polluting. That's a 33 year gap, and it still hasn't gotten all the older cars off the roads, and it hasn't gotten the older cars retrofit with Oxygen sensors. Instead we are still putting crap into the gasoline that has the sole effect of making cars manufactured prior to 1981 pollute less, while at the same time causing all cars, including those manufactured after 1981, get 10%-15% worse gas mileage, which requires more fuel to go the same distance, which causes them to pollute more.
Retroactive laws are disallowed, both in U.S. courts, and in English Common law for a reason: You can't make a prior act illegal, just as you can not make a firearm purchased under current law illegal in the future. See: http://en.wikipedia.org/wiki/Ex_post_facto_law
Forcing the USPS to maintain a fund for worker retirement up to 75 years from now is completely and totally unreasonable and serves only one purpose.
You're right, it serves one purpose. It subsidizes the health care costs for the rest of the federal government:
"Are you a new hire eligible for federal employee health benefits? Have you experienced a qualifying life event? Looking to switch FEHB plans? Federal and postal employees and annuitants can enroll in an MHBP health plan designed to fit their health needs."
The grandparent was talking about the USPS, which has been ruined by requiring pension allocations 75 years in advance, and yes, this was entirely a Republican venture.
Except, you know, the part about the Democrats who also voted for it, and the Democratic president signing the bill into law.
If you don't want to drive miles to a mailbox cluster, the USPS doesn't want to drive those miles to deliver a bulk mail envelope that only earned them 25 cents.
So raise bulk mail prices $0.01 per unit; they delivered 84.7 billion units last year http://about.usps.com/publications/annual-report-comprehensive-statement-2011/html/ar2011_financial_2.htm... not including 7 billion periodicals. The post office gets their 26 cents instead of 25 cents, and congress gets to keep the excellent Mail Handlers Health Insurance which the post office subsidizes for them, since it's basically what every GSA employee gets, despite the name. The postal carriers get to keep their rather inflated pensions. Everyone is happy.
The big question: will I be able to put something else on there? Like what OpenWRT did for routers?
Not if you want working Netflix, any of the major television networks, or a DVD player.
You should also be aware that seat-back displays for "infotainment" are OK, but using the in-dask display is only permitted in most states if the vehicle is stopped, in park, and the engine is off. Some states don't allow it even then, although there are plenty of after-market hacks to override this, since they sell exactly the same systems in countries which haven't made it illegal (yet).
For some reason people believe governments make wiser decisions than wealthy individuals, but most of the long term projects happening in the world these days, the kind of things that matter to human survival as a species, and not just "the right party" winning the next short term election, are all being funded by wealthy individuals.
Or to put it another way: focus is no substitute for vision. Government bureaucrats rare have vision.
my robots.txt contains one item which doesn't exist. If you try to access that item your IP is added to the firewall drop list. (until the next reboot)
I don't even have much hosted, just some pictures I don't want to give to flikr.
On the other hand, you've just documented your disallowed content, so I actually don't need to access the content itself in order to index it -- I only need to know to download your robots.txt and shove it into my index.
As the service grows (assuming it does), then I can have a fleet of non-contiguous IP addresses which I use as "content verifiers" for the robots.txt contents (e.g. directories vs. files), and I can "burn" them against your site for content verification.
The arms race escalation is pretty obvious, and contains some interesting twists, but it's basically an arms race, and you will be as effective against it as the battle against SPAM has been so far (there are strategies there, too, but they involve forcing hosting of email bodies by the email sender and similar techniques).
So using the same tripwire technique that the phone companies used to use against wardialers (like I used to be, before it was a criminal offense, and then still, before I turned 18) won't prevent the eventual success.
Personally, I would never do this, since the stuff people think is very private, and then feed to robots in the robots.txt anyway, is generally not very interesting in the first place.
They hated it because it laid the blame squarely where it belonged, at the foot of a very difficult problem to resolve, unless you made automatic local replicas of LDAP subtrees.
A shortsighted and arbitrary kernel limitation does not really count as the fault of the downstream devs who get to suffer for it. As you point out, your "solution" actively encouraged your devs to make a completely wasteful userspace cache of something the kernel should just provide transparently; since you already know this solution, and apparently had access to the kernel code - Why didn''t you either fix the limitation, or if not possible, just build the damned cache yourself and serve high-latency requests from it, rather than getting into a blame-game with people who (reasonably) just expect LDAP to work as advertised?
Because, contrary to popular belief, there is not an infinite amount of available wired memory in the kernel for doing negative caching, and even in the positive caching case, the memory goes quickly. Also, contrary to popular believe, putting everything in the kernel doesn't make it magically faster. Also, POSIX mandates a finite number of groups, and those groups must be attached to each credential, and all internal operations pass around credential references inherited from the thread for the current call context.
As an example, if you are talking a file server serving users at Genentech (someone who use Mac OS X based file servers with internal security partitions requiring lots of group containers), then you are talking about 10,000 users with mostly non-overlapping combinatoric group membership in 200+ groups each, and each of these requires a UUID, and for Windows interoperability, a GUID, be carried around with them. Add to that negative caching (with the possibility of DOS attacks, or innocent misconfigurations, ballooning the negative cache out of control), and the fact that AppleDirectory supports a group being a member of a group, and you can quickly chew through Gigs of credential cache.
The only sane place to put all this crap is in user space.
The team responsible for doing the user space part was the DirectoryServices daemon team. If I had been allowed to do the cache, I would have. It's not like I didn't have a lot to do with the genesis of the OpenLDAP project, which was the basis for AppleDirectory anyway.
--
And the reason for the local replica is disconnected operation. What happens if you are connected to the corporate network, close your laptop, and head home. On the bus ride home, you open up your laptop to access a file, it has an ACL on it, the ACL requires knowing if you are in a member of the necessary group to access the file, the isGroupMember() call goes out to the kernel thread, the kernel thread sends it to DS in user space because, hey, hell, it doesn't know -- and DS in user space doesn't have it cached.
So DS in user space tries to make the request to the central DS(es) to which it is bound. Only you *aren't* on the corporate network any more, are you, you're on a freaking bus, and you have no local replica.
To make matters worse, the interface on which the connection was made is known to be down, but, hew, Mac OS X networking didn't shut down the socket. And it didn't shut down the socket because most people are on WiFi these days, so there are transient connectivity failures all the time, and it can't tell the difference between a transient WiFi connectivity failure and a more-or-less permanent one, so your request is sitting on the upstream socket Send-Q, not getting answered by the upstream server.
And it was sent to the upstream server in the first damn place because you didn't make a local replica of the user credential for your active local users when you had the chance and connectivity to be able to do so. So the open(2) system call in a user space app is blocked on a cred check, which is blocked on a group membership resolution call, which is blocked on the user spa
(as mentioned in the article) 1: We already know it's down
Then put it on the freaking dashboard for the network service outages so we know not to bother you. If you really don't want to be bothered, put up an "Estimated time to resolution, given past history"/"Estimated time to resolution for [characterized as problem X]", or you're going to get the "we know you know it's down; when will the f---ing thing be back up?" calls anyway.
2: If we don't know it's down, it's probably not down
Something is wrong. Maybe a switch under your control, not mine, is partitioning my part of the network, or maybe the new security you put on MAC address per port and didn't tell us about, or told us about but not in a meaningful way, has made it so we can no longer plug in both our laptops to the same switch port. How about something on the dashboard to let us know how many unresolved issues there outstanding at any given time, or over a period of time as a graph. If there is a spike on the graph, there's something you own that'd not sufficiently monitored, and it's still your problem.
3: We will ping and test several times before digging into the problem
You should be doing short interval periodic monitoring at all times. Even if this part of the dashboard isn't visible to us [users], it should be visible to you, and variances above a certain amount vs. a weighted moving average of expected RTT, for instance, should be flagged.
One of the things the DS developers at Apple hated most, which I implemented, was a kernel weighted moving average recorder on user space DirectoryServices response delay calculator. When making external group resolution requests to user space from kernel space (the kernel credential could only hold 16 groups, and a user could be a member of N, which in practice at Apple, ran to several dozens), the resolution task pops up to user space. If user space takes "too long", the kernel declares it non-authoritative until it re-authorizes itself as authoritative. It flagged extra long latencies in DirectoryServices responding to requests as kernel log messages.
They hated it because it laid the blame squarely where it belonged, at the foot of a very difficult problem to resolve, unless you made automatic local replicas of LDAP subtrees.
If some connection is bouncing around like a handball in a box on a paint shaker, perhaps it's time to disconnect that connection and flag it for field service.
4: Believe it or not, we've tried turning it off and back on again
Yeah, this spackles over a herd of issues that should actually be resolved, like packet storms causing the switch to partition off a port as being "too noisy"; adding more spackle each time it happens ain't going to make it stop happening. Maybe (probably) this one is not your fault, but it'd be nice if the person whose fault it is could get notification of the problem of which you are aware and they are not. Be a f---ing team player, folks.
5: During an outage, we're not just staring at the screen -- we're following a path in our heads
Unexpected dead ends can be found with time domain reflectometers. Try documenting, then automating, the steps you are taking so instead of staring at routing tables, you can be over at the fooseball table, or back home in bed.
6: We calculate subnet masks and CIDR as easily as breathing
So basically, you "grok" radix trees? And?
7: We do not tolerate bugs; they are of the devil
Funny: #4 is explicitly designed to tolerate bugs without fixing them.
Let me give you an explicit corollary, using the terminology from the article: there is no such thing as a white whale. Yes, it might be more important from a business perspective to be back up than it is to track down the specific root cause of the bug, but pretending it isn't
Slashdot Mirror
This struck me as well. In the original article, they put a bound of 100 milliseconds as counting as "low latency" in their book, but Wikipedia's article on algorithmic stock trading puts it in the microseconds instead:
"Low-latency traders depend on ultra-low latency networks. They profit by providing information, such as competing bids and offers, to their algorithms microseconds faster than their competitors."
https://en.wikipedia.org/wiki/Algorithmic_trading#Low-latency_trading
100 milliseconds is about 10,000 times too slow, even if we are talking in the neighborhood of "tens of microseconds faster", rather than just "microseconds faster".
Here's an article from 2011 where they justified spending $300M ($0.3B) on a new transatlantic cable to eke out an extra 6 milliseconds: http://www.telegraph.co.uk/technology/news/8753784/The-300m-cable-that-will-save-traders-milliseconds.html That's just 6% of the 100 milliseconds that these Java guys are willing to waste running Java instead of C code.
The reality is if the Nuclear power industry was forced to cover it's own liability and fund itself it would cease to exist.
Unless they were permitted to reprocess fuel as well as building breeder reactors, at which point there's be near zero waste to be subsidizing the storage on, and you'd practically eliminate the need to mine and refine pitchblende in order to obtain Uranium from the yellowcake. Win-win.
Also Hitachi tried to *give* a U.S. town in Alaska a pebble bed reactor in order to prove the technology, and they wouldn't take the thing.
Almost everything you are describing is a productization issue. These types of issues exist, randomly, from phone to phone, because each phone is separately productized by the partner vendor. Generally, the productization, even between single letter/digit hardware versions from the same vendor, end up being handled by different teams, so there is typically not a lot of consistency here. There are vendors who are exceptions, but they are rather rare. Samsung is not one of those vendors.
Certainly be careful about search strings which have no other determinable purpose than terrorism. A search for "chainsaw" could imply running a muck thru a bus station but might also relate to tree clearance. "Shot gun" might mean references to hunting or skeet shooting. But what would someone use a pressure cooker bomb or a ammonium nitrate bomb for other than blowing up people. Its not like one would run around the woods with a pressure cooker bomb to hunt deer or a car bomb as a party favorite.
The pressure cooker is out in left field, unless you are a curious person who follows current events and wants to know what the government is doing with Dzhokhar Tsarnaev these days (he pleaded not guilty on July 10th, is being represented by the Federal Public Defender's office, and is in solitary confinement for 23 hours a day to segregate him from the rest of the population at FMC Devens, a federal prison medical facility).
For ammonium nitrate, and nitrogen-phosphorus fertilizer + diesel fuel explosives, both of which were used during WWII, they were commonly used to remove tree stumps when clearing farmland. Typically, you either rent heavy equipment, have a large tractor, or call in someone with a stump grinder these days, unless you can wait 2 weeks and are willing to drill a bunch of holes straight down and poison the root-ball with Round-Up(tm) and pull it out two weeks later.
PS: Stump grinders were invented in 1956 by Vermeer, so before that time, they weren't an option for removing stumps; Round-Up(tm) wasn't invented until 1970, so that wasn't an option. So you either got hold of heavy equipment, used a machine called a "Back Breaker", burnt them down to as much nothing as you could (generally a very risky proposition), or blew them up.
If a company is popular and thinking of floating you're too late to get rich signing up. Chances are if you get shares they'll already have been diluted and you'll only get them if you stay there for a set number of years AND they don't get further diluted. If you're in the first 50 or so employees in a company that becomes a large multinational AND you play your cards right you MIGHT make some real money.
Depends on their valuation and exit strategy; if they plan to sell out to someone like Facebook or Yahoo, instead of an actual IPO, the options are going to be worth a lot less. If they are going to have a 35% loss like Facebook had, then it's not going to go well for the AMT charges for the people who exercise at the price they'd like to have, compared to the price they actually end up getting after whoever their makers are are done floating the stock to the first third party sell off prior to the employee lockup lifting. Facebook barely hit their ask in the past couple of days, and that was due to projected Ad revenue. Meanwhile everyone already had to pay their 2012 tax bill on their locked up shares for their RSUs and ISO early exercises at the "realized" value, which is much less than the actual.
You are unlikely to get ISOs, unless they've worked a deal with the VCs, or have done the Google-thing, and made the ISOs non-voting stock to avoid control equity dilution.
If they don't ask for too high a valuation, it could be a good deal, but it would have to be a grant price of something like at least 15% lower than the IPO value, assuming they wait a year after the grant, and long term gain it with a target between January and April, for you to break even on the taxes. That would mean waiting at least to Jan/Apr for the IPO so that you can sell long term stock in the tax gap to pay your tax bill. If they pull the trigger between now and the end of the year, instead, then it's a short term capitol gain and subject to AMT unless you come out of lockup before the end of the year, and can successfully sell. At that point, it's basically regular income, and if you're in California, that 15% for break even moves to 45% lower, since between the state and fed, that's what they're going to be billing you.
Either way, you pay gains on your grant price as your basis price, and from $0-basis amount is considered income in the grant year (usually, there is a 4 year vesting with a 1 year cliff before you can touch any of it, at which point it goes month to month on availability for sale). This is no longer pre-dot.bomb, given Sarbanes-Oxley. If you actually think it's imminent IPO, you would probably be better of getting bonused, unless they start low, have a quick ramp, a quick vesting cliff, and give you a great deal.
Anyway, anyone entering into ISO or RSU agreements pre-IPO these days would be well advised to talk to a tax accountant before taking an offer.
I would be interested in an approval rating poll comparing Obama, Snowden, and the current frontrunners for the Democratic and Republican nominations for the next election.
I wonder if any candidate has run for the U.S. presidency from outside the U.S., perhaps in the early history of the country?
The promise is a specific stipulation. Article 3 of the European Convention on Human Rights bars Britain and the other signatories from extraditing prisoners if they could face capital punishment. There is no death penalty in any of the 15 member nations of the European Union.
This is an attempt to eliminate willing participation of these 15 EU member states, and other states with similar laws and policies, as potential havens for Snowden on the basis of a possible U.S. death penalty or torture of the extradited person.
See: http://www.deathpenaltyworldwide.org/extradition.cfm and: http://www.amnesty.org/en/library/info/AMR51/171/2001/en
The latter document is available in English, Spanish, and Arabic.
Hey! What happened?!?
I ticked the "block intolerance" checkbox, and now I can't reach the web filter configuration page any more!
So much bullshit. LOL
Sure, Android devices vary a little bit... but why would HTC worry about what screen size Samsung has?
COGS - Cost Of Goods Sold. To get the best volume pricing on screens, you buy screens that your competitor isn't buying. Otherwise, you end up in a fight like the one where anyone else trying to buy an iPhone comparable screen out of LG ends up in: Apple simply buys all available stock, and then gets an exclusive contract for all future stock from that screen manufacturer. Apple does exactly the same thing with 5-7 parts in all the iPhone models so that no one else can buy them. It has the added benefit that it stops "Third Shift" production runs of iPhones at the factories of "iPhone clones" built on the same assembly lines that build the iPhones.
To avoid this situation, HTC has to buy the parts that Apple and Samsung are not buying, and which are availalble in manufacturing quantities, for the cheapest pricing. This usually means "in stok" parts, which in turn means you don't get to pick your screen resolution.
So in fact HTC has a *very big* interest in Samsung's screen size, because if the parts were drop in replacements for the Samsung device screens, HTC risks having its supply stolen out from under it, and coming up short on a manufacturing run.
The only device the manufacturer has to worry about is their own, and they KNOW exactly what type of hardware it has.
And that's what they do, and that's what makes it impossible to do what Apple does, and have the Apps run exactly the same across all Android devices, without at least having display scaling artifacts - artifacts which Apple Apps do not have; even on the changes iPhone 5 aspect ratio and therefore resolution not being an even multiple, the default for App store apps is to put up black bars, rather than making than making all the cowboys (for example) look short and fat in order to fit the screen.
Specific Android version features are identical. None are removed, but features can be / are added (see IR Blaster on the GS4 and HTC One).
This is called a "minimal spanning set". And yes, you can write your App to the least common denominator (LCD) for hardware features, but if you do, be prepared to have your lunch eaten by the company that writes their clone of your App, but uses all the available features of the hardware - unlike your App.
You also point out: "people will buy new devices anyway, as soon as they come out, all things being equal"... well, you could do that on Android too.
But people don't! What's the consumer incentive? If all the Apps I have are built to work on any Android phone, then they are written to the LCD, then I don't get any new benefits from the new hardware, except for one or two partner supplied Apps that probably come with the phone -- what most people would call "crApps" or "crapware". With Apple (until the iPhone 5), I always get more/better/faster.
How compatible is the hardware profile across even just the Samsung Galaxy line of devices?
You'd actually be better off not paying for upgrades to ancient devices to boot.
And the vendors aren't paying for it, and neither are the carriers. So you're agreeing with my original argument, it seems: if you have Android version number envy, buy a new device.
Android also has baseline support for GPS, accelerometer/gyros, etc., so again, no clue what you're talking about.
Yes, but you can't depend on them being there in the most cheap-ass Android phone out there, and when they are there, with parts sourced from different suppliers, you can't depend on the behaviour being identical, for the same App, on differrent Android platforms, even if you as an App vendor were willing to lock yourself out of the segment of the market that doesn't have the hardware feature by making your App dependent on the feature.
So Nokia builds a smartphone instead of a feature phone (FINALLY!), they don't have an OS for the thing, they license the Windows phone OS so that they at least have something to run on their first real Smart Phone they've ever built.
Then the thing flops.
This is Microsoft's problem how? Why weren't you doing Smart phones, or at least getting into them in the last near-decade like everyone else, Nokia?
How can you expect your first time to market with something you've never built before, and have a demonstrated historical inability to build at all, to be a success or failure based on a third party OS license?
So how does Apple do it? The iPhone 3gs released in 2009 can run the latest iOS 6.
The Apple monetization model for carriers is not based on carrier lock-in, and hasn't been since they changed the FAS (Federal Accounting Standards) rules under which they operate. These are the same rules that disallowed them from offering the 802.11n firmware upgrade to iPod users for free, but allowed them to give it away to iPhone users. The particular FAS rules they were using would have caused the firmware giveaway on iPods to be a Sarbanes-Oxley Act violation, and under the new rules, by realizing their revenue up front, they are now permitted to upgrade everything.
Apple also has a high enough profit margin on iPhones to pay for the carrier qual out of petty cash, plus it has had special contracts with the carriers which force them to certain infrastructure requirements, including updates. One of the deal-breakers for the first iPhone release not being on Verizon was that AT&T was willing to bend to Apple demands that they integrate web access for their voicemail system in order to implement the "Visual Voicemail" feature of the iPhome, while Verizon didn't want to bend. The reason Verizon didn't want to bend is that they wanted to be able to charge for a call completion, as well as charging for connected minutes, while you listed to the voicemails on the customer account; web access would not have given them that. In other words, Verizon was not willing to cave on monetizing their customers voice mail accesses. If you used a phone on Verizon prior to them releasing the iPhone on that network, the reason the voice mail access was such a twisty and time consuming maze was to increase customer usage of minutes to access it.
Finally, there's actually a monetary advantage to Apple for having everyone running the same version of the OS, and it's tied directly to having a single, central App store. With a single, central App store, it's important to Apple to have all the devices in the field present the same binary APIs to the Apps obtained from the store, in order to increase monetization of the App store. This doesn't exist with Android devices, both because there is not a single manufacturer of Android phones, as there is with iPhones, but also because your "Android 4.1.2" on one device can be slightly different than the "Android 4.1.2" on another device.
In simple terms, the Android model is that Google publishes an Android tree to all partners, and the partners duplicate the repo at some point and code freeze it. The only thing that goes in the partner repo after that point is the code necessary to productize the device based on that code base. This is also why the partners do not like to revisit a device, and why they can't just carry around changes for the device on top of a top-of-tree Android repository snapshot as local branches.
The breakdown works out to:
Source tree:
- iOS: version branch tag (all APIs the same)
- Android: version that was in the tree at the time of the snapshot (APIs may vary, even for different devices from the same partner)
Tablet vs. phones:
- iOS: from the same tree, maintained by the same company
- Android: from different trees per device, within the same company; Samsung laptops and phones: different divisions, don't talk much
Aspect ratio:
- iOS: same on all devices (4x5) except iPhone 5 (5 was a bean-counting decision on screen cost and remonitization of Apps and content)
- Android: varies widely between devices
App store:
- iOS: centralized, controlled by an entity that benefits from uniform APIs and versions
- Android: split, usually one Google, one vendor, per version
App store content:
- iOS: shared by all devices
- Android: can't be shared by all devices; each App on a new device is potentially a new port
Productization:
- iOS: handled by the seller of the device, who runs the App store, and who enforces uniform versions and APIs
- Android: handled b
A lot of medical devices are built using Java.
First Google result: http://www.oracle.com/us/technologies/embedded/embedded-java-for-healthcare-433550.pdf
It's been used in medical devices since the late 90's, shortly after it was invented.
For those applications, Java is purpose built.
This PDF is Oracle's "Markitecture" -- it's how they want things to work. They have not certified and indemnified their embedded JVM for use in life support systems. Don't expect them to. Don't expect a device manufacturer to bear the costs of certifying both the JVM and their application specific code, as a combination, for that use. IT's not going to happen.
Yes, my Java ring is in a box in my workroom... I do not wear it every day and do Green Lantern-ish stuff with it, like Sun was predicting would happen when they gave them away at Java One.
S3, what used to be their flagship a month ago is still running 4.1.2.
This is an incredibly dumb argument.
(1) How does updating a phone you've already paid for to the latest OS sell more phones, if you don't need a new phone to get the latest OS?
(2) How does updating an old phone lock you into the carrier for another 18 months so that the carrier is willing to subsidize the cost, instead of you just letting your updated phone fall off contract, and then go pay-as-you-go, or contract with the cheapest carrier, which isn't the one that subsidized your phone?
(3) How do they monetize to pay the development costs, which might be better spent on newer hardware, since yours already works?
(4) How do they monetize to pay the FCC and other regulatory recertifications, since an SDR is defined as a combination of software and hardware, for certification purposes?
(5) How do they monetize to pay for the the carrier qual process, especially if you won't end up locked back into the carrier?
It's good money after bad, and what's actually pissing you off is that you don't get new software for your old phone, and YOU get to pay the monetization costs, even if they are a break-even, by having a carrier contract with termination fees so that these things get paid, even if you decide you don't like your carrier.
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway. What really sets languages apart is the tooling that's built up around them. The debuggers, the IDE, the profilers, etc. Also, the consistency and extent of the standard API plays a huge role in how useful a language is. I would rather use Brainfuck with an amazing tools and a rich API than use Java, Python, or Ruby with bad tools and an inconstent and incomplete API.
I think it would be very difficult to convince Terumo Cardiovascular Systems to build their next blood gas monitor system, or any of their medical devices, on a Java substrate. I think it would be difficult to convince Radiometer Inc. to base their next portable point of care immunoassay system on a Java substrate. I will go further: I doubt you could get any company working on life support systems of any type to trust Java enough to use it as a substrate.
Java is not suitable for a great number of applications, and, indeed, any language that uses a runtime system, and is either interpreted or JIT'ed, or not, is unsuitable for those applications.
For those applications, you need a language that compiles to ROMable machine code.
For applications like industrial control systems, both in manufacturing, and, again in life support, such as the control systems in nuclear facilities - or even coal-fired facilities, if they happen to have their output powering a pediatric ICU, any garbage collected language is unsuitable, since there is very little control, without infinite memory available, on when a GC will run. You can not implement hard real time in a GC'ed language.
For those applications, Java is unsuitable.
There are some languages suitable for those applications: assembly, C, Ada, FORTRAN, C++ (if you disable RTTI and certain aspects of polymorphism, and use an older version, rather than the current draft standard version). There are others, but they are infrequently enough practiced that they would be suspect, both in their mathematical provability, and in their ability to be audited for coding errors.
So No, any language is NOT as good as any other. Not even close.
This is a 50 billion dollar (or yen equivalent) public relations exercise. The government wants to look like it is actually doing something about an issue it has zero control over now.
The Japanese government doesn't want to admit the truth that these areas are going to remain uninhabitable for hundreds, if not, thousands of years - because it promised the Japanese people that they would be able to return to their homes. The technology doesn't exist to clean up all this contaminated land.
$50B will buy an awful lot of concrete. Concrete plains are rather habitable when you cover them with dirt.
I think it would be great to start equipping all motor vehicles with (well-designed, forwards-compatible) systems like this so that in 20-30 years when driverless cars are a viable option on the road, there's the infrastructure in place to support it.
You are aware that there is not a car manufactured after 1981 which does not have an Oxygen sensor, and therefore does not need reformulated gasoline with MTBE or, now, other additives, to keep it from polluting. That's a 33 year gap, and it still hasn't gotten all the older cars off the roads, and it hasn't gotten the older cars retrofit with Oxygen sensors. Instead we are still putting crap into the gasoline that has the sole effect of making cars manufactured prior to 1981 pollute less, while at the same time causing all cars, including those manufactured after 1981, get 10%-15% worse gas mileage, which requires more fuel to go the same distance, which causes them to pollute more.
Retroactive laws are disallowed, both in U.S. courts, and in English Common law for a reason: You can't make a prior act illegal, just as you can not make a firearm purchased under current law illegal in the future. See: http://en.wikipedia.org/wiki/Ex_post_facto_law
Forcing the USPS to maintain a fund for worker retirement up to 75 years from now is completely and totally unreasonable and serves only one purpose.
You're right, it serves one purpose. It subsidizes the health care costs for the rest of the federal government:
"Are you a new hire eligible for federal employee health benefits? Have you experienced a qualifying life event? Looking to switch FEHB plans? Federal and postal employees and annuitants can enroll in an MHBP health plan designed to fit their health needs."
MHBP - Mail Handlers Benefit Plan: http://www.mhbp.com/
The grandparent was talking about the USPS, which has been ruined by requiring pension allocations 75 years in advance, and yes, this was entirely a Republican venture.
Except, you know, the part about the Democrats who also voted for it, and the Democratic president signing the bill into law.
If you don't want to drive miles to a mailbox cluster, the USPS doesn't want to drive those miles to deliver a bulk mail envelope that only earned them 25 cents.
So raise bulk mail prices $0.01 per unit; they delivered 84.7 billion units last year http://about.usps.com/publications/annual-report-comprehensive-statement-2011/html/ar2011_financial_2.htm ... not including 7 billion periodicals. The post office gets their 26 cents instead of 25 cents, and congress gets to keep the excellent Mail Handlers Health Insurance which the post office subsidizes for them, since it's basically what every GSA employee gets, despite the name. The postal carriers get to keep their rather inflated pensions. Everyone is happy.
The big question: will I be able to put something else on there? Like what OpenWRT did for routers?
Not if you want working Netflix, any of the major television networks, or a DVD player.
You should also be aware that seat-back displays for "infotainment" are OK, but using the in-dask display is only permitted in most states if the vehicle is stopped, in park, and the engine is off. Some states don't allow it even then, although there are plenty of after-market hacks to override this, since they sell exactly the same systems in countries which haven't made it illegal (yet).
Those with the money control the future, good or bad.
Yes, I remember now. It was from a book at my local Carnegie Free Library, funded by wealthy philanthropist Andrew Carnegie:
http://en.wikipedia.org/wiki/Carnegie_library
Or it could have been at Stanford, which was funded by railroad tycoon Leland Stanford:
https://en.wikipedia.org/wiki/Stanford_University
For some reason people believe governments make wiser decisions than wealthy individuals, but most of the long term projects happening in the world these days, the kind of things that matter to human survival as a species, and not just "the right party" winning the next short term election, are all being funded by wealthy individuals.
Or to put it another way: focus is no substitute for vision. Government bureaucrats rare have vision.
my robots.txt contains one item which doesn't exist.
If you try to access that item your IP is added to the firewall drop list. (until the next reboot)
I don't even have much hosted, just some pictures I don't want to give to flikr.
On the other hand, you've just documented your disallowed content, so I actually don't need to access the content itself in order to index it -- I only need to know to download your robots.txt and shove it into my index.
As the service grows (assuming it does), then I can have a fleet of non-contiguous IP addresses which I use as "content verifiers" for the robots.txt contents (e.g. directories vs. files), and I can "burn" them against your site for content verification.
The arms race escalation is pretty obvious, and contains some interesting twists, but it's basically an arms race, and you will be as effective against it as the battle against SPAM has been so far (there are strategies there, too, but they involve forcing hosting of email bodies by the email sender and similar techniques).
So using the same tripwire technique that the phone companies used to use against wardialers (like I used to be, before it was a criminal offense, and then still, before I turned 18) won't prevent the eventual success.
Personally, I would never do this, since the stuff people think is very private, and then feed to robots in the robots.txt anyway, is generally not very interesting in the first place.
This is a joke, right? I mean the obvious joke is right there, they can't have written the obvious joke, right?
"NSA gives suspect the third degree"
They hated it because it laid the blame squarely where it belonged, at the foot of a very difficult problem to resolve, unless you made automatic local replicas of LDAP subtrees.
A shortsighted and arbitrary kernel limitation does not really count as the fault of the downstream devs who get to suffer for it. As you point out, your "solution" actively encouraged your devs to make a completely wasteful userspace cache of something the kernel should just provide transparently; since you already know this solution, and apparently had access to the kernel code - Why didn''t you either fix the limitation, or if not possible, just build the damned cache yourself and serve high-latency requests from it, rather than getting into a blame-game with people who (reasonably) just expect LDAP to work as advertised?
Because, contrary to popular belief, there is not an infinite amount of available wired memory in the kernel for doing negative caching, and even in the positive caching case, the memory goes quickly. Also, contrary to popular believe, putting everything in the kernel doesn't make it magically faster. Also, POSIX mandates a finite number of groups, and those groups must be attached to each credential, and all internal operations pass around credential references inherited from the thread for the current call context.
As an example, if you are talking a file server serving users at Genentech (someone who use Mac OS X based file servers with internal security partitions requiring lots of group containers), then you are talking about 10,000 users with mostly non-overlapping combinatoric group membership in 200+ groups each, and each of these requires a UUID, and for Windows interoperability, a GUID, be carried around with them. Add to that negative caching (with the possibility of DOS attacks, or innocent misconfigurations, ballooning the negative cache out of control), and the fact that AppleDirectory supports a group being a member of a group, and you can quickly chew through Gigs of credential cache.
The only sane place to put all this crap is in user space.
The team responsible for doing the user space part was the DirectoryServices daemon team. If I had been allowed to do the cache, I would have. It's not like I didn't have a lot to do with the genesis of the OpenLDAP project, which was the basis for AppleDirectory anyway.
--
And the reason for the local replica is disconnected operation. What happens if you are connected to the corporate network, close your laptop, and head home. On the bus ride home, you open up your laptop to access a file, it has an ACL on it, the ACL requires knowing if you are in a member of the necessary group to access the file, the isGroupMember() call goes out to the kernel thread, the kernel thread sends it to DS in user space because, hey, hell, it doesn't know -- and DS in user space doesn't have it cached.
So DS in user space tries to make the request to the central DS(es) to which it is bound. Only you *aren't* on the corporate network any more, are you, you're on a freaking bus, and you have no local replica.
To make matters worse, the interface on which the connection was made is known to be down, but, hew, Mac OS X networking didn't shut down the socket. And it didn't shut down the socket because most people are on WiFi these days, so there are transient connectivity failures all the time, and it can't tell the difference between a transient WiFi connectivity failure and a more-or-less permanent one, so your request is sitting on the upstream socket Send-Q, not getting answered by the upstream server.
And it was sent to the upstream server in the first damn place because you didn't make a local replica of the user credential for your active local users when you had the chance and connectivity to be able to do so. So the open(2) system call in a user space app is blocked on a cred check, which is blocked on a group membership resolution call, which is blocked on the user spa
(as mentioned in the article)
1: We already know it's down
Then put it on the freaking dashboard for the network service outages so we know not to bother you. If you really don't want to be bothered, put up an "Estimated time to resolution, given past history"/"Estimated time to resolution for [characterized as problem X]", or you're going to get the "we know you know it's down; when will the f---ing thing be back up?" calls anyway.
2: If we don't know it's down, it's probably not down
Something is wrong. Maybe a switch under your control, not mine, is partitioning my part of the network, or maybe the new security you put on MAC address per port and didn't tell us about, or told us about but not in a meaningful way, has made it so we can no longer plug in both our laptops to the same switch port. How about something on the dashboard to let us know how many unresolved issues there outstanding at any given time, or over a period of time as a graph. If there is a spike on the graph, there's something you own that'd not sufficiently monitored, and it's still your problem.
3: We will ping and test several times before digging into the problem
You should be doing short interval periodic monitoring at all times. Even if this part of the dashboard isn't visible to us [users], it should be visible to you, and variances above a certain amount vs. a weighted moving average of expected RTT, for instance, should be flagged.
One of the things the DS developers at Apple hated most, which I implemented, was a kernel weighted moving average recorder on user space DirectoryServices response delay calculator. When making external group resolution requests to user space from kernel space (the kernel credential could only hold 16 groups, and a user could be a member of N, which in practice at Apple, ran to several dozens), the resolution task pops up to user space. If user space takes "too long", the kernel declares it non-authoritative until it re-authorizes itself as authoritative. It flagged extra long latencies in DirectoryServices responding to requests as kernel log messages.
They hated it because it laid the blame squarely where it belonged, at the foot of a very difficult problem to resolve, unless you made automatic local replicas of LDAP subtrees.
If some connection is bouncing around like a handball in a box on a paint shaker, perhaps it's time to disconnect that connection and flag it for field service.
4: Believe it or not, we've tried turning it off and back on again
Yeah, this spackles over a herd of issues that should actually be resolved, like packet storms causing the switch to partition off a port as being "too noisy"; adding more spackle each time it happens ain't going to make it stop happening. Maybe (probably) this one is not your fault, but it'd be nice if the person whose fault it is could get notification of the problem of which you are aware and they are not. Be a f---ing team player, folks.
5: During an outage, we're not just staring at the screen -- we're following a path in our heads
Unexpected dead ends can be found with time domain reflectometers. Try documenting, then automating, the steps you are taking so instead of staring at routing tables, you can be over at the fooseball table, or back home in bed.
6: We calculate subnet masks and CIDR as easily as breathing
So basically, you "grok" radix trees? And?
7: We do not tolerate bugs; they are of the devil
Funny: #4 is explicitly designed to tolerate bugs without fixing them.
Let me give you an explicit corollary, using the terminology from the article: there is no such thing as a white whale. Yes, it might be more important from a business perspective to be back up than it is to track down the specific root cause of the bug, but pretending it isn't