jtolmar

You'd also have to compare this against the download size of the protobuf library itself.

Lovely little collection of sites like this, which showed up last time - https://href.cool/Crimes/Simple

(I linked to the category that the scissors is filed under, but the collection is extensive)

Companies that sell security systems want big stable government paychecks, but can't just bribe lawmakers, so they instead secure votes for pro-surveillance policies by getting "think of the children" style articles published.

I tried that before contacting them.

So far their advice is just to try the same thing but longer, though.

My Framework laptop suddenly stopped charging or booting. Hopefully it'll end up being one of these, if their support ever stops telling me to retry charging it for 24 hours.

This is the right way to think about it. My only disagreement is that I'd do the local DB before the local service. A bunch of local versions of the service pointing at the production DB sounds like a time bomb.

And it's definitely worth emphasizing that having no framework, MVC, or templating library is not a real problem. Those things are nice if you're familiar with them, but if the team is familiar with 2003 vintage PHP, you should meet them there. That's still a thing you can write a website in.

It's clearly a title font. If someone uses that as a body font, it's hopefully a shitpost.

It's certainly better than it used to be, since there are more satellites, and a lot of work goes into doing well in these environments (I used to do the GPS integration for Google Maps).

There are two big tricky parts about urban canyons. First, yeah, you still have quite a few satellites, but they're all in the same directions. Satellites directly above you don't really tell you anything. Satellites in front of and behind you can only tell you how far you are along that axis. You don't have any satellites to the sides, because you're in a canyon. So in an idealized version of a really bad urban canyon, the GPS can tell how far you are on the street, but not which street you're on, which is what the user actually wants to know. (I did a lot of work on knowing this from context, but it's still quite a mystery on a cold start.)

The second is that, unlike natural canyons, signals in urban canyons tend to bounce. So instead of seeing the satellite missing, you see it giving a signal that's consistent with if you were in the next street over. Which is the same problem we had in the first place. There's a lot of outlier detection done in the chips, but in a really noisy environment, sometimes that'll inevitably end up throwing out the good data and choosing the outlier.

GPS assumes* light travels in a straight line, which it doesn't due to atmospheric effects and reflections off buildings. L5 is a second frequency from the same satellites, which is affected by these problems differently, so the chip can compare the differences between the two signals and guess what's up with the atmosphere and buildings / throw out the dumber looking signal. It's also mostly independent so it's more data. L5 is also a bit less affected by atmosphere inherently.

The upshot is much better accuracy in urban canyons, and a small improvement where GPS was already good.

* Obviously people making chips and apps know this and try to mitigate it.

There's a few parts to it.

javascript used to be awful. Using JQuery was more or less required to have a decent API and not have your entire app full of polyfills. Those days are behind us, but the precedent remains.

Some javascript APIs are still pretty bad. Fetch and XMLHttpRequest are both really warty in their own ways, to the point where you're probably writing a wrapper function. Common-enough collection operations are missing, you'll need to write some sort of utils file. So you're definitely going to want at least some sort of small library for the missing stuff.

The DOM forms a parallel, persistent tree to your application state, and you need to manage the relationship between that and your app. Parallel state trees just always suck (I've also dealt with them in Box2D, some game engines, SVG renderers...), it's probably an antipattern. It's not that big of a deal for a small app, but for larger ones it starts getting hairy. And it certainly feels like you should be able to write a better API easily enough, but because the problem is that the entire DOM is based on a parallel state tree model, your wrapper library ends up getting large before you know it.

There are good technical reasons to use some sort of build system for your web content. Concatenating and minifying all your javascript helps a ton. But to do a really good job of minifying you basically need a whole compiler, and at that point you might start pulling in all sorts of clever transformations that seem like a good idea.

The new technology looks like it could threaten artists' livelihoods by replicating something about their work. The old legal framework for protecting artists' livelihoods from photocopiers etc was copyright. The goal of making sure artists can both make art and eat is still relevant, so people reach for the tool that used to make sure that was possible.

I'm impressed that running it on CPU only made it ~20x slower. How did you do it?

The page is doing something strange on scroll, it's almost unbearable on Firefox mobile

> So for example, I want to schedule a doctor’s appointment on my personal and have my other calendars mirror that time block, but scrub the details/make it generic. Super specific idea obviously

Actually not that specific at all! I know a lot of people have at least the work/personal schedule split, and personally I have the additional side project one the same as you, which I bet is pretty common among people putting on this very website.

I also know a lot of people have other arrangements they'd like. Partially out trans people jump to mind. And I'd like my personal contacts to know what my side project life is up to but not vice versa, which is probably not standard but I doubt I'm alone.

So I think customizable ways to separate your life and who is able to see it is not really a niche feature at all, and just a commonly missing one.

> 2. Mark it up 5x-10x.

From the limited searching I did when I first noticed this, it seems to actually be a more or less flat $10 markup, regardless of whether that works out to 10x or 10%.

Maybe some sort of fixed cost is involved?

If you're a central planning committee trying to solve for the best outcome under physical constraints, nothing beats nuclear power and railroads.

If you're living in an economic system where investment is primarily determined by rate of profit, then you need to identify a solution where everyone involved is making more money than they would be without you. So it's very important they're competing with oil on economic terms while increasing demand for solar.

I don't think there's a way to extend union-find to do what you want in the general case. You might have more luck starting with a minimum cut algorithm.

For the specific case where you can identify some of your edges are more or less likely to be deleted, though, you can run union-find on only the stable edges, cache that result, and then do the unstable edges. Whenever an unstable edge is deleted, reload the cache and redo all the unstable edges. This works for something like a maze with open/closable doors.

Terraform Industries has a process for converting atmospheric CO2 and water into hydrocarbons (particularly "natural" gas), at the cost of a huge amount of electricity.

Because solar panels keep getting cheaper and oil doesn't, they think they can out-compete the cost of oil in some markets (sunny with expensive oil) in the near future, and more places over time if solar power keeps getting cheaper.

The author hopes to encourage a huge investment in solar power, which would be good for the planet and people in general (and unstated, also Terraform's bottom line).

The union-find data structure / algorithm is useful and a lot of fun.

The goal is a data structure where you can perform operations like "a and b are in the same set", "b and c are in the same set" and then get answers to questions like "are a and c in the same set?" (yes, in this example.)

The implementation starts out pretty obvious - a tree where every element either points at itself or some thing it was merged with. To check if two elements are in the same set, check if they have the same parent. Without analyzing it, it sounds like you'll average findRoot() performance of O(log(n)), worst-case O(n).

There are a couple of simple optimizations you can do to this structure, the type of things that seem like they shouldn't end up affecting asymptotic runtime all that much. The first is that, whenever you find a root, you can re-parent all the nodes you visited on the way to that root, so they'll all be quicker to look up next time. The other is that you keep track of the size of sets, and always make the larger set be the parent of the smaller.

And neither of those actually do anything impressive alone, but if you use both, the algorithm suddenly becomes incredibly fast, with the slowest-growing (non-constant) complexity I've ever heard of: O(the inverse of the Ackermann function(n)). Or, for any reasonable N, O(4 or less).

I copy/pasted the code examples, reformatted them so they'd work in a different language (javascript), and refactored it to write my own language instead of Lox.

Then I did it again with a different destination language design, and had to reference the book less.

Whenever I end up writing an interpreter for a third time, I'll probably be able to do it without referencing Crafting Interpreters at all, if I had to. But I expect I'll still check the book before doing certain fiddly parts of the parser.

The left was outside, the mountain face was basically a vertical line, and all the things we associate with "deeper" were found further and further to the right of that line. Some ways in you'd find an underground river (which floods when you first find it), then a chasm (enemies spawn from here), then a magma river, [spoilers for ancient versions of DF start now] eerie glowing pits, and finally adamantine. Finding adamantine made the king show up and demand you mine more and more adamantine, but the more you mined the more likely you were to have your fortress suddenly end in a cutscene.

All these fixed elements gave the game a specific progression of increasing rewards and challenges, and a guaranteed story arc for the whole fortress.

I ran a simple Markov chain text generator bot on 4chan for a while back in 2008, because I wanted to see if it could pass the Turing test on /b/. It could, and also derailed conversations quite a lot, so the technology is certainly there.

Modern political accusations of botting are more like a way to turn people with differing opinions into a non-person conspiracy, though. It's not as fun and silly as my old Markov bot.

Most abstractions will accept one layer of ugly hacks for situations they were never meant to deal with. I'd recommend waiting until the second layer of hacks starts to form, then refactoring with what you've learned, since that second layer of hacks is when things start to really fall apart.

I think if you divided economists up into two groups, with A including all the economists with popular media platforms or who work in government policy, and with B including the rest, those stuck in academia writing papers that only other economists ever read, then you would find that group A fits your quip very nicely, and group B does not.

> I would be interested in anyone posting what they think is an economically viable path to challenging Google.

You only search whitelisted sites, which removes a lot of the SEO and blogspam from the results, and makes the index is wildly smaller. Search is free, but users can also pay a cheap subscription for the ability to flag sites as spammy, submit sites they think are missing, and submit queries the site has trouble with. Someone manually goes through the top N most-repeated submissions each day (early on this is all of them) and determines whether to tweak the whitelist.

Because your initial audience has to be people who are very enthusiastic about better search results, you should identify what they're interested in and focus your efforts on initial whitelists to things they care about. That might be technical questions (MDN StackOverflow, every random framework's docs site), or maybe whatever it is journalists would want to have access to (I'm not qualified to answer).

I don't think VC-encouraged hypergrowth is possible with the above strategy, but you could probably get to ramen profitable in a reasonable time frame, with slow growth ever after.

I've been working on one of these on and off for a while now!

It'll eventually be up on gosayhito.com. I'll try to remind you when it's done, but you can also probably put the website in as a monthly thing to check on.

Back when I was working on location for Google Maps navigation, we explicitly disabled the wifi-based location service, because it was less accurate, and occasionally started giving locations from several seconds ago.

So to me it's kind of a baffling decision.

GPS itself doesn't use much battery at all, nor do the calculations that use it. GPS-enabled apps use a lot of battery because they have to constantly wake up the device and enable the antenna, but that hardly matters for a navigation app, which is already awake and scanning constantly. Most of the battery use on Google Maps nav comes from keeping the screen on, and re-drawing the map it shows.

Source: I used to be the lead GPS engineer on this product.

Of those, private property - the Marxist definition of it, at least - is mostly new. For anyone not familiar, that definition of "private property" is something like productive assets used by other people for the profit of the owner, and "personal property" is like, your clothes or your TV. It's a little artificial, and fuzzy in some cases (but not that fuzzy, it's a useful way to look at society).

Prior to the industrial revolution, most private property was land and slaves (or serfs, same thing). Land supports only so many people, and land is finite, so both of those have limits on growth. And tools for any given trade were generally cheap enough that anyone of that trade would own their own set.

With the industrial revolution, suddenly the best ways to produce certain goods were wildly more expensive than what any given worker can afford, and even more wildly more productive. So there needed to be a mode of organization besides "every worker owns their own set of tools," and at the same time, factories were the first thing ever to be more valuable than owning land. So that's why "who owns private property" suddenly became an important question about 200 years ago, when "who owns land" would've been the entire discussion for most of human history.

If you check out something where people just ignore copyright, like fan fiction or ROM hacks, you'll find something that's not very hard to follow at all. Easier to follow than what particularly reboot-happy studios do with their copyrights, since people generally come up with more descriptive names for their fics/hacks/etc than "Star Wars 5."

90% of that is garbage, of course but that's true of anywhere.

If you'd like a specific timeframe where it's useful for a franchise to be controlled by a single entity, I'd say 5-10 years. Anything more than that and, even if you still have the original artist in charge, they'll be in a completely different place in their life by then.