mzan

An inspirational reply of koverstreet https://lwn.net/Articles/1028572/ He is focused on solving all bug reports, and in iterating bcachefs in the faster way possible. It is a sort of implicit contract with its users base: "you are using bcachefs in production/real-world despite it is experimental, and I will support you restoring files and improving code".

So, I can understand why he doesn't like waiting too much before releasing improvements. The Linux kenernel release cycle can transform weeks in months if some bug-fixes requires new features or refactorings, like in case of a new file system. I'm sorry that him and Linux maintainers didn't find a good approach.

BTW, I used bcachefs for 1-2 years with 3 HDD and 1 SSD in cache. It supported this usage scenario better than ZFS for a desktop/workstation like mine setting.

Bcachefs was not kicked out because its design and implementation is of bad quality. A bad quality software is something that is: full of bugs; every 4 fixed bugs you introduce a new one; the design is so wrong that it is difficult to add new features; the code is difficult to understand.

If you consider various metrics like irrecoverable loss of data, lines of code, features, Bcachefs is a very good project. It is under development, so the source code is not "stable" and there are frequent updates, but the behavior of the file system is fully under control and it is only improving,

Bcachefs seems a really well designed filesystem, because it takes in consideration the lessons learned from other filesystems and its code base is compact and elegant.

It is also very robust because corrupted metadata can be reconstructed scanning the leaf nodes with data. So there are very few weak points in case of disasters. Infact every time there were a report of corrupted data, the bcachefs team was able to fix the code and retrieve the data of the affected users.

I used it for a while, and I were impressed. For example it automatically upgrade its data structures.

It is true that there were a commit of bcachefs that broken the kernel build, because in conflicts with others commits. But this can happen: it is not strictly related to the quality of code of bcachefs, but more to the interaction with other developers, that up to date it is the weak point of the project.

OpenDistro Leap/Tumbleweed/Aeon/...

OpenDistro should identify the community tools used for building the various distro. One distinctive aspect of OpenSUSE is how it is easy to create new distro, or custom repositories. So it should be the focus of the new naming scheme.

You can try also https://gtoolkit.com/ The language is the same of Pharo, but the GUI is better, IMHO.

Glamorous Toolkit/Pharo are better than CL as IDE/GUI. It is more like a "video-game", because the IDE is a first class citizen and you can customize it. For example you can notice if some classes are not passing some tests, because there are flags in the IDE.

As language I prefer CL, because metaprogramming (i.e. macro) are more explicit and clear respect Smallatalk approach.

In CL you have something like "(some-dsl-prefix ...)" and all the things following the "(some-dsl-prefix ...)" are clearly is the specified DSL. You can expand the macro, for seeing its semantic.

In Smalltalk you had to check the metaclass that created the object, but objects can be created in different point respect their usage, so good luck. Then you had to inspect if the behavior of some standard method is modified/customized. CL macro run at compile-time, while Smalltalk metaprogramming code run at run-time, using reflection, and customization of metaclasses.

A CL macro has a better view of the DSL code, because it can walk in it. I don't remember how Smalltalk solves this.

I tried Smalltalk few years ago, so maybe I missed something.

This type of workflow is natively supported by https://github.com/facebook/sapling, https://github.com/jiju-git and https://github.com/arxanas/git-branchless. Both these tools can interact with normal git repositories.

The idea is to divide commits between public commits that are untouchable and under-dev-commits that can be amended, split, merged, reorderdered, and so on. One can play freely with under-dev-commits, because every modification done on them is locally registered, and one can navigate in a tree of undo.

You must see that "in many cases of false accusation, there were two or more women against a man, [and they were lying]¹“ is also not proof of anything.

Yes I agree, but my original meaning is that there are many cases of false accusations with two or more false accusers. So saying that "many women reported ..." is not per se a good enough convincing argument, without analyzing in details these reports and the context. I said this, because intuitively one believe that if there are two or more accusers, then something must be true. Obviously as you said, the contrary is not true: one accuser is not more believable than two or more.

What is your metric for “cases of false accusations”? Are we talking rape cases only?

Sexual abuse in case of famous/important person, where money is involved, and domestic violence in case of conflicting divorces. In Italy, an official document signed by judges, psychologist and other legal operators, informs the Senate that the false accuse (strictly false or exagerated, not simply "unprovable") are presumably from 70% to 90% in case of conflicting divorces. This is the link to the document https://www.senato.it/documenti/repository/commissioni/comm02/documenti_acquisiti/957%20FENBI%20-%20A.pdf

You prefaced your statement with “I would not like many of the women he frequents³”. Is your personal opinion of “the women her frequents” an indicator of whether or not he was capable of raping or trafficking them? Is it in any way relevant at all?

I don't know the women he frequents, but it can be a suspicious context, because there are many rapist, but sometime there are also false accuses. So a proper trial must be done. I didn't know the details, so after reading more, probably he is guilty. I wrote in general terms, because sometime there were cases against famous people like Johnny Depp or Woody Allen were the accusations were not true.

I agree on nearly all, and I admit of not being informed on the details. I disagree on this: I'm not accusing the women, because I'm in favor of a fair process against Andrew Tate, not against the women; the number of women against one man is not a proof, because despite the common sense, in many cases of false accusations, there were two or more women against a man, and they were lying.

I don't like Andrew Tate, but probably I would not like also a lot of women he is frequenting. There are possibilities that they are blackmailers and not victims. So, I hope that Andrew Tate will be convicted on the base of proved facts, and not because he was not able to disprove the words of his accusers. "Proving innocence" can be an hard things to do, if you are considered guilty until proven innocent.

I agree. F# has also type providers (https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/) that are a form of type-inference on steroids, for assigning types to external resources.

IMHO, whenever possible it is better using static typing, but there are real world problems where the nature of data is extremely dynamic, or the types are very complex. In these cases a naive but rigid static type system can be a problem. So in these cases it is better or a relaxed static type system where some constraints can be checked at run-time (i.e. like a dynamic type-system), or a very powerful static type system. In a certain sense, Common Lisp and Racket are examples of the first case, because you can add type annotations to code, so they are both dynamically and statically typed language.