cyclohexane

joined 3 years ago
MODERATOR OF
[–] cyclohexane@lemmy.ml 3 points 4 months ago (1 children)

Tell us more about unison

[–] cyclohexane@lemmy.ml 2 points 4 months ago

I know double semicolons are a thing, but I've never had to use them. I forget what they're for, but yeah it's supposed to be an escape hatch for something that shouldn't be happening iirc.

The curried snd uncurried functions... Maybe you are confusing with SML, because everything in ocaml is curried by default. Though admittedly the standard library could be more complete, but I personally am happy to use third party dependencies for less common things.

[–] cyclohexane@lemmy.ml 8 points 4 months ago

Its best to use a protocol that doesn't allow unencrypted messages

This is an implementation thing and not a protocol thing. What protocol doesn't allow unencrypted messages? I am sure signal's protocol would still allow it, it's just that the implementation doesn't.

And same for XMPP. Just go with the implementation that doesn't.

[–] cyclohexane@lemmy.ml 8 points 4 months ago (10 children)

Sad I had to scroll to the end to see this.

Ocaml is brilliant and has the nicest type features. It's almost like Haskell but more approachable imo.

[–] cyclohexane@lemmy.ml 1 points 4 months ago

Maybe because I'm not from an English speaking culture that I don't see the far right stuff

[–] cyclohexane@lemmy.ml 37 points 4 months ago (5 children)

People prefer centralization, and it makes sense. The Fediverse resolves most of the issues with decentralization, but so does centralization, which came way sooner, and arguably did it better.

Also, people seem to forget that Facebook was pretty cool back then. It had superior features, and was not the buggy mess it is today.

[–] cyclohexane@lemmy.ml 18 points 4 months ago

Striking terror in the hearts of genocidal invaders is a good thing yeah

[–] cyclohexane@lemmy.ml 10 points 4 months ago

Unless you pay from the exchange's wallet

[–] cyclohexane@lemmy.ml 1 points 4 months ago

I have read that it is faster, though I have not tested it myself. Personally, my initial reason to use it was just to try something new and explore the unix world. My reason for staying is that it is a very simple init system that is pleasant to work with. It made me understand what an init system is and use it a lot more.

Systemd is good if you just want something invisible and you do not want to mess too much with an init system unless you have to. Everything integrates with it

OpenRC is nicer if you want to write your own init scripts. It is very well documented also.

[–] cyclohexane@lemmy.ml 2 points 5 months ago

For #2,

For gaming, if you use steam, you may not face more than the following:

  • game does not work with no well known way to resolve. You can find this out by checking protonDB
  • game does not work because it needs to enable some options. Very easy to fix, and you can find the options on proton db for each game.
  • does not work because you didn't setup steam right. You often need to enable proton, which in short is steam's emulator or windows
  • does not work because your gpu drivers did not install. This depends on distro and they should all have a guide on how to do it, but usually it is just a matter of installing something.

For programming, you will love your life because everything programming is way easier on Linux.

[–] cyclohexane@lemmy.ml 3 points 5 months ago

For #1, I've made the realization that most distros are lightweight skins or addons on top of another distro. Most of the time, if you start with the base distro, all you have to do is install some apps, change some configurations, and suddenly you have that other distro. It is much easier than doing a reinstallation.

If you filter out all of these distros that only do a little on top of an existing, you're left with a quite small number actually. I'd bet it's less than 10 that are not super niche. Fedora, Arch, debian, gentoo, nixos are the big ones. There's some niche ones, like void Linux and Alpine.

So I'd say if you try all of those, you don't need to try any more 😁

[–] cyclohexane@lemmy.ml 5 points 5 months ago

First time Linux user you mean?

I wouldn't recommend it, unless you can navigate the terminal well. When you install arch, it installs no desktop environment, only the ability to talk to a terminal.

It's technically possible and very doable with some googling, but I wouldn't recommend it.

 

In a lot of projects, this is usually done via README. It tells you what running dependencies to install and how to run certain commands.

This can get harder to maintain as things change, the project grows, and complexity increases.

I see two parts to automate here: actually setting up the environment, and running the application or orchestrating multiple apps.

How do you address this?

 

why?

Because bash feels clunky to write and work with for anything non-trivial, especially compared to other scripting languages.

Why not another scripting language (no compile necessary)?

Because bash and sh are installed nearly everywhere. Any other scripting language means the user is required to have that installed, and that is far less likely to be the case.

If I could write my scripts in a nice syntax, but be sure my users will be able to use it effortlessly by distributing to them compiled versions, then that would make both of our lives easier!

Thoughts? Are there any languges that do this?

 

Hello all,

I am looking for suggestions for libraries to use on my project. It is a personal project, so I'm happy to experiment with lesser known or new libraries.

The application will be a mix of content-focus and client side interactivity (think to-do list with server side persistence).

My current approach is as follows:

  • Server side rendering on NodeJS with a template engine, complemented with client side scripting for interactivity (mostly vanilla JS)
  • Use liquidJS as template engine (any alternatives?)
  • Use fastify as the HTTP / Backend server with @fastify/view plugin for serving liquidJS (and other template engines)
  • use vanilla JS scripts for interactivity and DOM manipulation
  • use vanilla-SWR for data fetching, mutation and persistence on server side. Link: droyson/vanilla-swr

Any other suggestions?

 

React (and Vue, et al) was built with client side rendering in mind. It just does not seem to fit the server side rendering pattern.

What are the use cases? From my perspective, if your app is a rich web app with a lot of interactivity, you probably want CSR and don't benefit much from SSR.

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

Using React SSR for all of these seems like the wrong tool. What am I missing?

 

suppose I enable CONFIG_CMDLINE_BOOL=y and CONFIG_CMDLINE="...", but I also add a cmdline using efibootmgr via -u option, which one takes precedence and gets executed?

Does an initramfs make this more complicated? does it also have its own cmdline?

 

The majority of Linux distributions out there seem to be over-engineering their method of distribution. They are not giving us a new distribution of Linux. They are giving us an existing distribution of Linux, but with a different distribution of non-system software (like a different desktop environment or configuration of it)

In many cases, turning an installation of the base distribution used to the one they're shipping is a matter of installing certain packages and setting some configurations. Why should the user be required to reinstall their whole OS for this?

It would be way more practical if those distributions are available as packages, preferably managed by the package manager itself. This is much easier for both the user and the developer.

Some developers may find it less satisfying to do this, and I don't mean to force my opinion on anyone, but only suggesting that there's an easier way to do this. Distributions should be changing things that aren't easily doable without a system reinstall.

 

It seems that around July 15th, the repo for Barinsta, the FOSS instagram frontend that was abandoned about 1-2 years ago has been taken down.

The repo was hosted on codeberg, after the original author took the github repo down. The second maintainer moved the repo to codeberg, but it seems little was done to maintain it. The second maintainer seems to have deleted previous blog posts about barinsta as well.

I have the repo backed up locally (hence why I noticed), but it does not work in its current state.

Its probably not worth using instagram anyways

 

hello friends,

I am looking for a way to do what I described in the title. When running command command, I dont want to have to type SOME_ENV_VAR=value command every time, especially if there are multiple.

I am sure youre immediately thinking aliases. My issue with aliases is that if I do this for several programs, my .bashrc will get large and messy quickly. I would prefer a way to separate those by program or application, rather than put them all in one file.

Is there a clean way to do this?

 

I have been having some trouble doing this and was wondering if it is a common theme or there is room to make it better.
Sometimes packages wont compile at all and thats fine. But recently I cross compiled some system packages and it bricked my system and was no longer able to ssh into it. I am not asking for help in this specific issue, but want to ask if this is a common occurrence for this kind of setup? It does not seem to be a popular setup

 

want to run a bittorrent client on a headless server. The server is a raspberry pi so it is limited a bit limited on resources.

Whats your favorite bittorrent client with a good command-line interface?

 

I've been using geometric weather, but wondering if people have other options for weather apps.

Widgets aren't necessary

 

I've been using geometric weather, but wondering if people have other options for weather apps.

Widgets aren't necessary

view more: ‹ prev next ›