HN user

coderedart

64 karma
Posts1
Comments43
View on HN

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"

OpenSUSE Kalpa 4 months ago

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.

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.

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.

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

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.

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).

Zuck is an outright liar. There are now mountains of exceptionally good research showing a solid causal link between social media use and negative mental health impacts on young people (no, I will not google that for you, please do your own homework).

what is the point of the statement if you call someone a liar, claim that there exists material to prove the lie and then say, that you will not link to this material?.

I will recommend a couple great channels for Math:

1. https://www.youtube.com/@SawFinMath : She is a great Professor that walks through problems/solutions one step at a time, so that you can follow along. Has a bunch of Under Graduate course playlists like discrete math, calculus, (abstract or linear) algebra, statistics. highly recommended for the great pacing and solving a lot of problems live.

2. https://mathispower4u.com/ : Another professor who takes an open math textbook (free), and makes a course out of it. Its a little bit more difficult because of denser "pure math" material, but in return, you basically cover everything that a college usually would. He has courses like discrete math, calculus, graph theory, trigonometry, statistics, algebra, geometry etc. Also solves a lot of problems live.

I haven't really tried it, but apparently there is https://www.myopenmath.com/index.php which is sort of like exercism in that you follow along a textbook and solve problems. If someone has tried this, maybe they can share their experience.

The star of that benchmark is actually nanoserde.

1. outperforms a bunch of binary formats (as well as all other text formats) 2. has zero dependencies with fast compile times (even the derive macros are custom and don't use syn family crates as build-time deps)

Whatever the solution to it might be, vague and fuzzy questions—while magnets for chatter since they can stand in for whatever someone wants to read out of them—are not the way to get there.

This is a great line. If HN had a quote of the month or something, this should be nominated for that.

Is C# Underhyped? 3 years ago

Honestly, this thread is kinda low quality. OP seems to be taking criticism of C# personally and going full defensive mode. And the question itself is too vague to answer properly. Is this post just seeking validation of one's own preferred language?

WASM by example 3 years ago

well, for starters, wasm is sandboxed. So, if a wasm library needs an import (eg: read/write filesystem), it has to be explicitly provided. It cannot do anything except math by default. This allows host a high amount of control.

different wasm libraries can have separate memories. So, if a library X depends on a jpeg decoder library, the host has to provide that as import. The jpeg decoder library might export a fn called "decode" which takes an array of bytes of a jpeg, and returns an Image struct with rgba pixels. This allows the "memory" of the two libraries to be separate. the jpeg decoder cannot "write" to the X's memory, cleanly separating the two of them.

Wasm component model recognizes higher level objects called resources, which can be shared between libraries (components). This allows X to simply pass a file descriptor to jpeg decode fn, and the sandbox model makes sure that jpeg library can read from that file only and the rest of the filesystem is still offlimits. wasm is already getting support for garbage collector. So, a high level language can just rely on wasm's GC and avoid shipping its entire runtime. Or the host can guarantee that all the imports a language needs will be provided, so that the language libraries can shed as much runtime weight as possible.

Finally, Component model is designed from ground up to be modular, which allows imports/exports/namespaces and other such modern features. C.. well, only has headers and usually brings a lot of backwards compatibility baggage. The tooling (eg: wit-bindgen) will provide higher level support like generating code for different language bindings by taking a wit (header for wasm) declaration file. If you are familiar with rust, then https://github.com/bytecodealliance/cargo-component#getting-... shows how easy it is to safely create (or bind to) wasm bindings

Ah, good to know. Although, Crime means nothing when police can easily just register a fake case and ask to monitor your email id. India has fallen a lot in human rights ranking in this decade.

Yeah, no way mailfence is that privacy friendly. https://www.hindustantimes.com/cities/mumbai-news/how-cops-c...

The police were able to get a lot of info from mailfence to catch a stupid student who thought using a vpn and mailfence would enable him to send threats easily to the richest man in india. The police got info on how many accounts were from this country, how many of them were active, monitor the mail account for new mails etc..