I used to work for a startup that quickly grew to become one of the biggest Lambda users in my country (according to AWS). The entire business was serverless, not just Lambda but backend DynamoDB, APIGW, Cloudfront, etc. There was maybe 2 EC2 instances in the whole company.
Having seen what that model of development can do from an operational/security/agility/scalability/efficiency perspective, I think the comments on HN about serverless saying "it's just CGI" or that they could do something similar without vendor lockin are honestly laughably ignorant. If you haven't messed with Zappa (https://github.com/Miserlou/Zappa) or Serverless Framework (https://www.serverless.com/) at least a little you are missing out.
Yeah, seems dumb "economist" thinking. The idea that "if someone gives up and walks away, everyone behind them benefits" is a absurd on two fronts.The stall owner clearly doesn't benefit from a lost sale. Mulled wine, mince pies and hot chocolate are not fungible. Maybe you are allergic to chocolate. Maybe mince pies make you gag.
Also, optimising for queue length only makes any sense in the described scenario if all stalls are owned by a single entity.
I'm not even going to touch the "only add something to your todo list if you are going to do it immediately" stupidity.
You shouldn't pass unescaped/untrusted input into a subshell but your suggestion doesn't solve for every case. It protects against ";" but not path traversal with "../../../../../foo/bar".
This issue with the backups happened to me as well. I managed to solve it by disabling iCloud Backup which deletes all the backups, then re-enabling it. I think essentially what happens is some stuff gets backed up, and even if you delete that stuff from your phone it's still retained in backups for some period of time.
It's not the inflation component which is killing real personal income (ex transfer receipts)...it's the bad modelling which is used to generate current estimates that are subject to revisions.
The revisions show the real picture, and it is not pretty.
When I had to do some pf work, googling around rendered this project which uses pf to provide network segmentation for jails and edge firewalling. Was quite useful learning reference:
I grew up using Debian and later Ubuntu, longer than 10 years on those distros as a kid and into my career as a sysadmin/operations person. Ubuntu LTS was my main workhorse form about 10.04 through to ~14.04.3.
Late 2015 I decided I wanted a "Chromebook" style user experience where I could have a repeatable build of the base OS that could be thrown away plus a backup system based around duplicity to restore my homedir. I had used preseed to deploy large fleets of Ubuntu boxes at work so it was a natural option.
But I decided a few things: Firstly, I was sick of LTS 3.x kernel. Secondly, if 16.04 and all other distros were adopting systemd I may as well go to the source and use a RH based distro. Finally, that preseed wasn't as good as Kickstart used in RH based distros.
So I came up with https://github.com/sinner-/kickstart-fedora-workstation to provide repeatable builds of Fedora the way that I like it. I've been happily using it since then (across 2 versions of Fedora and a hard drive failure)! The .ks file will be updated for F26 this weekend as it just went GA today.
This looks SO cool! Kind of like Erlang but at a different level, so you can model both inter-node systems (like Erlang) but also intra-node systems (like USB3 drivers)!
As someone who has been thinking a lot recently about SPARK/Ada and "free" formal verification, can anyone tell me how this language compares on that front? If I write a P program, do I get the ability to "prove" its correctness?
I was a team lead for an IBM operations team for 6 months in 2016. Aside from my first two days, I worked from home the entire duration of the role, based in Sydney. Most of my staff were in China, with handoff to the next shift in Europe (who were all remote staff as well).
I am a big fan of grsec, RBAC and sandboxing stuff. But let's be real here people! Those are good features on servers where there isn't a giant security black-hole called X, where any local exploit of the app can turn it into a compromise of the entire GUI system.
Look at the hoops that adversary resistance focused distros like SubgraphOS have to jump through just to mitigate the giant attack surface that X opens.
Until Wayland becomes the usable default standard, "Linux Desktop Security" is an anachronism.
> I don't think, or get the impression, that this would be used for full-system virtualization. It seems to be more targeted toward an AWS Lambda sort of usage pattern; a micro-VM that spins up to serve one API request, or to act as a long-running tiny daemon to do some housekeeping task. It looks like a fancy fork(), to me, rather than a competitor to Docker or LXC (and especially not KVM or Xen, which can run a whole Linux kernel in the VM).
Almost. With ZeroCloud (OpenStack Swift + ZeroVM + appropriate middleware), you should imagine Lambda+S3 in the same service! Your "function" executes much, much closer to the location of the data, it doesn't require "shipping" from the storage service to the compute service and back again. You can take in an object, perform a transform (e.g. text search, encryption, transcode, etc) and store the result as a new object.
If you think about it, it's kind of the future of large scale computing, immutable dataset + immutable compute, that can horizontally scale to huge numbers of nodes.
I have been following ZeroVM since it's inception and often go to the website and stare longingly at my screen thinking of amazing things it could do (when coupled with OpenStack Swift to make "ZeroCloud"). If you look at my HN comment history you can see multiple articles about "serverless" where I tried to tell people about ZeroVM.
But they got bought by Rackspace (who originally open sourced Swift) in late 2013, and then their github account activity dropped to 0 by early 2015. Rackspace has probably one of the worlds largest Swift deployments, so maybe one day they will do some cool things with ZeroVM ala ZeroCloud but for now the forward movement of the project seems dead or at least proprietary :(
Other interesting implementations of the same concept include Joyents Manta, which is also open source and actually probably more flexible than ZeroCloud (you can SSH into your container).
It doesn't matter whether you use WhatsApp, Facebook Messenger "Secret Conversations" or even Signal app (or PGP or any public key based communications system)!.
If you are not verifying key fingerprints out of band, then you are potentially vulnerable to a malicious server MITMing new sessions.
If you want secure end-to-end messaging, verify keys out of band, do not solely trust a 3rd party for key exchange!
Confirm, it's just a DNS block like previous attempts by the AU Gov to block stuff.
If you're on a Apple device you probably need to use VPN to specify an alternate DNS and either route your traffic through that VPN as well or just use it for DNS.
> First off, the replication thing. It is true that ES, C*, and Mongo replicate within their cluster mostly automatically. However, this is not without cost. It takes non-trivial amounts of network capacity, disk I/O, and CPU cycles to migrate shards from a failed (or downed) node to a newly stood-up node. Often, many GBs must be moved and for something like ES, where shard replicas reside on many different nodes, that means much of your cluster feels the impact of this. The cluster can heal, but healing isn't easy.
I'm talking about replication, not sharding though. If the data is actually lost then you have to bear the penalty of re-replicating it to match your replica count regardless, there's no magic wand here to do with "persistent storage". If the data isn't actually lost (e.g. due to CoreOS automagic reboots) then you absolutely should be putting the cluster into maintenance mode until the reboots are complete.
> As for Cinder, it's reliant on OpenStack APIs which (at least as of Juno) are reliant on things like RabbitMQ. We've seen a number of OpenStack failures due to RabbitMQ partitioning and split-brained scenarios.
Still pretty confused when you mention OpenStack. Cinder doesn't rely on OpenStack APIs per se, it provides an OpenStack API (for block storage). RabbitMQ clustering has longstanding issues with partitions which are mentioned explicitly in the documentation, nothing to do with OpenStack, everything to do with Erlang MNESIA DB. Any decent OpenStack team has learned by now to use singleton RabbitMQs with a master/slave configuration loadbalancer (i.e. haproxy) in front.
> We're also back to the disk-on-network problem again: SCSI backplane ---ethernet---> client will never be as fast as local disk.
Right. But wasn't the comment about persistent storage? You're never going to have persistent storage in your k8s cluster that magically avoids that problem, so not really sure what the point is here.