I'm interested, but can't navigate the website. The down-arrow in the lower-right is unclickable, maybe covered by some semi-transparent chrome of my browser, not sure. And no idea why there need to be 4 directional arrows.
That's Reveal.js / Slides.com format. It became very popular in 2010s. The idea behind the 2-d navigation is that you can use left-to-right to move between chapters, and move down to dive into a specific chapter. This allows you to skip chapters due to time constraints. Or hide gnarly details about something so that these specific slides do not break the flow of presentation but still having them available for the audience online. Or, having slides announcing demos, but if demos do not work the down slide would have a video demonstrating how the demo is supposed to work. Many possibilities like this. Also the slides are produces using Markdown, so the format was appealing to many authors.
However, doing chapters well turned out to be tricky. Ideally you want them to be of similar size and have 3 to 7 of them in the talk, but many presentations aren't structured like this. The rise of Slideshare and SpeakerDeck for sharing slides in mid 2010s caused this 2-d navigation to go out of favor: those services only support linear static slides. This is also a reason why people use fewer animations in slides nowadays and why tools like Prezi didn't catch on (that was another presentation tool with non-standard navigation that went out of favor very quickly).
Many people still use Reveal.js to make their slides but they stick to left-to-right nav only.
Very interesting article, and the color picker is exceptionally revealing. As for the challenge, it stopped working in Firefox after the first half dozen examples; but on Chromium I got a decent .0042 Fun!
I thought of this when I saw that the final criteria in the list is Social Understanding. Might be a lot of humans who can't measure up to sentience by these parameters! ;-)
(and I wonder what my ADHD friends would think of the Executive Function requirement as well...)
This web page doesn't do a good job of motivating the reader.
I understand what the Plasma Desktop Environment is. But what is "atomic and transactional Linux"? What are the advantages to the alternatives? What other projects are similar? What is the motivation for this project in particular? Most importantly, why should I want to use it?
It's a glorified Live CD, with added "persistence" for user data. Updates are done by replacing the system install (which is readonly during normal operation, just like a Live CD) and rebooting, with an A+B mechanism enabling seamless updates during operation, as well as rollback if the new install fails. It's the modern "cattle not pets" approach to system administration: every system is running a well-defined ("atomic") Live CD equivalent, not something bespoke that's the unpredictable result of partial updates and/or edits on the running system.
No, updates are done by creating a snapshot of the read only mounted root, and applying the packages via the usual package manager in there. The snapshot only becomes active at reboot, and if starting fails it'll revert automatically back to the last known working snapshot for the next boot.
Things like /etc are writeable, so you don't need to reboot for simple configuration changes.
You can run it just like always with all packages installed - it's just not recommended as the additional complexity on updates increases the risk that manual intervention is needed, and tooling is good enough that for a lot of stuff you don't really need it there. Like, toolbox or distrobox as podman based containers running in the host namespace (either as user or root), allowing persistent installation of debug tools, without having to reboot.
Really well explained - I use fedora kinoite, and have had hard time grasping how the immutability exactly works when compared to traditional setup.
I would add to this that homebrew is a nice tool for being able to install software that are not in flatpaks and if you do not want to add too many layers to the "os-tree".
The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.
Also doing basic polyglot stuff is a bit messy, if you have toolboxes like "node" and "php". But if you have project based boxes, then you end up with billion copies of node.
But what a pleasure it is to just update the base image and have things work, or rollback if something fails. Hell, you can even rebase the base image to some other setup, and most likely have your system work.
> The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.
You can limit the access of distrobox, but it's a bit annoying, as they didn't think about isolation when designing it. Personally I'm not doing much with distrobox - I've been using LXC for ages to run some applications (like browsers) somewhat isolated, with only specific directories shared between home and the container.
Few years ago I started switching some of them to podman as that makes it easier to pre-build and share containers between systems, with a custom wrapper script to mount in resources as needed (directories, wayland socket, pulse/pipewiresocket, ...) - with my approach the opposite of distrobox: allow nothing per default, and specify resources that should be available.
So when I switched to immutable systems I had everything ready already to not have to rely on either system packages or flatpack and distrobox too much.
Overall I'm very please with the progress there - suse microos is pretty much everything we were hoping to achieve with our phone OS back at Jolla 15 years ago, but for most of the things were just not ready. We did use btrfs with snapshots to allow roll back for updates, though we didn't do a full read only root - and ran into issues with btrfs just not being stable enough at that point.
This is what I don't get. You're supposed to use flatpaks and distrobox and docker none of which are easier or better than just using the package manager. And if you do use the package manager you have to reboot for the most trivial thing. And this is the future. Maybe for an appliance but for a desktop?
Install Fedora Silverblue, or any subedition if you don't like Gnome. The one for Cosmic it's being polished and looks good. You basically use 'toolbox enter' for developing with Docker, Python with pip with venvs and the like and Flatpak (and Flatpak SDK's) to install the desktop software.
If you don't like Fedora's Flatpak repos you can disable these and reinstall all the software installed from FLathub, there are instructions to do so online and again once you do that you pretty much finished your desktop needs.
RPM's are just used as overlays in an emergency (maybe you need virtualization support, but you just install the libvirt services/tools once and you'll never touch rpm-ostree again). Ormaybe to try Waydroid. Again, use rpm-ostree once and forget.
Your maintenance? Upgrade the system with 'rpm-ostree upgrade' and 'flatk upate'.
This is the future, and well, Guix wants to do the same but with Guix and Guile for everything, and IMHO it's a good step over Unix. AIX with SMIT was not-so-Unix, ditto with Solaris with SMF and the like. If Unix itself diverged a lot from v7 with BSD sockets and ioctls, who cares about classical Unix.
The true Unix philosophy lies from late 90's in Plan9/9front, the C creators stated that Unix was already dead and 'rotten'. 9front does Unix better than UnixTM itself. No VT's, true 'everything it's a file everywhere' - hello 9p-,
namespaces, rio being much unix-like than the X11 nightmare. No BSD crazyness to create a socket, no ioctls.
If something better gets created with FedoraOS, GNU Guix with Shepherd (plus Hurd too; non-root filesystem mounting and the like looks very liberating for the user), that good for us, the thinkerers. You get really easy rollbacks (9front too, per file, with GeFS), less tirany from package managers (flatpak can set updated desktop software with a stable kernel and with Guix everything it's pinnable, reproducible and whatnot; and from 9front, everything it's statically compiled, so you build something once, backup that file, restore it, done), and so on.
Linux distros that are updated with full system snapshots instead of package by package, similar to Android. The key difference is most of / is mounted read-only[0] and is only changed by distribution provided updates so you and the distro team always know exactly what's running.
> What are the advantages to the alternatives?
Greater control and stability since its essentially always running in a supported configuration. Easy roll-backs to a previous update if something goes wrong. You always know exactly what your system is running if you want to keep it in sync across machines (more useful in a server setting).
> What other projects are similar
Kalpa is a "sibling" project to AeonOS, which is atomic OpenSUSE but with Gnome (and other changes, which I'll get to). There's also the Fedora Atomic line of Fedora Kinoite and Silverblue (KDE and Gnome respectively), U-Blue, Bazzite, SteamOS, and more. I think most major distro lines have an Atomic variant at this point.
> What is the motivation for this project in particular?
For Kalpa specifically, it's to offer a KDE alternative to AeonOS. Originally there was just AeonOS, which was OpenSUSE MicroOS (an atomic version of OpenSUSE Tumbleweed) with GNOME installed. Aeon has diverged greatly from MicroOS though and I think it no longer uses it as an upstream. AeonOS also refused to support KDE[1], so Kalpa was created. Kalpa still uses MicroOS as its upstream and I'm not sure if there's any plans to change that.
> Most importantly, why should I want to use it?
I use it on my personal laptop because it lets me have all the benefits of a rolling distro (up to date packages) without the stability concerns. Updates apply automatically in the background and I know when I reboot I'll always have a working system available to me.
[0] /etc is mounted as an overlay FS so you can still make changes to it. /var, /usr/local, and /srv are also still user-writable. I think /mnt is too but I forget off hand.
[1] Aeon is generally anti-customization and does its best to only offer one way of doing things. This is to prevent configuration drift and reduce the maintenance burden per snapshot. GNOME also has a more regular release cadence, which makes it much easier to integrate than KDE (or so I've been told..)
Would the A/B filesystem approach à la Android be a good way to distribute Linux with ZFS-on-root without all the angst from DKMS modules versioning?
[Maybe unrelated, but just occurred to me (some horror stories have prevented me from trying ZFS-on-boot in linux after Ubuntu botched it with their Zsys “adventure”).]
If i understand the intention of a zfs root combined with an a/b approach — it feels like this btrfs root and immutable gives you the same benefits but with better mainline support.
> Would the A/B filesystem approach à la Android be a good way to distribute Linux with ZFS-on-root without all the angst from DKMS modules versioning?
This is exactly what Valve's Steam OS 3 does. (Except it uses Btrfs for the two root partitions, not ZFS.)
It's closer to the "sealed system volume" model that macOS uses. The core OS filesystem isn't (normally) writable, although you can finagle it to add drivers and such.
Yes, all projects in this sphere should communicate better.
An atomic distro is one in which the updates are swapped atomically at reboots. They also go by the name of immutable distros. Only the "system" partition is immutable.
Most popular I would say is SteamOS followed by the Fedora variants (Silverblue, Kinoite) and derivatives (Bazzite).
They are still limiting in daily use, rough around some edges.
Yeah. I use bazzite, but had to overlay like 5 apps. Flatpaks are often disappointing or just do not exist. AppImage is awesome, too bad it is used rarely.
It's buried in the About page, but it uses different terminology. They definitely have to review their copy.
> Automatic Updates: Updates never touch your running system, only taking effect on reboot.
> Resilient: Due to the atomic nature of updates, if something goes wrong, the system will automatically roll back to the last known good working state
It's never been a great argument. Even non-atomic Linux distros have you reboot after updates. It's just the safest way to ensure that everything is running with the updated packages. You're kind of in an untested state if you have mixed versions of applications and their dependencies running.
Plus, updates aren't the only thing that require reboots. Various config changes will need a reboot or at least require you to log out and back in. Even just adding your user to a group needs you to end your session for the change to apply.
Isn't the point of Linux kernel live patching (kexec, ksplice) to reduce the need for rebooting after kernel updates? There's certainly a user base that still aims to maximize system uptime.
That depend on your needs.. linux can do live update if you need that, usefull on servers..
But atomic versions as more target to desktops or containers where you need to have know working setup and when you upgrade you replace it by newer one..
So you dont update per se... You install the new version in a separated partition and boot into it the next time you restart.. Same with containers, you just destroy it and recreate with the new version..
If the new version fail you boot back to the old original version that is know to be working and have not being replaced..
The ideia is to ensure a known to be working system is always available..
There's https://kinto.sh/ you can install on any distro. For visual similarity, GNOME is already quite Mac-ish, but there are distros like elementaryOS that go further by e.g. moving window controls to the left side.
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.
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
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.
Hope this makes it to people soon. Have a family friend who was diagnosed with cancer a few days ago. It was here in Canada, so they offered her assisted suicide, literally within 30 seconds after telling her she had cancer. She didn't even really process the diagnosis before they were offering to help her die. They didn't offer to try any experimental medicine.
Not a comment on the parent post's situation, but MAID in Canada isn't quite turning out how it was promised. A recent report making a splash in certain circles pointed out that ~200 people in Ontario in 2023 got assisted suicide either the same day or the day after they filed their paperwork. The most notable case was a woman who, after submitting her paperwork, changed her mind and wanted hospice instead. However, she was denied hospice care and subsequently was put down.
Bit by bit, Canada risks defaulting to suicide over expensive care. That's not what people voted for when it was first proposed.
The problem isn't that the urgent request went through, it's that she requested hospice or palliative care and was denied. And, let's be honest, POA should not be sufficient to euthanize a person who is awake, aware, and revoked consent.
"Do no harm" has been replaced with "put them down if it's cheaper and we can get away with it"
That's a separate problem from the parent post, and the point of my post was that her husband requested the decision on the assisted death, not the government.
I didn't mean to suggest that the government is going to hide under people's beds and stab them in their sleep if they get sick.
The government is responsible for funding every aspect of this process, though. It regulates the controls and rubrics over who gets what kind of care. The husband may have instigated it, but the system is broken if a person eligible for euthanasia isn't eligible for palliative care or hospice.
Most importantly, I continue to contend that MAID is turning into something that isn't what Canadians voted for. It is, however, turning into something that its opponents feared might come to pass.
Thats how I read it as well. The deeper issue is that he shouldn’t even be able to contact them when they deemed her lucid enough to not be eligible just a day earlier, especially when they were keen enough to notice he was burned out.
Separately, why do these services have to move so quickly? It seems like it’s either glacially slow in other countries where people pass before even finishing the paperwork, or insanely fast like in this case. There really should be a balance.
Since we're talking about Canada, ostensibly the government, as the provider of healthcare, wants it to be inexpensive enough that the citizens have a first-world level of care... as opposed to euthanizing sick people because it's easier than providing hospice or expensive treatment.
After all, using the monopoly power of government and taxation is meant to be more efficient and provide more services at lower costs.
A cynical person might presume that MAID is being used as a cost savings measure more than an empathetic alternative for those who do not wish to wait to die of natural causes.
Are the headlines the tip of the iceberg, or the exceptions that gain notoriety? When the government and health care system are so deeply intertwined, who has access to the data but not an incentive to obscure the facts? With any luck, time will tell.
Oh, mostly just the hospitals, the insurers, the medical device manufacturers, the pharmacy benefits managers, the pharmaceutical companies, the group purchasing organizations, and the clearinghouses. Everyone who can take a bigger cut if there’s more money sloshing around the industry.
That sounds like murder to me. I couldn't believe that and thought you must have been misrepresenting the facts. Nope, your summary is correct; the full case is there, in black and white, on page 22 of the Ontario Solicitor General's report, as you linked; and amazingly it was reviewed by a committee that didn't seem to find much wrong with it. That is very deeply disturbing. I have quoted the case overview below:
>CASE 4B
Case Overview
Mrs. B was a female in her 80s who had a challenging medical trajectory following
coronary artery bypass graft (CABG) surgery. She experienced several post-operative
sequelae, including wound dehiscence, osteomyelitis, and respiratory failure. She
required specialized care in hospital, including additional surgical procedures. Due to
physical and functional decline, Mrs. B elected for a palliative approach to care. She
was discharged home with palliative supports (i.e., palliative care team and home care
support services, including adaptive aids and personal support services).
Mrs. B reportedly expressed her desire for MAiD to her family. In response, and on the
same day, her spouse contacted a referral service on her behalf. The following day, a
MAiD practitioner assessed her for MAiD eligibility. She reportedly told the MAiD
assessor that she wanted to withdraw her request, citing personal and religious values
and beliefs. She communicated that pursuing in-patient palliative care/hospice care and
palliative sedation was more in-keeping with her end-of-life goals.
The next morning, Mrs. B presented to the emergency department (ED) of her local
hospital. Her spouse was noted to be experiencing caregiver burnout. Mrs. B was
assessed to be in stable condition, and thereby discharged home with continued
palliative care. Her palliative care physician completed a referral for in-patient palliative
care / hospice care due to her social circumstances (i.e., caregiver burnout). Her
request was denied for not meeting hospice criteria for end-of-life, and a long-term care
application was offered.
On the same day, Mrs. B’s spouse contacted the provincial MAiD coordination service
requesting an urgent assessment. A different MAiD assessor from the previous day
completed a primary assessment and determined Mrs. B to be eligible for MAiD. The
former MAiD practitioner was contacted. This MAiD practitioner expressed concerns
regarding the necessity for ‘urgency’ and shared belief for the need for more
comprehensive evaluation, the seemingly drastic change in perspective of end-of-life
goals, and the possibility of coercion or undue influence (i.e., due to caregiver burnout).
The initial MAiD practitioner requested an opportunity to visit with Mrs. B the following
day to re-assess; however, this opportunity was declined by the MAiD provider due to
their clinical opinion that the clinical circumstances necessitated an urgent provision. An
additional MAiD practitioner was arranged by the MAiD coordination service to complete
a virtual assessment. Mrs. B was found eligible for MAiD by this third assessor. The
provision of MAiD was completed later that evening.
That doesn't account for the good-will and word-of-mouth generated from any successful matches, which presumably could lead to many more customers than those lost due to marriage.
Very anecdotal, but in my experience people have no attachment to or enthusiasm for dating apps. I've heard (acquainted) couples say the met on dating apps. No one ever said which ones.
I think the difference is are they people asking in a relationship or not - asking which app is categorically asking where they can find someone to hook up with.
Or it's curiosity (genuine or polite). Maybe, for some people it tips the scale into trying the app either because they were already thinking about trying some/any app, or switching away from their current one.
I don't know if anyone who's asked me has started using the app as a result, but I think it (anecdotally, again) supports an idea that a successful results for one app organically helps its name recognition.
Edit: unless you meant the difference was between people asking which app vs which spouse.
No, you understood me exactly as I meant it - which app.
I met a partner of five years on the apps and people often asked how we met but they never asked which app (Tinder) - we actually saw each other on multiple apps but she did not respond on Bumble because it forced her to send the first message, which I thought was interesting feedback.
I mean, one wedding can draw in over a hundred people, and the specific dating app in question gets name dropped not infrequently. The last wedding I went to, Hinge was mentioned in at least one of the speeches.
I feel like dating apps almost exclusively take off via word of mouth. It doesn’t have to be marriage, though, just people finding matches worth meeting.
Almost every dating app is scammy, buggy, heavily paywalled, and barely used. If you see an ad for a dating app, it’s usually in that category.
Maybe we only have enough food to feed the entire world, because of greed. Every time we've tried to impose a system that spreads the wealth to the masses, rather than it resulting in equality, it has led to suffering and bloodshed. And ironically, in the Soviet Union and China, the death of millions from starvation.
Isn't that what the Zink, ANGLE, or GLOVE projects meant to provide? Allow you to program in OpenGL, which is then automatically translated to Vulkan for you.
DirectX 9 is long term stable so I don't see the issue...
No current gen console supports it. Mac is stuck on OpenGL 4.1 (you can't even compile anything OpenGL on a Mac without hacks). Devices like Android run Vulkan more and more and are sunsetting OpenGLES. No, OpenGL is dead. Vulkan/Metal/NVN/DX12/WebGPU are the current.
Also, if we're talking Switch 2, you have Vulkan support on it so odds are you would choose 2x-10x performance gains over OpenGL. It isn't that powerful. My 6 year old iPhone is on par.
People generally don't realize how much more CPU efficient calls are with Vulkan, DX12 or Metal. And especially on handhelds, the SoC is always balancing its power envelope between the CPU and GPU so the more efficient you are with the CPU, the more power you can dedicate to the GPU.
The aforementioned abstraction layers exist. You had dismissed those as only suitable for backporting. Can you justify that? What exactly is wrong with using a long term stable API whether via the native driver or an abstraction layer?
Edit: By the same logic you could argue that C89 is dead for new projects but that's obviously not true. C89 is eternal and so is OpenGL now that we've got decent hardware independent implementations.
I don't see the point of those when I can just directly use OpenGL. Any translation layer typically comes with limitations or issues. Also, I'm not that glued to OpenGL, I do think it's a terrible API, but there just isn't anything better yet. I wanted Vulkan to be something better, but I'm not going to use an API with entirely pointless complexity with zero performance benefits for my use cases.
reply