Shamar @Shamar@qoto.org

@informapirata

Mai caricare un elenco di password, ancorché cifrate, su un server di estranei.

@Hamishcampbell

In Italy we used to have a law that imposed to banks to provide 1/13 of their profits to indipendent centers that used such money for no-profit organizations.

The thing worked very well until such centers were not turned into political affiliation tools. Then they became a mess (and while I'm not much informed right now, I'd guess the law was abolished).

It was 20 years ago or so, btw.

The approach was great because the contribution was mandatory and was not given to a government agency or so, but to independent organizations that had a single, quite specific goal: maximize the outcomes for the no-profit organizations.

Such approach could work for free software too: companies should give the money but NOT have any say on their use. Intermediate organizations should account on how they improved the security, the quality or the innovation of the whole ecosystem.

@VictorVenema

@wolf480pl @njoseph_1

Nevermind, I'm too tired.

Didn't realize the 2 was referring to the log4j version.

@wolf480pl

Dynamic linking is what made #log4shell possible in the first place.

But... what's log4j2?

@njoseph_1

@paoloredaelli

Posso suggerirti di non usare #YouTube per trasmettere le messe?

Non solo per questi problemi, ma per tutelare le persone che la concelebrano.

A me non piacerebbe finire su YouTube, con la mia Fede e le mie relazioni profilate da #Google.

@ekaitz_zarraga

This is the relation I have in mind: to build a complex software you need complex tools.

Given the computing power of modern hardware we shouldn't need them, but we need them because each software is grown too complex.

@wim_v12e

@wim_v12e

How many mainstream software did you try to read and understand completely in a month?

I do not mean "enough to hack them" but enough to predict where a bug is by looking at it at occurring at runtime.

@ekaitz_zarraga

@ekaitz_zarraga

Exactly.

The complexity of a software should be measured by the average time a person need to completely read and understand it.

A simple software can take a day or a week. A very complex one, a month.

Everything above, is broken beyond repair.

Yes, we need to rethink almost everything from scratch.

@wim_v12e

@ekaitz_zarraga

Yes, I am.

Not much on #Jehanne, but on deciding what computing should be (and thus what Jehanne aims to become).

Yeah, complex software exists.
But it should not.

So now make is useful because of #WirthsLaw... but it should not. 😉

@ekaitz_zarraga

As for a simpler make, maybe: but it's not that complex. It's just that I'm not sure it's needed anymore.

@ekaitz_zarraga

In fact, most of times I build a single program or library in jehanne and it takes few seconds.

The kernel is the slowest component (except of gcc/binutils, obviously), but mostly because to create the initrd, it starts a previously compiled kernel in qemu and copy the required binaries as served by a 9P2000 local fs.
Iow, not something you would optimize with make.

Obviously 10 or even 20 files are not too many but I'm quite surprised it take your machine minutes to compile them.

@ekaitz_zarraga

I think my point is that if you can percieve the difference between compiling with a makefile that check timestamps and all, and compiling with a script that don't give a shit and build everything, your project is too complex and should be split into smaller pieces.

Needing makefiles on today hardware is a huge smell.

@ekaitz_zarraga

Makefiles fasten compilation.

GCC/binutils apart, compiling #Jehanne from scratch take 2 to 3 minutes. A whole operating system, including kernel, userspace programs and all.

When makefiles where invented compiling and linking a simple hello world used to take minutes, so it was rational to spend computing cycles to minimize the amount of compiled code keeping track of the modified files and their dependencies.

But is this still true today?

To be honest, I don't think so.

Today makefiles and similar tools are used to tame the huge complexity of big codebases, while the right think to do would be to avoid writing such big codebase from the beginning.

That's basically why I did't port neither gnu make nor plan9 mk to #Jehanne: I don't think we should still use them.

In other words, I would suggest you to use a simple lisp (or rc, or sh or... whatever) script to build your code instead of make and similar tools.

@ariel@m.costas.dev

While we shouldn't waste energy as if it was an unlimited resource, we should be careful with performance optimization.

We should ban #blockchain technologies as soon as possible, but we should also note that #BigTech married the greenwashing thread long ago.

They can offer "green" computation on a scale by cutting from their carbon footprint the energy consumed by the connected clients (mostly browsers).
This is obviously unfair because they control such client-side computation in several ways, including by controlling the browser development, the standards and the frameworks used to build upon them (#React, #Angular and so on...).
Not to mention the actual decision of which version of the code you run on your browser, that can be "personalized"/targetted just like ads.

So ultimately they lie, as usual.

BUT arguing about performance and energy consumption might end up supporting their rhetoric.

So sure, compiled software is more efficient then interpreted one, but (first) you need to consider the whole computation, including remote client and data transfer, and (second) you need to compute the optimal balance between the pollution of the biosphere and the predation of the cybersphere.

Amazon might even (pretend to) provide the most energy efficient computation, but in the end they would use the power provided by the data collected to move goods around the world in a very polluting way.

@aral