sdepablos

Heavily inspired - I suppose - by the oldest (2018) solar-powered website, Low Tech Magazine https://solar.lowtechmagazine.com/about/the-solar-website

What most people talking about 10x vs 1x engineers forget is that the last 10-12 years of VC-pumped software engineering has created an insane amount of 10x engineers not because they're better, faster or more intelligent, but just because they're people that care about their job, even if it's boring, and they deliver quality at a constant pace.

Doea anyone know about this Breakthrough Institute?

> The Breakthrough Institute is a global research center that identifies and promotes technological solutions to environmental and human development challenges.

Well, I think that the demand of developers is not so much because of the increase complexity of systems but because a lot of companies think they need developers, when they only need technology, and a lot other think than just adding more devs is the solution (the hyperinefficiency of the hipergrowth companies is at this point legendary, as the guy earning $1.5M/y getting and losing - but getting paid nonetheless - multiple tech jobs at the same time proved)

We humans reject the concept of exponential growth, specially when it can kill our way of life, and in that sense developers don't realize that 80% of our work could be automatize in the next few years.

I've been in the industry for more than 20 years now, and what's clear to me is that a lot of time is spent coding and debugging things that have been done previously plenty of times (Non Invented Here syndrome) and that in most cases are not core to our companies.

What I expect it's not so much things like Copilot or AlphaCode (that of course will be used) but serverless services that we'd plug into our solution (how many more login services do you want to implement AGAIN?), like we do right now with APIs, but at a higher level, with a standardized communication protocol between these services.

The same will happen the infra level, with only a few people creating and mantaining "low level" solutions while the rest of us will use abstracted services on top of that, like using Cloud Run instead of learning a massive APIs like k8s (I'm not saying that they're comparable right now, but at some point something evolved from Cloud Run will make learning k8s unnecessary)

What will happen once developers are freed from the most time intensive aspects of their job? Probably and for a few years the unmet demand for developers will cover our increase in productivity, but at some point I expect this job will face some of the problems you can see in other sectors.

The thing is that you can host the server container also in AWS https://www.simoahava.com/analytics/deploy-server-side-googl... or Azure https://www.simoahava.com/analytics/server-side-tagging-azur...

Myself, and it's has ñ

How it this different from any DAG-centered orchestration tool like Dagster or Prefect?

Of course the best option is doing BOTH things: indexing the context automatically via a modern personal search engine that accepts all kind of media and does vector / full text and relation indexing, plus the information wroten by the user

When submitting this story I was actually expecting HN to show me the original post, not accepting it as a new story :/

Pure SaaS. Check their pricing [1], as is row based and depending on how much data you need to move it can easily go out of budget ;)

[1] https://www.stitchdata.com/pricing/

I saw this project a few months ago and I'm really surprised how fast they've been adding new connectors [1]. I was initially a little doubtful about them implementing their own protocol [2] instead of using Singer [3], already OOS, but it looks like it panned out for them. In fact I've been using Stitch Data for a couple of years and I've find myself "fighting" with their support team about bugs I think we're Singer related, mainly with DDL commands.

[1] https://docs.airbyte.io/changelog/connectors [2] https://airbyte.io/articles/data-engineering-thoughts/why-yo... [3] https://www.singer.io/

Sounds kind of strange not having incremental replication, it would make no sense for an ETL tool. In fact the documentation for PostgreSQL [1] is somehow contradictory at it both states "Incremental sync (copying only the data that has changed) for this source is coming soon" but also "Feature: Incremental - Append Sync / Supported: Yes"

[1] https://docs.airbyte.io/integrations/sources/postgres

Thanks a lot rhamzeh!

Don't you find Flatpacks and snaps a little slower? The overreliance of Ubuntu 20.04 on snaps was my reason to finally ditch it for something else

Oh, didn't know about it. Thanks!

I'd say they're two really different products, so even if FB popularity is falling dow, that does not mean that WhatsApp would follow. In fact I'm pretty sure that thanks to services like money sending WhatsApp is poised to grow in quite a few countries.

Unfortunately I'm from Spain where WhatsApp penetration is around 90%, vs a ~65% in UK, so I still know plenty of people, specially family, without a Telegram account (I'd say almost no one over 50 has an account)

Sometimes I think HN people were born out of thin air and don't have families. That or mine is special, because if I said to them to change from WhatsApp to whatever in the basis of privacy concerns they'd say that: 1. FB already knows everything about them (btw, a social network the still use) 2. They'd lost contact with a lot of people

And all this without taking into account features that can make the product even more pervasive (I'm thinking payments)

The problem is that once a product becomes the de facto solution and everyone is onboard, is hard to change it, specially one with network effects. If it wasn't we would be using e.g. other search engines, wouldn't be?

Finally, I'd say the announcement of this change is perfectly timed: just after Christmas and in the middle of a pandemic. By the time we meet again with our extended families and we do the de rigueur holidays' technical support this change will have been forgotten by most people ;)

Not so much with ultra-high-voltage lines. China has been doing it for years because of the really long distances between electricity production and consumption.

https://en.m.wikipedia.org/wiki/Ultra-high-voltage_electrici...

Same happens with Cervantes. A funny thing is that the more languages I learn, the more vocabulary I recognize in a given language. In most cases obscure words from one language are pretty common in another.

Agree with both, but in the case of Le Guin I clearly prefer the Hainish Cycle, with classics as The Left Hand of Darkness, The Disposesed or The Word for World is Forest

Didn't know about Ventoy https://github.com/ventoy/Ventoy but the possibility to install something in an USB and from now on being able to boot from any (and multiple) ISO/WIM/IMG/VHD(x)/EFI that I copy there is pretty sweet.

Thanks setheron. If I find the time (the eternal issue) I may to take you on your word )

No, I've using virtualenv for quite some time and I still use it when I'm the person in control of the dependencies, though I'm moving little by little to the docker way. Why? Because sometimes the problem is not only on the dependencies, but in Python itself. As an example, as of today gcloud does not support Python 3.9.

I'm in the same situation: until I figure (if ever) how to use NixOS and control version my OS, I tend to use Docker for any application with lots of dependencies, specially Python related ones

Not my field of expertise, but seeing that generating the voice is one of the biggest costs, have you think about generating it yourself with something like https://github.com/mozilla/TTS running the process in commodity hardware?

I usually prefer to do both: store the original documents, and try to parse and store them in the database for the easiness and power of SQL

Maybe the main issue here is that while SPAs make life so much better - proper testing, immutability, one way data bindings, speed of development... - for frontenders, they make it worse for absolutely everyone else: backenders that were able to hack a passable frontend or modify a proper one; final users that deal with bigger and slower webpages; devices struggling to render websites; backends that now need way more CPU to do SRR then they ever needed with traditional websites; beginners that were able to look at the HTML & CSS of a page...