Not because vim vs nano vs emacs etc. Just that plain text is not enough.

I want to be able to encode more of my memory and context to my notes with a minimum of fuss, and therefore want to embed images (gasp!), tables, hyperlinks, and even file or sound embeds in my documents.

Yes, open simple file formats are better than closed complex formats (and doing text vs binary formats has something to say for it as well).

No, I don't like that Onenote's .ONE file specification is super complex and therefore only semi-open.

But I'm not about to lock myself into a DEC dumb terminals 80x24 limitations where I have to learn some greybeard's key bindings for everything, all for the privilege of losing all my ability to embed multimedia combined with said gatekeepers tut-tutting me that I should just make a link in my terminal to the local image file, nevermind that you can't copy/paste an image into a bash terminal and have the file be saved to that directory (ok it probably exists but is some obscure something).

So I watch Xournal++ very closely, specifically [this issue](https://github.com/xournalpp/xournalpp/issues/937) because it will have the total package, multimedia embeds, ink support, text support, file embeds, all in one file that I can syncthing save to wherever else I like.

But until then? Onenote desktop, sorry but not that sorry.

I do this stuff with my notes in Emacs and it's really nice. Emacs is a graphical application and its notetaking facilities are really outstanding. It even supports syntax highlighted, executable, exportable code snippets, as well as all the basic text formatting, hyperlinks, tables of contents, tables, etc. It's a great tool for developers and sysadmins to use for notetaking.

If you know Emacs isn't for you, that's totally fine, but I wanted to throw this out there for bystanders that when someone suggests to build your notetaking workflow around a great text editor, the proposition is not at all to somehow confine oneself to an 1980s terminal.

Even custom hyperlinks and text notes that refer to chunks inside PDFs are easy to do.

I've had many well-intentioned but ultimately abortive attempts to get on board with Emacs.

So, are images 'possible' or 'trivial'? Not trolling, and I do note that you say it's not part of your workflow.

On the other hand: no, Emacs is not a WYSIWYG word processor. The need to support terminal as a display backend weights heavily on the pace of GUI improvements. That's because all interface elements need to be renderable on all backends (not strictly true, but the prejudice against GUI-only elements is significant). So if you hope to be able to easily and conveniently display something like this: https://klibert.pl/statics/vw-doc-view.png then Emacs is empathically not the best tool for the job.

so (out of the box) in org mode if you type [[./file/path/to.png]] it will turn into a link, if you hit Ctrl-c-x-v it will toggle between showing images as a link (which will open in a new emacs buffer) and just showing the images inline.

ALSO you can just drag an image file onto an emacs window and it will display it in a new buffer.

however getting it so that A) images are displayed automatically when you finish typing the [[path]] and/or B) dragging an image into emacs will result in a new link in orgmode... that's probably possible

This is the package you're looking for. Just drag and drop images into the org mode buffer and you're done. I've been using it for years to take lecture / book notes in org mode where I have to constantly take screenshots and embed them in my notes.

part A is still annoying though. if you have inline images toggled and type in a new image it still turns into a link instead of an inline image.

Thank you Richard

Why?

vim would not be what it is, without emacs to rage against.

Emacs is emacs because its extensible, between vim, neovim and vim9, im starting to think people might enjoy the extensibility seeing as that brings vim up to 3 scripting languages to write things in.

vim has become what it purported to hate

Yea, you will get a lot of Emacs and Emacs with Org mode answers here. To be fair they not wrong :) As a complete emacs newb, start with something like "doom emacs" ! It's brilliant for beginners.

>Emacs is a graphical application

Too few ppl know this.

Including me until now. I will examine this emacs of which you speak. No promises but I can at least attempt to run it.

Goodluck :)

Get used to the basic workflow for a little while and forgive the monospace-ness while you evaluate the workflow. I like taking notes in Gollum wikis, the wiki format used by GitLab and Github. The project management features enabled by default in Doom will kick in for that. Decide how you feel about those.

If you like the workflow, take a look at org-modern and take a few minutes to work out the proportions for variable pitch fonts. Then you can have Org text render in a nice, proportional font that you like and use monospace only for the embedded source code (including shell languages) blocks.

As an alternative to the using git repos to store notes collected into projects, take a look at Org Roam v2 for keeping a topic-based knowledgebase that you can work with without thinking much about the filesystem, and which offers mindmapping features.

That stuff works great for me, has required zero substantial elisp knowledge to get working, and has been natural for me to ease into. I hope you find a workflow you like!

Direct embedding binary data in the Org files would be cool for emailing Org files around, though. It looks like Org does support this kind of embedding on export, if you don't mind exporting to other formats when you send documents around.

For now, I've settled on GoodNotes because it's good enough at PDF Backup, OCR Search, and drawing. I have given solid tries to Evernote, ZoomNotes, Concepts, and Notion, and they each are amazingly better than GoodNotes in at least one major respect, sometimes multiple, but none of them are good enough on those zero-compromise requirements and GoodNotes is. FWIW.

EDIT: Oh, while I'm flamebaiting, I also use my ipad camera to take pictures of screens. Life is too short to schlep screenshots between computers, especially the ancient ones that run scientific equipment (lots of 68000, XP on some recent ones). Printer emulators and java applets can get bent. Runs everywhere, my ass. Moore's Law has given us gigahertz and megapixels, and if I can use them to eliminate painful asinine pointless busywork that's my god-given right and nobody is going to convince me otherwise. Sometimes I even use my ipad camera to take a screenshot of something on my PC and toss it into the mix. Sue me.

Paste on your iPad

Clipboards are synced through iCloud.

if i had to share a screenshot from my laptop/phone, it is a matter of taking the screenshot and "sharing" via kde connect. take all of 3-5 seconds and this workflow is now available to everyone

I swear I'm not shilling for Google Keep, but I've found myself using it more and more over the last couple of years; it hits a sweet spot between "limited enough that I don't get distracted" and "advanced enough that I can still express myself".

The biggest praise is its ubiquity. It's just there when I need it. Interesting article + my in-the-moment thoughts? Google Keep-ed. Want to add a reflection at the end of the day with a picture? Google Keep-ed. Need to remember an address in the car? Toss it in the Keep and open it on my phone.

  function qn ()
  {
    date_today=$(date +%F)
    year=$(date +%Y)
    month=$(date +%m)
    day=$(date +%d)
    FNAME="$NOTES_DIR/Work/journal/$date_today.md"
    #FNAME="$NOTES_DIR/Work/journal/$year/$date_today.md"
    echo "### $(date +%F' '%T)" >> $FNAME
    rlwrap cat >> $FNAME #
    echo -e "\n" >> $FNAME
  }

Thank you!

In the meantime, I'm using stylyslab write [0] which uses svgz and is a good replacement for OneNote and a compromise I'm willing to make to not be locked in but tbh the OneNote app is just so much better.

[0] http://styluslabs.com/

I keep having dreams of making a linuxnote for OneNote files since the file format is technically open specs, but as they are super complex and I've barely opened a hex editor before I just don't know what I'm doing enough to actually try parsing the bytes of an arbitrary file yet.

And exactly which one of them can't I do in asciidoc?

If it is more than step 1 cut, step 2 paste, the tool has too many steps for my workflow, which like other users have posted is mostly a braindump of knowledge or context around several tables, links, and images/screenshots, sometimes with digital ink if I'm on a device with an active stylus.

But for producing formal documents, I have checked out asciidoc before and have respect for its capabilities, I just don't consider it in the running for my particular workflow as I see it as a different tool.

I'm not after version control for my notes though I know many others like it.

Sowhat handles transactional data well, you could implement double-entry for example with relative ease. Other things include: links, events, quotes, tasks, formulas and a few organizational elements. I combine these elements in different ways depending on the problem.

[0] https://github.com/tatatap-com/sowhat

https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro...

But spreadsheets applications tend to be more useful than annoying. Doing tables with formulas in text docs are possible, but it seems more annoying than useful. In some instances I enjoy using jupyter notebooks.

Also sync is not that great for massive datasets: I tried to sync my 22k-ish Evernote notes to Apple Notes and it took days and I never got the same number of notes on all the different devices. If you are currently building your notes you will probably not encounter this issue, though.

I was considering obsidian, but the devs say that obsidian is designed for a maximum of 20k notes.

So, I'm already on the upper bound, as you are. Probably, obsidian would be slow if I import all my notes.

Evernote, on a Windows 10 Desktop, now works fast, at least for me. I think we undervalue this fact, we undervalue the fact that it is hard to make good note taking apps that can sync and search fast with more than 20k notes. I guess there are users with 60k notes!

They are currently still catching up to reach feature parity with the old native clients, but at least they are releasing more frequently --which means betting the house on Electron technology is paying off--.

I do not use Evernote any more (finally ended up with plain files in iCloud Drive and EagleFiler to top it off) but I am still following their releases as a paying customer.

I agree with you, though: Notes is really quite good. I'm not sure how Notes syncs, exactly, but for whatever reason it's not blocked by my employer.

https://wiki.c2.com/?CommonUserAccess

Is this comment auto-generated? What do you mean?

Maybe I'm just a weirdo. I love reading manuals and discovering interesting nuances in the things I use every day. Or picking some new software at random and learning about it just because it's fun and interesting.

Software is interesting and fun in different ways to different people; most people find tools accomplishing their goals with as little overhead as possible far more fun than reading technical docs. Not saying you’re wrong to like reading manuals, but it’s not a moral failure to have a cognitive profile, or heck, even a schedule that’s meaningfully hindered by your daily toolbox having reading prerequisites.

I don't get that allergy to reading. For a long time it has been accepted that you had to read a manual before using something relatively complex, as not everything can be expressed intuitively, and because intuition is not really universal.

Do you know how many pages of software documentation the average person will read in their entire life? Zero. Why? They don't have to, and imposing that requirement yields no benefit. I'm always astonished by the perennial hubris required to glibly assert chemical engineers or historians or teachers or physicists or lawyers or doctors or librarians or literature professors (or even other developers who want to concentrate on other tasks) only avoid software tools with prerequisite study because they're too lazy to read.

The purpose of software is to help people more easily solve their problems. The bigger the barrier to entry— prerequisite study for example— the harder it is for most people. That's acceptable if the complexity is genuinely necessary to afford or augment expert usability in purpose-built software, but it almost universally compensates for ham fisted interface design. Interfaces that stop expert users from doing things efficiently and only afford beginner workflows are also poorly designed. Expert vs dumbed down is a false dichotomy.

For many FOSS developers and users, tolerating counterintuitive interfaces turned into a badge of honor, and that turned into an aesthetic preference. It's not the default state of software, it does exclude non-technologists, and is why FOSS alternatives are still alternatives for every application not specifically designed to be used by technologists, even though they're free. Every single one. Every professional photographer on the planet who relies on Adobe Photoshop would jump for joy if Gimp even came close to being a sufficient replacement. That preference is also why developers don't generally make significant interface decisions in any professionally managed software project.

Not having a technologist's domain knowledge or priorities isn't a contemptible moral failure. Having it doesn't come with design expertise— learning design takes a lot of study and practice, but I'm guessing you have other things you'd prefer to concentrate on learning. Which is fine. Just realize that assuming documentation is sufficient to guide users through software is primarily informed by your not understanding software usability rather than everybody else misgauging the importance of software documentation.

Engelbart assumed people wanted an interface for "trained experts" -- the idea being computer applications were important enough for people to invest time in learning new concepts to make their work more efficient.

Larry Tessler and others argued you should present a beginner's interface based on existing metaphor. Larry eventually went on to work at PARC and Apple where his work inspired (and frustrated) generations of computer users.

Boarding noted that Tessler (and others in PARC) needed a raision d'etre inside the Xerox organization and partially used "building document handling systems for secretaries" to justify their budget. Kay was well known at the time for wanting to use computers in education, so it's no wonder the interface Jobs saw at PARC was one tweaked for beginners.

This isn’t to say I don’t enjoy learning apps anymore, I just have to guard my time more wisely.

Still, as front-end, I find myself mostly working through Windows VM's, on top of KVM. I pass through most of the hardware (usb controller, the main GPU), and get a native windows experience. Most work happens through Chrome, VS Code and Windows Termnal. I use PowerToys to get some kind of tiling window manager.

There are two reasons for this. One is that my workplace has security setups for Windows and Mac, but not linux. I can grant them full control over the VM I use for work, and can use the standard setup for vpn, etc, as well as ability to use all corporate resources with no pain or hacks.

The other is that a lot of things are more painless. Working across multiple monitors requires less setup, scaling 4k "just works", most hardware and front-end software I use behave as-well or better than on linux (particularly webcam + Teams, that I depend on heavily).

Also, as editor, I still use emacs for some things, when I just want to edit some file in a random directory.

But for development work, I've switched to VS code. The ability to ssh into any remote VM, container, etc, and be able to work directly on a remote server, complete with gitlens, debuggers, file browsers, shell access, etc, is a killer app for me. I also love the pane management, which provides the tiling window manager functionality I love from i3/Pop Shell. (Power Toys is ok, but not quite as efficient for me as i3.) Emacs CAN be set up to do those things, but that takes more effort, I feel, and still not the same user experience.

I was slightly disappointed by i3 and xmonad and built my own WM in lisp.

In the old days we used to write our own tools by extending and combining existing tools. Now people seem to just download python and use whatever library comes with it after a day or two of experimentation

This is especially true where there's a selection of tools that all work within a similar "market" space for X functionality - some are going to be less complex, some more intuitive for me personally, some fulfill a one-off need and their other functionality is duplicated by another system I know much better (and have put the time into learning).

That shouldn't take away from your enjoyment of reading through minutiae of various systems, but you can't reasonably expect a lot of people to match your enthusiasm for doing so.

It's entirely possible there's a community of people out there who don't mind reading about abstractions exported by tools. Especially if it means you'll save time in the long run.

The original post seemed to me to be a mild introduction to the concept that maybe you can get your job done more efficiently with extensible / combinable simple tools rather than waiting for someone to add a feature to Gnome.

It's totally fine if you don't want to do that. If the person in the cube next to you does that, how is this an insult to you?

Maybe you're not the audience for this article.

Your statement A:"The longer something has been around, the longer it will be around" is not the opposite of B:"the shorter something has been around, the shorter it will be around".

Rather they mean the same thing. 'longer' and 'shorter' here are just English language ways of referring to the same time t that an object has been around.

If someone tells you "the longer a distance is, the more time it takes to walk it", that is exactly the same as "the shorter a distance is, the less time it takes to walk it"; there's no logical leap there.

I could conceive a rule that says "archeological artefacts are likely to be around for a long time" and it'd be a mistake to conclude that this means that non-archelogical artefacts will only be around for a short time.

But that doesn't seem to be how the Lindy effect is formulated, either on Wikipedia or on your post, so there doesn't seem to be an error in applying it to new things.

   the more something has been continued to be around due to be continuously and repeatedly selected from a pool of similar other somethings, the longer it will likely continue to be so.

If there is no selection process, then the Lindy effect is either meaningless, or decomposes to an assertion that the current thing is the only way to do something.

Why can't we 'invert' it, just because it's statistical effect? Yes, in your formulation, some of the new things in the pool will go on to live a long time, while others will be selected out.

But so what? We are talking about the expected lifetime of an item in the pool, conditioned only on it's age. There's no fundamental problem making a statement that this expected lifetime is short for new things, even if some fraction of those new things will last a long time, right?

After all, we don't know any one individual item that's been around a long time will last a lot longer. We only know we expect it to. Because even long lived items have finite lifetime, hence they'll eventually die (and when they do it'll be really surprising, because they've been around so long; but it will happen eventually.)

And so the statement is always talking about expected lifetime, whether for items that have already lasted a long or short time.

(Hence I still don't think there's really any logical 'inversion' here.)

Everything that's new in the pool might be better than everything that's old.

All you can say about the old stuff is that it was better (by some metric(s)) than anything it had to compete with so far.

But you can't say anything about the new stuff. Sure, statistically it is likely that it will some blend of bad, middling and good, but you don't actually know the mix, or which term describes which items, until after the selection process (i.e. time) has taken place.

But I think you are outside the Lindy effect model at that point.

To put this in the example of the original post: The author says visual studio code is expected to last less time than VIM.

You could counter by saying: "hey, maybe, uh, the rise of Product Management as a discipline has meant that modern software overall will have longer lifetimes, and hence it's not fair to guess that VIM will outlive VSCode".

And that'd be a fine position. But imo the right way to frame that isn't "the author did an incorrect logical inversion of the Lindy effect model"; rather it would be "I don't think the Lindy effect model applies to this domain".

(No one is saying the Lindy model is universal.)

I guess you could say you want to apply it only within a given year of software; so, we're happy to look backwards and apply the Lindy model to software written in 2011, but we've no idea how to think about the lifespan of software written in 2022, and aren't allowed make any inferences from software written before 2022.

That's fine, but that's an additional constraint we've added, is outside the Lindy model, and, really, we're in "all models are wrong, some are useful" territory here, where I'd ask "is it really useful to throw away all that previous data? Wouldn't it be a better starting point to use the lifetimes of previous years as at least a prior?" And if you grant that, then I think theres no logical error here.

It "might", but the empirical observation behind the Lindy effect points that this is unlikely (if we take "better" to mean "more fit to live and grow old and still used").

Sure, we haven't seen the new things develop yet. But we have seen that most new things dont survice time: the things that survive are a small subset of each "new things" (say, vi and emacs, and not one of 100+ 70s programming editors).

https://en.wikipedia.org/wiki/Lindy%27s

Then if the software has been around for one year, the expected value of p is 50%. But if the software has been around for ten years, the expected value of p jumps to 0.5^(1/10) ≈ 93.3%.

In this way, if a piece of software has been around for longer, then it has a greater chance of sticking around. In fact, the expected number of years it has left is indeed equal to the number of years it has already been around, as stated in the article.

In practice this mechanism is more complicated, as all software is influenced by a changing environment, but this same idea is still at the core.

This reasoning is incorrect. You have to take the distribution of p into account.

In a world where almost every software has p=0.5 the software which has been around for 10 years is likely to have been lucky and not to have higher p.

that's comparing A->B with A->B. comparing A->B with B->A would yield "the less time a distance takes to walk, the shorter that distance must be"

Yes, that's the point. feral (your parent comment) has accurately observed that Etheryte (your grandparent comment) has mislabeled A->B as B->A. But feral is completely correct that "the more time something has already been around, the longer its future expected lifespan is" is exactly the same claim as "the less time something has already been around, the shorter its future expected lifespan is". Etheryte is making a pretty bizarre error; he seems to be under the impression that "a < b" is the opposite of "b > a".

To use your own example: You have to take a long time to walk a long distance. That doesn't mean you have to take a short time to walk a short distance.

You basically only know one thing about something, which is how long it has been around. The things that come to life and die that you observe will be, on average, in the middle of their life.

So if something has been around for five years, given no more information, your best bet is that it'll be around for another five years.

One year? Another one year.

Hopefully this explains well why the Lindy effect also says that something that's been around for a shorter period of time is more likely to disappear sooner.

You can see Notion come out, and go "wow, I find this good and I think it will keep being around and good for a while". Like the GP said, the fact that it is young doesn't mean it is doomed, or even that it is not good. The Lindy effect says nothing in that direction.

Sure, you can have a much richer model of the world than the Lindy model provides.

>fact that it is young doesn't mean it is doomed, or even that it is not good. The Lindy effect says nothing in that direction.

No; it says that young things are less likely to last than old things. If the average expectancy is small, sure it doesn't guarantee any one thing is doomed (some aren't) but it absolutely does tell you that most of them aren't going to last long.

Imagine a friend tells you that they know someone who is planning to become a professional rock star when they leave school.

They are probably not going to make it, because most people who try don't. You can't be sure, because some people do become rockstars. But it's not an error to be sceptical of their chances.

If you hear they are still gigging after 3 years, even if they haven't made it yet, you are probably a tiny bit less sceptical.

That all makes sense, right?

If you tell your rock star friend to go back to school, you are helping him minimize risk. The chances are that he won't make it, but that's not a consequence of the Lindy effect. It's because surviving in the rocking world is difficult as it requires that people pick your music repeatedly over other available bands, which is the requirement for the Lindy effect to apply, not its consequence.

More importantly, if you tell every rocker to stop and go back to school because their chances of succeeding are low, you end up with no rock bands. Because all rock bands have to start out being new.

Believing that most new rockers won't become big is fine. Believing that any rocker that is new won't make it is wrong, in fact you can be certain that some will.

We're not making absolute statements about either new or old things.

We're not saying any one new thing definitely won't last another 10 years, the same way we're not saying any one old thing will definitely last another 10 years.

The whole discussion is about what things are likely to do.

There's a place for formal logic in discussions of probabilistic models, but it can also confuse people.

> Believing that any rocker that is new won't make it is wrong, in fact you can be certain that some will.

If you were made to bet money repeatedly on whether a new rocker or an old rocker would still be a rocker in 5 years, you would end up with more money if you always picked the old rocker. This means that older rockers last relatively longer and new rockers last relatively shorter ("on average" / "by expectation" / "probabilistically"); that's literally the same statement.

That the underlying mechanism might be gradual removal doesn't change this, and doesn't matter.

I got the sense that the author is trying to say the latter, however what they literally said is more like the former: Visual Studio Code, specifically, is likely not to be around in 30 years. I can't argue with that.

Yes it is, in this context.

When you take into account more factors, then sure you can get a better prediction. But then it's not the Lindy effect anymore.

I'm talking about the Lindy effect only. Nothing else.

First sentence on the Wikipedia page:

> The Lindy effect (also known as Lindy's Law[1]) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age.

Proportional.

So if we assume that's implicit in my example, how does the Wikipedia page on the contrapositive help now? (It doesn't, as my argument isn't relying on any property of it.)

I would read up on the topic if I were you. Statistics can be unintuitive sometimes, and basing your argument on supposition can be unreliable. I'm not sure about the correct answer here, but most folks get e.g. the Monty Hall problem incorrect if they rely on their intuition.

For a product at T = 0, why would it be optimal to assume its lifespan would be T = 0 as well, rather than the average age of all products?

But this is a stupid-obvious problem. The Lindy effect is easy to write out in formalisms:

    age(x) > age(y) ⟶ life_expectancy(x) > life_expectancy(y)

    age(x) < age(y) ⟶ life_expectancy(x) < life_expectancy(y)

    age(y) < age(x) ⟶ life_expectancy(y) < life_expectancy(x)

No; not sure where you got that from.

>For a product at T = 0, why would it be optimal to assume its lifespan would be T = 0 as well, rather than the average age of all products?

I'm not saying it would be. (The original blog might, but that's irrelevant to my posts here.)

If you knew the average lifespan of all products, that would be your best estimate of the lifespan of a new product. (You can't use average age naively without thinking about right censoring.)

If the average lifespan of a product was short, then the average lifespan of a new product would be short. As the product aged, it's expected lifespan would increase.

I.e. the longer something has been around the longer it will be around, or, equivalently, the shorter it has been around the shorter it will be around (both obviously taking about expected times.) Make sense now?

The moment you negate A, both positive B and negative B, satisfy implication.

I.e. you can't claim shorter life implies shorter life remaining. For that to hold you need equivalency, not implication.

Here is an example. Rain implies streets are wet.

Does no rain implies streets are dry? No. There could be a flood or street cleaning, or a pipe burst.

The Lindy effect says that entities with longer realized lifespans have longer expected future lifespans.

In other words, if one thing has been around for 5 years, and another thing has been around for 3 years, then we know three things:

1: The first thing's expected future lifespan is f(5) years.

2: The second thing's expected future lifespan is f(3) years.

3: f(5) is greater than f(3).

Etheryte claims, in a gross error, that this does not imply that the expected future lifespan of shorter-lived things is shorter than that of longer-lived things. This is ridiculous; the claim Etheryte denies is a simple restatement of the Lindy effect. For our two objects of ages 5 and 3 years, the "new" claim would tell us the following three things:

1': The expected future lifespan of the first thing is f(5) years.

2': The expected future lifespan of the second thing is f(3) years.

3': f(3) is less than f(5).

But 1' is exactly the same claim as 1, 2' is exactly the same claim as 2, and 3' is exactly the same claim as 3. No claim has been negated, only repeated.

Because it doesn't hold invariant to time.

It's not hard to make a counterexample. E.g. when Windows 3.11 existed for several years and Microsoft published Windows 95.

If we were to travel back then and use Lindy effect we would get wrong predictions.

Because it's such a simple heuristic it only demonstrates one way effect.

Obviously? Look at the statement of the Lindy effect:

> The Lindy effect proposes, simplified, that the longer something has been around, the longer it will probably stay around still.

What do you think the word "probably" means?

It would, if the only thing that could make the streets wet is rain; ie if we were in a limited model where that was true.

We're talking in the context of a limited model in this thread. My point was that the statements are equivalent in this model.

Alternatively:

Imagine we were talking about the size of a pizza and how big a dinner it will lead to.

A blog says "wider diameter pizzas generally lead to bigger meals. Narrower diameter pizzas generally lead to smaller meals".

The first comment here says "just because wider pizzas implies bigger means doesn't mean narrower pizzas implies smaller meals, the blog has made a logical error!".

I reply "in the context of roughly round pizzas the two statements are the same".

You then give the example about the rain and streets. Hopefully it's clear that your general logical point isn't relevant to the pizza discussion, where there is a relationship between width and area.

Similarly, in the Lindy model, which we are actually discussing, there is a relationship between age and expected lifetime. That relationship is more complex than the pizza one, which confuses things, but hopefully the pizza example makes it clear why there isn't a general logical error here.

We are in a limited model. Many factors affect software lifespan.

It's a heuristic at best.

> The Lindy effect is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age.

This implies that things that have been around for a short period of time do in fact have a short expected lifespan. You're correct that "A implies B does not mean B implies A as well", but that assumption is not needed.

Also someone commented about COBOL. Of course no one thinks COBOL "is around", what also means statistics about usage. COBOL is declining and almost no one uses it anymore, so it is safe to say "it is almost not around".

https://www.bmc.com/blogs/cobol-trends/#:~:text=According%20....

The only way we stop using COBAL in production this century is to have some kind of apocalypse, or maybe an apotheosis.

[1]: https://en.wikipedia.org/wiki/Ultraviolet_catastrophe

Take any random thing and random time (with zero knowledge of actual lifespan), and on average, you are in the middle of it's lifespan. Therefore, if Thing-A has existed for 28 years, it is likely to last for another 28, if Thing-B has existed for 6 years, it's likely to exist for another 6, and so on.

It may be somewhat informative for comparisons but not in real life.

You are hiking away from a disaster with all your possessions and life's savings in your backpack, and are now at a muddy riverbank needing to cross. You ask me how deep the river is and I tell you the average depth is 6 inches. That sounds great, but I have most definitely NOT told you that you'll be able to get across without finding a deep spot and having to drop your backpack to survive.

Using this effect to make judgements about product lifetime is similarly uninformative. It is a hint leading to only a possible inference, not data leading to a valid prediction.

1. Not sufficiently useful relative to involved costs for most applications(data formats, configuration maintenance, etc.)

2. Disrupted by something that is "10x better" for the purpose(e.g. using a spreadsheet instead of a text editor for 2D, cell-oriented data)

3. Outside forces invading the ecosystem and obsoleting dependencies(new OS, hardware, etc.)

So what the Lindy effect describes in long-lived software is just the software that is relatively cheap to keep around, is hard to greatly surpass and resists invasion - which describes a lot of "worse-is-better" software, where the UX kinda sucks, and it's actually a bit too unstructured for any particular application, but not enough of these things that anyone cares to address it in the relevant professional scenarios where it comes up: instead the user just girds themselves to fight it into submission because they can spend six hours fighting it and one week debugging it or two weeks making a Right Thing that is much less compatible.

The basis for this kind of reasoning is essentially that, if you can assume that you are an 'average user' (and you don't have reason to believe you're especially late or early), the chance that your prediction about the longevity of the project is correct is most likely to be true if you 1/3 - 3x[1] the lifespan of the project currently.

That is because if say, you predicted VsCode existed a hundred times longer than it currently did, that prediction is only true if you are indeed among the first 1%. 99% of VsCode users making that prediction will be wrong.

[1]https://cdn.vox-cdn.com/thumbor/2VfpAbtj-yOq5gHhYIdgrAIdBuw=...

The Lindy effect is named after a restaurant, Lindy's, which ironically closed recently. If we were to take it as invertible, we would have to conclude that a brand-new restaurant, which opened an hour ago, is most likely to shut down one hour from now.

This is an obvious absurdity: if we wish to speculate on the longevity of new things, we can't use the Lindy effect to do so. It's a good heuristic for betting that something will continue, it's a bad heuristic for betting something won't.

https://en.wikipedia.org/wiki/Lindy_effect#cite_note-6

https://www.gwern.net/docs/statistics/1964-goldman.pdf

Yeah but in an hour it most likely shut down in two hours /s

I really don't get the whole argument over this definition, to me it sounds like a funny observation more than a law of the Universe.

It's not useful if you're trying to decide whether Bob's Education Mill will last longer than the state-funded community college opened in the same year, there are plenty of other heuristics which we might use there, but not this one.

That includes the expectation that something young will be (on average) half way through its lifespan.

It works based upon the 100% certainty that whatever you are, at some point you will cease to be.

On average, regardless of what you are, you are in the middle of your life or existence (some very high variance here).

In order to generalise it to non-certain events, such as a program crash, you'd need to remove the certainty assumption and rejig the consequent statistics - it might be doable, but you wouldn't end up with something quite so clean and simple.

Is it more of a process thing (having to change unit tests, code review, hire new people, etc) that prevents this? Or is it just too risky given the important roles of the mainframes?

Such a change would be transparent to the end user.. Except for gotchas like not all users have the source code for all of their dependencies. What happens if you want to update your program and you have a dependency on a binary from some vendor who went defunct 35 years ago? You're stuck compiling against whatever artifacts you have so does transpiling to C still work?

And note that the Lindy effect is about the expected value (mean). The statement "probably run another T hours without incident" could be interpreted as relating to the median, which is actually a little less than the mean. So the statement should either be "the expected value of the number of hours until the system stops is T", or "the probability of the system running for at least another T hours is a little less than 50%".

[1] Calculation: Lindy proportion 1 corresponds to a Pareto distribution with probability distribution function `a / x^(a+1)` where a = 2 and the range of x is [1, ∞). The cumulative distribution function is `1 - 1/x^a`. So the probability of the remaining lifetime being less than or equal to the observed lifetime is CDF(2) = 0.75.

I don't believe that, btw, just guessing at the mindset of the author.

Visual Studio Code is based on a much older line (visual studio) which dates back to 1997.

It's not nearly so new as it may seem, although I certainly appreciate the refresh from the older, more feature-filled (and feature slowed) visual studio proper.

Not to mention - most of the "new stuff" in visual studio code is really just a nice UI layer that's built using mature and incredibly battle tested tooling - HTML/CSS/JS.

It comes from the same parent company, with a lot of interest in solving many of the same challenges. The UI paradigms are obviously related, and if you've ever done any real VS project debugging, you'll find the structure of those configuration files very (very) similar to how tasks work in VSCode.

I don't believe the VSCode codebase ever actually pulled anything from the original visual studio, but the roots of the application clearly come from the same place.

Some people, a few for now, are migrating from VS proper to VS Code, including for languages like C++/C#. I am one of them.

I appreciate what VSCode is achieving, though, I can run on my Linux host and remote into my microcontroller bare-bones OS for debugging and everything works nicely together but it ain't no Visual Studio.

Should have called it something like "Technical Notepad."

I think the error is interpreting these things literally. If we did, then if it were 1990 we'd say Windows wouldn't be see the next century. Probabilities are attached.

By the author’s logic, COBOL programs still in use today will long outlive Linux. That could even be true.

There are 10 things that have been around for 10 years.

I think it’s safe to say that there is less chance of any individual thing that’s 1 year old being around in 1 year than the things that have already survived for 10.

I think there is a linguistic ambiguity here. What is meant by "the longer something has been around"? Longer with respect to what?

If you mean to say if A has been around longer than B, then A will stay around longer than B (in expectation), then this law is commutative with respect to A and B and what you specify as "opposite" holds.

If you mean to say if something has been around for t then it will stay around for some f(t) where f is an increasing function, then again what you specify as "opposite" holds.

I think you wanted to write A implies B does not mean "not A" implies "not B" as well. B implies A would be: the longer something will probably stay around, the longer it already has been around.

I get the impression from these people that they are constantly typing things. In fact, they're typing so much that they can't possibly waste valuable seconds using a mouse. I must be misunderstanding what they mean because that just can't be right.

And what's with the "you can achieve the same thing faster, without breaking your concentration" in regard to using a spell-checker or a calculator or whatever. Are you being serious? I can achieve the same thing faster? I mean how long do you think it takes to check the spelling of a word? Even if I must look it up in a physical dictionary, how long are we talking here?

Guys, seriously, slow down. You're going to burn out. I don't want to judge because I don't know you. Maybe you're a rockstar, but I'd guess that if you're really going this fast, the quality of your code is suffering.

Yes, you are misunderstanding. First, it's not only about typing but it's generally about doing whatever you are trying to do without unnecessary delays, including navigation between functions, files, windows, etc. Second, it's not just about saving seconds here and there: the end goal is to stay in the flow state, avoiding unnecessary interruptions and context switches. Every time you reach for the mouse and move the cursor or scroll a document you stop thinking at the problem at hand because you're focusing on the motion, and when you're done with the mouse you waste mental energy resuming your previous train of thought, maybe even forgetting something.

> Even if I must look it up in a physical dictionary, how long are we talking here?

This is actually a good example because it seriously disrupts your thinking by forcing you to pause for some seconds and completely focus on something else. I am sure proof-reading a long document in this way is much more mentally exhausting (and slower, but again speed is not the point).

Using a mouse does not distract me at all. I don't think about it, consciously, any more than I think about the motions my fingers make as I operate the keyboard. I'm not thinking about the tools, I'm thinking about what I'm doing through the tools; my hands move automatically.

I suppose it is like learning a musical instrument. At first you have to learn how to operate the instrument, practicing the motions to build up muscle memory. Then you start learning to play notes through the instrument. Eventually you stop thinking about the instrument, or the notes, because all that has become habit, and you just think about the music you are making; the instrument feels like an extension of your body.

If you have had a long-standing preference to use only the keyboard, and not the mouse, perhaps the mouse feels distracting for you because it is not part of the instrument you have learned to play. Of course this could be a self-perpetuating tendency.

... because I have well over 200 of own keybindings in my spacemacs dotfile already and quite a few of them don't do what I need in some particular situation or some underlying package got broken or, or, or...

> you're focusing on the motion, and when you're done with the mouse you waste mental energy resuming your previous train of thought, maybe even forgetting something.

That's because it's already half past 3 p.m and except having two or three coffees, I haven't eaten anything yet.

Besides, I highly doubt if I don't get any Nobel- or Turing-Award it's because I don't keep my fingers on the home row.

I can’t speak for others, but I keep my hands on the keyboard a lot of the time because I’m reading. As a (neo)vim geek, the key is to be really good at moving through the code. Being able to jump from where you are to where you want to be in a file far away without stopping allows you to read the code in a more linear way than it’s written.

It's also less cognitive load when the keyboard shortcuts are internalized. This may be worth it for operations you do a lot.

> Even if I must look it up in a physical dictionary, how long are we talking here?

This, however, takes an infinite time.

I have had a few co-workers who seemed to spend a great deal of time typing, but I have not generally been impressed with the quality of their work. In fact, the most incompetent developer I have ever met, an enthusiastic proponent of his favorite editor and its automation features, was also the most prolific, routinely churning out hundreds or even thousands of lines of awful, bloated, bug-ridden code a day.

The field of software development is large and varied, so of course it is possible that there are competent people doing solid work which really does involve a tremendous amount of fiddly editing, thereby justifying the otherwise inexplicable degree of attention given to sophisticated editors; but I cannot imagine what their working lives are like, and I hope I never have to find out.

That said, I don't optimize heavily against this the way some folks do. I use emacs and org-mode and GNOME (well, whatever the System76 folks are calling their reskinned GNOME desktop :)) which I think provide a nice balance. Emacs lets me switch between files with a couple keystrokes rather than having to dig through 10 tabs, and GNOME I think encourages an alt-tab based workflow. I still use the mouse for most other things though.

It really drove me crazy when I went from being a linux partisan for being responsible for quite a few different Windows machines and on a given day I could be working with anything from Win 98 to Win ME to Win NT to various editions of Win 2000 and XP and if you had to find something in the UI it would be slightly different in all of those which was a cognitive load. Contrast to to Linux where I did it all on the command line and it stayed the same in that time frame.

Compare that with the start menu. I type something, and the chosen program changes every time. I type notepad++, it shows the correct program until I type the d, then decides I really want to open edge and search notepad++ on bing. Or it launches an uninstaller instead of the actual program.

Now one of these days ms is going to optimize the win+r experience, so have fun while it lasts.

The trick is to rely on decades of acquired arcane knowledge about .exe filenames. What a great UI!

I hate windows as much as the next person, but to be fair that's kind of how command-line life works on Linux too isn't it?

So what lighting hue was best? Irrelevant, the important thing was that workers perceived that management was paying attention to their wellbeing.

I think something similar is happening in Windows (and Mac!) desktops, where they change small things "for productivity", and the majority of people will think it's an improvement, just because it's different.

Bt a small subset of us opinionated people will be upset that our carefully tuned habits are disrupted.

I feel like I've never talked to a person, techie or not, who didn't agree it was incredibly annoying to have UIs that they're used to change out under their feet.

In IT parlance, I guess lighting hues would be equivalent to the changing the window manager theme for a lighter/darker one ?

I'd say something like the "ribbon toolbar" upgrade of MS Office, which I think improved accessibility of functions, is one of the only examples I can think of. But then I'm not sure if that was just a case of getting used to the new layout.

Windows "Settings" versus the Control Panel is a counter example. It was a downgrade, it still sucks now, years later, but the Control Panel could be argued as 'dated' by some definitions.

I don't think it improves accessibility when I keep having to go hunting in different sections for the right button. (The ribbon in the Recycle Bin makes no sense to me either.)

I'll admit it can be daunting for a new user to see a lot of buttons, but if there is a tooltip or even a tutorial for each button showing where it can be useful, that shouldn't be much of a problem.

For me, the Ribbon is what made Office unusable. I've used MS apps since the MS-DOS and Xenix days. I remember the old MS menus (2 lines, bottom of screen, summoned with Esc) to CUA transition, then the horror of WinWord 1, then the passable WinWord 2, then the actually quite nice WinWord 6.

I still run Word 97 on Ubuntu under WINE. Works perfectly.

But after Office 2007, it is totally unusable for me.

I did say "But then I'm not sure if that was just a case of getting used to the new layout" - still open to that being the case.

Maybe it's like 12th edition text books, change for the sake of change. In the case of Office software, we need people to keep needing the 'basic' and 'intermediate' training sessions; we need credentials to justifiably decay with time?

> So what lighting hue was best? Irrelevant, the important thing was that workers perceived that management was paying attention to their wellbeing.

I doubt it would work if they changed the place of tools, the layout of the factory, stuff like that.

Many of the possibly meaningless desktop changes are also meaningless in the sense that they won't affect any workflow, and are therefore benign.

Sadly Microsoft is kinda forced to follow the trends, everything moves in all direction (web, phones).

Former Microsoftie here. While they are following trends, the actual impetus behind all the little changes you see all the time is that managers and ICs are incentivized to make "impactful" changes if they want good performance reviews. UI changes are a pretty easy way to have "impact". You can say something in your review like, "and X million users used the new taskbar that's in the middle of the screen".

When organizations are small, you have the resources to evaluate performance on a case by case basis because everyone works with everyone else to some degree. When organizations grow and you have layers of bureaucracy, inevitably some asshole middle manager gives someone a bad review for a bullshit reason (jealousy, racism, dislike, etc).

That's when HR swoops in and starts making processes and standards for everything to shield the company from lawsuits. Crucially, these processes and standards don't necessarily prevent the problem, but just let the company's lawyers argue that they tried to prevent the problem.

Now that you have processes and standards for everything, employees start gaming the system. The goal is no longer "do the thing that makes the company succeed". The company is so big that relatively few individuals have the power to swing the company's fortunes one way or the other. Instead, the goal is now "maximize my career growth".

Then you end up in the nonsense FAANGM situation where individual little teams are putting out crap and making decisions that make the company look dumb. Things that would be easy to ignore if a significant fraction of teams weren't doing it. All because they're doing things that maximize their "impact".

This is hard to correct because you don't want to be too harsh with your teams and hurt morale, and it's not like it's every team. So you try to be flexible, be tolerant of missteps as long as people show improvement, because if you just fired everybody who made boneheaded decisions in the name of "impact", the hit to moral would cause terrible attrition problems. And worse, some of them would sue the company, which was the problem you were trying to avoid in the first place.

s/company/university/g as needed.

It's one of those classic situations where every individual step in the process does at least kind of make sense, but the end result is bonkers.

Linux (and FLOSS in general) gives you the choice to have it the way you want it.

The only thing really changing right now is Wayland and the switch from window manager to compositors and the related support software. There are getting to be a decent amount of options in that regard with a good crop of lightweight compositors and tools starting to mature.

Xorg has worked for decades, a multitude of window managers and desktop environments have been perfectly usable for decades, and a couple of million people (going by Steam HW survey results) seem to be able to run games via proton perfectly fine.

Doesn't mean you have to think it's perfect, doesn't mean you have to use it for everything, but 'can't use any GUI app on linux' is definitely a you problem.

They attempted to make the new Settings panel the 'HQ' for everything, but in the process really buried some things (for technical people) under numerous additional clicks/sub-menus, if it's even there at all anymore. I think they've been addressing the concerns with new updates, but I still find myself floundering sometimes.

- After waking my computer from sleep, my last active window is not active any more. In fact, no window is active. I have to hit alt+tab to grab focus of the window again, or click the window (this probably wasn't caught because most people use their mouse for everything)

- There's new animations for the basic native Windows menus, including the Win+X menu I use for sleeping my computer, shutting down, etc. When you navigate to a sub-menu with the arrow keys, you have to wait for the animation of the sub-menu sliding out before you can interact with it. I've had to slow down my muscle memory to sleep my computer because otherwise I'll hit random other menu items cause the child menu didn't slide out fast enough to keep up with my inputs.

- I usually snap windows around with the Win+arrow keys shortcuts, but they added a new snap layout where sometimes when I do Win+up it brings the window to the top half of the screen. But that's also how you maximize a window, so I don't know how it decides which one it will do. In my experience it seems to be related to your key input speed.

- Sometimes I'll crop and resize images in Paint. They redid a bunch of the UI in Windows 11, and now when I use the resize menu, I can't hit enter to confirm the size I input. Again, seemingly this UI was only tested by people who use the mouse for everything.

https://docs.microsoft.com/en-us/windows/powertoys/run and check the search commands / hotkeys

My start menu / win-r days / open a shell to execute some commands are pretty much all over now and I just use PowerToy Run

Even after using W11 for a few months ("I will get used to it"), I still noticed everyday how I felt less productive and annoyed having to hover over the icon and try to find the correct window, vs just having them all laid out in the taskbar.

I’ve been running SwayWM for multiple years and it’s been great. There’s not anything I’m aware of that I can’t do in wlroots compositors; I even have Zoom screenshare working on my work computer under SwayWM. Most stuff, like WebRTC, doesn’t even require manual tweaks; just need the right packages installed. And you get the typical Wayland benefits, like great support for heterogeneous DPI, reduced jank, and potentially better robustness. (Depends on compositor for now; but there is a path towards compositor crash recovery, which should make things far better.)

A comparable Wayland compositor to Xmonad will likely rise as a good successor in the future.

Efficient remote desktop. Won't happen, ever. Simply cannot happen.

Blits from offscreen to onscreen surfaces bypass the compositor, so it can't implement them as RDP commands and instead has to push the whole image across the pipe every time.

This is why xorgxrdp is so crazy fast and responsive compared to every single Wayland RDP server.

I use sway (a Wayland compositor) on all my machines. But all of my headless machines run xorgxrdp because there is nothing in the Wayland world that is even close. This is a fundamental problem with Wayland that cannot be fixed until there is a perspective change on the Wayland committees. Sending surface-to-surface-copy commands through the compositor clashes with their worldview, but without it we will never have decent remote display -- even (as they say) as "the task of a higher-layer protocol".

That said, the best way to go in the future is probably going to be something more like waypipe.

edit: People seem skeptical, but…

GTK4: https://discourse.gnome.org/t/gtk4-efficiency-and-performanc...

Qt 5: https://forum.qt.io/topic/67371/x11-forwarding-slow-on-qt-5-...

Electron/Chromium: https://github.com/microsoft/vscode/issues/5243

Even my terminal emulator of choice; only fallback is software rendering.

Hope you can stomach video codecs, because that’s where we’re headed unless you stop updating your software.

Yes, I've been hearing that for 14 years now about several workflows Wayland broke (remote clients, etc.) and it keeps not happening.