Skip Navigation

Scoopta

@ Scoopta @programming.dev

Posts
5
Comments
357
Joined
3 yr. ago

  • The very weird Hewlett Packard FreeDOS option – Interesting things

    Jump

  • This honestly makes some sense though. Legacy bios is virtually dead on all modern systems. CSM still exists on some stuff but it's fading out. The A20 gate no longer exists, the PC industry is moving on. DOS on real hardware at this point is just going to get progressively more and more rare as the hardware further diverges from the IBM PC heritage it's clung to. Real mode is the next thing on the chopping block and that will completely kill the legacy bios and DOS outside of VMs.

  • It’s not working! Should I blame caching?

    Jump

  • Usually I do my best to blame the network with cause!

  • My Gnome and KDE setups

    Jump

  • The fact your gnome one has the kde icon in the top left threw me for a loop at first

  • appimage portablility across machines

    Jump

  • I wonder how that works on multi-user systems. How do they structure that so that settings are per-user?

  • appimage portablility across machines

    Jump

  • macOS applications are folders and that will never stop being weird to me. They basically use the same setup as windows but instead of making the application the executable in the folder they turn the whole folder into the executable

  • Are there any non-unixlike Linux-based OSes other than Android?

    Jump

  • Lol, yeah but React isn't Linux based so doesn't quite end up so cursed. Last time I played with it it was still really squirrelly.

    Because it's fun. As someone who is writing a hobbyist kernel(slowly) it isn't about making a functional OS, it's about learning how systems work and suffering while you do it =D.

    I wouldn't classify React as a hobby project per-say. I suppose it is but I put hobby OSes in a category of not having a goal to ever be production ready for anyone outside the developers. Tbh react would have way better compat if they focused on win32 over Linux as opposed to developing NT from scratch but the project is also old enough(1998) to be from a time where Linux wasn't what it is today in terms of wide spread hardware support.

  • Are there any non-unixlike Linux-based OSes other than Android?

    Jump

  • Your updated question has given me a rather cursed idea...psychopathic even. Replace the *nix userland with wine...have win32 user space on your Linux. The biggest problem I see with the idea is wine would need a DRM backend so as to not depend on X/Wayland. Ofc the kernel API would still be *nix but your user space would be anything but. There's only so much you can do to get away from a *nix environment when using a *nix kernel.

  • Are there any non-unixlike Linux-based OSes other than Android?

    Jump

  • Define what you mean by non-unix like? Android is Unix like, it hides it from the user but the NDK is still a Unix like API, all devices have a POSIX shell /system/bin/sh installed which can be accessed via a terminal emulator app or using adb. The filesystem structure is different than most systems but there's still a /dev, /etc, /bin, and /proc. Not to mention one of the most unixy designs being the fork() call which android uses as the basis of all app processes. What I mean is Android has a parent process containing all the basic stuff an app needs called zygote which is then forked to become an app processes when an app is launched and then the rest of the app stuff is loaded into that new process, an exec to fully replace the parent is not done. That's a very unixy design decision that isn't usually available on other systems.

    Technically speaking if we're going by the hides it from the user perspective then the steam deck qualifies to the same extent. It's hidden until a power user doesn't want it to be

  • Firefox 137 To Support HEVC/H.265 Video Playback On Linux With VA-API

    Jump

  • I definitely think this was a good move. Proprietary video codecs are silly and I'm glad VP9 and AV1 have been so widely adopted. I do wish more services used them instead of h.264 but at least it's something.

  • Is there a way to fund linux kernel development as a community?

    Jump

  • The thing about the kernel in particular is it's already mostly about money. With very few exceptions most maintainers are employed by someone, even just the Linux foundation, to work on the kernel full time. There's very little community involvement outside of the random patches here and there that community members submit. I think what OP is getting at is it would be nice if there was a community sponsored maintainer so it wasn't all just corporate employees but that likely means providing financial compensation.

  • Resigning as Asahi Linux project lead

    Jump

  • Making a feature request is one thing but complaining isn't helpful especially when they're working on other things. It's not like they're sitting on their asses doing nothing.

  • Resigning as Asahi Linux project lead

    Jump

  • I do get the irony, but I also do get where he's coming from about users always asking for more.

  • Removed

    GNOME launched their new website

    Jump

  • I'm also a plain compositor person but gnome is my favorite DE and sometimes I kinda miss the polished DE experience. My productivity doesn't...but sometimes I do lol.

  • Systemd Adding The Ability to Boot Directly Into A Disk Image Downloaded Via HTTP

    Jump

  • Even as a systemd user I'm starting to feel the kitchen sink creep in

  • New Apple Silicon Co-Maintainer Steps Up For The Linux Kernel

    Jump

  • Yeah, I agree with you. After seeing the latest drama I get why marcan was annoyed but also IMO his response only escalated the situation and was unproductive so maybe having someone else handle the upstream code will work out better for everyone.

  • Linux Patches Adjust AC Plug/Unplug Behavior During s2idle To Match Windows

    Jump

  • Yeah I agree here. I'd expect my laptop to stay asleep if it was asleep to begin with. Also I find it kind of annoying that in order to fix bugs they have to change Linux to mimic windows, especially when it's a situation like this where the change specifically results in a different behavior which is noticable to users.

  • "Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project". Thoughts on this post from Marcan?

    Jump

  • ...look man, I'm going to say this as simply as possible because you keep mischaracterizing or misunderstanding a lot of what I say. I'm not making any claims about kernel policy, full stop. I never did.

    I'm not saying his behavior is justified in regards to calling rust a cancer, I'm just saying that he is making a legitimate technical complaint, regardless of his motives...and EVEN if he wasn't, name calling is unproductive.

    C is high level ASM, Linus has said that as a quote, I personally agree with it having written both, it's an opinion, not a statement of fact, you can disagree all you like but the fact that some kernel maintainers share the opinion is a valid point to bring up in this conversation about multiple languages causing a divide. I will find the source for his quote if that will satisfy you.

    Lastly, the point I'm trying and failing to make is the kernel is 1% ASM, rust when fully brought into the kernel will comprise far more than 1%, additionally it is FAR more different to C than ASM is regardless of your opinions on the C is high level ASM statement. It WILL create a language barrier, the question is how significant will that be. The ASM is a small minority of kernel code, rust won't be.

  • "Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project". Thoughts on this post from Marcan?

    Jump

  • C is basically high level assembly. It's hardware agnostic high level assembly. I have written both, this is personal experience and also I believe even Linus has said EXACTLY that statement. It is an opinion ofc and you're welcome to disagree but it isn't just me.

    I never said it was a policy but it's definitely true. Inline assembly IS still assembly. I'm saying if the code can be written in C it more than likely will be over assembly unless there is a very good reason to write it in ASM. The kernel is 97.97% C and just over 1% ASM. If that doesn't prove what I'm getting at Idk what else will. It's a totally different circumstance than replacing large swaths of C with rust or introducing large amounts of rust in favor of C.

  • "Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project". Thoughts on this post from Marcan?

    Jump

  • There are already 2 languages in the kernel: C and Assembly

    Assembly and C share a very very close relationship. C is really just high level ASM and ASM is used as little as realistically possible in the kernel so the situation is different.

    That already happened and Linus decided to accept Rust code into the kernel.

    Doesn't mean you should neglect the opinion of every other maintainer. I'm not saying rust shouldn't be included here or that Linus shouldn't have the right to override his opinion. I am saying calling names as opposed to discussing his concerns is not productive. FOSS is a collaborative space and that collaboration is important even if redundant at times.