devrandomguy

We'll trade you Alberta for the West Coast. I know, you're probably telling yourself "This is a terrible deal! Cali has a bigger population and economy than all of Canada!" But just remember, we helped you score Alaska for dirt cheap, so you owe us one.

More importantly, could Docker be ported to WASM? Because then I could just send the server to the client. Send the whole cluster, run it all in a single threaded browser process. Make the client part of the cloud, sharing in all of the cloudly comforts. /jk

Plot twist: Commercial jails suddenly lose their funding, but a billionaire's family buys them all up in the nick of time. Only one inmate is lost in the confusion; his lawyers claim that he may also be a victim of identity theft.

Yeah, implementing a Vault client in the browser is just asking for trouble. Currently, I am copy-pasting into the browser, which has two obvious vulnerabilities: the clipboard, which is accessible to everything, and the login page, which could be running an XSS exploit.

Perhaps we could eliminate both problems, by handling authentication outside of the browser, and then injecting an auth cookie into a new browser tab?

  1. `curl site.com/login` to get the login form as HTML
  2. Extract the form submission URL and the name of the user/pass fields
  3. Pipe a key from Vault, to a URL encoded HTTPS POST request (curl again)
  4. Receive the resulting session cookie and the login-success URL from the login response
  5. Insert or replace this cookie into Firefox's jar
  6. Open a new browser tab to the login-success URL

This way, the browser never sees the password, and the clipboard never holds it. The session cookie is still just as vulnerable as ever, but is of a lower value, assuming that it alone does not grant the ability to change the user's password or PW recovery email address. The entire sequence could be scripted into an `authenticate my-user@site.com` command, which would depend on a connected Vault client (or some other backend scheme). I have no idea if this would work on mobile operating systems, it might not be possible to write to the FF cookie jar from another app.

On a tangent, has anyone tried using Vault as a personal keyring, rather than using a cloud based password manager? In particular, how much would I need to trust each device that runs a Vault instance, if I was concerned mainly about malware running alongside it?

Right now, I have everything in Keepass, and no good way to synchronize that between devices. Merging key repos is a royal pain, but mainly, I don't like the idea of trusting everything to an organization that I can't hold accountable. Running my own service on a generic tiny EC2 cluster feels like an improvement, although I would still worry a little about the virtual neighbors.

This reminds me of an incident report I saw back when I used to work in a warehouse. A forklift driver raised the boom too far, and smashed it into a high power lamp. He immediately let go of the controls, and decided to get away from the forklift, rather than lower the boom, concerned that the metal levers might electrocute him. As soon as he stepped on the ground, he completed the circuit that was preciously blocked by the rubber tires, and paralyzed himself from the waist down.

The report recommended jumping clear, and then using this hopping escape strategy. It did not recommend or countermand moving the vehicle to break a potential circuit; I guess that situation is too complicated for a blanket policy.

Actually, this is a real issue. For one, there is the Wayback Machine, which could very well see increased usage and mindshare as legally mandated content takedowns increase. For another, if, say, Facebook wanted to harvest data from this network to create shadow profiles and flesh out missing patterns in their analytics, then they could easily follow everything, keep the raw data/content internal, and never develop the ability to retroactively un-analyze that data when a delete request comes in.

+1 for keeping the [A]GPL. As I understand it, the CRUD service that backs this would be separate software, which only communicates with this editor through an API, so it would not be affected by ORY's license.

If ORY was a full stack content editing service, rather than just a client with a demo server, then you could still run it unmodified, making it easy to share the source (just link to the official repo). Your other services could either operate on the data being saved by ORY-service, or communicate with it via an HTTP API (whose implementation would be an open component of the ORY-service). But once again, your own software would not fall under the AGPL, because they do not extend, or trivially wrap, ORY.

The only way an AGPL license would force a user of ORY to share their own code, would be if they forked ORY and extended its own codebase, or wrapped it in a trivial adaptor for some framework or platform, e.g. a Wordpress plugin.

IANAL, and the AGPL is a long read, but I do feel like I understood it, and could use this alongside closed-source services.

Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.

So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features of decentralization. Even providing that verb seems kind of deceptive to me; it implies that content that enters the network, could conceivably be purged, which will affect how people use the network. Perhaps DISOWN would be a more accurate verb, especially if it would only be accepted from the original owner.

Or someone starts up a city-wide drone delivery service for brick & mortar retailers. It could also offer a huge safety improvement for herb & powder retailers.

SQL is familiar, but it is not simple. The vocabulary is large, and inconsistent between implementations. It is hard to predict the performance of a complex query, without resorting to rules of thumb. Understanding EXPLAIN ... PLAN requires a fairly deep comp sci background, and familiarity with a variety of data structures that are rarely used directly by programmers.

Contrast that with a system of map-filter-reduce pipelines over an append-only data set, like a classic CouchDB. A reasonable pipeline can be composed by a junior dev, just by repeatedly asking "What do I want this report to summarize? What information do I need to collect or reject, for that summary? How can I transform the shape of the information that is currently in front of me, into the input that I wanted when I planned the high-level end result?" And, if they need help with that last part, then at least they are asking for help with a small subset of the problem, instead of "Something is wrong in this forest of queries, can you take a look at it with me?" Or, "I need to add a column, may I ALTER TABLE?" They can even prototype the whole thing on an array in Javascript, if they are more comfortable there.

SQL can be a beautiful language that feels very natural, once you have had a few years to build up fluency in it. It might make for an excellent shell language. But, having spent time prototyping systems in CouchDB (which were admired for their elegance, but rejected due to the relative obscurity of Couch, grrr!), I have to say, that my previous bias for querying over transforming, was ultimately holding me back, bogging me down in leaky abstractions. We should have started with MR, and then learned SQL only when presented with something that doesn't fit the MR paradigm, or even the graph processing paradigm, which IMO is also simpler than SQL.

As for the original subject, yes, Hadoop is a pig, ideally suited to enterprisey make-work projects. All the way through the book, I kept thinking, "there has got to be a simpler way to set this up."

If I was confident in a GAI's ability and willingness to emulate me, then I might be willing to grant it my identity, after I die. My work would carry on, and accelerate, while I would still get to have the final experience of death, for better or worse. The people who depend on me would not be abandoned, and the people who like me, might like the new me even better.

We might become a species that undergoes metamorphosis from a carbon based body to a silicon based body. How much of a caterpillar remains in a butterfly, when it emerges/ascends?

A photo of White: https://3.bp.blogspot.com/-_-DoMQ0CuAQ/VzzPgbjhjOI/AAAAAAAAC...

It is a rack of tensor processing units. https://cloudplatform.googleblog.com/2016/05/Google-supercha...

There's an auto-playing video in that page somewhere. Switch to reader mode before it gets you.

Sounds cool! But why do we need to use a Twitter or FB account to sign up? I am trying to eliminate the closed silos from my life right now, because they represent the polar opposite of "transparent, flexible, democratic".

Hah, reminds me of snub nosed fishing vessels. If a commercial fishing license costs ~$1k per foot of boat length per year, then cutting 3' off of the bow seems like a great idea. You can even temporarily reattach this ornamental nose, whenever the boat is not being inspected.

React, as it initializes into a server rendered DOM on the client, has a requirement that the server rendered markup is exactly identical to that which it would have rendered itself as an SPA. TL:DR this is required by the shadow DOM, an optimization that is responsible for much of React's efficiency in browser DOM manipulation.

When your client and server are both running the exact same UI code, then keeping the server rendered HTML in sync with the initial state of the client side DOM, is just a matter of keeping the application state in sync. That is done be serializing it into the response and then reading it from the client side app during init.

But, if the server is using an entirely different codebase to render HTML, then it would take heroic automation to keep that in sync with what the client expects. Better to just use a different type of client side framework, in that case, I guess; seeing React clients backed by servers that are written in neither JS nor compile-to-JS languages is another surprise.

Wow, the modern PHP community is on fire! I had no idea. I basically rage-quitted PHP years ago, after repeatedly inheriting a series of Wordpress wrecks.

Just curious, how does a PHP application handle server side rendering? By shelling out to a headless browser? What if the content is so personalized that server side caching isn't helpful, is it still viable to SSR a React client?

She's an elementary school teacher, and I am living very cheap. No new clothes, minimal meat products, no social events. Just resting for a bit. From a global perspective, I am quite privileged, but within my home country, my family has been near or below the poverty line for most of my life.

Good coffee shops are certainly adequate, and many of them, in Europe anyway, have a section that is nicely furnished for a full day's work.

There are some extra perks to a good co-working space, though. It is library-quiet, and you are surrounded by people who are living and working a similar plan. I was actually able to informally recruit a guy who often worked near me, when we needed to bang out a bunch of UI components and their services, for a design that the client and I had already detailed fairly well.

For expats of most countries, if you spend no more than about a month per year in your native country and don't have property there, then you can declare non-residency. This way, you don't have to pay income tax to your home country, as you are not using their services. Also, if you are constantly on the move, not actually setting up shop and taking local clients, then local income taxes don't really apply either. Nomads aren't really compatible with most income tax systems, for better or worse.

It is different for Americans, though, they are on the hook for income tax regardless of where in the world they reside.

I was living the nomadic developer lifestyle for a couple years, and it has been the best experience of my life. Living in and working from a dozen or so different countries has given me an incredible perspective on where in the world I actually want to be.

If you and your SO are a developers, then I would highly recommend a work-cation in Prague. I spent a few weeks at a really cool co-working space, PaperHub, which was part of the Institute of Cryptanarchy (lol). They take BTC for everything, the transit system is a dream, and there are tiny little specialist grocery stores everywhere. If I was ever going to return to the same place twice, it would be Prague.

Beware of burnout, though - there is no rest in this lifestyle. The home office wants me online during their business day, and constantly learning new cultures is a huge cognitive load. After two years of this, I needed to settle down for a while; right now I am resting between jobs, thanks to a very supportive mother. Oh, make sure to take good care of your parents, they may end up being the only solid, reliable people in your life.

Thank you for explaining. That tweet would almost certainly be considered unacceptable within my own society, because it reinforces division by a highly visible, but ultimately misleading metric: skin tone. I get that there is a persistent segment of the population that needs help to achieve economic and educational parity. Surely, the group targeted by this tweet could have been identified by a label that is specific to the relevant issues, and supported by logically sound metrics?

"underprivileged" is a term we use around here, and the social systems do seem to have a sensible set of filters for it: low household income, mental illness or physical disability, lack of formal education, refugee status, etc. The good thing about a label like "underprivileged", is that a person can truly overcome it and put it behind them. It does not have to be a part of their cultural identity, it is just an environmental problem to be solved.

Tools for automating the mundane tasks of running a co-op, sounds like a great idea for a project. Something along the lines of the GNU tool suite.

How does one build and maintain a co-op? Could anyone recommend a book on the subject, that covers a variety of nations or regions?

Looks like a lot of the top-voted suggestions are only applicable to a single country. If your suggestion has a major restriction like that, then would you please declare it upfront?

OTOH, these "universal" web apps/sites can work quite well without JS. As long as the developer isn't doing silly things like using <button> as a link, or using an anchor to submit a form.

At one point, I built a sortable filterable table for an admin UI, using React. One of the admins was a "no js" guy, and he thanked me for building the whole thing in functional HTML. Up until that point, I had no idea that the admin side of the system was even usable without JS; that was just a natural consequence of optimizing for SEO and load speed (server side rendering, URL representation for all significant state).

One possibility for a useful energy source, in a dirty crowded moon system, would be chemical reactors. Rhea has a thin, oxygen-rich atmosphere, and if you have oxygen, you can burn almost anything. Titan's methane seems like an obvious choice of fuel.

It would be really interesting to compare the economics of shipping large volumes of fuel around moon system, to shipping them around a relatively tiny ocean.

We are receiving a wireless telegraph! It is from Marconi. He wants us to get off his lawn.