any number of reasons: language barriers, existing American firms anti-competing, smaller domestic markets, less centralisation, and, yes, in some cases, regulation, but, when it comes down to it, it's better to have smaller firms that don't (or less frequently) damage society than larger firms than do, even just from the perspective of wealth distribution.
I think he's saying that, yes, this regulation means that your own companies are more ethical, but European consumers end up using these less-regulated American companies anyway. this is true, but this problem has started to be solved by the EU anyway, for example, with the Digital Markets and Services Acts
Entity formation time; time and capital required to hire the first N employees; number, cost and time of licensing required before first sale can be made. Each are higher in Europe. Combine that with the multiple languages and regulators which inhibits scale and you get the present situation.
Which, I will note, is fine. It’s optimised for stability, not wealth. On the other hand, it naturally means having to choose between American and Chinese tech giants.
> Entity formation time; time and capital required to hire the first N employees; number, cost and time of licensing required before first sale can be made. Each are higher in Europe.
Which Europe? All of those can be done online with minimal effort or upfront investment in many EU countries. Do you mean Belarus?
> Combine that with the multiple languages and regulators which inhibits scale and you get the present situation.
This is true, because the EU is composed of 20+ different countries, each with different languages, cultures, histories, priorities. It's impossible to remove that boundary.
> All of those can be done online with minimal effort or upfront investment in many EU countries. Do you mean Belarus?
Each of them can be done online in most countries. All, very few. I think only Estonia comes to mind. (At least one form in that process requires visiting a notary in most of Western Europe.)
The cost of terminating an employee is also a unique risk that European firms have to capitalise for which American start-ups do not. Again, I understand why one would choose this stability. But it comes with a cost.
> It's impossible to remove that boundary
It's absolutely possible by mandating a lingua franca. But it would cause irreparable damage to those cultures, which is why the EU--sensibly, in my opinoin--has chosen to preserve them. But this is a choice and it comes with costs.
The US had an entire decade of war on cryptography that was literally required to safely transact on the internet, and yet the 90s had plenty of online store startups.
Granted the chat control issue, is unfortunate on the privacy front, however I wouldn't call it a hindrance on innovation.
IMO, often innovation happens because it is motivated to work around rules and regulations. So in many cases regulation and rules are what drives innovation. People want to hack the system and thus have to innovate. A completely hacked and open system doesn't really inspire new ideas, because the old ones just work fine already.
The title is kinda odd. "Lowering resource usage of foot with systemd" sounds more appropriate.
Not knowing that foot is a terminal emulator, I assumed that foot is some kind of improved resource manager that allows for a general lesser resource usage.
// Define variables
let name = "John"
let age = 30
// Display a greeting
echo "Hello, my name is {name}"
// Perform conditional checks
if age < 18 {
echo "I'm not an adult yet"
} else {
echo "I'm an adult"
}
So there is no input, everything is known statically. No sanitation required. Any additional checks done by amber in the bash code is unnecessary.
It isn't even pure bash, if it uses external commands like `bc` and `sed`. It should probably limit itself to posix shell (or bash, if they need to) and coreutils.
They are only listing `bc` and `bash` as a prerequisite, but the example uses `sed`, so this is also not complete. So a full list of all required tools would be the first step.
But I am working on embedded systems where I write lots of POSIX shell scripts that run in tiny initramfs, etc. so I am very picky with my dependencies. If I had a better language to target busybox, that would be welcome as well.
I tested this a bit now, because I was curios, so it also requires `sudo` for the installation, installing it as `root` or as user with write permissions to `/opt` will not work and causes the misleading error:
Please make sure that your user can access /opt/amber directory.
Creating this directory, either manually or by the script before it fails to download amber, will cause the installer script think that amber is already installed. So not a very high quality shell installer script for a tool that generates shell scripts.
My only fear is that every vendor will now have to implement secure boot and other mechanisms in order to make sure that only signed software runs on their devices, while providing no way for the customer to take ownership of the device back, so that they can run their own software.
I really hope that we eventually get a mandate so that every device, that requires an internet connection for any and all features, will also have to allow the customer to overwrite and use their own software in case they have to make any software/security repairs themselves.
Strict launch integrity (unlike "secure boot") depends on a customer-defined root of trust. OpenCompute (OCP) Caliptra is an effort by hyperscalers to enforce a platform root of trust with OSS firmware, mandating dual signature by server OEM and hyperscaler customer. The platform RoT is responsible for validating device firmware and OS boot.
> Often we see.. great security.. compromised by other great ideas for mgmt and other things.. starts to weaken its security posture.. want to keep Caliptra very clean [via OSS firmware transparency]
Isolation architectures like pKVM on Android can run banking or wallet applications in a security-controlled VM, alongside arbitrary user-defined VMs. In contested environments, both security and the freedom to innovate are necessary to survive an arms race with a competent adversary.
Personally, I have more trust in open source software than anything the vendor puts on their devices. But very often either the vendor software is only allowed to run, or you have to disable secure boot to run your own software, weakening your security.
So I would like to have a process where the actual end-user and owner of the device is the root of trust, and then transfer that trust to the vendor software or to their own software if they so choose, instead of having the manufacture, vendor or some agency be the root of trust. Of course, it can come with a sensible setup, where the vendor is already trusted, but that trust should always be revokable.
There should also be a way to remove or transfer the ownership to another person, if the device is sold.
pKVM goes in a different direction, where software that is run, does not trust the host system, which IMO is not very nice. Trust is something that goes both ways and need to be earned, if I put trust in a software and install it on my system, then I assume that the software also trusts me. If the software doesn't trust me, why should I trust it?
If there is no trust between us, then it should not run on my system but on someone elses and let me communicate with it via a well-defined API we can both trust.
I would love to see a Linux distribution picking up on the concept of NixOS, with its content-addressed-package store and then use overlayfs and bubblewrap to create process local FHS compatible root file systems with only the dependencies of each process inside.
Well, both Guix System and NixOS can do this, where they construct a containerised environment with FHS layout. IIRC neither uses overlayfs and they do the namespaces by themselves instead of relying on Bubblewrap, but inside the container you get exactly what you'd expect.
At least in Guix it's `guix shell -CF`, where `-C` is of course the `--container` flag, and `-F` for `--emulate-fhs`. I'd imagine that `nix-shell` works the same way, but I'm more familiar with guix than nix, so I can only speak for that.
I only ever tried NixOS, but the FHS stuff there seems to only be about getting Steam and other proprietary software to work. I would suggest to have this per default, so that the only application that actually sees the real file system would be PID1.
That is an interesting idea, but I don't really see what the purpose would really be.
As you said, having these kinds of FHS containers really is only actually useful for proprietary software, with free software being adaptable for a "non-standard" filesystem. Of course, it's sometimes helpful to do this even for free software, which is of course why this is an option, but I do struggle to see what would be the idea with making it the default for all non-PID1 apps in such a system.
All I could really reckon is that it might be easier for user familiarity, but at least in my experience, one gets used to the new layout pretty quickly. You'd ideally be configuring the whole system in either Nix language or Scheme anyway, so things like `/etc` are a bit superfluous, and since you can get `/bin/sh` and `/usr/bin/env` symlinked for things that expect it, most things should work anyway. Well, unless done poorly, but nothing one couldn't patch.
In NixOS you have only one central package store `/nix/store`, so all packages need to be installed there. This is necessary, because the software is patched to use that path. IMO patching it this way is a bit hacky, when there a better options.
If overlayfs is used, the software would not require patching, so you could have multiple package stores if you like. Maybe a package store in `~/.nix/store` as well. This would allow with a immutable rootfs (e.g. immutable `/nix/store`) to still install packages per user, or even per project a different package store.
But I've been using Atomic Fedora for the last 2 years and my whole work flow has shifted to using containers for everything CLI, I can have specific container images for work on qemu images, or terraform for example. And everything else like Steam games, VLC, Firefox all run in Flatpaks.
So the end goal is to not make any modifications to the host image.
> So the end goal is to not make any modifications to the host image.
IMO the goal should not be to have a immutable host image, but to have a immutable rootfs of each process. Immutable host base images might contain libraries or software that is not required by the application, they are more difficult to update, because they need to be updated as a unit, and probably require a reboot.
To make this stable, you need to hack around with A/B partitions for a fallback. IMO this would not be necessary if we had every package just installed under its checksum under `/pkgs` or what ever, an then use overlayfs to create a file system customized for every process. All that is required here to revert back is the old 'profile' and then start the old packages from the `/pkgs`. Like NixOS does it.
However NixOS doesn't use overlayfs, they use symlinks and patching of the paths in the sources to archive it.
Using overlayfs would also allow changing the package path (`/pkgs` here, or nixos package store `/nix/store`) at runtime, because the software would not require patches, so people could install an additional store in their home directory for instance.
Sounds like you're leaning more towards the Qubes OS model, even though I'm sure you don't want to go that extreme.
Either way I'm very happy with Atomic Linux, it's a huge improvement. I'm sure there will be more improvements that will offer separate rootfs for each process. Isn't that already handled by running flatpaks in their own container root?
> Sounds like you're leaning more towards the Qubes OS model, even though I'm sure you don't want to go that extreme.
Qubes OS is full virtualization. I don't want to boot a separate kernel for every process I want to start. That is not very useful.
> Either way I'm very happy with Atomic Linux, it's a huge improvement. I'm sure there will be more improvements that will offer separate rootfs for each process. Isn't that already handled by running flatpaks in their own container root?
As the article here says, not all apps can be used as flatpak.
Currently flatpak is mostly for GUI desktop apps, most common cli tools are missing. For instance there is no gcc flatpak.
Also the layers under a flatpak are not separated by individual packages but by broader runtime environments, thus they contain more stuff than each individual application requires. I want a system that could even be deployed on a small embedded device, because it is so generic.
I have containers for everything CLI. Like I'll have one specialized for build tools, one for manipulating qemu images, one for Terraform/ansible and so forth.
I even build cargo packages in a container, install the binary, and then run it outside the container.
> As the article here says, not all apps can be used as flatpak. Currently flatpak is mostly for GUI desktop apps, most common cli tools are missing. For instance there is no gcc flatpak.
I would consider Fedora Silverblue/CoreOS, NixOS and even flatpak as a sort of hacky way to implement that. I don't know of any PoC for this. I would guess that there might be some research budget available for that approach.
I owned a Kobo Glo and Pocketbook Touch, and I preferred the Pocketbook, because it allows to install koreader as a application into the stock firmware, while on Kobo you need to quasi dual-boot your system into koreader or stock firmware via a menu.
In my experience koreader integrates much better with calibre and allows managing my library with a filestructure. So that is a requirement for me.
Also the stock firmware on the Pocketbook was able to deal with my huge epub archive, because it didn't require indexing the library on the device, which Kobo struggled with.
From that experience I would pick a Pocketbook over a Kobo.
IMO Kobo is absolutely built to be a "better managed library experience" than kindle - but as you say other platforms are better if you have a large non-drm'ed library. Unless you plan to buy books from publishers / use the overdrive (now Libby) system, I do think a more user-focused offering like Pocketbook will be better.
I think this is a place where some regulation could do a world of good. I wish I could buy any ereader I want and shop at any bookstore I want. I wish publishers were forced to respect first sale doctrine on digital goods.
I fully agree! I'm also disappointed (but not surprised) that kobo (or some other 3rd party epub seller) hasn't created an API where you register a key pair (or whatever) and can decrypt books on your devices. I suspect it's based on publisher demands. Ironically, this is one place where a blockchain might be useful - sales are recorded on it, contracts are written with respect to it, and if the publisher goes belly up users can run nodes to maintain it.
There are multiple ways to install Koreader now. I think the most common is to use KFMon and NickelMenu which installs the quasi-operating system into a book in your main menu.
I am a bit disappointed. I though this was about the Linux perf tool and would make a point that better tools are required while providing some suggestions.
All I got was a piece that more or less states that generic benchmarks are not as useful as one might expect and that other stuff is important too. Which TBH is not really that surprising...
Perf is very powerful but indeed can be hard to get good information out of. Try pprof and read a bunch of Brendan Gregg’s articles about perf (and bpftrace).
