The “just add reddit” or “just add site:reddit.com” has been trash for a while
Has that ever been true? I always assumed it was some sort of shadow marketing campaign to get people to look at reddit more. Pretending that one website is the only reliable source of answers on the internet is incredibly audacious, it always seemed very farfetched to suggest that
I'm not sure what you mean when suggesting Linux is a singular implementation around which features are exclusively designed. There's all kinds of software that runs on all kinds of different OSes. Userspace applications, for example, can take advantage of POSIX compatibility to ensure that they run on all platforms (Linux, BSDs, even Windows).
Does systemd have any similar sort of compatibility guarantee? Can I run systemd-whateverd on BSD? Can I run systemd itself on BSD? I'm pretty sure most other init systems support at least one other OS if not more. Would the maintainers even support merging patches that do this? What about musl?
I am also a Void user, but will agree that the installation process can be very difficult, especially if you want to set up encryption in ways the standard installer does not support. You have to install it into a chroot (which I believe is how Debian was installed 20+ years ago).
That said, it is a great learning process and really helps you appreciate how awesome xbps is as a package manager!
I believe you're thinking of Gentoo. But it seems that you can get precompiled kernels in Gentoo these days.
+1. systemd is something the Linux ecosystem really needs, but its execution is abysmal. We should be designing around standards so the best product can win. We should not be designing around singular implementations that could make it easy for Red Hat to execute a EEE strategy to consolidate Linux on the workstation.
I can't wait till a crowdstrike-like flaw is exposed in systemd so we can all see how terrible^W wonderful monocultures can be.
I dunno. I’m a believer that there is real benefit to diverse teams and there is some evidence in support of this.
You're 100% right! But good luck convincing the bean counters.
The full write-up can be found here and should be fairly readable for users of this forum.
Some quotes that I thought were interesting:
With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc's addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.
So 64-bit systems seem to be a bit more resistant to this it seems? But I can't be completely sure given how much I've read about this yet.
This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.
It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).
And OpenBSD wins again it seems.
Do you know how vim has distributions like lunarvim, lazvim, nvchad, etc.? Simply installing something like lazyvim can quickly and easily convert vim from a text editor to a full blown IDE.
I think Gnome needs something like this. A curated set of plugins that are easy to install and maintain compatibility with different versions of Gnome - something that would deal with the API churn in Gnome while maintaining a stable, usable desktop environment.
I don't know if this is feasible, because I haven't used Gnome since 2.x, but I think it would really help make it an actual full blown DE.
I doubt that you're interested in arguing in good faith, but if by some miracle you do care about having an informed opinion before opening your mouth, how would you respond to things like this?
This essentially killed my (EU-based) startup in the project management and collaborate space. Before MSFT bundled Teams with O365 we were rapidly growing and closing enterprise customers in the automotive, energy and education industries with high retention rates. Right around the time the Teams bundling started our retention dropped, churn went through the roof, growth slowed down, we failed to raise our next round because of it and had to drastically downsize the company, causing even more churn (about 80% net churn in 2 years). This move by the EU is good, but too little too late - 99% of the companies that were hurt by this have already shut down, and the ones still running will take years to recover...
Just in case this comment didn't make it explicitly clear, you can just invoke the python binary inside your venv directly and it will automatically locate all the libraries that are installed in your virtual environment.
To show how this works, you can look at the sys.path variable to see which paths python will search for modules when you run import statements. Try running python3 -c 'import sys; print(sys.path)' using your system python, and you will only see system python library paths. Then, try running it again after replacing python3 with the full path to the python3 binary in your venv, and you will see an additional entry in the output with the lib directory in your venv, which shows that python will also look there for modules when an import statement is executed.
One for every current ~0.5% market share!