If more people are able to step back and think about the potential growth for the next 5-10 years, then I think the discussion would be very different.
I am grateful to be able to witness all these amazing progress play out, but am also concerned about the wide ranging implications.
> think about the potential growth for the next 5-10 years,
I thought about it and it doesn't seem that bright. The problem is not that LLMs generate inferior code faster, is that at some point some people will be convinced that this code is good enough and can be used in production. At that point, the programming skills of the population will devolve and less people will understand what's going on. Human programmers will only work in financial institutions etc., the rest will be a mess. Why? Because generated code is starting to be a commodity and the buyer doesn't understand how bad it it.
So we're at the stage when global companies decided it's a fantastic idea to outsource the production of everything to China, and individuals are buying Chinese plastic gadgets en masse. Why? Because it's very cheap when compared to the real thing.
This is what the kids call “cope”, but it comes from a very real place of fear and insecurity.
Not the kind of insecurity you get from your parents mind you, but the kind where you’re not sure you’re going to be able to preserve your way of life.
My hot take is that portions of both the pro- and anti- factions are indulging in the copium. That LLMs can regurgitate a functioning compiler means that it has exceeded the abilities of many developers and whether they wholeheartedly embrace LLMs or reject LLMs isn't going to save those that have been exceeded from being devalued.
The only safety lies in staying ahead of LLMs or migrating to a field that's out of reach of them.
Sorry but I think you have it the other way around.
The ones against it understand fully what the tech means for them and their loved ones. Even if the tech doesn't deliver on all of its original promises (which is looking more and more unlikely), it still has enough capabilities to severely affect the lives of a large portion of the population.
I would argue that the ones who are inhaling "copium" are the ones who are hyping the tech. They are coping/hoping that if the tech partially delivers what it promises, they get to continue to live their lives the same way, or even an improved version. Unless they already have underground private bunkers with a self-sustained ecosystem, they are in for a rude awakening. Because at some point they are going to need to go out and go grocery shopping.
There is a massive difference between a result like this when it's a research project and when it's being pushed by billion dollar companies as the solution to all of humanities problems.
In business, as a product, results are all that matter.
As a research and development efforts it's exciting and interesting as a milestone on the path to something revolutionary.
But I don't think it's ready to deliver value. Building a compiler that almost works is of no business value.
Noone can correctly quantify what these models can and can't do. That leads to the people in charge completely overselling them (automating all white collar jobs, doing all software engineering, etc) and the people threatened by those statements firing back when these models inevitably fail at doing what was promised.
They are very capable but it's very hard to explain to what degree. It is even harder to quantify what they will be able to do in the future and what inherent limits exist. Again leading to the people benefiting from it to claim that there are no limits.
Truth is that we just don't know. And there are too few good folks out there that are actually reasonable about it because the ones that know are working on the tech and benefit from more hype. Karpathy is one of the few that left the rocket and gives a still optimistic but reasonable perspective.
It could also be that, so often, the claims of what LLMs are achieve are so, so overstated that people feel the need to take it down a notch.
I think lofty claims ultimately hurt the perception of AI. If I wanted to believe AI was going nowhere, I would listen to people like Sam Altman, who seem to believe in something more akin to a religion than a pragmatic approach. That, to me, does not breed confidence. Surely, if the product is good, it would not require evangelism or outright deceit? For example, claiming this implementation was 'clean room'. Words have meaning.
This feat was very impressive, no doubt. But with each exaggeration, people lose faith. They begin to wonder - what is true, and what is marketing? What is real, and what is a cheap attempt for companies to rake in whatever cold hard AI cash they can? Is this opportunistic, like viral pneumonia, or something we should really be looking at?
This reply is argumentum ad personam. We could reverse it and say GenAI companies push this hype down our throats because of fear that they are burning cash with no moat but these kinds of discussions lead nowhere. It's better to focus on core arguments.
How does a statistical model become "perfect" instead of merely approaching it? What do you even mean by "perfect"?
We already have determinism in all machines without this wasteful layer of slop and indirection, and we're all sick and tired of the armchair philosophy.
It's very clear where LLMs will be used and it's not as a compiler. All disagreements with that are either made in bad faith or deeply ignorant.
I would claim that LLMs desperately need proprietary code in their training, before we see any big gains in quality.
There's some incredible source available code out there. Statistically, I think there's a LOT more not so great source available code out there, because the majority of output of seasoned/high skill developers is proprietary.
To me, a surprising portion of Claude 4.5 output definitely looks like student homework answers, because I think that's closer to the mean of the code population.
This is dead wrong: essentially the entirety of the huge gains in coding performance in the past year have come from RL, not from new sources of training data.
I echo the other commenters that proprietary code isn’t any better, plus it doesn’t matter because when you use LLMs to work on proprietary code, it has the code right there.
> it doesn’t matter because when you use LLMs to work on proprietary code, it has the code right there
The quality of the existing code base makes a huge difference. On a recent greenfield effort, Claude emitted an MVP that matched the design semantics, but the code was not up to standards. For example, it repeatedly loaded a large file into memory in different areas where it was needed (rather than loading once and passing a reference.)
However, after an early refactor, the subsequently generated code vastly improved. It honors the testing and performance paradigms, and it's so clean there's nothing for the linter to do.
Author attributes past year's degradation of code generation by LLMs to excessive use of new source of training data, namely, users' code generation conversations.
Yeah, this is a bullshit article. There is no such degradation, and it’s absurd to say so on the basis of a single problem which the author describes as technically impossible. It is a very contrived under-specified prompt.
And their “explanation” blaming the training data is just a guess on their part, one that I suspect is wrong. There is no argument given that that’s the actual cause of the observed phenomenon. It’s a just-so story: something that sounds like it could explain it but there’s no evidence it actually does.
My evidence is that RL is more relevant is that that’s what every single researcher and frontier lab employee I’ve heard speak about LLMs in the past year has said. I have never once heard any of them mention new sources of pretraining data, except maybe synthetic data they generate and verify themselves, which contradicts the author’s story because it’s not shitty code grabbed off the internet.
> Yeah, this is a bullshit article. There is no such degradation, and it’s absurd to say so on the basis of a single problem which the author describes as technically impossible. It is a very contrived under-specified prompt.
I see "No True Scotsman" argument above.
> My evidence is that RL is more relevant is that that’s what every single researcher and frontier lab employee I’ve heard speak about LLMs in the past year has said.
Reinforcement learning reinforces what is already in the LM, makes width of search path of possible correct answer narrower and wider search path in not-RL-tuned base models results in more correct answers [1].
> I have never once heard any of them mention new sources of pretraining data, except maybe synthetic data they generate and verify themselves, which contradicts the author’s story because it’s not shitty code grabbed off the internet.
The sources of training data already were the reasons for allegations, even leading to lawsuits. So I would suspect that no engineer from any LLM company would disclose anything on their sources of training data besides innocently sounding "synthetic data verified by ourselves."
From the days I have worked on blockchains, I am very skeptical about any company riding any hype. They face enormous competition and they will buy, borrow or steal their way to try to not go down even a little. So, until Anthropic opens the way they train their model so that we can reproduce their results, I will suspect they leaked test set into it and used users code generation conversation as new source of training data.
>>> It is a very contrived under-specified prompt.
No True Prompt can be such contrived and underspecified.
The article about degradation is a case study (single prompt), weakest of the studies in hierarchy of knowledge. Case studies are basis for further, more rigorous studies. And author took the time to test his assumptions and presented quite clear evidence that such degradation might be present and that we should investigate.
We have investigated. Millions of people are investigating all the time and finding that the coding capacity has improved dramatically over that time. A variety of very different benchmarks say the same. This one random guy’s stupid prompt says otherwise. Come on.
As far as I remember, article stated that he found same problematic behavior for many prompts, issued by him and his colleagues. The "stupid prompt" in article is for demonstration purposes.
Progress with RL is very interesting, but it's still too inefficient. Current models do OK on simple boring linear code. But they output complete nonsense when presented with some compact but mildly complex code, e.g. a NumPyro model with some nesting and einsums.
For this reason, to be truly useful, model outputs need to be verifiable. Formal verification with languages like Dafny , F*, or Isabelle might offer some solutions [1]. Otherwise, a gigantic software artifact such as a compiler is going to have a critical correctness bugs with far-fetched consequences if deployed in production.
Right now, I think treating a LLM like something different than a very useful information retrieval system with excellent semantic capabilities is not something I am comfortable with.
I firmly agree with your first sentence. I can just think about the various modders that have created patches and performance enhancing mods for games with budgets of tens to hundreds of millions of dollars.
But to give other devs and myself some grace, I do believe plenty of bad code can likely be explained by bad deadlines. After all, what's the Russian idiom? "There is nothing more permanent than the temporary."
I'd bet, on average, the quality of proprietary code is worse than open-source code. There have been decades of accumulated slop generated by human agents with wildly varied skill levels, all vibe-coded by ruthless, incompetent corporate bosses.
Not to mention, a team member is (surprise!) fired or let go, and no knowledge transfer exists. Womp, womp. Codebase just gets worse as the organization or team flails.
It doesn’t matter what the average is though. If 1% of software is open source, there is significantly more closed source software out there and given normal skills distributions, that means there is at least as much high quality closed source software out there, if not significantly more. The trick is skipping the 95% of crap.
yeah, but isn't the whole point of claude code to get people to provide preference data/telemetry data to anthropic (unless you opt out?). same w/ other providers.
i'm guessing most of the gains we've seen recently are post training rather than pretraining.
Yes, but you have the problem that a good portion of that is going to be AI generated.
But, I naively assume most orgs would opt out. I know some orgs have a proxy in place that will prevent certain proprietary code from passing through!
This makes me curious if, in the allow case, Anthropic is recording generated output, to maybe down-weight it if it's seen in the training data (or something similar)?
Has a "N million context window" spec ever been meaningful? Very old, very terrible, models "supported" 1M context window, but would lose track after two small paragraphs of context into a conversation (looking at you early Gemini).
Umm, Sonnet 4.5 has a 1m context window option if you are using it through the api, and it works pretty well. I tend not to reach for it much these days because I prefer Opus 4.5 so much that I don't mind the added pain of clearing context, but it's perfectly usable. I'm very excited I'll get this from Opus now too.
If you're getting on along with 4.5, then that suggests you didn't actually need the large context window, for your use. If that's true, what's the clear tell that it's working well? Am I misunderstanding?
Did they solve the "lost in the middle" problem? Proof will be in the pudding, I suppose. But that number alone isn't all that meaningful for many (most?) practical uses. Claude 4.5 often starts reverting bug fixes ~50k tokens back, which isn't a context window length problem.
Things fall apart much sooner than the context window length for all of my use cases (which are more reasoning related). What is a good use case? Do those use cases require strong verification to combat the "lost in the middle" problems?
New idea generation? Understanding of new/sparse/not-statistically-significant concepts in the context window? I think both being the same problem of not having runtime tuning. When we connect previously disparate concepts, like with a "eureka" moment, (as I experience it) a big ripple of relations form that deepens that understanding, right then. The entire concept of dynamically forming a deeper understanding from something new presented, from "playing out"/testing the ideas in your brain with little logic tests, comparisons, etc, doesn't seem to be possible. The test part does, but the runtime fine tuning, augmentation, or whatever it would be, does not.
In my experience, if you do present something in the context window that is sparse in the training, there's no depth to it at all, only what you tell it. And, it will always creep towards/revert to the nearest statistically significant answers, with claims of understanding and zero demonstration of that understanding.
And, I'm talking about relatives basic engineering type problems here.
Whenever I see this, I make the (almost always correct) assumption that the SOTA models had an advantage, with the alternative explanation being a complete lack of awareness of the state of AI (which is very very rare for a tool like this).
With SOTA missing, it also is a strong indicator that someone like you is not the target audience.
Well acttshually, it's 100% efficient. If you put 1W in, you will get exactly one watt out, steady state. The resulting steady state temperature would be close to watts * steady state thermal resistance of the system. ;)
I don't think you could use "efficiency" here? The math would be based on thermal resistance. How do you get a percentage from that? If you have a maximum operating temperature, you end up with a maximum operating wattage. Using actual operating wattage/desired operating wattage doesn't seem right for "efficiency".
Working with a Chinese vendors is an adversarial first relationship, where 差不多 is deeeeep in the culture (and, from my experience, tends to survive trips across the ocean).
There are professional communication/training courses for working with Chinese vendors/colleagues that spell all of this out, because it's not some secret. It's just a very different culture, with high context communication (I'll let you read what the practical implications of that are elsewhere). Want to have your mind blown? Look up what it means when they say "yes", when you're explaining something.
Being a low context person, I have significant and severe communication problems when working with Chinese colleagues/vendors.
I did not find this to be the case, except with a few low quality vendors we ended up dropping.
It was mostly the same as anywhere else, you go talk to them in person, tour their facilities/processes, and see what else they've built.
I was warned strongly about IP theft and cost cutting, but didn't find that expectation quite met reality. It may have been that our products were mostly un-copyable, and we specified everything precisely, or were just lucky.
Given that Mandarin has many forms of "yes", isn't the problem that all those forms map on to our singular "yes". For a native speaker "yeeeessss" means something very different to "yes", but they would use a different word.
Knowing which is being spoken or heard is going to be hard.
chabuduo is basically fail fast, fail early with Chinese characteristics. Maybe because I was in a frat, but talking to Chinese salespeople seems very similar to talking to my frat brothers.
Personally, I never really had too many issues sourcing from China because I made sure I was always introduced to a reliable partner first.
And secondly, I told them when deciding on two options, choose the better quality option, regardless of price.
Basically, I didn't tell them to save us much money as possible if that made all the difference.
Googled that ‘yes’ thing. Not different from my experience in other parts of the world. ‘Yes’ means ‘yes, sir’ only in the army. What is your environment?
As someone living in the Nordics my experience already with central Europeans and especially so Americans is that these cultures are already much more high context than the Nordics. I guess up here we're all borderline autistic?
I've done business the other way around, Western Europe with Finland. I think it's just different context? There are unwritten customs and meanings in Finland as well, just different ones.
Even UK vs Netherlands is a significant difference in how things work in business deals and that's just a 45 min flight. Unspoken expectations are different on how the other side is supposed to behave.
I have observed the same across a bunch of linguistically Germanic countries (DE, AT, CH, NL, DK, NO, haven't been to SE, didn't observe it in IS), and I thought of it as "cultural autism." Apparently "higher context" is the politically correct way to say it. Now I know!
Danish and Norwegian are not linguistically Germanic. If anything, German has more old Norse influences. And dutch.. Well, dutch is the illegitimate child of england and germany.
>Danish and Norwegian are not linguistically Germanic
Where do you get that notion? My education (and some googling to refresh my memory) has Norwegian, Swedish and Danish classed as "North Germanic" according to comparative linguistics. That is one subset of the West Germanic languages which most of northern Europe speaks.
I live in Germany. 'Ja' here means 'ich stimme zu' only when explicitly asked. That's why Germans stick 'Ja?' after every second sentence. Ja? In general, 'ja-a...' means 'I hear you', same as almost everywhere else. That has been my experience.
And why do they say ‘right?’ every time? Because without it my ‘ja’ does not mean ‘yes, sir’, but rather ‘I hear you, go on’. So, same as everywhere else.
Hardware engineering, where an inappropriate yes can mean massive amounts of time and money wasted, making it a very low context environment, by necessity.
>Look up what it means when they say "yes", when you're explaining something.
Is there a term for this? Because I see it in my personal life as well dealing with some low price manual labor that doesn't speak english.
Instructions often get lost in translation, the reply will be "yes" and it doesn't get done. I know they want to sound professional and confident, so saying no or asking questions is a "bad thing".
Lying. It is called lying, deceit, or bearing false witness.
In my house I do not permit "yeah", or "okay". It is "yes" and anything else is interpreted as a 'no'.
Once you press someone to speak a "yes" as a solid commitment, for example to an understanding of an instruction. If this puts the person on the defensive then you are dealing with someone who is not interested in being held accountable.
This isn't fair, because it's misunderstanding the problem. It's not that they're lying, it's that, in their culture, the meaning of yes is something different, meaning "I hear you" rather than "I understand you". If they're not strong with english they might not have a grasp of this, so (in the case of Mandarin as primary language) you have to usually think of it as an empty "uh huh" type filler word, not a word with actual meaning.
The real problem I have is the "saving face" concept prevents them admitting they don't understand something. This is where the "high context" part comes in. You can't listen to what they say directly, you have to go off how they say it, and other context clues. This is what I have the biggest problem with. The only way to know if they actually understand something is test their understanding, like have them repeat/explain it back to you. From a low context/western perspective, this results in low verbal trust (because it technically is). I've wasted so many hours on taking something said at face value, that I just default to verifying everything that's said, and trying to be patient when I find out the truth. But, I am getting much better at reading the cues, so can usually spot when the (from my western/low context perspective) bullshit when it starts.
There are old stereotypes around this clash of meaning/culture, but it really is just that. If you're from their culture, and speak their language, there's no "bullshitting" or "lying". From what I've been told, it's incredibly clear when someone is saving face, and it's very clear what the response should be, to "help" them save face. Westerners are, literally, just blind to it all. It's an incompatible mindset and language/expression that requires a robust translation layer that needs to exist in one of the parties. I seem to be mostly incapable of high context communication, even in english, so I'm just as "at fault" in the two party role of communication.
I live in a different world than most where the expectation is we speak the truth, stand behind our word, and in the event of failure we maintain the relationship after resolving the conflict.
As for saving face, I provide opportunities to walk back, restate, or take back something that was said. People get angry, misspeak, or respond with fear and that is understandable.
I get what you're saying, but you're ignoring intent here. They're, literally, using the wrong word, without meaning to. In their language they have multiple "yes" that mean very different things, but they incorrectly use our single "yes" for all of them which, as you're very correct to point out, has a very specific and STRONG meaning. This is a conceptual mapping mistake, not an intent.
They're trying, and slightly failing, to speak a language they took time to learn, but is still unfamiliar to them, my dude. The alternative is that you/I should learn mandarin. I applaud their efforts that allow me to be lazy, even if it means I have to understand some shortfalls in the communication.
If you learn a language, but accidentally use the wrong word in conversation, because maybe nobody has corrected you before, does that make you a liar? Of course not. That's what's going on here.
I was ignoring the language translation with excessive simplification while speaking of a framework.
To your specific point: no, grace abounds for those who remain in conversation and continue to repair the situation.
As for having a single 'yes', we backwater Americans have multiple versions including yeah, okay, yup, ya, yessssss, hell yes, yuppers, uh huh, right, right-o, got it, absolutely, and I am sure a dozen more.
I am speaking of intent. The intent, regardless of the language used, commnunicate in a way that both parties have no assumptions and if there is a miscommunication on anyone's part, both parties work to resolve it without blame. And I thank you for your reply, my dude, which I take as a verbal suffix of casual frustration. English is not my first language mind you.
Can you share some resources/books/courses to learn more? I'm interested in exploring working with Chinese vendors and it would be nice to learn from someone else before jumping into it.
I knew the Real ID requirements wouldn't be enforced, at least here in California, about a year before, after I saw the requirements: California can't enforce it because it would prevent too many undocumented people from flying.
Although, I thought it would just be delayed indefinitely. I suppose it effectively has been.
> "ok install systemd..." and now... it just goes.
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.
This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because."
I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy.
I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local").
I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms.
I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this?
It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing.
Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo.
I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
> I think better proof of this would be a rejected PR rather than a neglected bug report.
I understand the sentiment you're expressing here, and it's often a reasonable one.
However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess.
How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote").
systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance.
But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)?
Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself.
So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity.
If you think that's stupid, how would you solve it?
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided.
Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly add landmines, like systemd-update-done.service. It has an unusual dependency requirements, it runs before the network filesystems but after the local filesystems.
I bet you didn't know about it? It's a service that runs _once_ after a system update. So the effect is that your system _sometimes_ fails to boot.
> systemd has .mount units which are way more configurable than /etc/fstab lines
It's literally the inverse. As in, /etc/fstab has _more_ options than native mount units. No, I'm not joking.
Sounds like your admin, distro, or the systemd team could pay some attention to systemd-update-done.service
The "can only be used in /etc/fstab" systemd settings are essentially workarounds to do those things via fstab (and workaround fstab related issues) rather than depend on other systemd facilities (c.f. systemd-gpt-auto-generator). From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
This service is the standard part of systemd. And my distro is a bog-standard Fedora, with only iSCSI as a complication.
Are you surprised that such a service exists? I certainly was. And doubly so because it has unusual dependency requirements that can easily lead to deadlocks. And yes, this is known, there are open issues, and they are ignored.
> From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
No, they are not. In my case, I had to use fstab to be able to specify a retry policy for mount units (SMB shares) because it's intentionally not exposed.
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
The '_netdev' option works a treat on sane systems. From mount(8):
_netdev
The filesystem resides on a device that requires network access
(used to prevent the system from attempting to mount these
filesystems until the network has been enabled on the system).
It should work on SystemD and is documented to in systemd.mount
Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.
but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.
Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.
> Sure, and systemd would translate that directly into a dependency on network startup...
You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:
In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown which should not have been there - and were not there - when the units were first loaded.
> ...not "just works" inference.
Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.
I saw many corner cases in systemd over the years. And to echo the other poster in this thread, they typically are known, have Github issues, and are either ignored or have a LOLNO resolution.
And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.
> "I found one bug in systemd which invalidates everything"
I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.
"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.
I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.
reply