coderedart

21 gün öncediscuss

duplicate from 11 hours ago: https://news.ycombinator.com/item?id=48790302

A more direct title is: ai-hating-author abandons ai-loving-rust for ai-hating-zig.

coderedart

4 ay öncediscuss

very likely to be India.

- Plenty of sources online about the LPG crisis, as the govt has invoked essential commodities act (gives govt extra powers to crush black market and force companies to prioritize distribution to domestic households over industrial use cases).

- E-commerce like amazon/flipkart have also run out of induction stoves (or selling at a premium like RAM).

- Electricity is a state subject, and two of the south India states (bangalore-KT/hyderabad-TG) offer free electricity up to 200 units for low-income households under "gruha jyothi scheme"

coderedart

4 ay öncediscuss

I daily drive kalpa and also installed it on my family computer. I landed on kalpa after a long time researching, so, let me dump an overview of this new distro tech.

# Terminology

1. Immutable: The core OS (/usr directory) is kept in "pristine" condition by disallowing modifications.

  - Discourage installing packages or removing packages.
 
  - well-tested (as most users are running the same OS with same package version)

  - System upgrades are an entirely new immutable copy

2. Atomic/Transactional: Similar to atomicity in databases, where a bunch of operations are bundled into a transaction (atomic =indivisible unit), and it either succeeds completely or it fails completely. Just like that, a system upgrade succeeds or it doesn't. There's no partial package updates.

NOTE: kalpa in particular, uses suse-microos tech called Transactional-Update https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha...

# Atomic styles

4 mainstream models of immutable distros:

1. declarative-config: ALL your system configuration in a config file eg: package versions, network config, user accounts and so on. eg: NixOS, BlendOS

2. OSTree-based: You use cloud/container (OCI) technology (eg: docker files) to layer upon existing layers (eg: pre-baked system images). eg: fedora's atomic spins, vanillaOS, endlessOS. So, fedora coreOS is the base layer -> atomic spins like silverblue/kinoite layer desktop packages like gnome/kde etc.. -> the infamous gaming distro "bazzite" layers gaming packages like wine/steam/drivers etc. and so on.

3. Btrfs-snapshot-based: You take a btrfs snapshot of your root partition before upgrading, so that you can boot into it if the upgrade fails. eg: suse-microos family (kalpa belongs here), chimeraOS

4. systemd-mkosi based: You essentially "curate" an entire OS filesystem in a directory using mkosi and deploy it as an immutable disk image. eg: kdelinux

NOTE: systemd-mkosi is the vision of systemd maintainers as mentioned here: https://0pointer.net/blog/fitting-everything-together.html . There's a whole bunch of system features in development to achieve this ideal.

Most of these distros (except btrfs-based) simply use the A/B root system. They just maintain two root partitions/images, put any upgrade into the "other" partition, mark that as live and the current partition as backup. If the boot into the new partition fails, they just boot into the backup partition and just wait for next upgrade.

As they don't allow usage of system package manager, you are supposed do package management at user level. For gui apps, you resort to flatpak. For other utilities, you usually pick homebrew or language-specific tools like cargo, pip/npm etc..

# The magical tool called Distrobox

This runs containers in userspace and tries to integrate them into your system as much as possible.

A lot of software development requires system level services or shell access or install dependencies etc.. You obviously can't do that on host, as system package management is essentially forbidden and half the point of immutable distros is to keep the host "clean".

So, you create a container and do all your development in there. If it gets too dirty, you just delete it and create a new one.

Personally, I use an arch container for development, as it has all the bleeding edge packages and the convenient AUR too. vscode (from flatpak) supports connecting to containers using official remote extension. I also run a media server inside it. You can also install any system packages or cmdline utilities you want inside it (eg: codecs, ollama, etc..).

# Why kalpa over others?

- Great KDE polish that suse is known for

- btrfs tech is mature and was already used in suse for years, the atomic system is very simple to understand and you can just pick the snapshot you want at boot menu.

- Despite being immutable, customizing the system (eg: installing a driver, kernel modules, firewalls etc. ) is easy too.

  - just enter a transactional update shell

  - this creates a new mutable snapshot of the current system and chroots into it

  - run all the commands you want inside the shell. eg: install/remove packages, enable services etc.

  - exit shell. This will mark the transaction as success/complete and set the snapshot as live for next boot.

- Minimal by default.

- Updates are fast/tiny, as they are just routine rolling release updates from tumbleweed repos.

There are some problems too:

- single maintainer

- less popular, compared to alternatives like fedora-based atomic spins.

- It's based on tumbleweed, so, you get lots of tiny updates (almost daily). Fedora based, for example, have weekly/bi-weekly updates.

- still in alpha stage (but once you set it up, it's rock solid).

- Immutability is still a new concept, and flatpaks are rough around the edges. Expect bugs. Mutable/traditional distros are still easier to use, as that has been "the way" forever.

coderedart

5 ay öncediscuss

Kdelinux uses pacman for now, but the eventual goal is systemd-sysext based mkosi images.

They are also considering moving to buildstream and join gnome.

coderedart

8 ay öncediscuss

The naming is definitely unfortunate, as I was briefly excited for a lua VM written in rust.

Anyway, for those who want a lua version of nodejs/bun/deno, try looking at https://luvit.io/ (lua) or https://lune-org.github.io/docs/ (luau - AKA roblox lua).

coderedart

8 ay öncediscuss

It seems to just be re-exposing existing lua runtimes, which makes the naming very unfortunate IMO. The underlying runtime Luau, for example, details its performance here https://luau.org/performance . Luajit is already popular and has plenty of benchmarks online.

coderedart

8 ay öncediscuss

Throwing in my support for kde connect. It's just super convenient and it's FOSS + cross platform too. kde should honestly advertise it aggressively. There's nothing like it anywhere else.

coderedart

9 ay öncediscuss

You absolutely can just transpile any language into any language. You just need to be willing to give up on performance, and fil-c is more or less doing just that.

coderedart

10 ay öncediscuss

That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();

coderedart

10 ay öncediscuss

Local reasoning is the foundation of everything formal (this includes type systems) and anyone in the type-system-design space would know that. Graydon Hoare (ex-rust dev) wrote a post about it too (which links to another great without-boat's post in the very first line): https://graydon2.dreamwidth.org/312681.html

The entire point of having a static-type-system, is to enable local reasoning. Otherwise, we would just do whole program analysis on JS instead of inventing typescript.

coderedart

2 yıl öncediscuss

I hate this. I did not notice the vast majority of them. So many backgrounds/sets are just green screens :(

coderedart

2 yıl öncediscuss

Actually, looking at the https://component-model.bytecodealliance.org/design/wit.html is the best way of understanding why we have what we have.

We have the basic primitives like signed and unsigned integers of various sizes, floating point numbers, bools and chars.

Remember that wasm components are like shared libraries (dll/so objects). Shared libraries themselves have dependencies (eg: vlc needs qt, which needs mesa, which needs x11/wayland etc..). Each component/shared library has a set of imports from other shared libraries and exports items to other shared libraries or apps.

For example, lets say that I want give a vector/array as an argument or receive it as the return type. On native libs, we just give a pointer + len as arguments, and the function can simply read/write using that pointer.

Except, wasm components are isolated (shared-nothing model). So, I can't just allocate the bytes and give a "pointer" to the jpeg decoder. Because both of us don't share the memory. This has a few reasons:

1. security: separate memories make sure that a component can't read/write another component's memory. 2. safety: If we don't have higher level types, then people will just pass around blobs and cast those bytes into types. Imagine one component thinks of rect as `Rect { x, y, w, h: f32 }` and another component thinks `Rect { x1, y1, x2, y2: f32}`. Without "record" types, we can't find that error. 3. flexibility: Lets say we want to pass around a list of strings between components. how would you do it between rust and js? To let each language feel natural, we need to "copy" these higher level types across the boundary (and wasm needs to understand these higher level types) into the respective suitable types.

This is why we have records (structs), strings, list<T>, variants (tagged unions), Option<T> and such types to allow for a feature-rich API. These are all passed by copy at the boundary with proper validation by the runtime in advance, so you get both performance, safety and ergonomics.

Finally, we also need to talk about "ownership", because some objects (like files via file descriptors) need to be passed across component boundary and we need to wasm let somehow know that we are passing on ownership of the file. We do this with "resource" (object with an ownership like a file descriptor or host native object or socket etc..). And wasm must also ensure that the object will be alive for the duration of the borrow.

The rest of the WIT is simple.

Interface is literally just a group of type signatures or objects. just like a module in python, rust. In C world, we usually just prefix the library/type name for all the function that belong to a certain library/type. In WASI, we just place the related fns inside an interface.

Similarly, a world is just a group of imports and exports that represent a component. world = component. world can import/export types/interfaces/fns/data. You can have multiple 'worlds' and interfaces within a wit file.

And a package is a group of wit files. similar to a java or go package that a file belongs to.

Its not really hard to understand. Most of the terminology directly translates to what we all see in any modern language like js, py, java, rust, go etc..

And the docs are not accessible at the moment, because its still a WIP and unstable. They are experimenting with rust and js to see how well this model works in practice.

coderedart

2 yıl öncediscuss

Its definitely rarer than double or single quotes occurring in string. But I was wondering about the parent comment's concern of passing a string through multiple levels of escaping.

> until you need to get your string through several levels of escape. how many backslashes to add? depends on how deep your pipe is and how each of those layers is defined

coderedart

2 yıl öncediscuss

Won't you still have to escape the closing bracket if it occurs inside the string?

coderedart

2 yıl öncediscuss

Ty. I could feel that there was a joke in there somewhere, but didn't remember the mercury pressure thing

coderedart

2 yıl öncediscuss

Water heater for bath/showers

coderedart

2 yıl öncediscuss

There was v lang in recent memory which made grand claims.

coderedart

2 yıl öncediscuss

using wasm goes into crazy territory imo. It would probably be bigger, and opaque, with no proper errors (unless you compile debug info which would make it much bigger).

I think we already have an almost perfect language i.e. Lua Everyone knows it (or can learn it easily). tiny runtime to embed. sandboxed by default. garbage collected. Only feature missing is static typing.

coderedart

2 yıl öncediscuss

> Rust's borrow checker has a reputation for making it hard to write entity-component systems. And ECS are core to modern game dev.

Isn't it the opposite? That rust's borrow checker makes it hard for non-ECS paradigms due to ownership and XOR mutability rules. While ECS is best for rust, as it "owns" things and schedules the mutating functions without any conflicting race conditions.

The most popular engine in rust right now is bevy, which embraces ECS for everything (including UI).

coderedart

2 yıl öncediscuss

Conclusions from a single data point are the most correct

coderedart

Submissions

Distributing shared libraries with the executable on Linux

comments