insertcredit

I made a reasonable argument and backed it with referenced facts. Besides the downvotes I received, my main posts were flagged and are now invisible. On top of that, I get low quality comments that add nothing but dilution to the discussion ("Hey did you know I am black?"). Those posts did not get flagged. It's quite clear that the thought police will not allow any discussion on these matters to take place here.

Is this relevant to the discussion? Does it change anything of what I wrote and referenced? Why do you keep bringing it up?

I've been all over the US, NYC is a dump of colossal proportions, a train wreck happening in (maybe not so) slow motion. I live in Europe and parts of Manhattan reminded me of the third world. Hype / reality distortion have a lot to do with NYC being perceived as "vibrant" or "most important".

I defined crapware as something which dilutes the space of good libraries, offers nothing new and pretends to solve non-existing problems. I made my case.

More misinformation here.

Emacs Lisp is a Lisp-2.

Emacs Lisp has lexical scope.

When writing code in Emacs, Emacs Lisp for all intents and purposes can be seen as a subset of Common Lisp, not an entirely different language like you present it to be.

Please try not to propagate this sort of misinformation again in the future. The things you claim are obviously wrong to anyone who has ever used Emacs Lisp, even once. Have you ever done that?

I mentioned the problem Lem claims to solve and proved that there are existing solutions to that problem. I also put forth that Lem is inferior to Emacs/SLIME/Sly when writing Lisp which should be obvious to anyone with Emacs experience. Then I made additional points which at least two people found of interest and tried to provide answers to.

I'm pretty sure all of that does not translate in me not telling you anything.

This post is full of misinformation.

cl-lib.el is not discouraged, it's widely used by Emacs itself and pretty much every substantial Emacs Lisp library out there.

What's discouraged is using an older version, cl.el, at runtime [1] because it replaces existing Emacs Lisp functions and pollutes the namespace. Even that's ok to use at compile time though.

Lastly, cl-lib.el is not cumbersome to use.

[1] https://www.gnu.org/software/emacs/manual/html_node/cl/Organ...

One persistent problem I see in the Common Lisp (love the language!) space is the wide availability of crapware that not only doesn't bring something new to the table but is actively damaging to the community since it's diluting the set of good libraries and making it harder for new users to tell the wheat from the chaff. Lem is crapware. The problem it's supposed to solve, writing CL without configuring Emacs, is not a problem since there exists Portacle [1]. Lem is inferior to Emacs/SLIME/Sly in every way especially for writing Lisp. Lem has no future. But it exists and may act like a strange attractor to those who don't know better.

A question I'd really like to find the answer to: Why is there so much crapware for CL?. Why doesn't the community come together behind the few, really good, libraries but instead almost everyone goes out and does his own thing, the end result being an ocean of crap.

[1] https://portacle.github.io/

Immersion is the killer feature of VR, not standalone graphical fidelity. FOV, 6DOF tracking are far more important today than 4K per-eye resolution and 120 FPS. Moreover, foveated rendering will give us drastic graphical fidelity improvements, in the very near future.

Like you I think the Quest will change everything. I feel that it has to, at this point, for VR momentum to break through. Do you think Oculus will dominate the space in the coming decade? I can't help but be reminded of Sense/Net from Neuromancer as a potential VR-only business with massive upside and potential (userbase in the hundreds of millions if not billions) that can be done _today_ if VR headset proliferation went beyond gamers. I am thinking if Carmack and Abrash can't get it done, chances that anyone else will are slim, at least in this generation.

One fact that's seldom reported is that RTM's father, Robert H. Morris Sr, started working for the NSA in 1986, two years before RTM unleashed the worm. Food for thought maybe?

First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language.

Second, unsubstantiated proclamations like "Overuse of them led to LISP code being hard to read" reinforce the previous point. Could you provide a clear reference where Lisp macros are considered "mistakes of history"? Clear references where overuse of Lisp macros turned out to be a problem?

I'm curious if you've ever used a Lisp development environment with facilities such as interactive macroexpanders or if you're just assuming things based on your (incomplete, suspect) understanding of the domain.

I am not sure I would call cranelift "substantial" in terms of exposure/usage. From what I gather, it's not used at all for normal, everyday Javascript.

I stand corrected though, every little bit helps. Here's hope they'll start using Rust in more places where it counts.

Not bad but a little bit of a publicity stunt.

A major source of vulnerabilities is (still) the Javascript engine and that's (still) written in C++.

Even worse, as far as I know, Mozilla has no plans to rewrite even parts of Spidermonkey in Rust.

For some recent examples:

https://usn.ubuntu.com/3688-1/

https://usn.ubuntu.com/3749-1/

I've spent enough time (not much) with urbit to write a Nock interpreter/compiler. There are aspects of it that rub me the wrong way such as the needless custom terminology and general esoteric nature that sometimes reads like an occult grimoire but I also think that a lot of the criticism aimed at them, especially the politics, is misguided. Having watched Yarvin present on urbit a couple of times, I would say he is mostly driven by the intellectual atmosphere of the early Internet, before the masses moved in, thus his attempts to not "cast pearls before swine" by making things too accessible so to speak. I do not agree with this stance but I can certainly understand it without having to resort to conspiracies. Other than that, he most definitely reinvented Lisp, badly, but I am willing to give him a pass there too. There is nothing at all that attempts to make real the vision behind urbit around today and I do think it is an interesting vision. Finally, Alan Kay likes it.

I've known you (from your posts at comp.lang.lisp) to be eager to present the facts as you see them and thorough in your argumentation. What is it about Urbit/Yarvin that merits this sort of post?

I will copy my post again, here, to expose your strawman or unwillingness to stop deflecting:

"One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ... Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do."

This is the post you replied to, with arguments that (still) hold no merit. Now you are trying to shift this into something else rather than stick to the points I made _in this thread_. You pick and choose a reply of mine _from a different thread_. Moreover, you write: "This whole thread is a discussion of the relative complexity between sysvinit and systemd". No it is not. As I wrote: "The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture."

I would take you more seriously if you stopped presenting one logical fallacy after another.

This is disingenuous, systemd-journald is the default in every systemd-using distribution I am aware of. The philosophy of systemd is all about tight coupling and forcing its singular vision on end users. When that vision falls apart you can not claim it is not really a systemd problem because in theory you could have gone out of your way and done something that is not encouraged.

You are using logical fallacies in your argument.

First, not _everyone_ has adopted it (loaded language). Google, which controls the vast majority of Linux systems on the planet, has not. GNU has not. Others [1] have not.

Second, the critique against systemd is substantial and solid enough to stand on its own regardless of popularity. Popularity does not imply quality, you should read "Worse is better" by Richard Gabriel. Politics, network effects and an octopus-like architecture that imposes itself via ever-increasing interdependencies are reasonable explanations to systemd adoption. For a distribution provider or package maintainer, it has gotten to the point where it's easier to go along with systemd than try and fight it, since the latter option means extra work. This is really a sad state of affairs.

[1] http://without-systemd.org/wiki/index.php/Main_Page

"Closer in spirit" does not mean anything tangible in the real world, you are merely playing with words.

Solaris SMF is vastly simpler than systemd and has a much narrower scope and focus. I don't recall mentioning bash scripts in the post you replied to, so you are simply being disingenuous by presenting a false dichotomy.

The fact that people keep repeating the "messy shell scripts" fallacy is proof of how effective systemd propaganda has been. The vast majority of Linux systems on the planet, which ship software made by Google, do not run systemd.

One gets the impression that optionality is only theoretical. Same for separate binaries. The degree of coupling in the systemd architecture is enormous. So then, what purpose do separate binaries serve other than being able to (conveniently) be used for deflection or provide a certain facade?

The philosophy of systemd exemplified through PRAXIS is one of subsumption and uniformity (== taking away choice) under a singular vision defined by the systemd implementors. In practice, this means that you are penalized in various ways if you don't "buy in all the way". You can take a look at all the distributions that ship systemd by default and see how many have bought in all the way vs not using the "additional functionality".

At least as far as Debian is concerned, you will find that the people with skin-in-the-game (administrators) were massively against systemd. The Devuan fork/split happened exactly because of that.

One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ...

Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do.

The complexity of Sysvinit is orders of magnitude less than that of systemd.

Devuan is a Linux distribution that does not ship systemd by default.

You are comparing apples and oranges.

Fully agreed. There has been a race to the bottom regarding technical competence by various entities for various reasons. To me it seemed at the time that Redhat used dark-pattern-like behavior in order to push systemd, exploiting people's hopes regarding a more unified Linux ecosystem.

There is nothing wrong with making things easier to use. The problems begin when the people you put in charge of that effort (Poettering and co) are extremely short-sighted, do not properly understand what came before and thus make mistakes that could have easily been avoided, are average-at-best engineers with a personal history of bad projects (pulseaudio, avahi), are bad communicators and take valid critique poorly.

When I was still at Google, colleagues at Android and ChromeOS teams laughed at the mere mention of systemd. The general consensus in the teams I mostly interacted with was that systemd resembled a hidden iceberg with enormous problems, the magnitude of which would slowly become apparent. Which is one of the reasons Google has mostly kept away from it.

If you don't grasp bash after two decades of Linux experience, you should maybe question yourself as to why that is rather than blame bash. Maybe you never properly spent a few days fulltime trying to learn it?

I'd take bash scripts without hesitation over systemd any day of the week. I can debug bash with my eyes closed. Every single time I had to debug systemd, I wanted to kill myself.

Launchd is nowhere near as bad as systemd and doesn't suffer from the latter feature creep.

I refuse to use systemd to this day. It's unbelievably complex and became established through political power play rather than any sort of merit. Which is without a doubt not what I expected to see in the Linux ecosystem.