This looks a lot like 33mail (https://33mail.com/) which I've been using pretty happily for 4-5 years now (and paying I think $10-15 a year for, so a lot less than this on a per month basis, but they're not strictly unlimited)
With no personal knowledge here my guess is that's just marketing speak, and the real reason it was removed is... well... Slack is an enterprise product and a lot of enterprises don't want or need this, and the idea of a vector for remote control even being possible just blocks a lot of sales and complicates security audits in BigCo. I'm sure they offered a way to disable it but the feature was still in there so... just my guess though.
Seconded... it's early days but it's nice to finally see a good successor to ScreenHero, which was never fully integrated into slack as well as it worked before aquisition, and with this change it's sort of like it's dead now. They don't have multiple cursor support yet for instance, but they do have a nice system that avoids some of the problems with accidentally both sharing simultaneous control of the same cursor so that you have to click to take over the cursor. Similarly, switching seamlessely back and forth who's sharing and/or which screen you're sharing has been really nice.
Hah, sorry, also posted a similar response in parallel but on parent! I had to google though, I couldn't remember if maybe Elixir used Core Erlang, I'm still a little fuzzy on where that's used and if any important relation to Erlang Abstract Form
I like the idea, but I think most users never would/could author their own UI's, and many who could would only want to a small percentage of the time.... but maybe your idea could work if there was essentially an API marketplace AND a UI marketplace, and services competed on both of them seperately... v1 from a service would (probably) always offer both to be usable but if it published some contract for how they talk to each other so they were decoupled and anyone could author a new UI (and, I suppose if it were a marketplace, sell it, but maybe given constraints only selling the API is realistic and UI is more FOSS/enthusiast driven/fork based?) and make it discoverable as an alternative to try out.
Reminds me of a recent comment I saw but can't find by Douglas Lenat (of Cyc[1] fame, also relevant here) about how all the work on deep learning was great but now we need to marry the two, much like the ideas about how the "right brain" and "left brain" or system 1 and system 2 or something work together and work differently but we couldn't very well function as humans without both.
I'm wondering about applications of this to robotics? Like, could this replace any of the needs/uses for force-feedback sensors in robotics, and/or for all the cool stuff Dexter[1] is doing to precisely locate it's arm in space with solutions less coupled to the hardware specifics/manufacturing? Could also maybe be really cool way to train robots on really precise behaviors if they can copy with really fine precision exactly what someone does with their hands and fingers, maybe can generalize/learn from a few simple demonstrations really complex interactions if the 3d fidelity is good enough? Dunno, definitely lots of other concerns/questions but robotics and VR/AR stuff come to mind for me and weren't mentioned at all in the article or any of the other comments, curious if any reasons I'm missing why not relevant there.
I don't know why this isn't getting more attention/comment (someone else independently posted it looked similar below with another link to your domain) but here's the one I found from your profile link for comparison http://tympanus.net/Development/RainEffect/
I don't know the technical/methematical explanation for this, or if one is really needed (though it seems like a valid question to pose), but it is noteworthy that black holes and the big bang are the original "singularity", and that there are several related theories in which they are directly related, notably Big Bounce[1] and my favorite (which I learned of from Lee Smolin's amazing Life of The Cosmos[3]) Cosmological Natural Selection[2]. There's also a variant of Cosmological Natural Selectionm CNS-I[4], but that one possibles borders on religious, though it's possible it could be falsifiable/supportable some day by modeling.
I suppose it's even somewhat plausible that the answer to your question, in combinations with the other theories, are "all true", and that for various reasons or models the first N big bangs did result in immediate/fast collapse back to another big crunch/black hole, and that each subsequent crunch/black hole created another universe, until there was a universe that survived long enough to create several black holes, and so on and so on...
Also commented below but the idea here was not actually mutation but safe and dangerous versions of methods... E.g, below insert is mentioned and it has no safer version so it has no ! version... Elixir adopted this convention from Ruby also, but there is never any mutation in Elixir of course as BEAM doesn't allow it.
Didn't know whether to respond here or above to parent, but ! In stdlib of Ruby does not indicate mutation but "dangerous version"... Often the same thing but I believe all methods in std lib with a bang also have a noo-bang version, which usually does not mutate receiver, but could also be, for example, File.read vs File.read!... I forget if Ruby has those but Elixir does and they indicate there that one returns an error or ok prefixed tuple but the dangerous version just raises an error if the file isn't present for example.
Do you mean ReplayTV? I owned a Tivo at some point but replayTV was great because it auto-detected ads and had an option (or default behavior?) of skipping them automatically. Tivo you had to manually push 30 second skip 6 times.
For the specific use case in question, what I've been doing for years is not just hashing the data, but hashing an internal secret AND the data. The secret isn't stored in the database anywhere (usually an env var but could be a secret in vault or other outside config), so our hashes are deterministic (and don't need a seperate salt for each one), but our hashes will never cooincide with another system's hashes. I didn't see this mentioned in article but didn't read thoroughly, I thought this was a pretty good compromise but curious for other perspectives/forget if I read this technique somewhere or just made it up as a reasonably good safeguard.
would it, or would it leave it up to the article publisher, but say IF AND WHEN you issue a retraction/correction, here is the way you must do it? I don't know that I agree with the proposal per se, but I think this specific criticism is misguided/wrong.
I added it as a feature to my package kubert[0] but that needs a little love/work I haven't had time or motivation to do recently, and there's upstream work in Kubeclient needed to make it work with GKE (when I started work was doing kube on AWS but since moved to GKE, and helm instead of ky for templating/deploy). But I really wish there was a fairly cnanonical tool a bit like this but working with helm and more or less adaptable or most kube deployments, maybe via a few adapters or something. If anyone knows of one, or wants to help to turn kubert into that, let me know.
I have tests that do this :-) Well, not for an order, but with a sort-of-monolith sort-of-microservice system with email, dashboards, reporting, a JS SPA and a lambda/flask/zappa based API thats decoupled from the admin app, we want one live, round trip of all the data flowing and actions along the way... we can point it at staging, production, and I think dev (via docker-compose, but that part wasn't done last I worked on this). It relies on some special hard-coded/pre-setup accounts and stuff, but they're real, just marked as test related in their names so everyone knows not to touch them.
Depending on what you mean by "in a decentralized fashion" the two aren't mutually exclusive. Many bitcoin clients, like Electrum, are distributed, non-centralized, but rely on the existence of SOME copies of the entire blockchain somewhere, but only verify back a fixed configurable number of blocks themselves when sending and receiving money. I suppose there's a minor degree of "trust" involved there, but I think the number of full nodes talked to is probably also configurable, so it would be pretty hard to fool the client, I think equally hard or harder than other kinds of double spend attacks.
I submitted this mostly hoping to see if there were already any comments on it, but I guess maybe now there will be if anyone has thoughts! I'd never heard of Dalmatiner before, and they admit bias because authors maintain, but they seem somewhat balanced in that I notice their spreadsheet here[1] acknowledges a fair number of advantages InfluxDB has over them.
I find it somewhat hilarious to list Neuromancer as "Hard SF", though I liked it a lot... but Gibson has never even used a computer when he wrote it! Which explained so much about it's weirdness to me...
It's half novel, half related series of 9 short stories, but Accelerando is great. The Martian by Andy Weir (movie based on it) was quite good. Daemon I think also qualifies, though it's SF dressed up as a thriller. Oh, Blood Music by Greg Bear probably counts? Except maybe the ending?
Tempted to mention The Diamond Age, but not sure that qualifies as "Hard", though closer than some other Stephenson maybe...
From thescribe's parallel comment it sounds like you're describing doctests which is a built in feature in Elixir, and I believe in Python also. Many languages have doctest libraries available, though not many support it being part of canonical documentation... I've been meaning to try the ruby-rspec doctest library https://github.com/doctest/doctest-rspec though there's several others besides that one
Erlang/OTP 20 came out June 21[0], so about 5 weeks ago.
Makes sense though, Eliir 1.5 was waiting for final release of OTP, and Phoenix was waiting on final release of Elixir, but they'd all had very stable preview releases for a while, so it wasn't a ton of work left on any of them, just finalizing and testing I imagine. I'm super excited to get my side project[1] upgraded to 1.5 and see the new dev conveniences!
This looks awesome! It's also a kind of perfect companion piece to an Elixir/Phoenix project a friend of mine, Travis, did over at Stride[1].
I also have my own social-good oriented learning-phoenix/ecto project[2], OpenPantry, which I started some months ago after I'd learned Elixir pretty well and done a little Phoenix micro-service, but still hadn't done anything full stack or involving Ecto or Channels... We're actively looking for help building out the feature set and it's for a great cause if anyone's interested, helping those with food-insecurity to get food more easily and with more choice than many pantry programs are currently able to provide!