evol262

Yes, to all of those, though some take more work than others.

It says a lot that "systemd vs init.d" instead of "systemd vs sysvinit" was there.

The question is not about the ecosystem, though, but about the kernel itself. Yes, there are embedded vendors (mostly networking equipment, and especially routers) who violate the GPL by not complying, but generally speaking, hardware vendors who choose Linux publish sources.

Those sources may not ever make it into mainline, but the device trees/drivers for embedded stuff does provide a reference for a cleaner, better implementation.

Compare to FreeBSD for the Playstation's management layer. Where are the contributions for Cell support? Where are the patches Sony certainly needed to make for wifi and bluetooth? Where are the patches from Juniper for validated FIPS?

> OpenMdev.io is meant for developers, not for users.

Frankly, it isn't meant for developers, either. Almost every page on that site is either woefully incomplete, or crib notes from docs/talks, which is fine for a high-level overview, but it's not an API reference developers can use either. The sample code is mostly just lifted from other places (such as https://github.com/torvalds/linux/blob/master/samples/vfio-m...), so useless you're better off reading the source (https://openmdev.io/index.php/OpenRM), or just links to other people's APIs which interested devs can find.

It's fine to collate this, but it's far more like someone's personal aggregator than any kind of reference site.

> No, it's a Libvirt alternative with convenience functions for VFIO users. Here's the documentation:

> https://openmdev.io/index.php/LibVF.IO

I read this before I ever wrote a reply, which you should have guessed because there was no other way to get any information. None of it tells anyone WHY this should use this instead of the bindings which have 100 developers on them, which have been battle tested for years, and for which the original author of VFIO wrote exhaustive, excellent manuals on the blog I linked earlier 7.5 years ago.

What advantages does your system offer?

> GVM/Mdev-GPU is unrelated to LibVF.IO which I think is where you're getting confused. LibVF.IO does not actually have any integration with GVM/Mdev-GPU so if you're reading that code you're not going to learn how GVM/Mdev-GPU works. We're planning to integrate the two but it's not done yet.

I'm not confused either about how GVM/mdev-gpu works or about its relation to libvf.io. It's not hard to read between the missing lines of your project roadmap.

> GVM/Mdev-GPU creates the mediated devices that are exposed in the mdevctl list. Read this code instead: https://github.com/Arc-Compute/Mdev-GPU/

I did read that. There's nowhere else I would have said "Haskell bindings to RMAPI". I didn't call it anything else because it doesn't manage any other kind of mediated device, it's a pretty thin shim, and there's no real way to suss out what it's doing other than reading the code or the autogenerated module docs, which don't actually tell any developers where to get the values they need to populate it, which they can only get by reading other API docs (not yours), and if they're going to do that, they may as well just write their own in a language they like better.

It's not clear from the outset what the advantage is over just submitting a PR to mdevctl to echo into /sys/devices/..../[create|remove], and overall, the README doesn't give any information about it whatsoever, even `--help` output to show the args and defaults.

> Sure, arcd is a reference Virtual Machine Monitor as it says at the top of this page: https://openmdev.io/index.php/LibVF.IO

No, it is not. Point blank, it is not. libvirt also isn't. Even qemu isn't for hardware virt, and you're not doing IOMMU operations on emulated CPU calls. kvm is. It's a toolkit to manage virtual machines, maybe.

This does not answer the question at all of "why not libvirt?"

> It's actually unrelated to GVM. You can use GVM with whatever you want, including Libvirt/Virsh/Virt-Manager because we wanted to support users of those things with GVM rather than requiring that they use LibVF.IO.

It's unrelated... for now. And there is zero reason to use this instead of libvirt hooks which were written by and are tested by teams which already do this for libvirt (which virsh and virt-manager are just interfaces to anyway).

Again, I'm not saying this to be critical. There are plenty of libvirt-based projects out there which would welcome a standardized tool which they could all use as an entrypoint to this, because libvirt strictly does not (and will not, even with modularity) cover this use case rather than everyone re-inventing their own tooling to handle creation. It is unlikely in the extreme that the current state of GVM will work for anyone else's use case, primarily because "give me the UUIDs of existing devices" is already handled by walking /sys, and creating a new one of a given type (or removing it on VM shutdown) in more or less the same way.

GVM isn't built in a way which is usable by any other project. That's ok, but it does nothing to explain the design decision.

> Well, we do create mediated devices exposed in mdevctl defined by a user config file, so I would say it goes a fair amount beyond Haskell bindings for the RMAPI. I think it's reasonable to describe a GPU mediated device as a virtual GPU given you get a virtual function that represents a scheduling share and virtual BAR space with a share of the device VRAM (partition of the GPU) which you can pass to one or several guests to allow them to run an unmodified guest GPU driver. I can't really think of a better definition for a vGPU. The Mediated Device Internals article pretty much explains the APIs GVM is dealing with - I believe we even link some sample code: https://openmdev.io/index.php/Mediated_Device_Internals

You create mediated devices for nVidia devices by sending ioctls exposed via RMAPI. This is potato/potato. The explanation you just gave STILL makes it sound as if this is a novel thing done by GVM/mdev-gpu rather than something common, and talking down to someone who is asking informed questions about why you did it this way by linking to internals (when I was physically there for most of those talks and helped write some of the docs) doesn't paint a pretty picture.

> Your comment seems kind of trollish so I'm not really sure what benefit continuing this thread has. I think most of the stuff you're asking about is more or less documented and spelled out as openly as we're able to. What we're trying to do here is to make this stuff more open and available to people rather than locked away behind binary blobs. More or less everything we do is put into our wiki with very few exceptions. OpenMdev.io is made to be open to our community of folks working on Mediated Device/IO Virtualization functions on various projects so if you're a developer on this stuff and think anything is lacking you're welcome to contribute or suggest it to us in our IRC or Discord. I'm sure there's always room to improve and we put a ton of effort into trying to listen to feedback and improve upon things ourselves as well as accept contributions from others

NONE OF THE STUFF I'M ASKING ABOUT IS DOCUMENTED OR SPELLED OUT. That's the point. From someone who was a maintainer, engineering leader, etc on a major open source virtualization platform who literally wrote code which does this kind of scheduling/creation across a cluster, I am telling you that your documentation is opaque, misleading, takes credit for things you did not invent, doesn't explain your use case, doesn't explain why you re-invented the wheel, doesn't explain why there's a gaping "missing middle" between "here are kernel sources/function signatures in drivers and here's a tool" (where that "missing middle" is /sys/devices/.../mdev_supported_types[/...] and "echo|uuidgen"), etc.

This is, or could be, a great start to a unified ecosystem. You are going to have a very hard time getting a developer/user ecosystem if you do not provide better documentation, "what these tools do", find a way to talk with other virt developers without condescending to them, present usable interfaces other projects can call which are not "here is YAML/JSON to operate on with exec()", etc, and most of all, to acknowledge the work other have done/the knowledge they have rather than presenting any of this like it's brand new or novel. It could be a great utility. Or it could be something no other project ever uses. That's up to you.

My comments are not intended to be trollish. They are intended to tell you "as someone who has written very similar code and done very similar things for a long time, the only way to figure out what the hell any of this was supposed to do was to literally read the source and make educated guesses". The average developer/user is not going to have the knowledge base to make those guesses at all, but they may see references to "arcd ..." like it's "developer documentation", go find it, and ask "why the hell is this managing qemu directly instead of libvirt", or "why is no libvirt XML/qemu hook provided"?

These are real problems for the project. Docs, always, for every project. I know yours is new, but these are of unusually low quality for a submission to HN, and doubling down with links to the same inadequate docs like everyone you're talking to is a moron doesn't help your reputation. Additionally, examples. And reach out to others -- proxmox, ovirt, xcp, openstack (nova). See if you can collaborate. This will mean using (or at least providing) libvirt bindings/XML snippets like everyone else. It will be worth it.

> Intel's Xe embedded SKUs are supported:

> https://openmdev.io/index.php/GPU_Support

I'm not trying to beat a dead horse here, but your matrix links to an archive of Intel's community forum, where it's a basic question, about Windows.

https://archive.ph/0McAE#selection-4883.0-4943.35

Then a link to Intel's LTS Linux repo. Do your scripts, if it's Xe, actually clone/build this and boot into it? What does "supported" mean in this sense? Do you replace the user's kernel with the intel-lts fork? If so, do you tell them?

> We did some things to enable GPU virtualization on older driver revisions for most Nvidia consumer GPUs and some AMD GPUs as well. Here's that post if you'd like to take a look:

You have some patches to drivers. Which is great. But "we did some things" on HN is best followed with "here's what we did from a technical level" or "here's the source", not "here's how to install our product".

https://github.com/Arc-Compute/LibVF.IO/tree/master/patches

Is there anything at all here which isn't applicable to other KVM-based virt platforms? It looks like not.

> We're building a free/libre (AGPLv3 & GPLv2) virtualization stack intended to support i915 (Intel) and Nvidia (OpenRM).

Again, this is great. But please be clear that "we're building a free/libre virtualization stack" is "we are building a very opinionated wrapper around qemu+KVM which is not using libvirt bindings for some reason". The "stack" definitely looks like "some utility scripts to make this easier".

Is there a project homepage with a roadmap, goals, and issues/bugs, and so on?

> Hey, OP here. Sorry I didn't get to this sooner as I posted this just before falling asleep. This comment basically hits the nail on the head in most areas. I am happy to say though that Intel now uses SR-IOV instead of GVT-g (deprecated since 9th generation Intel). Their replacement SR-IOV driver is now Open Source (recently made public):

This would legitimately be ideal information to have in the readme/top-level link.

> https://github.com/intel/linux-intel-lts/commit/41ef979f0894

This is pretty unhelpful. Legitimately. It's not mainlined yet, there are zero userspace docs, etc. The patch looks like it will pretty much "just work" when/if Intel bothers to get it into mainline. Until then, a patched/forked kernel is needed.

> Also to address the first comment in this thread - there are many inaccuracies here:

> Post-Ampere supports MIG and SR-IOV. VFIO-Mediated Devices (Mdev) are used both pre-Ampere and post-Ampere. This is how that works:

> https://openmdev.io/index.php/Mediated_Device_Internals

I maintained mdev support for a major KVM-based platform, but it's been a couple of years. That said, a link to how mdev internals work isn't useful to end-users, who just want to know "how do I partition my card"? As-in "which driver/utilities do I need to install"?

> For folks who are interested we also built LibVF.IO which enables vGPU/SR-IOV functionality on consumer GPUs:

> https://news.ycombinator.com/item?id=28944426

> If you're interested in a full list of supported GPUs you can read the following page from our wiki:

> https://openmdev.io/index.php/GPU_Support

Is there some way in which LibVF.IO differs from just being a wrapper around KVM/qemu? Because the scripts do an awful lot of stuff to your host system, and arcd.nim appears to just call qemu anyway: https://github.com/Arc-Compute/LibVF.IO/blob/master/src/libv...

Sure, it also binds/removes mdev devices, which is a nice convenience, and you have a couple of patches applied to the nvidia driver sources, but asking users to blindly execute scripts they have to wade through to find out exactly what they're going to do in kernelspace, plus the system. It's... asking a lot.

You're adding a virtual sound card, nim, shell aliases, samba, plasma, then blindly overwriting any kernel options the user has set without even the good grace of capturing them and appending them: https://github.com/Arc-Compute/LibVF.IO/blob/master/scripts/...

> Also finally this tool has nothing to do with nvidia-cli or mdevctl. It defines available mdev devices in the mdevctl list, it does not replace mdevctl.

It looks like it does a lot more than that, and less than that. It has nothing to do with nvidia-cli (which can also manage mdev devices), and "defines available mdev devices in the mdevctl list" only as a side effect of the fact that it's doing a whole bunch of other stuff to the system.

I'm not trying to tear down your project, but honestly, the docs could be far, far better about what this actually does, how it does it, which pieces you actually need, etc. Because it certainly looks like all of the system configuration could be done with ansible/terraform instead of shell and published as an associated project and/or prerequisite steps where users would be informed of what's happening to their system.

Similarly, it strongly appears that arcd could be more or less replaced by any given binding to the libvirt API, which would also allow the VMs to be easily migrated (assuming identical hardware), the libvirt XML shared with others, snapshotting, storage pooling, listed in virt-manager/virsh, and so on.

As a basic open source citizen, this would also help in "giving credit where credit is due". Bravo for stitching all of this together, but the project pages/repo certainly make it seem as if LibVF.IO/GVM did the work, and that's not really honest.

GVM, rather than "a GPU Virtual Machine ..." is Haskell bindings for the RMAPI.

LibVF.IO is "Utilities KVM+qemu VMs with vGPU passthrough for humans"

If there's a mistake here, please correct it, but going through the repos, it looks like a whole lot of glue. There's nothing wrong with that. It's still valuable. It's just that all of the work you did in researching/testing/building it could (and arguably should) just as well go somewhere like where one of the original devs working on vfio/GPU passthrough posted a five page braindump of everything you'd ever need to know which people have been shamelessly cribbing from (on the Arch Wiki and others) for years, maybe without knowing:

http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part...

It would be extremely valuable to the community to document HOW end-users can tweak all of these knobs WITHOUT windmill slamming a bunch of packages from scripts in your repo and relying on your nim glue to do it.

> More complex than that. MIG covers compute use cases only. For workloads where graphics are needed (or even the graphics APIs), you have to use preemptive scheduling, even on Ampere.

Thanks for the correction! Shows how much I've really used it outside of "does nvidia-smi do the right thing, and can I map those to pods". I had assumed that, since nvidia-smi on Ampere did both GPU and CPU slicing, that maybe they found a solution which allowed them to sidestep all of the inherent problems with trying to share GPU memory, but too much to hope for.

> No. It's gone on Gen11 and later. :/ And no replacement yet.

I've been relatively distanced from the nitty-gritty parts of GPU virt for a couple of years, but how/why did the end up pushing for root SR-IOV support for Xe along with patches for ReBAR at the same time as they dropped this?

https://www.intel.com/content/www/us/en/support/articles/000...

I guess they'll gate it behind enterprise dGPU SKUs when/if they ever release. Welp.

> The OSS NV KM stack doesn't support GPU virt at all yet.

I would have thought this also. As bad as the doc in the link is, it does explicitly reference OpenRM verification. I wouldn't trust nVidia's "big ball of hardly-commented source" for anything yet, but at least it is the "real" driver and not Nouveau, so I'd expect GPU virt to be supported, even if the code may be inscrutable.

I'm really just waiting for the HN link to confirm/deny the long-held suspicion that nVidia suddenly got really good around the same time SGI was in its death throes, and that the reason they resisted opening their drivers was due to routines with... questionable IP.

Looking Glass is kind of the closest you'll get for a trivial "I want shared GPU virtualization on my workstation", but GPU partitioning doesn't really work that way. Outside of the baseline support in the hardware itself, which is nowhere near generic enough for "works on any GPU" (it took supervisory frameworks to even get CUDA/OpenCL/etc to a point where you can stop worrying about writing transforms from scratch and just let PyTorch abstract it a little), this model of GPU partitioning doesn't perform well.

How do you allocate vGPU memory between a ML/AI VM, a VDI VM, and a gaming/CAD VM? All have dramatically different requirements. You also can't think of shader/GPU cores in any way similar to CPU cores. They're essentially just vector/linear algebra accelerators with little to no branch prediction, speculative execution, or anything else you'd expect.

Otherwise, you can sort of follow along here: https://openmdev.io/index.php/GPU_Support

There's an effort, but it's far from where you want, and there's no indication it will get there unless you can get all the vendors to agree on a standard at some point in the future.

This summary page is absolutely terrible.

It appears to be an open-source implementation of nvidia-cli for managing mdevs, which is arbitrarily nice, but it's not clear to end-users what this means.

Pre-Ampere GPUs (Ampere+ is MIG) were able to use the mediated device subsystem to partition cards into time slices. It's similar to SR-IOV, except that you can specify the size of the partition with more granularity than "give me a new virtual device".

Intel has GVT-g, which is reasonably widely supported on Gen12 and above (edit: too late/early -- Gen11 and earlier, not Gen12 and later -- thanks to my123 for the correction). nVidia had vGPU/mdev, and newer generations (Ampere and later) use MIG. It's unclear whether this supports MIG at all. AMD uses MxGPU, and they've never really cared about/pursued anything related to this, probably because their datacenter penetration is about 1%.

MxGPU is only supported on some FirePro cards. mdev was largely on GRID cards (mostly Tesla, some Quadros). MIG is on AXXX cards.

It's unclear why anyone should use this over mdevctl, which already supports GVT-g, and it's also unclear whether this is tied to the (very much "don't use in production") open source nvidia drivers.

For end-users, GVT-g, getting a cheap older GRID card, or using Looking Glass for your GPU are all more reasonable options.

This effort is great, but the readme is appallingly short on information even for someone who knows the problem domain.

This looks like a good first contribution.

hostnamectl DOES talk to sd_dbus, which DOES require systemd, which DOES require being PID1, and this message only pops up if you're in a container without the full subsystem running, access to the right cgroups, etc.

The naming is simply part of how dbus structures things, not to say that it's not part of it. I'm sure that, in retrospect, they wish they would have used "org.systemd...", but hindsight is 20/20.

If there's a scenario other than container without the right mounts/etc where this can come up, you should file a bug. If there isn't, you could see if you can submit a patch to improve the message.

It's not an indication that systemd confuses concepts. Its can indication that a) dbus is kinda shit, and b) I doubt if the systemd mapped out hypothetical dbus names 5 years in the future.

> I don't think we're going to reach and real agreements here, a lot of these things are going to be subjective. I think there's a certain amount of "if everyone around you is an asshole maybe you're actually an asshole" but I doubt I'm going to be changing anyone's minds today.

I don't think we'll reach any real agreements either, but I also don't think it's all that subjective. We could say my perspective is skewed from being "behind the curtain" for a decade, but it's equally true that I'm dramatically more informed about the economics and realities of open source contributions due to it.

Redhat was (and likely still is) a collection of engineers who are passionate about open source, and get paid to work on it. For a long, long time Redhat paid below the market average. It was not a place you went right out of college. It was a place where people who really gave a damn about open source went because the money was enough, and they got to work on something they felt was actually making software better.

It wasn't some corporate machine, it wasn't particularly profit-driven, and it definitely wasn't somewhere where the engineers wanted to push some corporate vision of how Linux should be. As of maybe 2017 or 2018, we started hiring more "new grads" and pivoting more to cloud workloads (outside of what Openstack already had), but the fundamentals didn't really change.

The perception of what Redhat is/was and what they actually were/are? is very different. It wasn't a perfect place, and the best ideas didn't always win, but at least you always felt like you could voice them, and you never felt like you were railroading a project to build a "moat" around some business model. Good projects got a lot of developer/admin/ops mindshare, and those dominated the market, so you should write good software which people will like/use. It wasn't complex.

One of the things which I miss the most (outside of being surrounded by people who were passionate about software ethics) is QA -- Redhat's QA is, in no small part, what has kept software quality high.

> That being said there is a bit of hard data, this post nicely shows gnome contributions over time, as less and less non-redhat developer contribute.

> https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...

> Now I'm sure you have a dozen explanations lined up for why that might be the case, most of them involving how good redhat is and how they're a bastion of light all that, which sure I have no way to definitively prove that there's any malfeasance going on.

Try not to turn people into strawmen.

The likely explanation is that GNOME has gotten much more complex and harder to contribute to, and the divide for new contributors to meaningfully fix bugs or add features has gotten wider as GNOME3 has stabilized (and bloated a bit). There's a clear pike just before 3.0, and it kinda declines after that, but some of the other major contributors (Ximian, Collabora, arguably Sun) aren't players anymore.

The other missing piece of data here is that, outside of the kernel (which gets a ton of contributions from hardware vendors submitting code to support their own stuff), you'd find the contribution ratio to be shockingly similar. glibc, openssl, and a number of other core projects are also more Redhat than not.

That doesn't mean they're trying to control the ecosystem. It means that, yes, it contributes to the company's bottom line, but you shouldn't assume that the contributions have a motive any more sinister than any other contributor.

GNOME's image problem is the same as GNOME's image problem always was, but we really haven't been talking about that. I'm not trying to defend Redhat or call you an asshole, but the amount of commits Redhat makes to open source projects all over is not subjective, that they get those commits upstreamed into projects they do not control is not subjective, etc.

Don't let your personal opinion about Lennart color what Redhat engineers do for open source or to paint all of them with the same "corporate peon building a 'moat' brush" (which also doesn't describe Lennart).

You don't agree with some of the decisions the communities made. That's fine. That's open source, too. It doesn't mean that you're right and Redhat is some Benedict Arnold scheming for control.

> project maintainers and project contributors don't agree. News at 11

This is just open source. "kernel maintainers hated working with the pulseaudio team" is not news any more than "Theo de Raadt/Ulrich Drepper dislike some ideas of others". It is part and parcel of open source development. It doesn't need 'whitewashing'. This is how quality software is built.

Conversely, even referencing that the LKML was full of angry messages (again, LKML having drama is like the sky being blue) about pulse (or kdbus from the systemd team, which is also a thing) is just evidence that Redhat did and does work with upstream rather than having some walled garden which they jealously guard from the rest of the community.

This is the opposite of how it worked. Again, I left a couple of years ago, but the methodology was "get a bug/RFE downstream, reproduce upstream if it's still there or implement the feature, get it through code review and merged into the codebase, cherry pick it into RHEL, making whatever changes are necessary".

Fedora is approximately as "vanilla" as Arch. If any patch was in a Fedora package which you had to pull out, it's because upstream did not accept the patch for some reason, but the maintainer decided it was critical enough to diverge. This isn't/wasn't SOP.

The Linux kernel patches are, as above, not really where they make money, which is consulting. But there is no such thing as an "upstream stable release" which Red Hat contributes to in any meaningful way.

Kernel features which are going to go into Fedora go into mainline. Not the LTS release. RHEL's support policy has a somewhat strict SLA on kernel ABI/API, and their support cycle is much longer than upstream "LTS" which "everyone else" (whomever that is, because Canonical and SuSE have policies similar to Redhat) uses.

Patches are cherry picked from mainline not to the "upstream stable" release, but to whatever version of the kernel RHEL-whatever shipped with. 2.6.18 for RHEL5, 2.6.32 for RHEL6. Forever. It has been this way essentially forever is not a new change, has nothing to do with excluding the rest of the community and everything to do with the fact that it was the only way that nvidia/emulex/whatever_hardware_vendor would agree to support Linux AT ALL. They were not going to rewrite their driver for RHEL3.5. Just RHEL3, now and forever so the ABI had to stay the same.

The patchset is publicly available as part of the SRPM, and as a raw .patch file. It is not individual patches anymore because Oracle was cherry picking patches from their cherry picks to repackage Redhat's source and poach customers.

It was moved to a single, enormous patch file so Oracle's kernel engineers actually had to work to integrate their ksplice/RAC/whatever patches, but that's politics.

> There's an obvious joke there :p

> But I think it's reasonably clear that I wasn't saying they were trying to build a moat around desktop linux, but around those enterprise offerings. One part of that is making their init system the defacto standard.

Frankly, no, it was not, or I wouldn't have written that. Those "enterprise offerings" have zero interaction with Pulse outside of some edge cases in SPICE for VDI.

The only "moat" that "they" were building (and by "they", you mean "individual contributors who happened to have a @redhat.com email address") was in making desktop Linux usable enough for their engineers to work on it day-to-day.

As I said elsewhere, RHEL6 used upstart. "They" made "their" init system the defacto standard by using upstart, finding a metric ton of things wrong with it (and upstart was used in the first place because maintaining complex sysvinit scripts and day 2 operations in horizontally scaling applications was such a nightmare that it was worth throwing away all of the accumulated man hours in those scripts), and writing something better.

Nobody forced the Debian steering committee, Arch, Gentoo, Slack, or anybody else to default to systemd.

> I don't think I can get into it without being rude, but I think that hasn't born out history. If an outsider does submit patches to scratch their own itch they can expect to at best be held to a much higher standard and at worst be treated quite rudely. I recognize that that's going to be subjective but there's definitely some bad blood between gnome and many third parties. Look at lxqt/lxde, appindicators, etc.

GNOME is what it is, and they had that reputation before Pulse.

We shouldn't conflate Pulse and systemd just because they were both Lennart any more than you conflate selinux and podman because they're both Dan Walsh.

This perception also grossly misrepresents or misunderstands open source. If an outsider does submit patches where? Which one of the 600 different projects are they submitting to? How many of them do you presume are controlled by black-robed @redhat maintainers?

OpenSSL, Apache/httpd, coreutils, glibc, and a bunch of other core projects have so few maintainers/contributors that we're lucky they move at all. There is not some "Linux@redhat" repo which it all goes to where patches from outsiders get gated. Open source is a reputation-based community. If a @redhat.com email happens to be a maintainer of a widely-used project, it is, broadly, because they earned it through contributions like anybody else.

Maintainers, once they get there, do tend to get less rigorous code review. That's true. But nobody hands you maintainer rights along with your badge, and the perception that things work this way is untrue both historically and today.

RHEL6 used upstart also. I had to write/maintain upstart files, too. systemd picked up steam inside Red Hat because of the number of edge cases upstart DID NOT handle.

It didn't do socket based activation at all. It didn't handle day 2 operations well (if you changed the configuration of some parent service and the children needed to be restarted, this was just as manual as sysvinit but with a clunkier format). overrides were terrible. Failing out on a depchain was problematic.

The debian politics never would have gotten there if Lennart (and others) didn't decide that it was easier/better to start from a clean slate instead of upstart's weird middleground of a "script" verb to kinda sort make transitioning from sysvinit scripts easier, but not a wholesale reconception of what an init system needed to be in 2015 or whatever year that was.

systemd was, in a sense, crowned because Redhat also tried upstart and had to suck lemons for an entire release/support cycle, wrote something better, and Debian followed on. Not because Redhat/others didn't try to make it work, or because of 7 people.

Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing.

If it dynamically creates systemd units or sets their properties (systemd-homed, systemd-networkd, systemd-resolved) using the dbus endpoints, it's systemd-something.

If it uses systemd libraries and lives in the systemd repo because it shares baseline docde, it's systemd-something.

systemd is modular in the sense that those components are build-time flags. For homed, for example: https://github.com/systemd/systemd/blob/main/meson_options.t...

Again, not confusing. Literally looking at the systemd repo for longer than 30 seconds would show you both why this it's considered modular, and why it's systemd-whatever

Pulse doesn't.

There was always a mixed ecosystem. At one point, we were using Chef, Ansible, Puppet, AND Salt both internally and in shipping projects.

systemd-homed, systemd-nspawn as isolation, and the rest of his ideas aren't being held back because they're controversial, it's because OStree/Atomic "lost" more or less the instant Red Hat purchased CoreOS and they didn't need to build their own de-novo k8s compute distro (parts of OStree lived on in CoreOS and are there as a testbed for immutable images for trusted computing in kiosks/appliances/VDI).

systemd-homed, using systemd-nspawn for management, and the rest go directly against the investments which have been made in [fedora-]toolbox, rootless podman, and flatpak. At the time that I left (~2 years ago), "Openshift is the new platform" was the phrase of the day, which means podman "won".

Red Hat/IBM (via the container toolkit, rootless podman, etc) is/was primarily invested in a growth sector, which desktop/server Linux is/was not, and the Container Development Kit, rootless podman, and the rest are direct mechanisms to get containers sold on k8s and openshift.

Lennart's passion projects are great for Linux, and maybe better ideas than Flatpak and Snap. They don't have a business case inside Redhat, though, and there's only so long that even a principal consulting engineer can essentially spend his time on research projects.

I would guess that he wanted to put more effort into an overhaul of CoreOS/OSTree and try to "unify" it with flatpak somehow to get back to "one Linux" instead of split distros for different cases, didn't get traction, and decided to go somewhere he could work on a passion project.

Desktop Linux is not Red Hat's core business and it hasn't been for a long, long time. Way before pulse or systemd.

This is, fundamentally, a gross misunderstanding or misrepresentation of the way that open source works in general, and of the way Red Hat-employed developers in particular interacted with the ecosystem.

I was in the engineering side in various positions for nearly a decade. The policy was upstream first. Open source first. If you think that the engineers at Red Hat didn't care about open source, or that anyone WANTED to invest god knows how many man hours into trying to create a sane experience from scratch, you're badly mistaken.

Pulse was optional in gnome-settings-dameon for a long time, and the primary reason it's deeply integrated now is because people LIKED IT (the horror!), since it finally solved a bunch of problems with Linux audio, and the dbus backend made stuff like "media keys work out of the box" seamless.

Similarly, GNOME has a dominant place in the market because... people liked it. It's market competition. GNOME had/has a place in Red Hat as the de-facto user experience for Fedora, and Fedora's principal role is user experience testing/feedback for the next version of RHEL, at all levels of the system, but the number of users who are gonna run Fedora without a shell is low.

Principally, a lot of Red Hat's engineers ran (and probably run) Fedora as a development workstation, though there was a fair amount of Gentoo, Arch, Slack, and others.

The only reason why there's a perception that "non-Red Hat stakeholders didn't matter" is because the vast majority of community users weren't submitting patches, and the other big vendors (SuSE, Canonical) were working on other DEs (KDE, Unity) which only shared parts. EndlessOS and other projects were GNOME because... it worked.

Pulse and systemd came into being because better solutions did not, despite a bunch of effort. I've used Linux since the 90s. ALSA was better than OSS, but it had enough thorny edges that JACK still had to be a thing (and still is, for audio engineering). Pipewire is an iterative improvement on Pulse. Audio will never be done.

OpenRC, Upstart, sysvinit, runit, and others were all terrible in various ways. The sheer existence of stuff like supervisord speaks to the existence of that. If I'm going to bet, it's always safe that whatever "booo systemd" person I'm speaking with has never actually had to maintain, troubleshoot, add features to, or otherwise work with pre-systemd init systems in any meaningful way.

Red Hat's business is consulting (or at least that's what "platform" is, discounting OpenShift, but "platform" had been stagnant in revenue for a bit, which precipitated the buyout). It is not selling Linux. It is getting paid to help companies make Linux work for them so they can save money in other places.

It is in writing features which make Linux better because some customer needs/wants it and has a bag of money, but not the in-house expertise to write it.

It is not desktop Linux, and it hasn't been since RHEL3 (or maybe before that). Any argument predicated on that is built on quicksand. Don't make a Texas sharpshooter fallacy.

You have (had) a bunch of very smart people who were very passionate about open source working in Linux every day, at a company with an "upstream-first" policy. They were actively working with/against desktop Linux user experience at airports, at home, on newer laptops, trying to get on Bluejeans calls, etc. It should not be surprising that they also saw problems and wrote solutions, which the gratis marketplace liked enough that they have widespread adoption.

You can personally dislike those technologies, but condemning their existence is just a different way of saying "I don't like open source when ideas I don't like succeed".

I'm a historian by training. The primary sources can honestly be hard to read through.

I always think of history as kind of a tapestry, and filling in pieces (neighboring states, for example) can be reasonably informative.

If I were working backwards, since you're into podcasts, The History of Rome is obviously quite good, and The History of England essentially picks up the historical narrative with the Anglo-Saxon states prior to the Norman invasion. Having a good, digestible background (through these) makes the "missing middle" easier to fit in. There are very few easy/readable histories of it, but there are good histories of the Merovingians, for example, which can inform a lot about the neighboring region.

Public opinion is where the commonly held "Collapse of the (Western) Roman Empire" == "economic disaster" comes from, and it's only very recently that mass market history has started to move the needle way from Gibbons' nonsense.

The Anglo-Saxon Chronicle (dubious as it may be sometimes), Gildas, and archeological evidence from Essex really don't agree with "fell hard". It very much appears that the empire didn't have enough resources to continue propping up a fringe border province from the death of Julian the Apostate onwards, and that Brittania brought in Anglo-Saxon foederati to help out, who filled a power vacuum after Constantine III left (and possibly invited others to settle).

Particularly under Honorious, fighting between the Vandals and the Franks tied up almost all of the Roman resources in Gaul, which mattered in a way Brittania did not, and the population started to move into fortified settlements, especially after Constantine III took most of the legionary troops off in rebellion. This isn't really that different from what was happening in Gaul.

Fifty years before the "fall" of the West, there was no meaningful military presence in Britain which was not foederati, and before that, the situation was so precarious that troops revolted, leading to its abandonment. As early as the crisis of the third century, Roman Britain's economy shifted to become far more regional, since long supply chains through Gaul were untenable.

The primary exports were extracted minerals. It was, at best, colonial exploitation in antiquity. Raids from the Caledonians had never stopped, ever. Britons convincingly repelled an Anglo-Saxon invasion in 490, and it was primarily peaceful after that (and before that). Balkanized, yes, but hardly subsistence living with roaming bands of invaders.

This isn't any different than northern Gaul, or southern Gaul as the Burgundians, Visigoths, Franks, and Vandals cycled through. Or Illyricum. It happened earlier, but not like you describe.

It's incredibly telling that Gildas had both the time and education to write a somewhat polemical history less than a century after a "complete collapse of the system, (where) people went back to sustenance living", in classical rhetorical style, wherein he mostly seems to regard Britons as still being Roman (despite the "fall" of the West by that time, and the abandonment of the province 100 years earlier), as a Christian, which also tells us that Christianity had not been abandoned yet.

This is utterly at odds with your views. Where and from whom did Gildas receive his education? Why should we disregard his accounts of Mons Badonicus? Why should we disregard the Anglo-Saxon Chronicle and archaelogical evidence from Essex, Wessex, and Kent?

This narrative is false.

The Western empire ended with a whisper, not a bang. The estate system was already firmly in place, Diocletian's reforms were the foundation of feudalism, "nations on the march" (Franks, Vandals, Goths) had long ago settled in the empire en-masse.

The fall of the West was changing the name on the door. Theodoric could have been a western emperor for all intents and purposes. Even the institutions remained pretty much unchanged.

The only real distress was that the loss of Northern Africa as the breadbasket for Rome meant that Rome itself continued to shrink/decline (a process which had been underway for a long time by the end), and that was only because of the lack of a grain dole, which had been in place for 500ish years anyway, because even the late Republic had significant problems with wealth inequality.

If you want to talk about economic downturns, currency devaluation after mining all of the silver in Iberia, the crisis of third century, independent administration of the East and concentration of the wealth of Egypt/Syria into Constantinople, and the amount of wealth which went into keeping up auxillia/mercenaries are better targets, and those all long predate the fall of the west.

My experience is that it broadly falls into two categories.

The first is comprised of people who never actually had to wrangle sysvinit/upstart (openrc is relatively sane), and have never seen the ridiculous amount of engineering time which went into hacky stuff like supervisord and bizarro, bespoke hacks to try to do things which systemd makes trivial: socket activation, optional service dependencies, file-based service activation/restart, "failing fast", timing various parts of the boot chain, etc. This class of people, broadly, probably never actually understood how `init` worked anyway (or how booting worked once dracut came into the picture), but they now feel like it's an opaque, unobservable system. They would have felt like that anyway if they had tried to work with pre-systemd tooling.

The second mostly thinks that systemd is against the "UNIX philosophy". This class of people, broadly, has never touched a "real" UNIX other than MacOS (and they probably never had to deal with netinfo) or BSDs (which are great). There was absolutely no sanity or consistency between, say, AIX, Solaris, IRIX, and Tru64, and all of them had various classes of "god" tools.

Lennart is not always right, but he does have a vision of Linux for the 99%. That is, one of the "against systemd" links is this: https://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is...

This is indicative of the problem. Ninety-nine percent of users don't WANT to configure 40 different baroque things with their own configuration files (rsyslog/syslog-ng, dhcpcd, resolv.conf, ntp.conf, /etc/hosts|/etc/hostname, etc). They want Linux to work. They want systemd-networkd to get them an address in 1/10th of the time, and they have absolutely no need to start a daemon which can set every DHCP option ever when ACKing. They to fuss with nameserver rotation to deal with flaky stuff for split-horizon DNS -- they want systemd-resolved to handle "this server can't be reached right now, so I'll put it in timeout, keep returning cached results, and send new queries to a nameserver which is responding."

If you still WANT to do the other stuff, nobody is stopping you. Yes, you probably need dbus and udev and udisks, and all of those things are light years better than the tools we used to have before, but systemd itself can be trimmed down to almost nothing if you want to. The alternative, building up a stack which can sort of approximate systemd, would take a very competent admin at LEAST a week to build deployment tooling for, and that's assuming they already knew all the stuff they needed to plug in.

This is rapidly becoming a bad joke. "You know how someone does Crossfit/is a vegan?"

You know how someone uses NixOS?

I've never used it, but I guarantee that Proxmox can pass through PCIe devices with VFIO, and USB requires no hardware support at all.

vmkernel hardware passthrough has exactly the same requirements (IOMMU support).

Are you honestly asserting that a warming climate was the cause of the Bronze Age collapse without addressing 1177 BC and the migration of the Sea Peoples at all while insinuating that Egypt collapsed (it did not -- it went through hard times, but came through, and its the closest thing to a contemporary historical record we have)?

The sudden influx of nations on the march threw a spanner in a complex network of trade and intermarriage for regional stability. We have *zero* real idea why the Sumerian civilization was supplanted, or even where it originated from for that matter. Was it a language isolate because semitic groups became demographically dominant through natural causes? Were the Sumerians transplants from somewhere else? Did the Akkadians, Assyrians, and Neo-Assyrians rigorously stamp out ethnic groups? Zero idea.

It doesn't bode well for your position that you appear to be ill-informed also, and that you're asserting that a blip (because agriculture had no problems coming back to Mesopotamia after we have a reliable historical record again) in the climate also caused every other civilization in the Levant to collapse rather than 'we have a fragmentary historical record of the death throes of those civilizations against unknown invaders who pushed out (in the Levant) from a geographical position which happened to also serve as the transit corridor for trade, diplomatic communication, etc?", along with evidence for civil unrest, natural disasters, and a large number of factors which are merely contributory factors to a complex situation.

Honestly, please go read 1177 BC.

Example of a garbage HN drive-by comment: this.

I've spent a _long time_ working in distributed systems with components which are "close to the metal". There are use cases for this, many of which are better solved by "hardware timestamping NICs" and "run a stratum 1/2 NTP server with high locality (and if you're geo-distributed, run multiple on systems dedicated to that purpose, because ensuring you're within nanoseconds of _someone else's_ infrastructure is generally an order or magnitude less important than internal coherence).

That was the best possible quote from the author/subject trying to explain the use cases. Did you even read TFA? It's completely unclear from their article what the intended uses cases are, what the problem space is, and how much working knowledge they have of existing solutions.

Naming people who invested in other companies who are investing in this one and showing what looks like a dashboard for a timekeeping solution is normal TechCrunch garbage, but that quote was a step above.

Comments like yours (going all the way back to /.) days really just tell me that you didn't read the article, and it makes it look like your primary goal is sophistry.

> “Currently, nobody uses time except for maybe Spanner at Google, CockroachDB or someone doing database things,” Rosenblum said. “We believe that there’s a lot more places, especially as more and more time-critical things came up. We can do time sync, since we figured out how to do that pretty well. And so we asked: is this part of a trend where we’re going to start programming these systems differently? And [researchers] got kind of excited about that possibility of us being able to pull this off.”

Who gave this guy who's apparently never heard of kerberos, ceph, SAML, or any other technology the rights to interview? Sure, their windows are larger, but "nobody uses time" is so clueless it blows the mind, and it's hard to imagine who decided that "NTP, but machine learning" is a $21M idea

That's also true of the areas in Southern Italy, Sicily, North Africa, and Illyria. Nothing about the East differentiated it, and the Romans saying that it conquered them culturally were the same as the Americans now lamenting that the US has seen cultural changes. "Oh no! You're not sending consular armies out every year to acquire new territory as your sole cultural identity!" was the complaint.

Completing the conquest of the Mediterranean basin and being left bordering only states against whom the Romans never had any particular success, the Sahara, (Parthians/Sassanids) or holding the line against rotating groups of peoples pushed further west in the Balkans and Germania left the Roman state without obvious paths to expansion. That does not mean that Hellenistic states "conquered them culturally".

If you think the West was some unified area with "Latin-speaking" culture, heritage, bureaucracy, and self-identity, you'd need to write a thesis-length paper justifying it no matter what century. Even the Italian peninsula was none of those things until long after the establishment of the Principate, at which point wealth had already precluded the existence of men like Cincinnatus.

This is completely arbitrary. Both from the sense that, as you mentioned, there are a number of inflection points prior to that, and in "Greek-speaking" being distinctive at all.

If the classical Roman citizen weren't horrified at the organizational changes under Diocletian, or the difference in response between Adrianopole and Cannae, or moving the Imperial seat, or Romanized barbarians leading legionary armies (all of which were 100+ years before the fall of the west), they'd keep going.

The fact that the population in the East spoke Greek (and Syraic, and Aramaic, and a bunch of other languages) is a meaningless distinction. The West never truly had a formalized language anyway, at least among the citizens. The East had the same history, the same institutions, the same government

They're not brittle when running -- they're brittle if/when there's a failure.

Bringing a Redis cluster back up is either "start each node in exactly the right order", "wait 10+ minutes", or "establish quorum yourself". Ten minutes can be a really long time in production.

This is fine. It's a great beginner project -- C++ is probably painful even statically compiled, and Go/Rust would be better.

But you may as well make it a little smarter. Over a decade ago, this utility could be done ad-hoc in 100 lines of Perl (including spacing and comments), and that includes "try to see if yum on RHEL6 knows where to find the missing dep, build a list, and prompt to install": https://gist.github.com/evol262/3d67c4295bbe78135a4927bd1d82...

It would be a fun project for you to try to do this with dpkg/pacman/dnf (which is basically the same as yum for syntax, just that you're not gonna be a sysadmin hacking out Perl to solve a problem)

That's sort of my point. I'm also an old fogey in Linux hipster-land, who started off with RH5, then moved to Mandrake, then Gentoo somewhere around the kernel 2.2->2.4 transition.

It was really important then to know how to identify hardware so you could actually have it supported in your kernel (I don't remember if `genkernel` didn't exist yet or whether I was just trying to squeeze out as much performance as I could -- probably the latter). But it was also the era of winmodems, winprinters, risk of actual damage to your monitor if you screwed up the modes in X11R5/6.conf, we had to use `lilo` and remember to update it every time, etc, etc.

A lot of the people I talk to know who end up in the same positions as me still use those skills -- but we use them at distro vendors to make sure that 'normal' users never need to worry about it. Honestly, with the way Linux has been adopted, my expectation would be that by the time I exit the industry, people with the skillsets you and I have will be rare, and mostly unnecessary. Linux "just works" on the vast majority of hardware these days, and we old fogeys put a lot of blood, sweat, and tears into making that so.

It's not that I think that it's useless, it's that it's not _required_ knowledge anymore, and anyone who is convincing themselves that it's giving them deeper knowledge considering the vast increase in complexity is kidding themselves. In a pre-EFI world where all you needed was a binary (any binary) located at `/init` which "knew" how to handle everything else, it was great.

At this point, if I were starting from scratch, I'd tell people try to really understand how EFI works (https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...), get a handle on IOMMU groups+SRIOV/nvme namespacing/whatever, and learn as much as possible about network namespacing and how SDN/CNI work, so "how does a packet get from the outside all the way to a pod || EC2/openstack instance || whatever" is reasonable, and that's not even touching "how does `dracut`/`mkinitcpio` come up and hand off to systemd+cgroups", because those are the areas where things are likely to blow up, rather than "whoops, you forgot to build the driver for your HBA into your kernel and now you can't boot", or "X11R6 completely shit the bed after a driver update broke your Xinerama config".

Different years, different problems, different things are important. What was crucial for us to learn in 2000 hardly matters in 2022 when an Arch live USB will more or less boot on any system anywhere and get you a working framebuffer, with a couple of commands to bring up your system.