tutfbhuf

Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust.

I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C modules in Python if you need the speed, but I don't know if that's a good answer to the problem.

Are there any languages that provides memory leak safety, so that the compiled binary is guaranteed to be memory leak free?

Maybe there will be a company like Red Hat that announces to support python 2.7 indefinitely, although I doubt it.

But why? WSL1 was something like wine but reverse, but WSL2 is actually linux.

Wrapper functions. If you want to extend or modify the functionality of already existing tools, but without altering them too much, so it wouldn't be worth to be a new tool on its own.

Can't remember the Headline, but it was something regarding Microkernel usage on constrained devices. In case the most stripped down version of linux does not fit.

Nintendo has used microkernels for the Nintendo Switch, I think it would be interesting to see if microkernels would also fit for the N64 or similar constrained devices.

> If your service is only provided by one machine then you have to accept it will occasionally be out of use.

But, I can minimize possible downtimes, by learning from other downtime reports on a bug tracker.

Sure, for most (including myself) it's impossible to review every little update. But the bug tracker of your distro is a good indicator if some of the most recent updates created a bunch of new tickets, especially those that are considered to be critical. In case of Arch Linux it is strongly recommended to read the latest update news on archlinux.org, before update.

In addition to that you get some experience over time which of your package updates caused most trouble in the past and you can take additional care. For example, I know that on my desktop the combo of displaylink and xorg does break from time to time with updates, therefore I carefully lookout for issues regarding xorg updates for displaylink users, before I do the xorg update.

Some people only have one server for a particular use case.

And servers might not always break in predictable/alertable ways.

> Configure a cron job or init script to update your system daily.

He recommends daily automated updates. This is quite dangerous from my personal experience in various distributions. An update might break your system or might put it into a vulnerable state. I very much prefer regular manual updates, as it allows me to read release notes, bug reports and manual user intervention instructions before update.

True, the Pi 4 with 8GB RAM would allow for 8 TB max recommended storage per node. Thus, requires you to have 7 Pis for 56 TB. I think that's still a good setup, even with 1GE.

btw, 10GE is the minimum requirement for a non-hobby ceph cluster

What does it mean to be FCC-certified?

TL;DR Node.example.com is an IPv6 adresss.

> I know it’s not there in your original comment [and I'm sorry that I have abused the square brackets in such a way, that it changes the meaning] ... My apologies there.

[No problem.]

Sorry but, Wisp already exists, twice! It's Lisp without parentheses:

http://dustycloud.org/blog/wisp-lisp-alternative/

and a little Clojure-like LISP in JavaScript:

https://github.com/Gozala/wisp

Execpt that you entered "[in the Switch]" from your own imagination and it's simply not there in my original comment.

> Nintendo actual devices use microkernel based designs. We are way past the usual FUD against microkernels.

Regarding pjmlp post, yes that's true, it wasn't clear (and still isn't) to me from his post, that he specifically speaks about the Switch when referring to "devices".

Ah okay, I somehow thought that Nintendo had used microkernels on other devices too, not just the Switch. The Nintendo Switch is certainly not a constrained device.

> I mean we could have this argument about how dozens of ancient / partially POSIX-complient / unstable kernels have had low footprints. But that's not really a credible argument if you can't actually use them in any practical capacity.

There are modern microkernels that are POSIX compliant and have a much lower footprint than linux. That's not the problem. I think the most prominent issue, people points out here is performance. However, it's very obvious to me that the extra abstraction of having a kernel vs having no kernel on an constrained device costs performance, and it's always a trade-off, both solutions can be found and both solutions are valid.

You could buy drives with higher capacity, then you need fewer RPI, fewer cables, consume less space/energy and still achieve 55 TiB capacity.

> And it’s rather disingenuous how you keep rocking back and forth between current generation consoles

I never did. I never mentioned current generation consoles not even implicitly. I always talked either about the N64 or (gaming) devices that are constrained and cannot run linux.

> However on the N64 you don’t need any of the benefits that a micro kernel offers while you do need to preserve as many clock cycles as you can. So a micro kernel isn’t well suited for that specific domain

How come that Nintendo decided to use them (according to reverse engeneering finds)? If they are not suited, then Nintendo should know that right?

laumars, I think what I'm missing to hear from you is why microkernels are such a bad and horrible idea and more importantly why Nintendo itself is mistaken if they had used them on their devices. Otherwise, I still think they are a good fit.

> Games consoles are about as far removed from a constrained device as you could possibly get.

It seems to me that you are always ignore low-end devices and very old devices.

If we are talking about an PS5 then yes, this and similar devices are not very constrained, even a full blown Kubuntu might run on some.

But, again there are low-end gaming devices with a tiny black and white screen for 10 dollars and old gaming hardware with very tight constrains. The N64 is certainly one of those constrained old gaming devices.

Even if unconfirmed, I think that Nintendo might use Microkernels according to reverse engeneering finds shows their massive potential for constrained devices. Although certainly not for performance reasons.

> Nintendo actual devices use microkernel based designs

That's very interesting, can you provide a source?

The problem is that you can only slim down linux so much. If the tiniest possible linux does not fit on your chip, then it simply does not fit, end of the story for linux in this case. However, there are tiny microkernels e.g. with less than 50.000 lines of C code that can fit on such a device + leave some room for a small application e.g. also smaller than 50.000 lines of C that also fits. This is all I want to say. And yes, I agree with all the other points/drawbacks including performance that people mention here.

> So not just low-end, but a decade old device that was already low-end upon it's release. That's hardly a fair argument to bring to the discussion.

Fair enough, I agreed that I should have come up with an better example. But before going down another rabbit hole, just replace router with any modern embedded chip you like, that cannot run linux as example.

Regarding QNX, I don't know their current requirements but what impresses me:

"To demonstrate the OS's capability and relatively small size, in the late 1990s QNX released a demo image that included the POSIX-compliant QNX 4 OS, a full graphical user interface, graphical text editor, TCP/IP networking, web browser and web server that all fit on a bootable 1.44 MB floppy disk."

> I should caveat that by saying, yes it's possible to write something partially POSIX compliant which could target really small devices.

Yeah, I think here's a interesting overview of some http://www.microkernel.info

I wonder how many of them are POSIX compliant (or partially) and what their requirements are. GNU/Hurd certainly is.

> How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though.

This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices and date models here. I cannot recall the model number, but I think we both agree that routers that cannot run linux exist, although not very common (anymore).

> Any OS designed around kernels, memory safety etc would be useless in general for constrained devices.

How about QNX then?

"QNX is a commercial Unix-like real-time operating system, aimed primarily at the embedded systems market. QNX was one of the first commercially successful microkernel operating systems. As of 2020, it is used in a variety of devices including cars and mobile phones." - https://en.wikipedia.org/wiki/QNX

They are "aimed primarily at the embedded systems market", their latest release is from "7.1 / July 2020; 5 months ago" and they are operating their business model since 1982.

> By the way, you wouldn't find any routers running a meger 512KB of RAM.

This is not true in general, although true for modern devices. There are older router models that cannot run linux. A few years back I unsuccessfully tried to flash a very minimal <1 MiB linux on an old TP link router. I was able to flash the rom but I couldn't boot, because there was not enough memory available, it wasn't 512KB but only a few MiB IIRC, still not enough.

> We are just pointing out that you massively misunderstand how micro kernels work

If someone points out, that linux kernel can be reduced in size and that there are some big microkernels, then I do agree and there is no misunderstanding, as far as I can see. Same holds true for the performance argument.

> As the GP said, micro kernels have a performance overhead swapping data between rings.

I agree that performance will be problematic, but this does not render microkernels useless in general for constrained devices. See for example: https://technik.community/2014/07/micro-kernel-the-best-choi... https://www.scirp.org/html/3-9301550_27477.htm