Login
You're viewing the mstdn.social public feed.
  • Jun 30, 2026, 7:11 AM

    When someone redesigns, replaces or rewrites a technology that's been around forever, there are lots of reasons why people might not be enthusiastic. Some are less obvious than others.

    There's plain inertia, of course: "The new way of doing things isn't the way I'm used to."

    There's more active frustration: "I already learned how to do this once, why are you making me learn it all over again?"

    And capability mismatch: "Arrgh, this specific thing I used to do a lot is difficult to do in the new system."

    But perhaps less obvious, there's an erosion of trust. When a thing's _never_ been replaced, you learn it with reasonable expectation that the knowledge will serve you well all your life. But after it's been replaced _once_ by enthusiastic rewriters, you don't have that expectation any more. Who knows, in five years the next batch of enthusiasts might rewrite it again! So it doesn't feel like learning the new thing will pay back on the same time scale.

    💬 15🔄 91⭐ 189

Replies

  • Jun 30, 2026, 7:12 AM

    (Brought to you by a conversation yesterday about 'ifconfig' and 'route' being deprecated in favour of 'ip'. So not very topical. But the point about trust erosion was a thought I hadn't had before, and retrospectively realised I was feeling it myself. And I think it applies more widely than Linux network management utilities.)

    💬 12🔄 5⭐ 50
  • Jun 30, 2026, 7:16 AM

    @simontatham I think this also strongly depends on the person, some people are much more change averse than others. I've noticed that I don't mind changes as long as they don't make things worse, and even enjoy the change of routine, but I know enough people where they are super annoyed that their routine has been  altered, even if the change was minute.

    No judgement on people who are like that though, it's just interesting to see how our tolerations differ.

    💬 2🔄 0⭐ 0
  • Leelooleeloo@c.im
    Jun 30, 2026, 8:00 AM

    @ainmosni @simontatham
    Geeks like changes. Always buying the newest stuff.

    Except when they make things worse.

    Like Systemd, Wayland...

    While I personally don't mind the ip command, the syntax did get a lot more complicated in the simple cases. More consistent, yes, but in this case that means the simple cases became more complex to be consistent with complex usecases. I suspect that people who prefer ifconfig, route mostly use the simple cases and those who like the ip command use the more advanced functionality and like the consistency.

    For me personally, I have a mix of Wireguard tunnels (that don't use wg-quick) and VLANs (that's 802.1Q, not 802.11), that used to require a whole bunch of different commands in addition to ifconfig and route.

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 8:43 PM

    @ainmosni @simontatham I am not sure this about being change averse or not as person. I have to learn a lot of new things basically every day, but I use free software because it should be my choice whether or when I learn something or not. I see the problem mostly where new things are not offered as an alternative I can opt-in on my own terms, but where they are pushed onto me.

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 7:20 AM

    @simontatham Linux has lots of little pain points like this for me, one reason I stick with FreeBSD (see also: systemd, hiding stuff in sbin by default, etc)

    💬 1🔄 0⭐ 0
  • Jun 30, 2026, 7:22 AM

    @Darius hey, if you're really unlucky it's now in the wrong one of /sbin and /usr/sbin!

    Debian's newfangled 'usr-merge' thing where /foo and /usr/foo point at the same place is _supposed_ to make it unnecessary to remember which things go where, but one noticeable effect for me is that now when I want to find out what package owns a binary, I run 'dpkg -S $(which thing)' and get no hits because 'which' finds /bin/thing first and dpkg -S has only indexed the file as /usr/bin/thing.

    💬 2🔄 1⭐ 1
  • 💬 0🔄 0⭐ 0
  • Jul 1, 2026, 1:30 AM

    @simontatham @Darius The usrmerge disaster started as a way to help badly-written scripts (and config for bad tools that don't search PATH) port from Ubuntu to RH.

    In Debian it became part of the toxic culture wars thing where making the naysayers cry is the point. It didn't even matter that we were crying about breakage of things even the "winners" used to rely on. No, must have progress! Oh, was that your ox we gored?

    Yes I'm still bitter, why do you ask?

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 7:44 AM

    @simontatham very much this. i'm also curious why the new ones don't come with an option/ aliases to behave like te old one.. its finger memory that's failing me. (or do they and they just don't shout about it?)

    Edit: wrote "behave like" I meant "have same UI as (as much as possible)"

    💬 1🔄 0⭐ 1
  • Jun 30, 2026, 7:48 AM

    @castaway in fairness, not everything about the old ones was great. I never forgave 'route' in particular for defaulting to doing DNS lookups on all its numeric addresses. Dammit, why do you think I'm _running_ 'route'? 9/10 times it's because my network is broken, and the last thing I want is it dithering forever failing to contact the name server. At least 'ip route' doesn't make you always add the 'work properly' option.

    But it's a good point that several of the most common ifconfig and route runes could easily be implemented as wrappers translating into the corresponding ip rune.

    💬 2🔄 0⭐ 8
  • 💬 0🔄 0⭐ 1
  • Jun 30, 2026, 11:12 AM

    @simontatham @castaway The reason for replacing ifconfig with ip is that the command syntax for the former can't request a lot configuration the latter can (because it was written for that purpose).

    💬 3🔄 0⭐ 0
  • Jun 30, 2026, 12:38 PM

    @mansr @castaway I'm sure you're right, and I've even used some of that functionality myself, but it _still_ doesn't change the resulting lack of enthusiasm to learn the new thing thoroughly.

    To decide whether it's worth putting in the effort, the question is not whether the change happened for a good reason. It's whether another similar change is likely in the future. If it happened because other stuff made it genuinely necessary, who's to say other stuff might not make it genuinely necessary again?

    💬 0🔄 0⭐ 2
  • 💬 1🔄 0⭐ 1
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 1
  • Jul 1, 2026, 6:44 AM

    @fanf @simontatham @castaway I haven't looked closely at the BSDs, but the ip syntax is still more logical and more easily extended when needed. Personally, I prefer it even though it meant getting used to a new thing.

    Why is this coming up now though? It's been 20 years.

    💬 1🔄 0⭐ 0
  • Jul 4, 2026, 11:16 AM

    @mansr As OP explained in the second post, it came up just because it came up. ( hachyderm.io/@simontatham/1168… )

    I think conservative interface evolution is an important aspect, and I think reworking user interfaces to new requirements rather than building epicycles on top of
    whatever we came up with in the past is important too.

    I think on a modern Linux-based operating system, it's still possible to install both "ip" and "ifconfig" without conflict, and both will work, but there is no doubt that "ip" is the default in the modern environment.

    Maybe the new interface is superior, but the point is that the change had a cost, the counterpoint being that legacy has a cost too. As with everything, it's a balance and a tradeoff.

    @fanf @castaway @simontatham

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 5⭐ 1
  • Jun 30, 2026, 9:20 AM

    @simontatham 'ip' is a separate beast that covers a lot more than ifconfig/route/netstat/etc could ever do.

    The better comparison would be ipchains -> iptables -> nftables (and all of netfilter along with that).
    And many folks think that OpenBSD pf is still way nicer/better ;)

    And things will get replaced, simply because the next folks do not get the old thing or indeed they were not part of the bikeshed why something is the way it is ;)

    💬 1🔄 0⭐ 0
  • Jun 30, 2026, 10:39 AM

    @jeroen
    There was a thing I read from an anthropological linguist: languages that don't change, die. Not every language that changes survives, but pretty much every language that doesn't change fails within a couple generations.

    I've wondered ever since how much more that might apply to.
    @simontatham

    💬 2🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Jun 30, 2026, 4:39 PM

    @dpflug

    But which way does the causality go? Could it be that moribund languages have too few young speakers to drive change? If all the speakers of a language are grandparents then first it'll ossify and then it'll die out, but the ossification won't be the cause of death.

    Edit: glide-typo.

    @jeroen @simontatham

    💬 1🔄 0⭐ 2
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Jun 30, 2026, 12:42 PM

    @simontatham I enthusiastically learned about tech when I was younger, but after so many things were needlessly replaced or reworked with an equivalent or worse version I stopped investing the energy. It’s not worth committing to memory anymore.

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 2:31 PM

    @simontatham Early on I saw technology advancing faster than I could afford or learn new computers and adopted a personal rule to ignore every other generation. So I went from CP/M skipping DOS directly to Unix, then later skipped the middle generation of Linux firewalling.

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 2:45 PM

    @simontatham I had a job years ago testing network devices, where I kept running into the problem that other people on the team were using deprecated tools and getting inaccurate results. For instance, I had an argument with some engineers who insisted an interface could only have one IPv4 address. ip tools allowed assigning more, but ifconfig (which was already deprecated) did not.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Jun 30, 2026, 8:03 AM

    @simontatham ip annoyed me most by being two letters that don't really make sense when referring to a network interface, it seems semantically worse. I don't know enough about why it was changed to decide if I feel it was necessary but I think changes that touch a lot of existing scripts are a bit rude. Such a change feels like a challenge to the idea of composition of small programs to get things done, which in turn feels like a threat to using the computer in the way that you want - but only for people who do that. Sometimes I think people read Who Moved My Cheese? and then decide to move the cheese for their own reasons. A horrible act of bullying disguised as necessary change or a byproduct of progress and improvement, sometimes it's impossible to tell.

    💬 2🔄 0⭐ 0
  • Jun 30, 2026, 8:10 AM

    @synx508 there's also a question of generality, of course. When I first learned Linux networking, I was really learning _Unix_ networking – the same ifconfig and route commands worked unchanged, or nearly so, on various other Unices. So the knowledge was more widely applicable at the time, as well as being useful far into the future.

    But if I learned Linux networking now, I'd only be learning this year's Linux.

    💬 0🔄 1⭐ 0
  • 💬 0🔄 0⭐ 0
  • Jun 30, 2026, 8:27 AM

    @simontatham
    Well said!

    As a devhead I've lost all trust in the for greed software industry. Too many fantastic software products have been unrecognizably enshitified.

    Don't flame me but MS Outlook is a powerful scriptable top boss of an email client. I use it to process hundreds of important emails a day and run a VM just for it, not kidding. But MS has violated trust, and the FOSS community only holds candles against the bazooka of Outlook's capabilities... I see no migration path...

    💬 1🔄 0⭐ 1
  • Jun 30, 2026, 10:28 AM

    @TrimTab
    I suspect the FOSS alternative for heavy mail scripting is mbsync/offlineimap, notmuch/maildir-utils, and some scripting in your language of choice.
    @simontatham

    💬 0🔄 0⭐ 1
  • Jun 30, 2026, 8:32 AM

    @simontatham when I first started using Linux as my main operating system, I had an extensive custom configuration for the window manager Sawmill. Then it got completely broken by an upgrade. I've never done more than the simplest configuration for any program since.

    💬 3🔄 1⭐ 0
  • Jun 30, 2026, 8:34 AM

    @pozorvlak oddly enough, that's _my_ window manager, and I too have a lot of complicated Lisp configuration for it.

    But I must have come in after the breaking change you mention. Certainly I started using it after it renamed to Sawfish, so if you're calling it Sawmill then I guess the breakage happened first out of those two things.

    💬 2🔄 0⭐ 2
  • 💬 0🔄 0⭐ 1
  • 💬 0🔄 0⭐ 1
  • Jun 30, 2026, 9:28 AM

    @pozorvlak @simontatham This is something that I feel like has gotten a lot better in the LLM world. "Take this existing setup and move it over to the new API in a mostly mechanical way" is a task that LLMs are pretty good at.

    It's still a pain in the ass, but I do think it's taken a bunch of the sting out of breaking changes.

    💬 2🔄 0⭐ 1
  • Jun 30, 2026, 9:29 AM

    @pozorvlak @simontatham (This doesn't of course fix the bit where you may also have to update your mental model of the software significantly. It's only helpful when there's a mostly equivalent set of functionality that changed its shape)

    💬 0🔄 0⭐ 2
  • Jun 30, 2026, 10:16 AM

    @DRMacIver @pozorvlak flipping that round, this points out a new risk this decade of large-scale breaking changes. One person using an LLM for a job like this may be able to doublethink their way around the environmental cost, but someone introducing a change that breaks 100 million users' scripts might well be causing _most_ of them to throw an environmental disaster at the problem, which is a far larger cost!

    💬 1🔄 0⭐ 5
  • Jun 30, 2026, 11:02 AM

    @simontatham @pozorvlak I'm pretty happy to singlethink my way around the environmental costs (which are comparable to just running the computer the software you're upgrading is on...) but probably not interested in arguing the case.

    💬 1🔄 0⭐ 1
  • Jun 30, 2026, 11:07 AM

    @simontatham @pozorvlak There are genuine environmental concerns around training (mostly insufficient grid capacity/storage and the resulting short-term significant increase in non-renewable energy), but inference isn't any more of an environmental disaster than normal computer use.

    💬 0🔄 0⭐ 1
  • Jun 30, 2026, 3:50 PM

    @pozorvlak @simontatham all my config is in #git, and the script that applies the contents of the repository to my home for is unreasonably portable. It even works on #HPUX! If my config doesn’t apply cleanly anywhere I make it more portable immediately.

    💬 1🔄 0⭐ 0
  • Jun 30, 2026, 9:26 PM

    @DrHyde I also keep my (minimal) dotfiles in git, but that doesn't solve the API-breakage problem - if anything, it makes it worse, if the same dotfiles repo must work across many machines!
    @simontatham

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 2
  • Jun 30, 2026, 9:39 AM

    @simontatham
    The real friction is not learning something new.
    It is losing the expectation that the knowledge will last.
    When a technology is rewritten too often, the trust layer erodes and users stop believing that their investment will pay back over time.
    Stability is not nostalgia.
    It is part of the architecture that makes a system worth mastering.

    💬 0🔄 1⭐ 0
  • 💬 0🔄 0⭐ 2
  • Jun 30, 2026, 12:45 PM

    @simontatham As a professional software developer, "don't fix what ain't broken" has to be one of the most valuable principles I learned, right up there with "The simplest thing that works is the best"

    💬 0🔄 0⭐ 0
  • Jun 30, 2026, 12:51 PM

    @simontatham This casual churn in tooling erodes trust in the system the tool exists in, not just in the tool itself. We need to be able to depend on our tools, to be able to reason about them, to know what their limitations are, and how they fail. We have a mental model of them and as long as changes are gradual and evolutionary it's relatively easy to adapt and to maintain trust.

    We're getting to the point that a generation or two of developers have thoroughly discarded notions of trust and consent. They are frustrated with caring about other people. Or maybe it wasn't that big of an issue because systems were smaller and balkanized - uses weren't as diverse and there was a tighter community that meant systems didn't need to change often and that changes served the majority of users.

    What's darkly amusing is that I have substantially less trouble recovering abandoned 50-year-old Fortran code than I do 6-month-old Python. For all its many limitations and flaws, Fortran takes backward compatibility very seriously, deprecating misfeatures over decades yet still managing to add major features. Python is a disposible language for disposable programs and disposable programmers.

    Who does disruption serve? In the past 15-20 years my answer has generally been "not me". Not out of being hidebound or change averse but because my needs are fairly stable. Most of the problems being solved are problems I don't face. So much seems like disruption is for disruption's sake not out of any actual (community) need. Stable means old and old is bad and anyone who argues can be safely ignored.

    💬 2🔄 0⭐ 5
  • 💬 1🔄 0⭐ 0
  • Jun 30, 2026, 1:05 PM

    @dtl @simontatham I don't know how else to express it. My expectation for a Python project is that it will need to be rewritten every 2-3 years simply because the development infrastructure has disintegrated . The underlying source code might need only minor modifications but the tools for doing all the software engineering tasks needed to maintain and package the code will have completely changed making the project unmaintainable.

    💬 2🔄 2⭐ 1