samc

joined 1 year ago
[–] samc@feddit.uk 17 points 1 week ago (1 children)

Unless, you know, they enjoy doing that

[–] samc@feddit.uk 28 points 3 weeks ago

The big downside is that, for backwards compatibility, the default must still be unsafe code. Ideally this could be toggled with a compiler flag, rather than having to wrap most code in "safe" blocks (like rust, but backwards).

One potential upside that people don't seem to be discussing is that the safe subset could also be the place to finally start cutting down the bloat of C++. We could encourage most developers to write exclusively in the safe subset, and aim to make that the "much smaller and cleaner language" trying to get out of C++.

[–] samc@feddit.uk 4 points 1 month ago

Obviously there's a lot of caveats about how representative this survey (or any other survey) is of the broader population, but I think this is a good reminder of how weird we all are. Nobody on here claims to use Ubuntu or Manjaro, yet they are more popular than Fedora (and potentially even arch, when steam decks are discounted).

There's nothing wrong with that, I love the weirdness of the Lemmy Linux community! I just always think it's good to appreciate when opinions (like my love of ublue) aren't as popular as you think they are.

[–] samc@feddit.uk 12 points 3 months ago (4 children)

Please somebody correct me if I'm wrong, but I really don't find the "chip makers don't have to pay licence fees" a compelling argument that RISC-V is good for the consumer. Theres only a few foundries capable of making CPUs, and the desktop market seems incredibly hard to break into.

I imagine it's likely that the cost of ISA licencing isn't what's holding back competition in the CPU space, but rather its a good old fashioned duopoly combined with a generally high cost of entry.

Of course, more options is better IMO, and the Linux community's focus on FOSS should make hopping architectures much easier than on Windows or MacOS. But I'd be surprised if we see a laptop/desktop CPU based on RISC-V competing with current options anytime soon.

[–] samc@feddit.uk 14 points 4 months ago

In my experience it Just Works ™️. I spin up a distro/toolbox, compile some software (e.g. Emacs) then run the executable inside the container, and up pops the GUI window.

If you use distrobox, you can even distrobox-export desktop files, at which point a containerised gui application is practically indistinguishable from one installed on the host system

[–] samc@feddit.uk 22 points 4 months ago (2 children)

Its all about how an application goes from "I would like to display X on a screen" to how X actually gets displayed. Wayland is effectively a language (technically a protocol) that graphical applications can speak to describe how they would like to be drawn. It's then up to a different program more deeply embedded in your OS to listen to and act on those instructions (this program is called a Wayland compositor). There's a lot more to it (handling keyboard input monitor settings, etc), but that's the general idea.

Wayland is a (relatively) new way of thinking about this process, that tries to take into account the wide variety of input and output devices that exist today, and also tries to mitigate some of the security risks that were inherent to previous approaches (before Wayland, it was very easy for one application to "look at" what was being displayed in a completely different app, or even to listen to what keys were being typed even when the app isn't focussed).

Thing is, change is hard, doubly so in the consensus driven world of Linux/FOSS. So, until the last couple of years or so, adoption of Wayland was quite slow. Now we're at the point where most things work at least as well in Wayland, but there's still odd bits of software that either haven't been ported, or that still rely on some features that don't exist in Wayland, often because of the aforementioned security risks.

[–] samc@feddit.uk 7 points 5 months ago (1 children)

Kotlin targets the JVM right? I think you'd need either a port of the runtime (dalvik?) Or an api translation later a la WINE.

But I don't actually know anything, so don't listen to me. Having a fully Foss phone with support for the android app ecosystem would be wonderful though

[–] samc@feddit.uk 44 points 5 months ago* (last edited 5 months ago) (24 children)

I always thought that people using searx etc over duckduckgo were just gluttons for punishment. Having gone an entire morning without search, maybe now is the time to dive down that rabbit hole...

[–] samc@feddit.uk 2 points 7 months ago

Thanks, fixed! (TIL you need the https:// bit on Lemmy)

[–] samc@feddit.uk 3 points 7 months ago* (last edited 7 months ago) (2 children)

There is, they just don't publicise it. Actually one of my favourite features of the service tbf. Just load up a web page and all my messages are there, regardless of where they came from.

[–] samc@feddit.uk 12 points 7 months ago (2 children)

Iirc microkernels have been the future since before Linux existed. There was a bit of a flame war between Linus and the guy who wrote the MINIX kernel about how being monolithic would be the death of Linux.

GNU Hurd also wanted to show the world how good microkernels could be, but sadly never got off the ground.

I'm not saying microkernels are bad, but I do wonder if there's some reason we don't see them out in the wild much.

[–] samc@feddit.uk 58 points 7 months ago (1 children)

There's a common thread between a lot of the missteps listed here and Embeacer group's recent troubles. The idea that you could fund 230 Spiderman 2's for the same price as buying 1 Activision-Blizzard-King really drove the point home to me.

The problem (in my obviously uneducated opinion) is that when you spend so much money in acquisition, especially of established companies, you're neither funding nor rewarding innovation. You spend $70B on ABK and some randos in suits get a huge payout that they invest in oil or crypto or whatever. Spend $70B on talent and early career devs and you could unleash a tidal wave of creativity and experimentation.

view more: next ›