Lutger

Its not laziness, its just a matter of priority. Like playing eve online, or doing nothing.

But really, there is what feels like an ever increasing list of 'stuff to do, things to attend', and preparing food (and sleep) are obvious time sinks to reduce, and of course people are willing and increasingly able to pay.

A recent survey (forget the link, sorry), listed time spend on food preparation / cooking nowadays as averaging out on just 28 minutes daily. Around 1980, this was still around 2.5 hours. I believe context is UK.

I easily spend 3 hours daily, because especially with a little kid I just think it is important to do, but I do also feel the weight of it.

Codeberg looks really nice, almost a copy of github, and is hosted in Germany while you can also self-host.

It isn't easy or realistic, yet. But these things always start with the guys and girls with energy and skills. They write blogposts, it gets picked up. Somebody starts making improvements, convinces their manager to do it. Slowly things start to improve, people start building tools, sharing knowledge. Some of these people also work in, or for academia, industry, government branches. Once enough people are ready to pay real euros, there will be entrepreneurs ready to provide solutions on the market, also in Europe.

I don't buy the idea that Europa has lost all the big tech so we're doomed or something. No, maybe we won't have an aws/azure/google cloud competitor any time soon. But it has never been easier to start a software product, the thousands and thousands of SaaS services we rely on can easily be build from the ground up by devs from all over the world.

Reducing reliance on others is primarily risk mitigation, which is increasingly perceived as necessary due to the rise of authoritarianism and wars, in western democracies at least. However, it is quite a sub-optimal solution, and in some cases very costly or close to impossible. It will almost always reduce economic growth, sometimes quite severely.

It would be in the best interests of any one country or group of countries to not have the threats which we think we must de-risk in the first place. Free trade was the primary way we thought we could do that, or at least Europeans thought that was the way. We were wrong all these years. I admit I was one of them. I thought at some point in the near future we would collectively move past this thing called warfare. How naive.

That is only the case if you think of migrating as an all-or-nothing. The services that he did manage to migrate went quite smoothly. If he would get stuck with one or two services, was it still worth it to migrate the ones he did manage? If you think it has all been in vain, then yes - its a different takeaway. But obviously Martijn does things step by step and I imagine he is happy even with the progress he made.

In other words, the question is 'is it easy to migrate to a service for which decent alternatives exist', rather than 'do decent alternatives exist for every service you depend on?'

You takeaway depends on what question you are most concerned with.

Agree, but rather than farming, I think it will enable developers to focus on more complex and interesting problems. Or spot a need in the market (doesn't have to be complex) and quickly solve new problems people are willing to pay money for.

Outcompeting only works if a software company is truly unable to pivot or outperform open source tools sponsored by the government.

The same thing can be said by free tools given away by big tech, like vscode. Here, microsoft operates actually quite similar to the government. There is no way a new company can create a competitor to vscode and charge money for it anymore. This pushes people to solve other software problems, rather than doing something else entirely. I don't think we'll be at the limit of economic value we can generate by writing new software just yet, if such a thing even exists.

It doesn't need to compete, not really. There are many bodies of government. National governments, local, state wide, and from many different countries. These all need software, often doing more or less the same. If they would pool their resources to pay development of useful software, theoretically it could overcome a tragedy of the commons and create really useful software cheaply. This increases productivity and thus economic growth.

It may compete with private software for a while, but not that much: companies will find a way to add value to existing open source software or create new propositions. Building out the boring and useful foundational stuff collectively will just move the bar on what is exciting and new software, or what are better takes on existing software. Companies will be creatively seeking out ever more complex problems to tackle once the government builds out the basic tooling.

And ideally, that is what private companies should be good at: quick to pivot, creative and innovative problem-solving.

Of course, that requires governments to play nice and enable companies to leverage their tooling too, and - perhaps a bigger problem - take responsibility for competent governance of the most important projects and manage their adoption well.

Thanks for actually looking things up instead of dreaming things up. This reminds me of Trumps claim that Zelensky is a hugely impopulair dictator, whereas in fact his approval ratings far exceed Trumps and he is very much legally chosen.

Misinformation is a disease.

I agree. I'm all for phasing out cars completely, but I don't think it is realistic even if there would be support for it.

Next best thing is to move cars to the edges of districts in urban areas. Create big parking spaces, covered in solar panels and equip them with chargers. Design them in such a way that everybody can walk in 5-10 minutes to their home from these parking spaces. In the space that we save this way we can have cycling lanes and trees. Of course, every house should still be reachable by car, if only just for mail delivery, for moving, for doing groceries etc. And people with handicaps should be able to get a permit to park near their houses.

I know one such district near me and its lovely. And one big city in the Netherlands is planning to build a new district in this way for 10000 people, it should be amazing to live there.

When you couple this with drastic improvements to public transport, I think we can move to pretty much ideal cities within a single generation, without abolishing cars and too much inconvenience. It is much easier for newly build districts, but I think this concept can be retrofitted to existing areas very well, if you can find enough parking spaces or garages at least.

Good point. I'm not really interested in farming animals, I really don't know enough about it. In the Netherlands we still slaughter little under a million of them per year, on a populations of circa 17 million that should still mean they are worth something.

But maybe grazing isn't worth anything at all and its only cost-effective if you put them in a big box and feed them grains or something. I don't know.

Vertical bifacial agrivoltaics system are a promising setup that addresses some of your concerns. Most importantly, tractors can easily pass through them.

Another good setup is to combine it while grazing sheep.

While that is emphasized, I don't think that really captures it. The idea is to apply permaculture to computation, as has been done with industrial agriculture.

Permaculture is in the first place an ethical or even utopian project, and I'd characterize it as a counter-culture. You can see this reflected in how permacomputing defines itself in opposition to silicon valley: there's a whole page on what they think is wrong with 'Californian ideology'. See https://permacomputing.net/issues/ and https://permacomputing.net/Californian_ideology/.

Permaculture is a design system grounded in ethics, that concerns itself with rethinking a sustainable society inspired by nature. A common trope is the 7 generations rule: how does a design decision today, impact the future of 7 generation down the line? The domain where permaculture is mostly associated with is agricultural systems, but it also has some influence in the built environment. It was never intended to be limited to agriculture. Permacomputing seems to want to extend or apply it to the domain of computing.

Honestly I don't find the idea of extending hardware lifespans the most innovative. I think it is interesting to rethink the whole of computing from the pov of 200, 500 or 1000 years into the future: if we still want to be there and have a good life for all (and do computation), how could that impact decisions on hardware today?

I think a model where we see all current hardware as a 'repository of components and materials' that can be re-composed (not just recycled) is far more interesting than merely extending lifespans. In that model, there is virtually no waste anymore. Everything can be recombined as we discover more valuable ways of putting things together, rather than thrown away, even after a longer time. I'd argue that also mimics the way nature works. Ecosystems are always growing in complexity as life evolves and diversifies, given the right conditions and lack of bottlenecks. There are no static cycles.

I'm not familiar with kernel development, but what's the difference anyway with C code? If you change the interface of some part, any users of it will be broken Rust or not. It will require coordination anyway.

It is customary for maintainers to fix _all_ usage of their code themselves? That doesn't seem scalable.

There's a more short-term goal for Grok, which is to replace what is left of the federal government with AI. That will significantly boost the money train, but is also a utopian (for some, dystopian for others) goal of replacing the expensive 'deep state' with a slim set of impartial algorithms.

Movement is as much a visual pollution as light is. I find it very, very distracting. That is perhaps a cognitive defect on my part. The fact that e-ink screens will be relatively static is only a good thing in my book.

Another complication might be that e-ink by itself is not visible in the dark, though it isn't a problem to add lights. However, that could again be a benefit.

Personally I would love a ban on ALL advertisement in public spaces, even print. Some brave politicians have done it on a city level, and the citizens just love it. Banning moving images and lights for advertisement would be a compromise, e-ink screens could then still be allowed.

There are lots of benefits for sure, but you have to weigh them against the users who can't be arsed to cancel their subscription and keep on paying. You'll miss out on those.

Not yet, but in the echo chamber I dwell in, a lot of orgs are joining Bluesky, and most actually left X. These are mostly journalists, scientists or people involved in politics.

At some point, it may become impossible for some of these groups - probably starting with journalists - to do their work and not be on bluesky. They will be on X and bluesky. Maybe. If it happens, then bluesky will eventually replace X. Because it will not be long before it will also be possible to leave X, probably the last to do so will also be journalists. Its more efficient that way. Then it will be just nazis and shitposters on X, and X will go the way of Digg and MySpace.

Alternatively, Twitter could also fragment completely and we'll never have an equivalent network again. There's no law stating we must have a single such network where are the celebs, news orgs and scientists hang out.

I haven't seen a single such a screenshot, not one.

> I don't think Chesterton has much to say about DHS, which is relatively new.

I'm responding to this statement. I thought it was pretty clear that the quote is still applicable, especially if you can read it applied to DHS. The comment I replied to was a response to a comment with the original quote. Its called Chesterton's Fence.

Chestertons Fence is a device or principle. It is not actually about a fence. As such, it still applies to, or pretends to apply to cases in the future, of which Chesterton could not be aware.

I assumed this demonstration was clear enough, but apparently I did something wrong here. Anybody care to explain why I have been flagged?

It has higher salaries for privileged people like senior engineers. Try making ends meet in a lower class job.

And you have (almost) free and universal healthcare in Europa, good food available everywhere, drinking water that doesn't poison you, walkable cities, good public transport, somewhat decent police and a functioning legal system. The list goes on. Does this not impact your quality of life? Do you not care about these things?

How can you have a higher quality of life as a society with higher murders, much lower life-expectancy, so many people in jail, in debt, etc.

There are a couple of reasons this is not convincing either:

- Other factors can often dwarf the separate deployment overhead, especially given that the deployment steps are done so often it will force the team to make it efficient and get used to it.

- There is no hard requirement for separate deployment in the first place, if we are just talking about react / spa you can deploy it in a single step. (Not saying you should)

The point is: yes there is quite a lot of overhead. From separate deployments, from separate state management and I think the big ones are often having two different programming languages and having to align schema on frontend and backend. It is hard to deny this. But then saying that because of this overhead, these kinds of apps take 2x time to code implies denying there are benefits as well, that under given circumstances can outweigh the overhead.

I think it is more interesting to assume that in some cases the benefits outweigh the cost of the overhead, and in others they do not.

Absolutely, this is one of the main assumptions where the blog falls apart. What takes more time and carries more risk, really depends on context. Boring, but unavoidable. This is another one:

> when compared to a world where that change isn’t risky (server-rendered ERB)

Server rendered html templates a la PHP - which is what ERB is, may be not risky in this smallish project with likely a fairly straightforward UX and seasoned rails devs, but it can be risky in others for sure. I think a lot of the motivation to embrace what react began was a desire to move out of a tangled mess of spaghetti templates, to be able to use means of abstraction and modularity as powerful as regular backend code. Frontend devs want to create and use components. You cannot create a component with html templates, not really. It will be a mess.

Moving from server rendered html to an api + spa architecture has quite an overhead of course. Just like adding a separate backend service. That price should be worth it. And a good developer can judge whether in which context that is the case. But pretending the benefits that motivate such a change just never justify the costs doesn't make sense to me.

The cost of a change is a very, very complex measure. Anyone who has a simple answer to it that is universal, true and useful will win a Nobel Prize. This is because the cost depends on the person who is making it and his peers, on its effects in the future, on the project of which it is a part, on luck and on the larger ecosystem in which it is done. There are just way too many parameters.

You are right, and this is where a little bit of engineering comes in. Push as much of the logic to scripts (either shell or python or whatever) that you can run locally. Perhaps in docker, whatever. All the token, variables, artifacts etc should act as inputs or parameters to your scripts. You have several mechanisms at your disposal, command line arguments, environment variables, config files, etc. Those are all well understood, universal, language and environment agnostic, to an extent.

The trick is to NOT have your script depend on the specifics of the environment, but reverse the dependency. So replace all `If CI then Run X else if Local Run Y` with the ability to configure the script to run X or Y, then let the CI configure X and local configure Y. For example.

I'm not saying it is always easy and obvious. For bigger builds, you often really want caching and have shitloads of secrets and configurations going on. You want to only build what is needed, so you need something like a DAG. It can get complex fast. The trick is making it only as complex as it needs be, and only as reusable as and when it is actually re-used.

Django admin also has various ways of filtering, search, navigation including menu's, pagination, permissions, custom actions and change tracking out of the box. Most importantly, it also includes ways to easily deal with relations (inline admins).

Last time I programmed with rails was many years ago, but none of these things are included in the default scaffolds right?

I understand the comparison with scaffolding, but I don't think they really overlap too much. You'd typically throw away a lot of the generated scaffolds from rails for a production app. They are more of a tool to avoid having to manually write boilerplate code, increasing productivity and (maybe) reducing errors. But django admin interface is meant for production, though often more as a backend tool than a customer facing interface. Different purposed. I miss the scaffolding in django and the admin interface in rails.

> with scaffolding and other rails generators with custom templates is that really a big asset?

Yes, it is. Django CMS just hits that sweet spot where you can do almost everything you need for an administrative backend with very little customization. Because there is a convention of how things hang together, you are that much more productive. Its kind of a cms that you can throw together programmatically, it sits at a higher level than scaffolding + templates.

Honestly it feels, ironically, like a very rails-like thing to do (here's my model, you know all about it: now generate an admin interface for it!), except that in the rails world it would be unacceptably ugly (in various ways). But it is this very ugliness that prevents you from exposing it to consumers, or spending more time on it that it really needs, so it tends to stay in that sweet spot of being just good enough to do its job. It is very pragmatic and effective.

Is it a must-have? No, of course not. You can DIY an admin interface with rails very easily, too easily almost. However, the same thing can be said about pretty much anything that rails has got going for it: you can DIY in django/python too. And there is always a package...

Very accurate. Every programming language or framework has this kind of emotional attachment of enthusiastic users, to a certain extent. But nothing quite like Rails. Its in the culture.

This isn't what rails advocates, is it? I thought SQLite in rails is a replacement for redis, not for postgres. I've been out of the loop though.

EDIT: this comment is more about rails itself than the actual blog. I take the point being, that sqlite is fine for starting out with a tiny app if you have very little users, and I think that is true.

However, migrating later on to a different database is a always a pain, so I wouldn't recommend starting out with sqlite if you intend to do that later on (with your production data).

Having years of experience in both, though not recently in rails, these are some of my thoughts:

Obviously Django ties you into python and its ecosystem while Rails means ruby (and its gems). The ecosystem is more important than the language. This can either impact your project a lot, or not much at all, depending on context.

Rails doesn't have the equivalent of Django's admin CMS. There are gems but Django is still much stronger. A lot of orgs have their entire CMS / administrated-by-staff part of the product written in it.

Rails, otoh, has a very powerful scaffolding cli. If you are proficient, you can generate some basic crud stuff in minutes from A to Z.

In general, I think Rails is at an even higher level of abstraction than Django. A lot of the architecture or structure is more or less given with rails, whereas you need to make a lot more choices with Django yourself. Routing is a good example. The 'batteries' that are included are also a bit bigger and seem to be in much more active development than Django.

Also a generalization: rails/ruby seems to value brevity and the DRY principle a lot more than is common in django/python. There's a split in taste on this, often python devs find the 'magic' of Rails rather frivolous and unreadable - even though django has a fair bit of metaprogramming itself, whereas Rails devs think the 'pythonic simplicity and straightforwardness' is actually rather crude. Or to be a bit more precise: in the rails world, code duplication seems to be thought of as a greater evil than semantic coupling.

I realize these are all quite subjective, and probably reflecting my own development experience more than being an accurate feature-by-feature comparison.

Fully agree, though I feel there are some nuances with third party dependencies. Consider the following:

Some third party dependencies are so widely adopted and supported, they are on-par with the main framework you are using in terms of support and development. They often don't lag the main framework in supporting new versions for long. I don't think these kinds of dependencies have the same drawbacks. You only have a couple at this level anyway, and should choose them carefully.

There are also dependencies that solve one particular problem well and very narrowly couple to a specific feature in your product. If they become problematic over time, it is easy to just replace them or even rewrite it yourself. Specifically, you could select these judging how well you could maintain the sourcecode yourself in such an event. Often, these are easy to extend as the focus is so specific. You can consider just adding it to your codebase and thinking of these dependencies as your code, except that it is written by someone else.

Of course, in the pandemic we saw extreme versions of this. Anything to avoid vaccination, but ivermectin and other risky drugs were no problem. If vaccination would be alternative medicine and ivermection government mandated, we might see the reverse.

So I don't think its vaccination perse, at least not on its own, but vaccines have various things going against them. Like someone else in this thread said, government mandate + preventative medicine has the right ingredients to form a conspiracy theory with, religious doctrine has historically amplified that as well. Additionally, there's also a distrust of 'big pharma' in general, and especially with minority groups a history of dubious or even malevolent medical experimentation by the government.

A big part of the antivaxxers are now also anti 5G, advocate against the use of sunscreen, are against wind energy and EV, sometimes pro-russia, anti-deepstate, etc. Some of this is fossil lobby, some of it is the result of Russian propaganda and other parts are just organic whackyness, like the flat earthers.