MZan @mzan@qoto.org

@publicvoit I'm an ex NixOS user, and I'm using GuixOS now. Migrating a working setup to another system is usually a joy in #NixOS and #GuixOS. Also studying the setup of others, and copy and paste good idea. But I agree that creating this "magic" working setup can sometime be a pain.

Moreover, if an application is also a platform, supporting plugins like Emacs, KDE, or IDE like Jetbrains, then it cannot work correctly in a Nix/Guix OS environment, because it is not running in a Filesystem-Hierarchy-Standard, and ideally also the plugins should be ported to Nix/Guix.

Summing up: what works, works very well, since it's reproducible and all in a few files (as reported by @eliasp ), but what doesn't work can be very difficult to port to Nix/Guix (as reported by @publicvoit).

@khleedril Shepherd is rather complex and/or different from other systems. For example a new service can extend already existing services with "new rules" and the way these extensions can be merged, is customizable. Elegant, but hard to grasp initially.

I started studying/using it. I wrote some internal notes, but never finished. IMHO, Shepherd needs a tutorial (ideally written by someone who didn't coded it), because there are various "pain point". So, I'm sympathetic with the author.

In other words, IMHO, it is not a case of RTFM, because it is missing some intermediate-level tutorial.

@civodul

@screwtape

... I don't see a problem of fragmentation, because Lisp is born to be fragmented. Also assuming to use only ECL, there can be an ECL with a set of macro supporting the PicoLisp way, and this is still a fragmentation. Every CL DSL is a fragmentation.

PicoLisp specifies in details also its run-time, while in ECL there are less details. PicoLisp removed many features from an hypotetical CL implementation, both for simplifying the run-time, but also as design choice, for making more clear what to use as calls to the C-world. Every advanced data structure must be a C library. In ECL you can be tempted to use CL libraries, instead.

But the most important aspect: one of the problems of fragmentation, is code reuse. But in an embedded context, usually the majority of code reuse is in the called C functions. Not in the business rules specified using PicoLisp or ECL.

@dougmerritt

@screwtape Up to date, I used Racket, Guile and CL (SBCL). I never used PicoLisp and never ECL.

Lisp is the "lambda-calculus" of real-world programming languages, because there is nothing you can remove from it, but you can express nearly anything with it.

PicoLisp is like Lisp, but also with a minimally, useful and composable run-time: C friendly; GC friendly; DBMS and external entities friendly; OOP system like Self but not heavy as CLOS; etc.. In this sense, it is brilliant. When you really need very advanced features, you can use external data-structures, defined in C libraries.

CL is a full-batteries included, industry complete (live) system to use in production. Many features are implemented (or defined) using the core Lisp language, so it is still elegant enough. But it is not obviously a minimalistic language.

ECL is a CL, but with a run-time optimized for calling C functions. There is for sure some intersection with PicoLisp domain.

Probably, PicoLisp is an example that you can map the Lisp philosophy to the embedding/scripting world, in a elegant and charm way.

Instead, ECL is an example that you can compile CL to different type of run-times. So CL is a flexible language also from the point of view of the target run-time.

It is difficult to choose between ECL and PicoLisp. But I don't see a problem of fragmentation... (next post)

@dougmerritt

@dougmerritt @screwtape also assuming the worst case scenario in which CL was not good enough for producing the final product, in any case CL was good enough for an initial prototype of the idea (one of the selling point of CL) and moreover the C implementation and the KC3 language took advantage from some of the CL programming language idea.

BTW, PicoLisp followed the contrary path. The author wrote a simple but efficient interpreter, with fast C FFI, a builtin DBMS and an efficient management of external entities. And he used it in projects for his customers.
@screwtape

@kravemir ok, I agree on all you wrote here and previously.

I thought better. For the sake of continuing the discussion... I think that Richard Stallman and FSF were right on many things, but there was a plan from private companies for deriding him/it, and picturing him as a fanatic.

He warned about Tivoization, and nowadays I don't own my Android smartphone. He was right about the benefits of GPLv3 vs GPLv2.

FSF movement can be extended also to all devices and products we don't really own, because we are not in control: e.g. cars, tractors, TV... Or the right to repair them.

Here we are probably on the same page.

I still think that OSS vs FOSS risks to become a divisive and useless battle, despite an honest one.

IMHO, the FOSS movement should focus more on an effective method for funding developers working on FOSS licensed code. Otherwise, choosing a (L)GPL like license can introduce more problems/headache than advantages: many end users do not see the advantages, despite there are, or worse think they are fanatics, and the code is not private-company friendly.

A community owned FOSS code, with a working community funding model, can be a win-win solution for developers and end users.

In other words: you cannot win the OSS vs FOSS battle only from a moralistic point of view. You must create a viable business model.

@kravemir in general, I agree. For example, I think that for many companies the fact that Linux kernel is GPL is a bonus point, respect BSD kernels. Companies can collaborate, knowing that there will be no unfair competition, with closed source forks. So, your considerations can work also for companies, not only for users.

But your considerations can be too much low level for end users (often the philosophy of the community is more important than the perfect FOSS license), and not enough detailed for developers (FOSS licenses can introduces compatibilities headache for developers).

For example: Apache HTTP server is a well known product with a strong community. Who bothers, in this moment if it is using APL and not GPL. In worst case scenario, you can always create a fully free community and fork under a GPL license. See for example MySQL vs MariaDB.

For developers, there can be unexpected problems. For example if you write the perfect btree-library under LGPLv3(+) license, GPLv2 code cannot call the library. And this is unexpected for developers. If you write a Bison-like tool, you need to use LGPL header files, with custom exceptions. And so on. So I can understand, if some developers, with perfect free-software spirit, choose a simpler license like MIT, for avoiding these incompatibilities.

Funny enough, my favorite license would be an Affero-LGPLv3+ but it does not exist. :-) I like LGPLv3+ because: I trust FSF/GNU for next versions of the license (the "+" part); it is compatible with all next (L)GPL products; it can be used in any code with any license, and only improvements to my library had to remain free; end users can always relink/rebuild a propietary product with a better version of my library; the Affero part extends these properties also to cloud services.

@contrapunctus

@contrapunctus to be honest, I consider the FreeSoftware vs OpenSource battle too much confusing. It can be useful on the home page of the FSF for declaring their ethical values, shared by all their licenses, but: for normal users the distinction between FOSS and OSS is too much fine; for developers it is too much unrefined. So, IMHO, it is useful as a marketing tool for the FSF, but not in the face of normal users.

All OpenSource licenses can be grouped in various categories, according their practical effects: the code is forever reusable/free/libre or there can be proprietary forks (e.g. GPL/LGPL vs MIT/BSD); the license is viral or not (e.g. GPL vs LGPL/MIT); the license can be combined with other licenses (e.g. GPLv3 code cannot be used in GPLv3+ code or LGPLv2 code cannot be used in LGPLv3 code); the license is viral also if used in network services (e.g. AGPL vs GPL); do you trust the organization responsible of the license or not (e.g. LGPLv2 vs LGPLv2+); etc..

So, I would always use the term OpenSource because IMHO it won the battle on the mind of end users. Then maybe, if one want to justify the use of a certain license, there can be terms like ForeverOpen (LGPL), MandatoryOpen (GPL), OpenSourceWithRestrictions (e.g. SSPL), but in the end, it is the specific used license dictating the usage scenario of the code, not its marketing adjectives.

Instead Anarchist, Free, Cooperative and other terms are fine if used for characterizing the spirit of a community around a project. Not the software itself.

My 2cents.

@freemo this reminds me https://en.wikiquote.org/wiki/E._O._Wilson "The real problem of humanity is the following: we have paleolithic emotions; medieval institutions; and god-like technology."

@sj_zero I don't comprehend the exact meaning of this sentence, and if recycling vs reuse is intentional or not.

The plastic industry would have us believe that plastic is a highly recyclable material, but in reality, it's not like aluminum, paper, and glass (although there are too many varieties of glass). https://en.wikipedia.org/wiki/Plastic_recycling

@contrapunctus in winter, if you wear a scarf and an hat, the face is covered a lot: many more than a medical mask. This is obviously accepted, because it is a protection from cold and illness. I don't see the difference in wearing a protective mask in crowded places. Is there an alternative way for protecting me and/or others from flu? Why a law should limit my access to simple and effective methods which preserves my health?

They call them "mask", but protective masks are not "carnival masks" or burqa. You still see many parts of the face. If there is a riot or a crime, you still have some hints for identifying someone.

I accept men with massive beards, and women with heavy makeup, so I can accept someone with a medical/protective mask, if I can see some part of the faces.

@m3tti funny enough, it is easier to represent HTML/XML content with s-exprs than JSON.

@codinghorror Business decisions should not affect (one's own) life. Can there be honest and fair business decisions, when life is at risk? At this rate, we'll all be blackmailable at the first moment of weakness and need. The state must not allow this, and it must protect the legality of the free market. /sarcasm

@mirkoh I'm not expert enough to answer. BTW, I'm using Guix both on my local workstation, and for a cloud server, that I administer using "guix deploy". The fact of having a unique declarative configuration file, is a selling point, and probably this cannot be maintained in your case.

In case of a foreign distro, probably the best approach is installing a Writefreely container, without using Guix altogether.

For other services already packaged for Guix, you can also define a Guix system and tell to Guix to generate an OCI container, and then install the container on your host. I never tried this path.

Guix is not mainstream, but it is rather flexible.

@zimoun I should try, because I nevere used "guix pack".

On the same line, before writing the post, I tried also with

guix shell --container --emulate-fhs bash coreutils sqlite

and the pre-compiled Writefreely binary was running inside this shell.

Probably, I can also create directly a Guix system container with the pre-compiled binary, without using Docker altogether.

In any case, I discarded all these reasonable and more elegant intermediate solutions, and I opted for a full "desperate-mode" solution based completely on Docker, because before this, I spent some time trying to package Writefreely without success. So I were burn-out.

This approach is feasible also for all other services with a more complex Dockerfile.

@codinghorror "The Shawshank Redemption" gives me the feeling that if you are serious and dedicated, everything is possible. But, I concede that the context is unusual, and many cannot agree with me.