KindaABigDyl

joined 2 years ago
[–] KindaABigDyl@programming.dev 31 points 6 days ago (3 children)

The modern one:

When there's a function that can be written manually in 10 minutes but you find a way to do it in 10 days using LLMs

[–] KindaABigDyl@programming.dev 2 points 2 weeks ago (1 children)

I feel like CachyOS should be further to Niche than Arch

[–] KindaABigDyl@programming.dev 4 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

You still need X11 or Wayland somehow. I would suggest something that can run in "kiosk" mode. That's essentially what you want - boot a single app and run that.

If you don't care about wayland, just install xorg-xinit (since you said Arch) and put this in ~/.xinitrc: exec steam -bigpicture

Run startx to launch it on its own. There may be other dependencies you need for steam or for games, but you don't need a whole DE.

If you want, you can even enable auto-login and then set up auto-start by adding this to your ~/.bashrc (or whatever shell you use):

if [[ -z $DISPLAY ]]; then
  startx
fi
[–] KindaABigDyl@programming.dev 1 points 3 weeks ago (1 children)

Yes. I tried it for 6 months. Terrible. Takes way too long to compile

[–] KindaABigDyl@programming.dev 1 points 3 weeks ago

Right but what I'm saying is speed wasn't really the reason to use it in the first place

[–] KindaABigDyl@programming.dev 10 points 3 weeks ago* (last edited 3 weeks ago) (12 children)

For me, I always keep coming back to Arch tbh

Sometimes I get fed up with managing a whole system and once in a blue moon bricking my system on an update, but the alternatives are always worse, and with btrfs now, I don't have to worry about the latter problem.

Nix was the closest to pulling me away. A centralized config? Beautiful. Static package store without dependency conflicts? Beautiful. Immutable applications? The WORST idea we've ever had as a community. For instance, imo, VS Code extensions are fundamentally incompatible with Nix. I spent weeks trying to get it to work doing multiple different things to try and hope it would work. It can't. VS Code just has to be mutable.

Anyway so I'm back to arch and have been for over a year since I tried Nix (and before that Fedora which has its own issues). Before that I had been on Arch for 4 years.

I think I'll stay now. It's really the best option out there. In my mind, Arch is Linux, i.e. it's how an OS should be built for the Linux kernel and the FOSS ecosystem, and it won't ever be beat

[–] KindaABigDyl@programming.dev 29 points 3 weeks ago* (last edited 3 weeks ago) (6 children)

Maybe this is wrong, but my understanding is BTRFS is generally slower than EXT4, and that's okay. It's not going for speed

Where it shines is not in its speed but in its versatility offering compression, rollback, subvol, etc

For example, for applications, you do a lot of writes/reads to Documents or load resources like for games, so use EXT4 for /home or for a dedicated /games partition

For your system, it could be broken via config tweaks or updates, so use BTRFS to have the rollback options

[–] KindaABigDyl@programming.dev 1 points 1 month ago

Ah yes bc it says:

You may not impose any further restrictions on the exercise of the rights granted under this License.

[–] KindaABigDyl@programming.dev 1 points 1 month ago

That was the context of the comment you replied to. Not sure why you're talking about something else

 

I created a little side project over the past few days, a new build system for C and C++: https://github.com/blueOkiris/acbs/

I've seen a lot of discourse over C build tools. None of them really seem solid except for (some) Makefiles (some Makefiles are atrocious; you just can't rely on people these days). Bazel, cmake - they're just not straight forward like a clean Makefile is, basically black magic, but setting up a Makefile from scratch is a skill. Many copy the same one over each time. Wouldn't it be nice if that Makefile didn't even need to be copied over?

Building C should be straight forward. Grab the C files and headers I want, set some flags, include some libraries, build, link. Instead project build systems are way way way overcomplicated! Like have you ever tried building any of Google's C projects? Nearly impossible to figure out and integrate with projects.

So I've designed a simplistic build system for C (also C++) that is basically set up to work like a normal Makefile with gcc but where you don't have to set it up each time. The only thing you are required to provide is the name of the binary (although you can override defaults for your project, and yes, not just binaries are possible but libs as well). It also includes things like delta building without needing to configure.

Now there is one thing I haven't added yet - parallel building. It should be as simple as adding separate threads when building files (right now it's a for loop). I know that's something a lot of people will care about, but it's not there yet. It's also really intended to only work with Linux rn, but it could probably pretty easily be adjusted to work with Windows.

Lay your project out like the minimal example, adjust the project layout, and get building! The project itself is actually bootstrapped and built using whatever the latest release is, so it's its own example haha.

It's dead simple and obvious to the point I would claim that if your project can't work with this, your project is wrong and grossly over-complicated in its design, and you should rework the build system. C is simple, and so should the build system you use with it!

So yeah. Check it out when y'all get a chance

 

I created a little side project over the past few days, a new build system for C and C++: https://github.com/blueOkiris/acbs/

I've seen a lot of discourse over C build tools. None of them really seem solid except for (some) Makefiles (some Makefiles are atrocious; you just can't rely on people these days). Bazel, cmake - they're just not straight forward like a clean Makefile is, basically black magic, but setting up a Makefile from scratch is a skill. Many copy the same one over each time. Wouldn't it be nice if that Makefile didn't even need to be copied over?

Building C should be straight forward. Grab the C files and headers I want, set some flags, include some libraries, build, link. Instead project build systems are way way way overcomplicated! Like have you ever tried building any of Google's C projects? Nearly impossible to figure out and integrate with projects.

So I've designed a simplistic build system for C (also C++) that is basically set up to work like a normal Makefile with gcc but where you don't have to set it up each time. The only thing you are required to provide is the name of the binary (although you can override defaults for your project, and yes, not just binaries are possible but libs as well). It also includes things like delta building without needing to configure.

Now there is one thing I haven't added yet - parallel building. It should be as simple as adding separate threads when building files (right now it's a for loop). I know that's something a lot of people will care about, but it's not there yet. It's also really intended to only work with Linux rn, but it could probably pretty easily be adjusted to work with Windows.

Lay your project out like the minimal example, adjust the project layout, and get building! The project itself is actually bootstrapped and built using whatever the latest release is, so it's its own example haha.

It's dead simple and obvious to the point I would claim that if your project can't work with this, your project is wrong and grossly over-complicated in its design, and you should rework the build system. C is simple, and so should the build system you use with it!

So yeah. Check it out when y'all get a chance

 
 
view more: next ›