• 8 Posts
  • 27 Comments
Joined 1 year ago
cake
Cake day: September 1st, 2023

help-circle



  • It’s about memory management.

    In programming terms: allocated memory has to have the data in it that you expect in order for your program to work. The unsafe languages do it by manually ensuring it’s good and doing so mostly at runtime, or just assume the data is valid and write code that looks valid and have somebody check it before the program runs, or do a mix thereof. In all cases, it require a lot of human intervention and because humans are fallible with different skill levels, this fail quite often.

    Safe languages are either built on top of unsafe languages that are battle tested and do lots of runtime checks behind the scenes (interpreted languages like python, ruby, javascript, etc.). Then there are languages that check actions at compile time like Rust. They tell you that the memory you’re trying to access can be modified by another part of the code, which might make unexpected changes and that in order to access it, certain conditions have to be met.

    In laymans terms: imagine you work at a storage facility (memory) and have to store and retrieve packages. To know where to store and retrieve them, you have a piece of paper with the aisle, shelf, and rack and position on the rack. That’s your pointer. To store something, you have to make space on a rack and put the item there, write down the name of the item (variable) and location on a piece of paper (memory address), and keep it on you.

    Imagine keeping all of that in order. You have to make sure you don’t write down the wrong location (off by one error), remove a piece of paper then it’s not valid anymore (dangling reference), remove a piece of paper without removing the item (memory leak), add a piece of paper pointing to something without actually checking what you expect to be there is there and then retrieve it later, and so many other things.
    Those are the things unsafe languages allow you to do.

    Safe languages either enforce that before doing certain things, you check stuff (runtime checks) or that before you even start doing anything, you plan how you would do, and that plan is checked.

    The crazy storage facilities are what most of our world runs on at the moment and there a whole lot of people who love it because it’s simple and they know it. “Just tell the intern to get that box there, I made sure it’ll be fine. Trust me, I’ve been doing it this way for years.” meanwhile somebody gets the wrong medicine because a piece of paper said another one was supposed to be on the shelf. There are a bunch of people who have thought about ways to improve it, implemented, tested it, and are using it to manage their storage facilities.

    Anti Commercial-AI license



  • I wish we had community linux project or something similar which was funded by donations and hired kernel devs to work on things the community voted on

    This is probably what I’m looking for. I wonder how we can get this started. “Linux Kernel Collective” where you can pledge money to the development of the kernel in general, a specific thing in the kernel, or a specific team - with or without stipulations i.e “I trust you, I just donate” and “please show proof e.g monthly reports”.

    Dunno what would need to be done to get that started, if it already exists, or whether something like OpenCollective could be a good starting point.

    Anti Commercial-AI license


  • If we can do it, I’d say via an institution like the Linux Foundation.

    That doesn’t seems like a good solution IMO, given how they already spend their money. If you gave 100 bucks today, 2 of that would end up in the kernel. It’s similar to donating to Mozilla to get Firefox funded, but with Mozilla there’s absolutely guarantee that’s where it’ll end up.

    We can chip in money, so Linux can spend money where they see fit.

    That’s one way to do it, but I find it quite indirect. I’m thinking more of the way similar to how Rust For Linux came in: an external org funded developers to work on an aspect of the kernel. We could do the same but the aspect being funding either existing maintainers or contributors aspiring to become maintainers.

    Other than that, I’d say we need to create an atmosphere for such people to thrive.

    This, I agree with in general. Specifically for the linux kernel, overworked maintainers mean there’s something wrong and hopefully spreading the load by funding those willing to contribute and maintain could be a way to do so.

    Anti Commercial-AI license






  • IMO, GUI applications should be written as agnostic libraries first and GUIs second. That way, anybody with time, skill, and will, can slap on an alternative UI on top.

    Firefox in this example should’ve written a library that allow calling a tab.previous(), updating the internal state, sending events like rerenderStarted, rerenderEnded, navigationStarted, navigationEnded, and so on, that the UI responds to like updating what the back button looks like, the rendered page, and so on.

    It would then be possible to have firefox Qt, Gtk, egui, or whatever else kind of frontend and it wouldn’t be required for Gtk4 to somehow interfere in the rendering code. Furthermore, it would allow embedding firefox nearly anywhere. But firefox is legacy at this point and such a change would be monumentally large. It’s just a pity that servo (firefox’s WebEngine successor) does the same thing firefox is doing, making it difficult to embed with tight coupling between UI and everything else.

    Anti Commercial-AI license







  • Like many others, I thankful for the contributions to Linux. It is great to be able to leave proprietary systems. But the Linux kernel has a major maintainer and leadership problem that is holding back possible contributors. It quite simply isn’t living up to its potential.

    The Linux Foundation seems to prioritise everything but Linux, the kernel still uses technologies and tools from another era (mailinglists, C), and from the outside the kernel looks like an uninviting, unwelcoming, and uncomfortable place to participate in.

    With more focused allocation of resources, there could be lots more people making a living working on Linux. Imagine being able to intern there because of an internship programming. Imagine being able to be able to apply as a junior developer with little kernel knowledge to apply there and learn the ropes to become a fully fledged kernel dev. Imagine their being training courses and introduction sessions, kernel workshops, and live kernel dev sessions multiple times a day to cover every timezone where devs and non-devs alike could join to learn more about the kernel and how to contribute or get a job there. Imagine companies could talk to teams at the Linux foundation’s to help them get their drivers into the kernel or even be guided to affiliated companies to write drivers for their devices.

    The kernel of course doesn’t just need devs It needs technical writers, marketing teams, outreach programmes at school, universities, government institutions, and it needs an arm that somehow talks to the public to get feedback on features they require or request and a way to get feedback from users (private and corporate alike).

    Just imagine the possibilities if things we run and prioritised differently. The potential to spread opensource far and wide would be amazing. Maybe we can still get there and I hope we do. Having someone as motivated as Marcan being nearly burned out from internal conflict is regrettable.

    Anti Commercial-AI license


  • I have never written a line of code in Zig, but I can read it and derive a pretty good idea of what the syntax means without a lot of effort. The same cannot be said for Rust.

    That’s you dawg. You probably have a different background, because I can follow zig code, but have no idea what a bunch of stuff means.

    See samples

    pub fn enqueue(this: *This, value: Child) !void {
                const node = try this.gpa.create(Node);
                node.* = .{ .data = value, .next = null };
                if (this.end) |end| end.next = node //
                else this.start = node;
                this.end = node;
            }
    

    pub fn enqueue(this: *This, value: Child) !void { , !void? It’s important to return void? Watch out void is being returned? Does that mean that you can write !Child ? And what would that even mean?

    const node = try this.gpa.create(Node); what does try mean there? There’s no catch, no except. Does that mean it just kills the stack and throws the exception until it reaches a catch/except? If not, why put a try there? Is that an indication that it it can throw?

    node.* = .{ .data = value, .next = null }; excuse me what? Replace the contents of the node object with a new dict/map that has the keys .data and .next?

    if (this.end) |end| end.next = node // what’s the lambda for? And what’s the // for ? A forgotten comment or an operator? If it’s to escape newline, why isn’t it a backslash like in other languages?

    start: ?*Node. Question pointer? A nullable pointer? But aren’t all pointers nullable? Or does zig make a distinction between zero pointers and nullable pointers?

    pub fn dequeue(this: *This) ?Child {
                const start = this.start orelse return null;
                defer this.gpa.destroy(start);
    

    this.start orelse return null is this a check for null or a check for 0 or both?

    However when I read rust the first time, I had quite a good idea of what was going on. Pattern matching and move were new, but traits were quite understandable coming from Java with interfaces. So yeah, mileage varies wildly and just because you can read Zig, doesn’t mean the next person can.


    Regardless, it’s not like either of us have any pull in the kernel (and probably never will). I fear for the day we let AI start writing kernel code…

    Anti Commercial-AI license