CallMeAl (like Alan)

Hell yeah! I’m typing this on a 2013 i7 Macbook air running LMDE 13 and it runs like a dream.

More like proton makes windows binaries not dependent on windows.

LTT is not sincere.

It’s the Pro Wrestling of tech. It’s Tech Entertainment. The focus is drama instead of technical accuracy or knowledge sharing. He “lost the match” because he never intended to win.

What did you like most about it?

If you are concerned about the new California law it is important to point out that the California law only applies to Operating Systems vendors and providers. It does not apply to end users.

For example, if you obtain a copy of a Canadian linux distro and install and use it on your computer in California, you aren’t breaking any law.

As far as I know you can change the audio output per app but not per monitor.

If the file is already selected you can do this from the keyboard:
SHIFT+F10 -> h -> ARROW KEYS (to highlight Firefox) -> ENTER

yeah, I’m not saying its fake but it does read just like a linux-horror creepypasta

There’s a old school tool call sar which can help you figure out what is causing the performance issues. Found a recent guide: Mastering sar in Linux: A Comprehensive Guide

If your system uses systemd you can set resource limits like cpu per process or user.

I agree with the idea of debloating and hardening your systems.

It helps to have some context as the approach I would take depends on what kind of system I’m running. I think its also good to identify your priorities to hone your approach.

When I want stability, fast security updates, minimal install size, I usually use Alpine which indeed uses the lighter busybox bin/sh instead of bash.

When it comes to my workstation shell I’m more focused on utility than size. So bash or zsh or fish, or whatever you find the most useful, makes sense to use.

Yes, 100 projects from the Fat Head would make sense.

Do you have any way to establish that these 100 more often come from the Long Tail?

If an app includes 50 well-known big projects and 1000 small projects, the sum result can still be that small projects make up for a large fraction of the code.

I understand your point that this is possible. It is an assumption to assume it is most likely the case however.

I would expect the Fat Head of most used open source projects to make up the vast majority of the open source code included in apps. It is not a common practice to include 1000 small projects into a code base for an app, or even 100.

Is it not reasonable then to expect that the 77% of app code from open source is because the most popular app building blocks are open source? Aren’t the popular open source languages, frameworks, and databases are themselves big enough to exceed the number lines of internally written code for the app business logic most of the time?

For example, if I make a “small” electron app its going to be 90% or more open source because the electron base is so large already.

The insight that a majority of open source projects are small contributions by hobby developers, and that it is their summed joint effort what matters, is very interesting.

The vast majority of open source projects are by hobby developers but how much of those projects make up the 77% of the open source included in apps mentioned in the study?

The author assumes an even distribution but I challenge that.

The most popular (Top listed by Github, Gitlab, etc) open source languages (python, typescript, etc), frameworks (rails, flutter, react, etc), and databases (postgres, mongo, redis etc) are all either directly corporately funded (Google, Microsoft, Meta, etc) and/or have robust foundations and sustainability plans.

I would expect these to make up the vast majority of the open source code in modern apps.

we had it back in the day https://en.wikipedia.org/wiki/ZipSlack