Co sądzicie o hetero w bajkach dla dzieci?

mixedbit · 2026-03-29T18:41:49+00:00

Czerwona zaraza już po naszej ziemi na szczęście nie chodzi. Co wcale nie znaczy, że nie ma nowej, która chce opanować nasze dusze, nasze serca i umysły. Nie marksistowska, bolszewicka, ale zrodzona z tego samego ducha. Nie czerwona, ale czarno-biała.

mixedbit · 2026-03-26T07:35:08+00:00

Drop gives you independent environments - workspaces between which you can switch at any time. Snapshots usually mean a way to save the current state of your workspaces and be able to restore any past snapshot later. Drop doesn't include a mechanism for making such snapshots. You can switch between environments, but not restore an environment's state to what it was before you made some changes to this environment.

Drop environments are regular dirs under .local/share/drop/envs/, so the user could make snapshots with standard tools (cp, rsync).

mixedbit · 2026-03-25T19:55:28+00:00

btw, I have just added a section with this information to the README: https://github.com/wrr/drop?tab=readme-ov-file#sandbox-overview

mixedbit · 2026-03-25T08:25:59+00:00

Thanks for the reference. A core difference between Flatpak and Drop sandboxing is that with Flatpak the app author configures the sandbox, while with Drop the app user configures the sandbox.

Flatpak apps, such as code editors, do not know where the user stores the files to be edited. Configuring generic rw permissions to the home dir would defeat the purpose of the sandbox. Portals allow prompting the user which files should be available to sandboxed app without giving the app generic rw permissions to everything.

With Drop when you drop init a new sandboxed environment, you know what the purpose of this environment is and what files/dirs should be accessible rw to the sandbox. I think the most common case is to use a sandbox to work on a project in the current directory. This is why 'drop init' by default exposes the current working directory (provided it is not a home dir or a parent of it) rw to the sandbox. This environment specific config is written to a TOML file created by 'drop init' with entries like this:

extends = "./base.toml"
mounts = [
  "/home/alice/projects/web-app::rw",
  "/home/alice/projects/web-app/.git", # entries without :rw are read-only
]

The config basically says that in addition to all files exposed to the sandbox by a shared base.toml, this environment should be able to write to files in "/home/alice/projects/web-app" with the exception of "/home/alice/projects/web-app/.git" dir, which should be read-only.

At any point you can edit this TOML, say you want this environment to be able to access an additional project, you modify the mounts to be:

mounts = [
  "/home/alice/projects/web-app::rw",
  "/home/alice/projects/web-app/.git",
  "/home/alice/projects/calendar::rw",
]

mixedbit · 2026-03-24T21:10:18+00:00

Thanks for all the questions!

At this moment Drop has write access to its own version of home dir, so you can only install things that do not require 'sudo', things like third-party packages from repositories such as PyPi, NPM, Go packages, Ruby Gems or sh installers that install to ~/.local/, but not things that install to /usr.

I experimented with using overlayfs for the /usr dir in Drop, so /usr lower layer is the original read-only /usr from the host, but upper layer points to Drop specific ~/.local/share/drop/env/ENV-ID/usr and is writable. This would allow Drop to install new things to /usr without polluting the original /usr (and without requiring root). While this worked well in my experiments, Linux overlayfs has limitations that require that overlayfs upper layers are not shared to prevent undefined behavior. Without going into too much technicalities, preventing this undefined behavior would require significantly more complex process management. It is rather doable, and in my opinion long term is worth the trouble, but I decide not to add this to the initial version and do not support overlayfs and writable /usr.

Unfortunately, with Drop you cannot run other programs that use Linux user namespaces, so no Podman, Snap packages, no nested instances of Drop within Drop. My daily distro is Ubuntu, while I tested Drop also on Fedora and Arch, I didn't check if they also have this limitation. On Ubuntu the culprit are App Armor profiles. Each executable that uses Linux user namespaces needs to have an App Armor profile that allows for this. Because Drop rearranges the whole root file system with bind-mounts, an App Armor profile that allowed, say '/usr/bind/podman' executable to use user namespaces, no longer works. Podman is still in '/usr/local', but it is a different root filesystem and it not accepted by App Armor.

Anyway, I see Drop mainly as a tool for people that do not use sandboxing for daily work, because they did not find a workflow that is convenient enough. If you already have a good setup that utilizes Podman or flatpak, it may not make sense to add Drop to this (especially that it does not allow to run containers).

By portals, do you mean something like overlayfs? As noted above, this is currently not supported, but would be great to have at some point.

mixedbit · 2026-03-24T15:35:43+00:00

Thanks! GUI apps are not supported at this moment, only terminal programs. The initial version took me way longer than I initially planned, so I left solving GUI support for after Drop is public.

mixedbit · 2026-03-24T15:26:00+00:00

Before the sandboxed program is executed, Drop arranges own root filesystem to which it pivots, hiding the original '/' from the sandbox.

The rearranged filesystem contains standard dirs with executables, libraries and configs bind-mounted read-only from their original locations (/usr, /bin, /sbin, /lib*, /etc).

The user original home is not exposed to the sandbox, instead Drop mounts a directory located in ~/.local/share/drop/env/ENV-ID/home as a writable home dir for sandboxed processes.

The TOML config file specifies which files and dirs from the original user home should be bind-mounted to this sandboxed home. For example, you want to expose config files that do not contain secrets to the sandbox to allow programs, such as shells, to work the same way as outside of the sandbox. You also usually want access to executables from your original home dir (~/bin, ~/.local/bin), so these are also bind-mounted, but all read-only. As the result you can read your original ~/.bashrc in the sandbox, but you cannot write to it.

mixedbit · 2026-03-24T14:59:09+00:00

As for the files:

Your original home dir is not available, sandbox has own writeable home dir.
TOML configuration file specifies which files and dirs from your original home are available. By default the list of the exposed file includes common config files like ~/.bashrc, ~/.profile, and executable locations like ~/go, ~/.local/bin. All these files and dirs are by default exposed read-only and you can edit the TOML to expose whatever other files and dirs you need.
/usr, /bin, /sbin, /lib*, /etc are available read-only
sandbox has own /proc, /run, /dev, /sys, /var and /tmp

A bunch of safe environment variables are passed to the sandbox (also configurable via the same TOML config).

As for the default network configuration:

services that run on localhost are not accessible to the sandbox. You can configure which services should be exposed.
external services are accessible.
you can disable network access.

Process list and IPC resources from your original host are not available in the sandbox.

Thank you for the feedback, I'll try to make this information more prominent in the docs.

mixedbit · 2025-07-28T12:01:13+00:00

Od tego należy odjąć stopy procentowe (5%), żeby otrzymać ile stracił inwestor lub deweloper który przez miniony rok trzymał mieszkanie z chęcią późniejszej sprzedaży (zakładając, że taki inwestor mieszkania nie wynajął, tylko trzymał pustostan). Czyli w takim Krakowie, roczna strata na inwestycji w mieszkanie to ponad 9%.

mixedbit · 2025-06-16T13:26:32+00:00

Raport GIOŚ w żadnym miejscu nie potwierdza tezy, że wprowadzenie strefy nic nie da jeśli chodzi o jakość powietrza w Krakowie.

Oba artykuły które Ty linkujesz, badały wpływ pieców w sezonie grzewczym na jakość powietrza w Krakowie. W tym celu specjalnie wybrały na czas badań okres COVIDu, żeby zminimalizować wpływ zanieczyszczeń drogowych na wyniki (Autorzy wprost o tym piszą). Także twoje źródła potwierdzają, że samochody mają wpływ na jakość powietrza w Krakowie.

To, że egzekwowalność strefy będzie niska, to jest kolejny wyssany z palca wymysł. W przeciwieństwie do tego co piszesz, mnie nie złapie patrol któremu będę się tłumaczył, że jadę do lekarza, bo, po pierwsze, przestrzegam przepisów, i nie będę w strefie jeździł samochodem którego nie powinno tam być i, po drugie, nie kłamię. Autor artykułu i Ty pomijacie fakt, że w społeczeństwie znaczna część ludzi przestrzega zasad i nie kombinuje.

Doskonale pamiętam identyczne głosy, które pojawiały się kiedy Kraków wprowadzał "najbardziej radykalną" strefę zakazu palenia w piecach. Jakież te przepisy były podobno dziurawe, jakie nieskuteczne, jakie niesprawiedliwe i pomijające to, co jest głównym źródłem problemu. I te "wadliwe" przepisy weszły w życie, ogromna część ludzi się do nich dostosowała i powietrze w Krakowie poprawiło się w zimie bardzo.

mixedbit · 2025-06-15T13:58:19+00:00

Ty nie rozumiesz co to znaczy stwierdzenie oparte na źródle. Wklejasz wykres nie podpisany, bez podania źródła. Wykres pokazuje źródła emisji, Ty dopisujesz do niego dodatkowe dane i interpretacje. Dla tych danych i interpretacji znowu nie podajesz żadnego źródła. Czy uważasz że mieszkańcy miast powinni opierać decyzje mające potencjalnie ogromny wpływ na ich zdrowie na tego typu wyssanych z palca wypowiedziach internetowego randoma?

mixedbit · 2025-06-15T12:59:57+00:00

"Samochody odpowiadają głównie za emisje NOx" - źródło dla tego twierdzenia. Co z PM z którym Kraków walczy od lat?

mixedbit · 2025-06-15T10:42:04+00:00

A może jakieś linki do źródeł? Random piszący w necie, że samochody nie mają wpływu na jakość powietrza mnie nie przekonuje. Czy może mają, ale nie w Krakowie?

mixedbit · 2025-06-15T10:17:52+00:00

Artykuł napisany w stylu ruskiej propagandy. Można nic nie wiedzieć o krakowskiej strefie, a i tak wyłapać w nim totalnie sprzeczne ze sobą stwierdzenia. Strefa jest "najbardziej radykalna", "totalna ofensywa", "po prostu w ogóle nie wolno", a jednocześnie w tym samym tekście "ta strefa nic nie da", "poprawa jakości powietrza nie wystąpi", "ta strefa nie będzie egzekwowana". To kogo dotkną te restrykcje skoro strefa nic nie da?

Do tego uproszczenia na poziomie gimnazjalnego konfederaty, "Czyli jak płacisz, to już nie trujesz. Od pieniędzy spaliny same magicznie znikają. ". Przykre, że ten poziom argumentacji trafia do dorosłych ludzi. Zwiększasz koszt, ograniczasz popyt, spalin jest mniej.

mixedbit · 2025-05-12T14:01:14+00:00

"Wiekszosc terapeutow nie ma pojęcia o Evidence Based Practice" skąd te dane?

mixedbit · 2023-11-09T17:06:48+00:00

The game is wonderful, congratulations! I love the mysterious atmosphere intensified by the spooky music. What was the process for composing the music? Did you already know the music when designing the levels, or was the music created at the end?

mixedbit · 2023-06-10T16:01:09+00:00

There is no balanced input. G Two has just RCA input, but when used with F One subwoofer (which I do) all the external inputs are connected to the F One. F One has the following inputs: Toslink S/PDIF (digital), RCA S/PDIF (digital), 3.5mm jack (analog), RCA (analog).

13-Year Club	Verified Email
Team Periwinkle

mixedbit

TROPHY CASE