Caching proxies are old hat. Things like squid have existed pretty much the entire lifespan of the web. Keeping things close to your servers means you don't have the inherent delay of pulling things from a remote server, regardless of how fast amazon makes things.
Additionally, not keeping all your eggs in Amazon's basket means you're not SOL when they have a datacenter hosting all your content go down. It also means that if and when a service that better fits your needs comes along, you are more readily able to migrate without problems.
Finally, site reliability is not something that takes a team the size of Amazon's. A lot of the things that are required for availability on AWS -- redundant systems providing services, standbys, etc -- are things that sysadmins were doing before AWS was extant. AWS' biggest gift to reliability is that its instances are less stable than most dedicated servers; you're taught from day one not to rely on a single server, so you build it right the first time.
So no, it's not hubris. It's calculating price/performance, it's applying things you're probably already doing to a new problem, and figuring out what the best solution really is, which rarely involves just throwing money at Amazon.
It lets them pretend that ops isn't a skillset you need people to specialize in. Just throw more devs and servers at the problem instead of building a good infrastructure.
It's a rather huge effort by a fairly small group of people not backed by any corporations [1]. They are aiming for bug-for-bug compatibility with Windows, including the driver model. One of the reasons for it taking so long, though, was it was discovered that a previous developer had written code garnered from disassembling pieces of the Windows kernel. Thus they had to perform a rather long process of auditing all of the code that had already been written to ensure that no Microsoft code was in the codebase.
I take photos miles from where there's cell signal. I write code on the bus while heading to doctors appointments. The web is about as far from a panacea as you can get. It's slow, it's bloated, falls apart when you don't have a connection, useful applications die when the company dies. Were some of the midi devices I use for music "web-based" they'd have probably become doorstops decades ago. A web-based IDE would be horrible for trying to develop code with an intermittent connection. The web is not a good time.
We don't need a universal OS. I'd go as far to say that a universal OS is bad. A universal OS leaves no place for experimentation, no place for different UI concepts, no place for people to customize things to the way they want. Would you really want every shirt to look the same? Every refrigerator, every door? Style is important.
Part of the cost is improving the peninsula rail corridor for full grade separation, along with the suicide prevention improvements Caltrain is already performing on the corridor. When it's built, there should be a lot fewer places for suicide and a lot tighter control.
The HSR depots are going to be downtown San Francisco, which is a lot more convenient than the pain in the arse SFO is, and LA Union Station, which is rapidly becoming a hub for rail lines going to Orange County, Santa Monica, Pomona, the South Bay, East LA, etc. LA Union station is rapidly becoming a rather good transit hub.
Both can, should, and are being done. The California Water Project is rather adequately funded. The Oroville Dam problem is due to a pretty unprecedented winter, not a lack of maintenance. The emergency overflow seems to have held, at least for now, so with hope they can put in a fix for the spillway.
Those are covered under other bond measures. LA has a multi-generation plan [1] for building out several new rail lines, busways, etc. It's harder to find an overarching document for the Bay Area because there are too damn many counties and transit agencies around here, but there are lots of projects -- BART to San Jose, Caltrain electrification, new rail lines and improved lines in SF, rebuilding the Dumbarton Rail Bridge -- that are in various stages of planning and construction.
Infrastructure is expensive. For example, the project to upgrade state route 99 in California, which parallels the High Speed Rail tracks for about 130 miles, to Interstate standards was projected to cost $22 billion ten years ago [1]. A lot of the huge costs are from the infrastructure debt of refusing to pay for a rail network, and for destroying a lot of the network that was in place. The HSR system will give a lot of benefits for a substantial amount of the state in terms of giving a modern transit backbone.
Windows is pretty inexpensive, and if you want something supported for more than a year or two, the options do tend to be somewhat costly. RedHat, for example, is $50/year for the equivalent of Windows Update. There are also a number of other advantages for windows in terms of things like remote management which RedHat doesn't have equivalents for.
You can have both. Postgres has foreign data wrappers, with Redis as a first class citizen. So, you can push your data to Postgres, and have it trigger to publish the updates. Databases have a pretty big toolset to make your life easier when you need to manipulate your data.
The Linux "solution" would be to yell at the driver maker to contort their driver to fit the Linux model and put it in tree. A vendor that refused would need to have their driver installer manually blacklist the kernel driver, and get support calls whenever the kernel's updated because the abi breaks again.
Much more than that. For example, both audio and video drivers had massive rewrites and rebuilds. Video drivers received a lot of tweaks for DirectX 10. More importantly, MS pushed the entire audio stack to use the User-Mode Driver Framework [1], which resulted in a lot of changes in how audio drivers access the underlying hardware.
Some of us have more significant medical expenses than others. My prescription medications alone would be $2k/month if I had to pay it out of pocket, and that amount's pretty set in stone. The alternatives, which I've tried, don't work for me, or make symptoms worse. Shopping around wouldn't do anything for me.
Or we could start funding medical research through our system of universities and the like. We have immense public and non-profit institutions that can take over. Maybe we'll even be able to see more benefit in treatment of rare and neglected diseases that way.
It also means that a large number of people could actually afford medication, doctors, etc. I have friends who can't afford going to the doctor, can't afford medication, so go without. Their quality of life would greatly improve by them being able to get into the system.
I would argue that having Part D coverage handled directly by medicare, with the power to negotiate prices, would have a positive effect on prices for Part B medication as well. By having Medicare only provide certain medications, it makes it more difficult to bring proper purchasing power. It would also make it a lot easier on people who are on disability to manage their health. I'm on disability, and when I have a problem with a prescription, it's an absolute mess trying to figure out if I need to contact Medicare, or if I need to contact my Part D provider. To make things more complicated, there are times I need to contact Medi-Cal, because I have a certain amount of my coverage handled under Medicaid.
By which metric is Linux more advanced than FreeBSD? Companies like Netflix use FreeBSD because its networking stack blows Linux out of the water. Further, how about Xorg, Apache, BIND, Nginx, etc? Significant amounts of userland tools and applications are written under more liberal licenses.
And when EC2 falls over, like it tends to do a few times a year? Hosts fall over, stuff dies. Something the scale of Snap, you're going to be doing setups that look a lot like cloud anyways. Bringing new systems up either by cloning a disk or through using PXE, setting up clustering, possibly by using the stuff they're already using, etc. You're going to be writing a lot of the same fallover code if you're running on someone else's hardware, so why rent?
When dealing with embedded stuff, you don't always have the luxury of code at first sight. Sometimes you have to write ugly code like this code does, sometimes you have to roll your own print statements because using printf pulls in a few k of code, sometimes you have to use a uart running at 600 baud to get a 60 hz timer. Of course, when you start going down the path of interesting, it's always best to write lots of good documentation to go with the cleverness, so people understand what's going on.
The author is coming from the embedded world, where saving time in an important loop can determine whether or not your code can operate in the required time windows. Keep in mind that there are a lot of micros out there that are being used for new projects that have memory amounts in the hundreds or even tens of bytes. When you start getting into those areas, sometimes you have to cheat to get things working.
There's all kinds of stuff entombed in cities, just waiting to be discovered. First thing this reminded me of was the Original Spanish Kitchen [1], which was a restaurant, also in LA, which closed one day in 1961 and spent the next 44 years frozen in time. The fixtures, utensils, coffee maker, everything intact, waiting for an opening that never came. All sorts of caches created when someone just couldn't do it anymore, or when plans fall apart.
However, ARMv8 also increased the power of the SIMD portion of the chip, going from a 64 bit wide set of registers to one that's 128 bits wide. So SIMD-heavy code will see a decent speedup because you can process more data per clock.
Yep. If it's just 32->64 there may even be a slow down as you need to pull bigger things through the various busses. However, Armv8 also brought a huge improvement to the instruction set, so recompiling with the proper optimizations will bring performance increases in a lot of programs.
It uses a lock-free method of ensuring that there aren't segfaults. When it needs to move a variable because it's gotten too big, it copies it to the new location and sets the pointer accordingly with the old location flagged as old. The old variable isn't freed, so there are no dangling pointers, with the downside of memory usage being increased some.
Or all the other devs are thinking, "woot, less hours of pager duty." Having people work off shifts can be rather beneficial if you stagger things properly. Scheduling like that, you hold meetings right after lunch, and that's about it. Everything else works just the same. Long as the scheduling is consistent, then having people slightly off the normal schedule works just fine.