What kind of programming work are you doing?
I’ve thought about situations like yours and what I would do if I were in that situation someday. For me, the plan is to try doing as much in the console as possible, which means Vim/Neovim for development and Tmux for window management.
Google pays the Linux Foundation a LOT of money.
Can we push back the deadline for the apocalypse? Have we talked to the customer to see if this is a possibility?
Search engines are websites that people used to go to in order to get helpful information. These days, they just spam out a bunch of SEO garbage, AI-generated bullshit, and ads.
Google, probably
Yes, a lot of developers have done this. Many examples have been posted on this thread (OsmAnd, Conversations, Davx5) - Mindustry is another example. free on f-droid (and Google store too I think), but $10 on Steam.
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.
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.
I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.
By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.
That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.
From my reading, it sounded like there was some controversy around whether it was ready to be merged it not. It sounded like some people felt that it wasn’t ready, but Linus decided to overrule them and merge it, saying it was ready enough and that merging it would help them improve it more rapidly.
Don’t worry everyone, I’m here to help:
Garbage
Outlook
Hot Garbage
Outlook (new)
Shit-tier garbage
Glad to be of service! Until next time…
Git’s internals are very easy to understand and once you know more about them, you’ll have a much better idea of how it works (especially when it comes to tags and branches). They’re so simple, you could even easily write your own scripts to parse git’s internal data directory if you wanted to.
I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#
there has to have been a significant global productivity cost due to the lack of a better UI.
I’m not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.
Xournal - a great way to draw on pdfs
There is no way to make a network request faster than a function call.
Apologies in advance if this it too pedantic, but this isn’t necessarily true. If you’re talking about an operation call that takes ~seconds to run, then the network overhead is negligible. And if you need specialized hardware for it, then it definitely could be delegate it out to a separate machine over the network. Examples could include requiring a GPU, more RAM, or even a faster CPU if your main application is running on more power-efficient CPUs.
I’m not saying that this is true in every case - they are definitely niche cases. But I definitely wouldn’t say that network requests are never faster than local function calls.
Same here. Sure, KDE and Gnome may have great Wayland support by now, but what about other DEs? The situation in XFCE seems to be pretty grim:
It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).
MATE seems to have piecemeal support. No idea what the status of LXDE/LXQT are. And there are plenty of other window managers that don’t have the manpower to support wayland either.
The deprecation of X is going to leave a lot of dead software in its wake.
Guess we’ll just have to deprecate the entire Windows OS then…
I’ve never had the chance to use a functional language in my work, but I have tried to use principles like these.
Once I had a particularly badly written Python codebase. It had all kinds of duplicated logic and data all over the place. I was asked to add an algorithm to it. So I just found the point where my algorithm had to go, figured out what input data I needed and what output data I had to return, and then wrote all the algorithm’s logic in one clean, side effect-free module. All the complicated processing and logic was performed internally without side effects, and it did not have to interact at all with the larger codebase as a whole. It made understanding what I had to do much easier and relieved the burden of having to know what was going on outside.
These are the things functional languages teach you to do: to define boundaries, and do sane things inside those boundaries. Everything else that’s going on outside is someone else’s problem.
I’m not saying that functional programming is the only way you can learn something like this, but what made it click for me is understanding how Haskell provides the IO monad, but recommends that you keep that functionality at as high of a level as possible while keeping the lower level internals pure and functional.