dmw_ng

Watching company employees consistently pop up on critical threads (not fingering CF here, many including at least Stripe come to mind as frequently occurring too) feels a lot like gaming the forum. Vetted messages like this from a recognizable source will often end up pinned to the top of the thread, but I don't really think they overly contribute to the conversation in most cases, and I find myself wishing there was some rule against it.

Not to say there shouldn't be a place for official responses, just that it's kinda tiring to see crowdpleasing justifications during times of stress displacing the thoughts of other potentially less biased folk on the Internet discussing the problem at hand.

(The counterargument would be that the status quo provides unparalleled public access to top-level staff, I'll leave that angle for someone else to explore ;)

You can get similar functionality very cheaply on AWS from the vt1 instance type. They're a PITA to work with, which is probably why they're still around $160/mo. for enough transcode to power a small city on spot. These cards can transcode a full ladder (5 resolutions) of a 60 minute 1080p video in around 4 minutes, or the full ladder for 8 60 minute videos in parallel in about 30 minutes. Those instances are based on off-the-shelf cards that cost somewhere around $2000 each.

Guessing Google went the custom route for wider codec support, but standard hardware for this stuff is readily available in the professional broadcast industry

That is true, and why not also ignore the frictions created by a single currency, free movement of labour and people, or the harmonization of judicial systems during times of crisis. Surely under such strain, it is only fair that Germany no longer subsidizes Italian public debt, institute border controls for the transport of gas and oil, eventually instituting controls for all energy-derived products of any kind where a pricing inefficiency is being exploited by any neighbour. It would mean Putin responded to our sanctions by destroying 70 years of European cooperation, and doing so without even so much as firing a single bullet.

Energy is the economy, and the failure of an integrated energy market means the failure of so much more.

That very much sounds like you're calling for the collapse of the integrated european energy market. This is not meant as an attack on you, just an observation that these nationalistic calls will continue growing louder from every part of the continent, and it is not even September yet. Already Norway has publicly commented on the possibility of rationing exports.

We have yet to even scratch the surface of the effects of this crisis

Put the HTML/CSS inside the JS, make that whole bundle cacheable, and make your "HTML" response basically be one <script> tag starting the JS and another containing the JSON response.

Folk have been using this technique for a decade or more

I love this story. The moral is not that folk in Siberia could now watch video, but that a whole chunk of the distribution lying between "fast US fiber" and "siberian 2.4kbps wet string" had their experience dramatically shifted to the left, enough so that new outliers impacted the average. Even after noting the lesson about the limitations of reliance on averages, still it skipped over this key element.

I remember the YouTube feather opt-in being spread by word of mouth at the time by folk in the tech community on fast connections. People really care about this stuff and the only reliable way to know is by engaging them directly.

B2 isn't great for low latency serving, objects that aren't in hot cache have extremely variable delays on first fetch, and the delay (at least as of a year ago) scales according to object size.

For largeish video (over 500mb) I remember seeing >1 second latency, enough to rule out using it for anything public facing

Seeing a lot of mixed feelings about the AWS UI here. Just my two cents: a good project shouldn't need it for anything much beyond fiddling during development and poking around during problem solving.

In the latter case, I deeply appreciate the minimalism compared to something like GCloud. You can pump the refresh button on many AWS consoles and they refresh in a second or two. Progress spinner cancer while present is minimal compared to many popular platforms, and in particular relatively nonexistent compared to the white elephant that is GCloud

Given the choice between a half-developed AWS console basically emitting some raw XML in a <pre> tag, and the overengineered overdesigned monstrosity of GCloud, I'd always prefer the fast hacky option especially while trying to figure out why something is broken.

While the GCE panels look visually fantastic, there are so many cases that make it obvious actual engineering workflows weren't considered during the design process. Be it missing buttons from the context-sensitive toolbars, pointless sidebars, or screens you can't refresh except by hitting F5 before leaving for lunch. I've yet to see any part of GCE that could be described as "snappy". Plenty of AWS bits come much closer to that (although I notice AWS has started slipping down the GCE road to hell in a couple of their newer service UIs)

AWS is far from perfect, I can't stand CloudWatch, but relatively speaking it is perfection compared to stackdriver

tldr I'm glad it's ugly, it means they were focusing on the important stuff

Ofcom are slowly getting their teeth back with upcoming regulation (3 decades late IMO), but in answer to "what would we really lose?", we'd likely suffer immediate tit-for-tat responses from the US if we attempted to meaningfully regulate or partition our media from theirs again.

I don't think anyone who has spent much time thinking about it sees the Russia/China/Iran firewalls as a bad thing, but we aren't them and we can't regulate our media in the same way.

The genius is exactly that they haven't bothered. Can you imagine the flow of layout bugs over the past 20 years, or the managers calling to scrap old content because it's generating so much workload?

That's very much a successful case of avoiding needless technology

Fully developed Flask projects tend to be significantly more hairballish and custom compared to something like Django, but it's extremely hard to kick the habit and convenience once something has initially been prototyped in Flask (or Bottle, same deal). Commercially I'd much rather encounter an existing Django project, but at home 90% of the time I'll reach for Flask first, the rest being cases where there are some off-the-shelf Django components that will definitely save a ton of time, and the ceremony is worth paying.

Links like this are stupid regardless of Outlook's behaviour because they require a perfectly reliable client and network and user in a perfectly undisturbed flow. If I can't F5, if I double-click, if my mouse is wonky, my wifi is bad, my power goes out, my computer hangs, my DSL dies just after a click, if I accidentally close the tab.. there are any of a thousand reasons why abusing GET for a one-time-use page or redirect is horribly wrong.

It takes incredible arrogance to continue using them in order to "improve usability" given all the obvious and common cases where they completely destroy usability. The difficulty for a provider to verify they aren't sending you to a phishing or browser 0day page barely scratches the surface.

Sounds very exciting, but curious about performance. Of course there will be downsides, it would be nice if this could be characterized somehow as part of the docs or site.

Does anyone know if this covers network-layer state like keep-alive or TLS session reuse?

Insufficient density or spectrum to serve all users in an area

Check out the uBlacklist extension, could not live without it.

The main trick behind AMP is simply the ability to load third party content in a hidden IFRAME on the google.com origin securely. Your clicks were instant because they were literally pre-rendered client-side before you clicked, and that's why custom JS is prohibited.

SXG and WebBundle basically help map that trick out into the browser's domain, rather than some nasty restrictive JS library. It allows eliminating the whole megabyte-sized supersystem of JS nonsense that makes up the AMP library and having just plain ol' regular HTML/JS, while still netting most of the performance benefits of the old approach.

Mobile networks may have improved but the speed of light has not, and so these techniques still have a place in contemporary networking.

This hasn't been true since the first third-party JS script was published. In reality a giant proportion of web users today are 'on Google' or 'on CloudFlare' or 'on CloudFront' even if they aren't aware of it. The address bar has been broken in this regard for at least a decade

> a clean implementation and no compatiblity hacks

Ignoring the minor typo, this statement will cause some in the audience to frown ;) The value of an implementation like this is the compatibility hacks. Maybe take a few leaves out of the PyPy/HPy book.. PyPy has been amazing from the outset, but only a fraction of the community have been able to use it because the compatibility story initially was very weak. 15 years later and it's still not quite there, and consequently neither are the users.

> database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM

Apps like this tend to perform like an absolute whippet too (or if they dont, getting them to perform well is often a 5 line change). It's really freeing to be able to write scans and filters with simple loops that still return results faster than a network roundtrip to a database.

The problem is always growth, either GC jank from a massive heap, running out of RAM, or those loops eventually catching up with you. Fixing any one of these eventually involves either serialization or IO, at which point the balance is destroyed and a real database wins again.

I want SPF/DMARC etc. results as features alongside all other message content, and overrides (like whitelisting, clicking "not spam") to apply similarly. Valid SPF/DMARC is so commonplace in spam that it's not worth treating specially, there are much more reliable indicators (e.g. domain age, Google safe browsing list, Phishtank) that in a variety of cases a user might still want to override.

I'm actively playing with this stuff so probably my requirements are a bit special, but even aside from that, it does still feel quite irksome that all mail input can't be cleanly recorded.

A small but important detail regarding Migadu: it's impossible to run their spam filter in a fully permissive mode. Some checks (presumably SMTP time like SPF) cannot be disabled, preventing the recording of all incoming spam. That's fine if you want to depend on their spam filter, but if the point of moving from Gmail is to avoid megaprovider lock-in, complete visibility of spam is needed to train an equivalent filter that does not belong to any service.

It's possible I'll eventually move on from Migadu due to this, even though there is otherwise a lot to love about the service.

The registration and login forms both appear to break Firefox password manager, even after applying a bookmarklet to remove relevant 'no autocomplete' HTML attributes. I just signed up, but chances are I won't be back after my clipboard gets overwritten

Regarding SES, beware they force a Message-ID header, preventing at least forwarding of mail without breaking threads. There are probably more gotchas to this I hadn't discovered.

Same problem, I figure it's some promo hidden by adblock. If you turn on reader mode it's fine

Separately, is there any possibility this documentation will end up online at some point? The inner workings of early Compuserve sounds like several years worth of well spent winter nights

That's a question designed to confirm priors, depending on perspective it's not necessarily an honest one. It's better to think about changes like this in terms of what becomes possible with overheads removed ("what becomes more convenient to do as an npm script if startup is much faster?") or comparable examples from other areas ("what happened to the web when it no longer became necessary to wait 300ms+ for application logic to respond to a click?") etc.

Similar concept from India https://en.wikipedia.org/wiki/Jugaad

OS packagers have bugs like this every so often, because they still run custom upgrade scripts behind the scenes. Pretty sure I remember one in Debian a few years back (sorry, name escapes), and it was not the first time I remember seeing that.

I made an earnest effort to switch to Brave, but I'm back with Google for almost all searches because 1100ms+ result page loads are simply unworkable here.

I picked 5 at random, but I guess it really depends on where you are. Assuming 5 was the real number, that's only $28k/month bandwidth spend given the average SWE salary in the UK (£38,561 going by google), including 33% for tax and non-salary costs. That's about 327 TB worth of undiscounted AWS bandwidth, or roughly a site averaging 993 Mbit/s.

A small video site might start at 3 Gbit/s, a medium sized one closer to 30. These estimates really are quite conservative depending on the context