evol262

Which, honestly, is grating.

It's great that the Arch wiki is as good as the Gentoo wiki was in 2002, but it would be even better if the Arch wiki actually acknowledged the people doing the work. For GPU passthrough, for example, the initial author/current maintainer of VFIO published a development blog which has a [multi-part series explaining VFIO and passthrough from the bottom up](http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part...) six years ago.

This is not referenced anywhere in the Arch wiki, despite the fact that it's the literal author, most of the steps in their wiki haven't changed in the intervening years, and it's almost certain that whatever place the authors of that wiki page eventually cribbed it from probably came from the original blog.

The Arch wiki contributors, in this sense, aren't great netizens. Worse, the Arch wiki (and various subreddits) are almost as bad as the Arch/Ubuntu forums were in 2005. They often lead to a bunch of "shotgun debugging" where users are copy and pasting things they don't understand at all in the hopes that it will fix whatever problem they're encountering for reasons they won't understand.

Arch is fine, and it has its place. There are some brilliant people using Arch. The community in general is full of people who intentionally shoot themselves in the foot and are then proud that they find superglue for the wound on the Arch wiki instead of using a distro with better engineering practices where they never would have had these problems at all. The mistaken belief that doing any of this somehow "teaches" you meaningful things about Linux as opposed to solving real problems (since 99% of the "problems" Arch users encountered will never be seen on other distros, due to the fact that the maintainers carefully ensure there are limited footguns out of the) is terrible.

The author graduated high school when I was 30. This article is very much "I wish every company worked like these tiny ones I spoke with, so I'm gonna try to make this the reality".

Unfortunately for Gen Z, they are not the first generation to think they are too smart or too good for their jobs/hours immediataly out of college. "I finished all my work, can I leave?" is just asking for more or more complex work.

These people are entry-level performing entry-level jobs, and have no distinction between "a family member died/my child is sick so I can't come to work" and "I don't feel great, so I'm gonna skip class today".

The world is not changing. All of this will go away. This doesn't mean that Gen Z's attitudes about corporate apathy are wrong, but there are some bridges companies don't want to burn, and that righteous sort of "bend the world to my will" attitude tends to fade with experience once you see the trail of wreckage you've left behind.

Sure, it would be great if we could all work 3 hours a day, make great money, and do whatever we wanted with our lives, but wishing for that won't make it so, and while there is not a _direct_ correlation between time worked and salary, "I put in the minimum amount of effort then leave instead of improving thing" doesn't get you much further than living with your parents while you complain about how unaffordable the world is.

> I mean yea... we had a gigantic pandemic and people were getting sick. We can also attribute the fact that you have goods and services and a vaccine in your arm to the same markets. Certainly the government helped in some ways but it also completely botched the response to the pandemic.

I'm not arguing that the government response to the pandemic was good, though. I'm arguing that the market response to it is and was terrible. Sure, some things remained functional, but having a run on cleaning supplies, hygiene products, electronic components, and others because the markets could not cope with elastic demand isn't a great look.

I understand how we got into this situation (compared to having stocks of unsold product which is eventually written off sitting in a warehouse somewhere). That doesn't excuse it, though. There is little reason other than "satisfy shareholders" that industrial giants should not have been able to keep up on demand for _bleach_.

> No this isn't that. If you're going to bucket list a bunch of people and say "blah blah blah libertarians think this" then I'm going to point out why that's incorrect and not representative of general libertarian philosophy which is a lot more than what is being discussed in the OP. It's not a fair characterization, and clearing up misconceptions is a fair thing to do.

I am not bucket listing a bunch of people and saying "libertarians think this". I am saying that libertarians and what even qualifies as "general libertarian philosophy" is so incredibly fractured and scattershot that even speaking of "libertarians" as some sort of group is an exercise in futility, and not only because people like yourself will leap to the defense of "libertarians" without any clarification at all.

> Great so then why are we blaming them again?

Because it there's ANY unifying theme between "libertarians" and "libertarians", it's "markets handle problems better than governments", which they demonstrably do not.

> If you want to say "they did have an influence" then fine, I'll say that Communists and such have had a big influence too.

And who's arguing for communism here?

> I'm not sure what your point is here. I guess in response I could say we experienced uncontrolled Communism during the 1940s-1980s and now again with the CCP. We've been there and tried that.

Sure, great, amazing. That's a position I'm happy to live with. Quibbling about differences in communist theory isn't relevant, since it actually seems to be popular with Gen Z and Millenials, and maybe they'll get a chance to actually try it through advocacy and electing people who match their beliefs instead of living in some no-man's land of "we don't wanna be part of your system, man, but if we were we'd do it so much better".

That's how democracy works.

> Other libertarians simply believe that markets solve problems better than governments do (hard not to argue with that right now)

Considering that the supply chain problems can be laid squarely at the feet of "markets" assuming that everything would operate in a vacuum like an econ textbook and imploding once external pressure interrupted things, it's very hard to argue with that.

> I'd also argue that really libertarians haven't had much of a way of influence in American politics and this is strictly the failure of the USG (Republicans and Democrats) to take action.

The principal problem with this argument is the "no true Scotsman" attitude of "real libertarians" compared to other "real libertarians". I don't know what "libertarians" are to you, but the obvious answer is that if they haven't had much of an influence in American politics, it's because their policies and stances aren't popular.

Most of the Western world experienced unregulated market dynamics in the robber baron era, and arguably again in the last 10-15 years. We've been there and tried it.

> The economy on the other hand is in total ruins, largely because of policies related to COVID-19, which also had a marginal impact on emissions.

This is the reddest of herrings. The government's role is to strive for the security and safety of its citizens. "Policies related to COVID-19" are part and parcel of that.

The economy is "in ruins" not because of "policies related to COVID-19", but because in striving for squeezing every last drop of profitability out of things, a "just-in-time" model was adopted for everything under the sun, which fell apart at the first real obstacle.

It's a supply-side crunch from the bottom of the chain on up. Companies which are depleted of capital in order to line people's pockets are unable to jumpstart the process fiscally, and decades of mistreating workers is backfiring as a labor shortage which *should* drive increased wages is leading only to calls for bailouts and government intervention, or _anything_ other than paying market wages.

Don't blame governments for unfettered capitalism being an ouroboros.

If those were goalposts, they weren't clear. The miss is that the article in the link doesn't discuss VMs or virtualization at all, so talking about oversubscription/etc seemed like an ad-hoc commentary on the hardware configuration unless I totally missed that in the article, but searching for "virtual", "VM", "vCPU", "subscribe", etc didn't find anything. There's a limited amount of effort I'm gonna put into digging into additional links on "Planet Mainframe" pushing mainframes.

That aside, comments on articles are sometimes more general. "How do mainframes compare in 2021?" is a conversation which is not intrinsically linked to "should you oversubscribe VMs 66:1 for this specific workload?", and I interpreted your comment at the former. I wasn't talking about the article at all.

> The entire scenario outlined is for a production deployment of Websphere backed by Oracle. IBM specifically calls out 1:1 memory for production workloads (which oracle very much is) in their performance documentation:

This discussion is about the configuration of the systems, not this specific scenario. While this may have been the scenario outlined for you, it wasn't apparent from your comment.

Production workloads on busy servers have very different requirements than consolidation, VDI, resiliency/redundancy, hardware abstraction, etc. Every workload needs a different evaluation.

All of these VMs running production Ora/OAM/OEM/Websphere workloads? No, don't oversubscribe. Some of them running similar workloads? More oversubscribe is ok. Few of them? Lots of oversubscribe.

Similar for interrupt locking. The "old" synchronous interrupt lock I was speaking about was "I have a bunch of VMs with CPU oversubscribe, and even if they're doing nothing, 30% or more of your CPU time goes to interrupt scheduling so every vCPU for a given VM can schedule simultaneously". This is solved.

"I'm running a CPU-intensive workload on a massively oversubscribed server" is not, and we really shouldn't expect it to be.

I am having a generalized discussion about virtualization oversubscribe. You are having a specific discussion about CPU-heavy DB workloads. Apples cannot be compared to oranges.

Yes, I mean KSM (and its equivalents in other hypervisors).

The CPU cycles are a non-issue for the configuration on this mainframe, and it's fair to assume that, since IBM developed the silicon and IBM engineers wrote the hypervisor layer, that most of the detrimental effects of "we need this to work across multiple CPU vendors and multiple generations of the architecture" are covered.

Even x86 CPUs get improvements to cache coherency in memory dedupe scenarios with generational improvement, and intelligent NUMA topology layout helps a lot. It's also worth noting that it's a mainframe, so essentially every configuration has a large number of other processors with a couple of instructions disabled so they don't "count" as CPUs for licensing, but they still perform work. I would not be surprised in the least if there were 1+ co-processors dedicated to offloading operations exactly like "LPAR || z/VM memory dedupe"

While I agree that this configuration needs more memory, mainframes are primarily used for very high throughput jobs. "Lots of memory to sit idle" isn't really a priority.

That aside, samepage sharing has been a thing in virtualization for more than a decade. If you have 800 VMs running RHEL8 for POWER, a significant amount of the memory load is kept in identical pages, which lowers the burden of oversubscription. The recommended workload is unlikely to be 1000 unicorn/pet VMs, and more likely to be a large number of VMs running the same base OS, and some of the same workloads.

Synchronous interrupt locking is also a solved problem.

VT-d is used for device passthrough. I suspect you're thinking of VT-x. But LPAR have been around forever, and aren't that different conceptually from jails, systemd-nspawn, LXC, and any other of a large number of OS-level virtualization solutions, except that you can stub in/out different kernels.

Yes, the kernels need to be "snowflakes", but that's not necessarily an issue if this is functionality you really need.

How do you expect to build upon the works of past philosophers if you haven't actually read them?

The "replacement" for Nietzsche's books, if that's a goal, must also address WHY Neitzsche's arguments are weak or insufficient. It must also address, to a degree, structuralism/post-structuralism, postmodernism, etc. This is not a process wherein Nietzsche (or Heidegger, or Hegel, or whomever). Questions of "how ought one live?" are not narrowly focused. Simply because you did not study philosophy and seemingly disregard the idea that different people may adhere to different ethical systems (as one part of philosophy) does not invalidate the discipline. There is no universal, provable "right" answer to "what is ethical?" Certainly there is overlap between virtue ethics and utilitarianism and intuitionism for how one might behave, but the reasoning behind them all differs.

Humans are not omniscient. Philosophers are not omniscient. It's disingenuous to talk about general relativity as an example, and much more cogent to talk about theoretical physics (to which I can't speak with any authority except as a lay reader who's aware of multiple theoretical frameworks which cannot be simultaneously true). Sure, you can have "more sophisticated arguments (mathematics)", but the answers to some of these questions may never be known. In philosophy, we will NEVER know the answers to questions about the human condition, the nature of knowledge, etc. Just because it's not mathematics which are "transferable" and can build on top of each other does mean that the knowledge is not transferable or that the arguments do not get more sophisticated.

Exactly what you're describing DOES happen in philosophy, and has always happened.

To verify and prove that you have a new, original thought, you essentially need to address everyone who's every written about it before, and their arguments (or at least intermediaries who have already done that). A lot of philosophical texts are "I have this new theory", and the remainder of the text is "so-and-so said this, but they are wrong/my idea is different because...". Think of something like Kant's Metaphysics of Morals. The vast majority of the text is little different from a proof with QED at the end.

In physics, you learn formulas, and those can/do build on top of each other (as well as mathematical axioms/shortcuts). Reading Aristotle isn't any different in that sense. You aren't reading Aristotle for The Physics. You're reading it for ethical theory (and virtue ethics in theory), the underpinnings of philosphy of science, and Aristotelian/term logic (so you can understand the arguments of later authors prior to propositional logic).

In order to understand philosophical thought and argument, it's necessary to have this knowledge, and it's no different than me saying "in the process of studying physics, you have to study geometry" (as a prerequisite to later mathematics). This isn't any different, and putting the study of philosophy in some sort of "philosophy is slow" or "can only be understood in the historical and/or cultural context" box denigrates the entire discipline from a position of ignorance.

By the standards of most of the world, no, he's firmly right wing, along with basically every other politician in the US.

By US standards, he's a moderate. So no, still not left. And that's why he got elected.

Please name a use for crypto which is not "buying questionable substances from the internet" or "like stocks, except that I can make more of them with my GPU".

They are, in every way, of less value to the economy than traditional fiat currency.

    * They have no guarantees or equivalent to the FDIC
    * Their value similarly unpinned to anything (for the sake of argument, let's ignore basketed currency, since crypto is not comparble to that and less table than those) other than investor confidence like FOREX
    * They are not tax havens
    * Their "production" consumes as much energy as some medium-sized nation-states
    * Chasing the hype has exacerbated the chip shortage as "peak capitalism" has encouraged fabs to produce GPUs for maximize profits at the expense of, say, chips for cars with their limited supplies

Not everyone who uses crypto is a dark hat crypto-libertarian hacker. Few people who clamor for crypto have good reasons to use it other than "why not have it as an option for people who want it?" or "I wanna do this stuff without being tracked".

> Please do not let moral posturing cause you to underrate the importance of a holistic approach which includes medication-assistance.

I get that you're a founder. It would be great to not cast aspersions on people. "I think your approach sucks" is not "moral posturing", and I'd question how many ethical doctors would recommend something insurance will not cover with an unknown end date to the treatment plan as "pharmacotheraphy" out of the gate.

For those who cannot gain muscle mass, injecting testosterone would also work (and would work for weight loss). Messing about with the endocrine system is tricky. Your body is really good at homeostasis. It's also really good at saying "welp, I guess that's covered, so I'm good" when exogenous sources of hormones are introduced.

Is this part of the treatment plan? What about diabetic patients (who appear to be a small part of the studies leading to approval)? How are you going to control for hyperglycemic ketoacidosis?

What's the long term effect of this on alpha cells and pancreatic health? How long is the titration for normal pancreatic function to resume? When exogenous glucagon is removed, what are the hunger levels of patients? Bounceback effect on weight if appetite is increased in the meantime?

Yes, use every tool in your toolbox, but there are a lot of unanswered questions about the medication in question, and a lack of insurance coverage. I've been overweight. Your body is not a formula in the "I calculated CICO, and...", but it does follow basic rules in a "I tracked my calories religiously, and over the last 2 weeks, my average daily intake was X, and the scale change was Y, so I need to modulate intake/activity up/down/stay the same" until you reach your goal.

That's hard for some (many) people. It's also completely sustainable. We want an "easy" way to do things. Sometimes "easy" things have detrimental effects in the long term, which are not apparent during clinical trials or short (let's say 3-5y or less) term, medically speaking.

Doctors would recommend pharmacotheraphy for obese patients because the health effects of being obese are dramatic, and almost certain to be worse than whatever the health effects of the drug are, because they have relationships with the vendors, because they are not sure whether the patient could affect the same change in health without them, etc.

However, if presented with the choice of "Patient X is able to achieve the desired outcome without the addition of medication", that would be the choice every time. You can filter that through the scale to "Patient X is unable to achieve the desired outcome without incurring significant financial burden/hardship by taking a new-to-market drug with unknown long-term consequences and an unpredictable prognosis once pharmaceutical intervention ceases, but the outcomes are so much better that this risk is warranted", which seems to be close to the starting point of the pitch here.

Medical ethics are not moral posturing.

Edit: your cofounder is doing a great job (https://news.ycombinator.com/item?id=28260302) addressing the tradeoffs here.

Not to put too fine a point on it, but this is not the greatest venue for comments like the last one in that chain (yours) (https://news.ycombinator.com/item?id=28261777). People here want to know how it works, why it works, what your pitch is, why we should recommend it, etc.

I am not your target demographic and never would be for a variety of reasons, not least of which being that I've been a competitive athlete in weight-class based sports for almost my entire life (outside of the 5-6 year period where i stopped training and became obese). I am here commenting, though, and you can make a fair guess about who I know based on the demographics of the US and their intersection with the market demographics of software engineers. Lots of overweight people with the kind of income which could afford this.

Like many people on HN, I read a lot. I'd hazard to guess that I come across many more startup ideas and news articles than most people I know, and I do bring them up in conversation. Fella is the sort of thing which I could recommend (well, "here's now insulin/leptin/glucago intersect as part of the HPS axis, and there are GLP-1 analogues, with this startup which may be able to help"), but I'm unlikely to if it leaves a bad taste in my mouth as yet another shill for medicating the symptoms instead of addressing the cause(s).

If I see responses like "this is the sort of stuff our customers talk to their doctors about" and not "this is why you should become our customer", I'm gonna write you off, and that's probably a fair assumption for HN in general. The comments are not the place for elevator pitches, marketing, etc. It reads like "I'm happy to answer your questions once you pay me, but not here".

I said that you may be an extreme outlier. You're also larger than every NFL player in history, everyone in World's Strongest Man, etc. A 10 mile jog (let's say 80-100 minutes of uninterrupted running) is the sort of "I could eat 50 eggs" number people pull out.

At 6'5", you are an outlier. 2kcal is too low, much as it's too high for the average woman. This doesn't mean that metabolism is a "colloquial" term. It means that "the physical, psychological, and emotional components" is a long way of saying "it's hard", and "the experiential variance I'm describing" is "the payoff did not seem to be worth the cost".

In general, my post wasn't intended to be an attack on you. It's that "I cut calories and I lost weight" is not anecdotal. It's factual. The anecdote, if any, is "I'm larger than the largest professional athletes and I can still perform". Since it's hard to stick with cutting calories for many people, throwing drugs at it with Fella is not the right answer.

A holistic approach which addresses trauma, reasons for emotional eating, lifestyle replacements, recalibration of palate, satiation even at a deficit, and all the rest should be explored alongside drugs so "I cut calories and I lost weight" is easier to stick with.

Diets don't fail because they're inherently flawed and the system is more complex than we think it is. Diets fail because people fail. "I tried and I failed, but I still do all this physical stuff or could if I wanted to" is dishonesty, whether intended or not.

Asserting that, for some unspecified (but large) fraction of the population, tracking your caloric intake and energy expenditure versus the number on the scale is inherently flawed is dangerous, misleading, and probably false. At least partly because overweight people may lie to themselves.

In this sense, and in the context of Fella, throwing more drugs at the problem isn't a solution any more than throwing additional hardware at an application because the developer insists that database indexes don't work everywhere. It's true, but requires extraordinary evidence, and should not be the baseline assumption.

This is what's known as an 'anecdote', and is at the crux of the issues surrounding weight loss.

Virtually every _controlled_ study shows that metabolic differences between adults are within a margin of +/- 15%, with essentially no way to eat the same amount of calories as a 200lb person and stay at 465lbs. Not least of which because your basal metabolic rate is much higher at that weight.

Virtually every study shows that overweight people significantly underestimate their input (whether intentionally deceptive or simply unaware) and overreport their physical activity, like "I can jog 10 miles", or "I play tennis about 7 hours a week", or "I regularly make 60 mile bike rides". If you do, you're the extreme outlier, and it doesn't change the data. Assuming you can do those things, you're almost certainly still in your 20s, and the health effects of your weight haven't really caught up with your body yet.

Very simply, it's far more likely that you miss some of the calories you consume, either because you don't actually weigh your food or you discount the signficance of "small" things. A pound of fat is 3500 calories. That's more complicated inside metabolic processes, but it means that "an apple a day" is 10lbs per year.

That isn't to say that "prescribe more medication instead of correcting the underlying issue" (trauma, self-medication, dopamine flush, whatever) is the answer, but that diets perform poorly for a large fraction and fail abysmally for another third because we are bad at tracking things, we are bad at being uncomfortable, and we bad at self control, etc. Diets do work. It's sticking to the diet and recognizing when you're off the rails which is difficult.

It's also difficult to acknowledge that this "diet" is not temporary and you can go back to old eating habits once the weight is off. The new caloric consumption is forever, because that's what brought you to the new homeostatis.

One provided a shelter for incitement to violence, culminating in an attack on the US Capitol.

The other one is naked people.

It's the difference between suing someone because they yelled "fire!" in a crowded adult theatre and being an actor on the stage of that theatre.

Historically, this is AWFUL for gaming on Linux, since NVidia is a terrible company which takes forever to get their drivers working on/with new features (Wayland, kernel modesetting, new kernel versions at all for a long time). You seem to be taking a lot of assumptions about what gamers want/need on Windows and cross-applying it.

Steam (via Proton, mostly) already does a lot of development work, and it doesn't care which distro it's on. "Oh no, I updated my kernel and now my graphics drivers don't load at all!" is incredibly common, even with DKMS. Sometimes (mostly) bugs get fixed in Mesa or whatever. Often, new subtle bugs are introduced when a new Wayland/Pipewire/whatever feature goes GA. Having as few moving pieces as possible (by using an LTS distro, or at least something which isn't rolling with upstream and has a modicum of QA) lets you optimize the pieces you need to without worrying that this or that API is going to change underneath you.

Intel and AMD drivers do not have this issue, and Valve was smart enough to not go with NVIDIA, but "I want to be up to date" is a terrible experience.

Additionally, it generally makes for a much less reliable/stable experience (gaming or otherwise) because `pacman -Syu` may at any point break something because you didn't read the release notes, or "mostly" stable features were committed upstream then released so the userbase can put them through their paces and report bugs the developers didn't encounter.

Users of Arch/Fedora Rawhide/whatever accept this, but someone who buys an OEM gaming machine does not need or want this.

Just to note, I AM saying that Arch is unstable. I've been using Linux for 20 years, and I've had my time with Gentoo and Arch. 99% of the tinkering users do is reproducing the work of professional developers at distro vendors who spend a lot of time and effort making sure you never encounter the problems Arch users revel in fixing at all. Sure, you can tell yourself that means you "know" more about the system. But that is time invested that you could have spent doing REAL THINGS, and solving REAL PROBLEMS which are not un-breaking your distro.

This is not a "sensitive" issue, unless you consider GP's opinion "sensitive". I don't. I also don't think it would lead to a curious, constructive conversation. There is probably nothing OP could offer which would change what the experience of 8 years in RH engineering showed me. At best, it would lead to another long reply where I tried to explain what RH was actually like versus GP's impression.

It's essentially GP posting on the Debian/OpenBSD/LK ML and saying "wow, these guys are arrogant". Well, they have strong opinions, and they need to justify them. If you don't have thick skin, you should probably avoid upstream discussions. It doesn't mean you should cast aspersions on the developers or their communities/companies. Linus is an incredibly nice person, but you wouldn't think it if all you saw was his mails blasting Intel for Spectre/Meltdown. You'd have a very different opinion of the man than who he is in 99% of interactions, and commenting about it on HN would be likely to get a reply similar to mine.

GP only had "anecdotal" experience with Red Hat versus actually working inside the company. When I started, I was worried that it would be different "behind the curtain". It was not. The other who mentioned junior engineers speaking up if they disagreed was spot on.

In 201x (2015? 2017? I dunno), RH changed their pay structure from being bimonthly to biweekly in the US to align with the rest of the world. There were hundreds of replies to the entire company debating whether it was better to pay us once a month and manage your money better, or once a week to be more consistent, or...

That's what the company was. It was not by the time I left. Granted, when I started, RH HQ was still on a college campus. If all you ever read was upstream mailing lists, you'd get the feeling that everyone (Linux, Theo [not that he works for RH, obviously], Lennart, whomever) other than Dan Walsh was arrogant assholes. That's not representative of who they actually are.

Painting Red Hat with a broad brush from incidental interactions versus the perspective of someone who spent nearly a decade there is dramatically different. Did it have problems? Sure. But none of the ones GP mentioned. The world is much bigger than what GP imagined from his anecdotal experience.

RH was a unicorn, and it's gone. LinkedIn last summer was essentially rats fleeing a sinking ship. IBM spent $35B on a company with no actual assets (a few patents) other than smart, passionate people. They would have had to really try to screw it up. And they did. I don't honestly know if there will be another RH in the future, but I'm hoping there will be.

As someone who spent 8 years inside Red Hat, this is exactly why anecdotal "evidence" is garbage.

Complaining that an engineering company is full of mostly white males (in an industry which is full of mostly white mails) is an example of nothing. Red Hat started programs to push LGBTQ+ people in 2014, women in leadership in 2017, neurodiversity acceptance in 2018, black leadership in 2018. You may think all of those things are late, but as driven company missions which they spend real money on (and real money on community involvement on), it's not insignificant.

A "good-old-boy's club" at a company where only 25% of engineering was even in the US is a little mindblowing. The vast majority of RH's engineers when I left were in Pune, Brno, Tel Aviv, and scattered across Europe (eastern and western), with a reasonable showing from Brazil.

Open source is, for better or worse, a place where a cult of personality matters. "This is a bad idea and we shouldn't do it" isn't personal. It's how the community interacts. It's an invitation to argue back and say "this is a good idea because XXX". This is basically how any upstream mailing list works also.

While Red Hat did have some cultural problems, they were primarily around resistance to establishing an engineering presence in China (and it's hard to fault them for that -- my team was truly geographically distributed, and adding someone in APAC would have meant we literally never could have met at the same time), and regional cultural attitudes.

I left last summer, along with a lot of other people, but your comment is apropos of nothing Red Hat was from 2013-2021.

> Maybe I just expressed myself badly, so let my try again. I predict that Rocky Linux will not be a big success, and don't think doing a free-beer RHEL clone (CentOS as most users understood it) is a worthwhile endeavor, despite a seemingly large audience. Yes, giving good stuff away for free is popular (and I do believe RHEL is a good product). Because they're largely dependent on RH, who 1) appear not very enthusiastic about the idea of people running RHEL for free even without support, 2) can largely determine how expensive running a clone project will be. That's why IMO it's better to analyze if users really need a strict RHEL clone, or if what they want from it (xLTS, better tooling, commercial software compatibility, whatever) could be better developed on top of Debian, whose incentives seem to class less. People who really really need a RHEL clone: time to pay up or go with the Stream (it probably really not-so-bad).

> Now unlike you I have zero inside knowledge or experience, so maybe I'm just talking out of my ass. But I am willing to make a somewhat falsifiable prediction, that Rocky and similar clone projects don't have much chance of success. Maybe I'm all wrong and Rocky can with a handful of volunteers and some clever scripts, resurrect CentOS-as-people-understood-it. Or maybe some deep-pocket 3rd party with a better brand than Oracle will step up. We'll find out a year or so.

So, let's try this. I agree that Rocky will not be a big success, but completely because I don't think there's a major market demand for a RHEL clone in 2020. New deployments will end up being a container Linux distro with deployments inside VMs or containers. (RH)EL8 is relatively new with low-ish adoption. We still had customers on EL6 six months ago when I left. Institutional customers aren't likely to move to EL8 until EL7 is nearing the end of phase 3 support, since the costs involved in reworking their applications to work (and their build/config management toolchain to work with modularity+etc. This has nothing to do with Red Hat's stance, which was (for the 7.5 years I was there, and still, from everyone I know who's still there) very overtly pro-upstream.

Users don't need a strict RHEL clone. They need a life raft until they can move to containers. It's not worth re-training administrators how to use some other package ecosystem. Rocky will fail, but for these reasons

> That's true in a literal-but-useless sense. Developers-RHEL might be bit-identical to real-RHEL at some dates, but as a product it's of course very very different due to lack of interim updates. And that's aside of the smaller speedbumps of registration and having to involve Legal if you want to run in a company.

Again, stop moving goalposts. Your comment was "why can't they just put it on FTP/WWW without support". That's exactly what they do. You aren't required to register it in any way, including downloading. You want a free "product". That isn't their business model. At least they make the sources for everything available, which took Canonical years for Landscape.

> I don't know how true that is, the CentOS wiki makes it sound like like the debranding part is non-trivial/manual labour intensive. So according to you the main bottleneck is hardware / buildservers? If that's true, one wonders why even the minor CentOS 8.x releases lag RHEL 8.x by 4 to 6 weeks.

This is literally the build system. I have real-life experience branding a number of Red Hat products, including rebranding Anaconda and the base system. See for example https://github.com/oVirt/ovirt-release/blob/master/ovirt-rel...

The lag is because Koji (which is also used internally) uses a hierarchical build/tag system. See https://docs.pagure.org/koji/using_the_koji_build_system/ and https://docs.pagure.org/koji/tag_inheritance/

For a base release, a mock root needs to be bootstrapped. This is more or less by hand, and does definitely require incremental builds of and the rest of the base system. I guarantee the CentOS releng team has scripts that do this, but I don't know where they'd keep them (I never worked directly with that team). Once they're in a koji buildroot, that buildroot can be used to bootstrap its way to a 'release' buildroot, with successive tags. Again, this is something that any build engineer should be familiar with.

The real wrench with 8 is modularity, which is also present in Fedora. If you really want to help CentOS go help them fix it:

https://lwn.net/Articles/805180/

Issues like "special version of RPM in the buildroot" are weird non-issues specifically related to how Koji works, but Modularity does have real problems.

> Sure, I largely believe the long-running narrative that a lot of core Linux development is paid/done by Red Hat, and that most other distros, including Debian/Ubuntu are free-riding to some extend. That's why I not really behind the cheering for Rocky, and think it's fairer in the end to either pay up, or roll up the sleeves and do a real _community_ enterprise OS based on Debian instead of cloning RHEL.

This is a no true Scotsman argument. I don't know what isn't "real" or "community" about CentOS other than the fact that there was/is overlap between CentOS maintainers and RH employees. Just because they have day jobs doesn't mean they can't be part of the community, too. Hand wringing about what's fair defeats the purpose of using a distro like a tool to accomplish goals.

> The first part might be true of RHEL customers, but I don't think it's true for CentOS customers. The customer base is of course diverse, but my guess is that for a very large part of the (CentOS, not RHEL) users, objections to moving to Debian/Ubuntu are practical (legacy/switching costs, maybe followed by maybe proprietary software support), much more than principled/legal.

You inverted this argument and you're asking the wrong questions. The question isn't "why aren't people moving off CentOS?", it's "why did they use CentOS in the first place?"

It's because they were already familiar with RHEL from previous jobs, and wanted familiar tooling (apt may be nicer than yum was, but dpkg is a dumpster fire for package maintainers compared to RPM, and RPM's tooling is much more cohesive than digging around in 10 different manpages for apt-cache || apt-file || dpkg -L || whatever to get information). Kickstart is nicer in many ways than preseed. Sure, the costs of swapping all of that are non-trivial both in the time investment for administrators to rewrite tooling and for the marginal loss in productivity until they re-learn tooling.

Going forward, container-first distros are getting the brunt of new deployments, which is exactly why RHEL isn't a growing revenue stream for Red Hat anymore, and why it doesn't make sense to keep pouring money into CentOS.

Red Hat is focused on OpenShift/OKD as the new "platform". Containers have their place, and it isn't everywhere for lowly end-users, but RH didn't drop CentOS to fuck over the community. They reduced support for the community because RHEL (and CentOS) are increasingly irrelevant to a company which has put their eggs in the CoreOS+Openshift basket as their future. That isn't specific to them.

All of the major vendors see the writing on the wall. What's better than making your systems easy to manage? Making it so they don't need management at all. Do everything in k8s and update a single system image quarterly (or whatever), and leave traditional workflows as an afterthought. Red Hat is lucky enough to already have RHEL, but if I were starting a new for-profit Linux company in 2020, I'd do exactly what CoreOS did or Rancher does.

That isn't how Red Hat does things in most of their projects. oVirt/RHV provides a reasonably "standard" example with their "rhevm-branding-rhev" package: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en...

It's a single package with relatively few additions, mostly color schemes in CSS.

Anaconda documents this in /usr/share/branding

RHEL puts a lot into subpackages of redhat-releasea

But it isn't really the point. There are thousands of packages. Only a handful actually deal with branding. I was an engineer at Red Hat for 7.5 years, and I left last June. I'm intimately familiar with this, and while it's more complex than sed, it's much simpler than it sounds, and the CentOS people are definitely familiar with it. Branding is NOT their hurdle. It's the build system, as they repeatedly mention.

And that is Koji, which is also open source: https://docs.pagure.org/koji/

You're blasting Red Hat for making it seem like they're somehow opposed to clones. That's fatuous. A major engineering company with complex workflows uses their own build system. News at 11. They also make this free and document the hell out of it. Anyone who has ever built a package for Fedora is familiar with it. Anyone who has ever dealt with release management/engineering for a product inside Red Hat is extremely familiar with it, and that includes many of the core CentOS team, plus the Fedora RelEng SIG is easy to join if you want to learn. It's complicated, but it's not black magic or even hard information to get. CentOS ALREADY USES IT.

It really doesn't matter whether the RHEL image is "for development use only" (you didn't want support anyway). Stop moving the goalposts.

> 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. It would be trivial to just put the actual RHEL8 iso as an unsupported download on their ftp/www server and sell the support separately, like Oracle or Canonical do. Instead, they kept this ridiculous make work project called CentOS around, that involved non-trivial manual labor meticulously rebranding RHEL into RedHat owned CentOS, whose users apparently mainly value it for being as close to RHEL as possible without paying. To a distant observer, the whole setup looks quite absurd. I think it's actually good that they finally put an end to it. But they should have either not started CentOS 8 at all or rode it out till the end. Pulling the plug at 20% of it's lifetime is plainly a shitty move.

But [they do](https://developers.redhat.com/products/rhel/download). A subscription buys you updates and support. RHEL itself is free. In addition, considering that almost all of Red Hat's products are "upstream first", branding is generally a single additional RPM which changes some colors. It is _not_ hard to rebrand RHEL

> 2. It appears that building a legal RHEL8+ clone is quite a task, and I'm guessing the amount of work involved is largely controlled by Red Hat Inc. I.e., they can make running/maintaining a project like Rocky or others more and more expensive if they choose to. I believe they going to test the limits of how difficult they can make building from their sources within the boundaries of the GPL. If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, if they are in the letter.

The only case in which this has happened is changing the packaging of the kernel-sources SRPM so Oracle could not pick and choose particular patches, and instead had to deal with a single massive diff to make stuff like kpatch work. The "expensive" part of building an EL8 clone is standing up a bunch of Koji builders. That isn't necessary either, strictly. It just makes "turn this SRPM into an RPM and combine it with a bunch of others into a temporary repo we can dogfood/release" easier. As always, it comes down to cost.

> 3. Given the previous point, I believe a project like Rocky is a losing proposition. If the "community" really values enterprise stability so much, better put the effort into an extra-LTS fork of Debian or even Ubuntu, and preparing for transition away from RHEL. Or just pay up, if you really believes the RHEL stability is so valuable. Clone projects are by necessity extremely dependent on actions of Red Hat Inc which has largely opposite interests. I don't know why people would volunteer for that.

The problem with this, broadly, is that the "community" is comprised of a lot of Red Hat-employed engineers. This idea that Linux is a bunch of "community" people that RH/IBM/whomever siphon off is completely fallacious. Sure, they exist, but the vast majority of Linux development is commercial. Some bug is reported in a downstream product that a customer pays for, or a feature is requested by a major customer (or the technical debt involved in maintaining something gets too high, or whatever), and professional engineers who are being paid to work on it write the patches upstream. Once they're merged, they get picked downstream into some kind of productized version.

Given that most of that happens in Fedora (or OKD, or oVirt, or whatever upstream is for a given product), CentOS being run by RH was pretty much the same embrace+extend+extinguish philosophy. The vast majority of RH engineers run Fedora, or an EL clone, and that isn't gonna change. What's different is that RHEL is no longer a growing revenue stream, and CentOS users didn't convert to RHEL at a large rate (or they reported CentOS bugs against RHEL, which is strictly against Red Hat's support policy).

What customers values is indemnity and the ability to point their finger at someone external, plus normal stuff like a security response team and responsible+timely disclosure during major CVEs. What the community value(d|s) is the ability to run commercial software that the vendor supports on RHEL without actually _paying_ for RHEL. It's not that they value 'enterprise stability'. It's that they value being able to run SAS or whatever without hacking the hell out of the installer. That isn't offered by an extra-LTS fork of Debian or Ubuntu, and no amount of complaining on Hackernews is gonna change that.

I honestly have no idea what you're talking about. The idea that UNIXes diverge from either BSD or SysV is not controversial. The fact that virtually every commercial UNIX had a completely different set of administration tools (other than vxfs as a add-on product to many) for any and every administrative task and init scripts in different locations are not orthogonal. "This system derives from SysV and that system derives from SysV, so I can administer them the same way" is complete bollocks and always was, even down to the location of the init scripts. That's the point.

At no point did I make any claim that inittab+runlevels was the "only thing going". I claimed that many systemd detractors hold to some abstract idea of a "pure" UNIX which never existed in the first place. As mentioned in my last comment (or my first comment) recognizing that there are fundamental limitations to traditional init and replacing or supplementing it with whatever (SAF, srcmstr, openrc, initng, you name it) and "being like systemd" are not even remotely the same thing except that they both manage service initialization.

This kind of false dichotomy is the point of the original post, which you missed in your fervor to turn it into a strawman. launchd, upstart, smf, runit, and other modern replacements are also not "like systemd" except that they manage services. SRC didn't replace init _at all_. It was a system run in parallel, as you well know. It was not a replacement for sysvinit, and AIX still has sysvinit. Again, as you well know, but it doesn't fit your narrative.

This is _exactly_ what I'm talking about. Neither SAF or srcmstr are equivalent to systemd, and you know it. Making the argument that they're even in the same ballpark is fatuous, except insofar as they have some abstract concept of service groups and replacing sysvinit with something better.

SMF wasn't added until later in Solaris 10. Other unixes (Tru64, HP-UX, Ultrix, AIX, IRIX, etc) did not have anything like it. They were either BSD init or sysvinit

The actual speaker is great, but the vast majority of people who have a problem with systemd get there philosophically.

In a "I never actually had to write any code which had significant interaction with existing solutions (openrc, upstart, sysv, bsd, whatever), but I know they exist, so I'll talk about them like they solve the same problems as systemd" way. Which they do not. Want socket activation, double forking, namespaced children, sane scripts/unit files that can build a good dependency tree? You have one option.

Additionally, people see other tools like systemd-network and say "but systemd is doing everything!" Which it isn't. Almost no distros package those as part of the default.

Even if they did, many of the anti-systemd crowd would rather live with a different, slower system (NetworkManager, for example) which is vastly most complicated than what they need. Ditto for systemd-resolved and local caching dnsmasq.

Systemd is not trying to replace NM or BIND or anything. It's basically saying "it's 2019. If you want to be able to work with a system without knowing the ins and outs of 30 different configuration files, and speed up boot time/auditability of your system significantly, you can use these services"

Some things are bad for the community in general. The dependence on dbus (and kdbus), systemd-logind, and other tools aren't very friendly to BSDs to anti-systemd distros. Frankly, from my POV, this isn't systemd's problem. The anti-distros are free to do what they want, knowing the limitations. The BSD guys have written compatibility layers, which you can do, because they're open standards.

Broadly, I'd say that the anti-systemd crowd holds to an idea of "UNIX" purity, as if HP-UX, Tru64, AIX, Solaris, IRIX, and others were uniform. The reality is that they were more different than they were alike, in terms of administrative tools, filesystem layout (is this /sbin/init.d, /etc/rc.d, /sbin/rc.d, etc?) and even software portability. A large reason that GNU autoconf exists is to detect all of the quirks on all of these platforms.

Additionally, anti-systemd people either never used X11R6/OSS/lilo and other old tools, or don't remember how terrible they were. Any large change in the community (X.org fork, ALSA->PulseAudio, grub) draws ire. From the same people who are trying to use syslinux and efibootmgr instead of just using grub2.

Some people would rather debate philosophy than get actual work done, and that's great for open source, even if it's frustrating. But those people never dug into the guts of upstart to make something work, or had 250 lines of sysvinit boilerplate+supervisord saved off somewhere to speed up a process that you can do in 4 lines in a systemd unit file.