![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that’s going to make their code so much cleanser and more manageable, I don’t blame them for thinking it’s all bullshit. It was last time.
I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that’s going to make their code so much cleanser and more manageable, I don’t blame them for thinking it’s all bullshit. It was last time.
I finally watched the talk today and that wasn’t what I thought he meant. What I thought he was getting at was that the rust parts of the kernel interact with lots of other modules written by people who don’t know rust. When those C modules change their semantics in ways that break the rust code, they can’t go fix it because they don’t know rust. In fact, whenever they make a change, they don’t even know if they broke some rust module, because they don’t understand the rust code well enough. And this is something that everyone is going to have to live with for the foreseeable future, because you can’t force all those other kernel hackers to learn rust.
I haven’t seen that paper before. The ones I remember were blogposts or web pages. In fact, this may be what I was remembering: https://www.gnu.org/software/hurd/faq.html Particularly the part about what happened with the port to different microkernels.
IIRC NeXT and OSX use Mach, but they don’t use it as intended. I think they’re mostly a BSD kernel with Mach functioning as an interface to userspace.
Hurd actually used Mach as a microkernel, and moved most functionality to userspace daemons. This meant that Mach’s performance issues, at least the ones related to IPC, affected the Hurd a lot more than OSX or NeXT.
And yeah, I think developer interest was the biggest thing that held it back.
Both, I think.
It’s built in top of Mach, which has some architectural issues that aren’t fixable without a huge amount of work.
And no one’s interested in doing that work because we already have Linux and Linux is fine.
There have been a couple of pretty good post mortems over the years. I think one of them is on gnu.org somewhere.
Ive been using it for several years. I hardly think about it at all, which is pretty high praise.
You can charge for FOSS, but you can’t prevent the first person who buys your software from sharing it with everyone else for free.
Sometimes I’ll start up ConnectBot, which is an android ssh client, on my meta quest. Then I connect to my laptop and attach to a running tmux session so I can use the laptop keyboard but see the text in a virtual window.
My actual laptop setup is pretty boring though
There’s a built in snippet system too, called skeletons, but most people seem to prefer the yasnippet interface.
I would like Debian and the fsf to come to some kind of agreement so Debian can ship the emacs documentation.
There are companies working on providing that experience for Linux. System76 is one. You can buy a laptop with their is pre installed. Everything works, including suspend. If something breaks, you call the support number or email and they either talk you through fixing it or sending it in for repair or replacement. It’s not that different from having a Dell or HP.
Some GPL projects do it. If you find someone infringing, it’s easier to sue them if you have one copywrite holder instead of 100.
Soon we’ll be able to emacs the way the developers intended.
I’m pretty sure I was set up for substitutes, but this was a while ago.
I did end up replacing my router a few months after that, so it may have just been that my connection was very slow.
Also, every time I tried it and it didn’t work, I had to do a full Pop Os install in order for myguix install media to start working again, which added a few minutes to the process.
I was thinking something to do with nonvolitile memory.
The real problem was that the guided install - guix pull - system reconfigure - reboot process took about three to four hours each time, so I gave up after a few iterations.
I did try playing around with bios settings a little, but I’m sure I missed some possibilities.
I thought that, but I had identical results using the stock install media and the modified nonguix one from systemcrafters.
The weird thing was that the initial install went fine, even after the first reboot. The problem was the next boot after my first system reconfigure.
Not only could I not boot my system after that, but I couldn’t boot the install media either. The only thing that would work was the installer for the most recent pop os.
I tried and failed to install it on my laptop last year. Couldn’t figure out the problem and went back to pop. I’m messing around with it in a vm, though, and liking it a lot. I may try again when I have some more time to troubleshoot.
What about Redox?
This is why I have a windows box. I’m hoping when they finally release SteamOS 3 for PC it will have stable SteamVR support.
The way nix deals with packages is very different from most distros. If you install a newer version of a package, the older version just gets hidden, not removed. This makes it very easy to rollback or recover from errors, but it does mean you tend to use more space.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.