He built it for himself first, posting frequently about it on X. Once it reached a point of stability, he announced that Basecamp was starting to transition it's employees from macOS to it.
I don't think it changes anything about what I was saying. If indeed dhh helped find a way to install hyprland more easily but failed to also provide a standalone recipe, that does not sound like a good practice to me.
This is not what I'm saying. I'm not saying that they should "solve my problem", I'm saying that their reputation should be reviewed negatively if they "create a distribution to solve a problem that has no reason to be solve by creating a distribution". Not that it is a very very bad thing, just that it shows that they are not really good at what they do.
'I'm saying that their reputation should be reviewed negatively if they "create a distribution to solve a problem that has no reason to be solve by creating a distribution".'
Why? People can do as they wish and you can use it or not.
I'm just saying that I trust people who know what they are doing, and if there is someone who does a "superficial" job* but present it as if it is the "whole deal", then they don't really understand what it takes to the whole deal and therefore they don't know what they are doing.
*: I don't mean "superficial" pejoratively, just that a "traditional" distribution does wayyyyyy more than what is done in Omarchy.
And, sure, they can do as they wish, and the consequence is that they get the reputation they deserve. You cannot say "sure, I poop in a bucket and pretend it is a good solution because my toilet is blocked, but people can do as they wish and you can visit my house or not", and I fully agree with that AND I will still say "the reputation of this guy should be reviewed negatively, as it is clear they have a low understanding of how to deal with basic plumbing". You cannot just answer me "What! How dare you to say this guy reputation should be reviewed negatively".
Its exactly what you’re saying. You have a different problem and a different opinion. And your conclusion is that „they are not good at what they are doing“
I’m really no DHH fan, but i think he knows what he’s doing and is also good at it.
The situation is simple, I'm just saying to people the following:
Whatever you call what this thing is, it does not look like the people doing it have a strong grip of what is usually considered important in "traditional distribution". If you don't care about these aspects, great for you, go ahead. If you don't even notice that these aspects are a thing or that this distribution is different on this point, then maybe it is worth for me (and others) to bring that out. Maybe for these people it is useful (and maybe it is not useful for other, in which case, I hope they will just act like an adult and don't complain that someone mention something useful for people who are not them).
I was reacting to someone saying that "Omarchy solved my problem with hyprland when no one else was able to, so it is an indication on how good of a distribution it is". I think it is the point: a "linux distribution" is there to solve a totally different problem. If you have difficulty installing hyprland, the logical solution is to provide tools to help installing hyprland, tools that can work in any distribution. If you go into a strange solution instead (such as ending up building a brand new distribution around it and saying "it's open source, you can always extract the specific code if you don't want the distribution"), then it is just natural that people wonder if you are really understanding how it works.
As for DHH, I don't know: being a good developer is quite different from what it takes to build a reliable distribution, and it looks like he is very prone to think that because he is a good developer, he is good at everything. If anything, the fact that he has no grasp at all at what people talk about when they talk about these kind of thing, it makes me think he knows even less what he is doing.
> Isn't it really obvious that a user space fs will always be slow, and especially slow with small files?
Small files seem like the perfect case for a user space fs... depending on what you mean by user space fs. If you mean interfacing with a FUSE (or similar) filesystem by using syscalls in your program to context switch into the kernel, then context switch to the userspace FUSE layer, then send it back to the kernel and then back to your program ... that will be especially slow with small files where date bytes per context switch is small. OTOH, if you mean a user space fs where your program has a built in filesystem it can access without context switching, then that will be of benefit ... especially if the files are small enough that you can pack multiple files into a single page.
If I got the article right, they were running FUSE inside the VM, and the VM's FUSE was talking to a process on the VM host (probably over virtual network). That can't be fast, not even theoretically.
Ever access to the fs had to go through two processes and two kernels, virtual networking, and probably even running on two different cores most of the time. That must be slow.
A filesystem is a database, it is a type of key value storage. there is a hierarchical lookup key that points you to an unstructured block of data.
Many databases(berkleydb, postgresql, sqlite) are then built on this unstructured database. There is absolutely nothing indicating that putting putting a key value database with hierarchical keys and unstructured blocks in a single file will be slow.
It could be, naive indexing or rebalancing could be very slow. But it does not have to be. In fact berkleydb is a neat case study here. superficially it is a ridiculously simple key value store, why does such a simple thing even need to exist, or have such a long lived presence. It turns out building the efficient structures needed to work with slow non-volatile storage is non-trivial. Early mysql used berkleydb as a low level storage engine. Note that mysql main selling point was speed before correctness.
See also: Virtual machines another ubiquitous case of a filesystem in userspace.
It's something completely different. A database like SQLite runs in the same process as the application
All the filesystem calls go through the kernel. A userspace file system is another process.
It's not like SQLite, it's more like Postgres. Try sending a few hundred thousand small queries to Postgres, and be surprised how slow it's going to be.
The file system api is not like sql that allows complex queries. It's a lot of tiny and simple requests that assume very low latency.
SQLite is in-process. A user space file system is another process. Like Postgres if we want to compare fs with dbs. And Postgres is slow for many small queries, like a userspace file system.
Quick tip for people who want to experiment with local models: A lot of the common smaller models are also available on openrouter or other services. Dirt cheap.
I know it's not the same. But a lot of people buy expensive GPUs, just to find out they have no real use for smaller models.
Openrouter is great for experimenting with models. I did exactly what you're saying to test smaller models that will run on commodity hardware and determine if it might be worth it to drop $10k on hardware. For me the answer was no, but it's close. I'm very excited for the next few innovation cycles to arrive.
Slightly off topic: What's currently the free Linux distribution with the longest support cycle?
For a while I used CentOS 7 on all of those small VMs, because it got security updates for a really long time. With minimal risk of breaking things on updates.
PS: after a bit of research Alma/Rocky Linux are probably the best choices for now. 10 years of support. But are they maintained well?
For a while (a decade+), I was running CentOS on my servers on the same assumption of long time stability and ensuing peace of mind. Then I figured that over such durations, the ecosystem drift becomes significant and keeping applications up to date and running on top of the OS becomes an increasing challenge (with the more "infrastructure" packages like glibc, python/Apache combos, GCC, ... slowly becoming incompatible with the latest applicative stack).
Then I figured that version upgrades were miserable, not just because I had painted myself in a weird corner with ungodly packages mix-ups, but because the upgrade path was always best-effort. I think I gave up during the 6 to 7 transition, as I realised that all I needed was fedora: with yearly or half-yearly updates I have no need to fight the distro's packages: stuff stays current and in working order, major distro upgrades go smoothly, downtime is minimal. I'm not considering going back to any "server distribution" ever.
Alma has a few affordances as it's no longer RHEL source compatible, which means it could ship priviledge escalation fixes with new kernel updates faster.
Rocky responded with an extra, optional to enable, security repo to provide mitigations to the exploits while waiting for RHEL to downstream.
Look pretty well maintained to me. If only judging by recent events.
Rocky's docs are also really nice. They aren't as thorough as RedHat's, but they're much more readable and concise, and tend to be written for a less enterprise-y audience.
Content wise the RedHat docs are great, but navigating the doc has a wired feeling that is hard to describe. Everything is black and white, the page has low information density perhaps because of the line space or paragraph space; the typesetting of command line and configure examples is not clear separated from surrounding text; mouse cannot select text of the command line examples; the page top is distracting because it keeps showing and disappearing as mouse scrolls up and down. Somehow the left navigation pane is also difficult to follow, easy to get lost when trying to find a section.
I don't care much about being fully RHEL compatible, or no ABI changes at all. I just want a system that gets security fixes quickly with as little chances of breaking things as possible.
How about a lightweight immutable distro, like say Fedora CoreOS or openSUSE MicroOS?
Fedora CoreOS in particular has had a good track record delivering patches quickly. Like for CopyFail was pushed to the stable channel in about a day, IIRC, but the patch was already available within a few hours of disclosure in the "next" / testing channel.
Talos and Flatcar are also worth considering if you want an even smaller attack surface, from what I heard they weren't even affected by CopyFail.
This oversimplifies reality. Fedora has a community and actively makes decisions RHEL has no interest in. But yes they also help with testing many things.
I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs.
Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cockpit and deal with it whenever I have time.
>!!!I see no reason not to go with a rolling release distro!!! for personal servers. Run all the services in containers and !!!have the base OS auto-update itself as often as it needs.!!!
There are things that need 9^5 and there are things that don't. If someone backs up their application configs and data properly, then the only thing that really matters is a proper backup strategy.
All my critical files are backed up periodically (manually) via rclone to S3 glacier, and all my services are documented in dokuwiki. If you use ansible or want to store configs and installation scripts, a private git repo would do well.
After that, I don't see a problem running rolling or short-support OS like Fedora Server for application hosting.
Great. I like my personal servers to just keep working. Without having to restore backups. And without having to spend one Saturday every month to update and fix all the servers.
I have around 20 "personal toy servers". I really don't like to fix them all the time.
Most of them are some small VMs or some Rasperry Pis controlling something. I want minimal changes on those systems, but still being able to update them.
Then you also have to auto-update the containers, if it's a public facing service. Either you'll have to build containers yourself or hope the developer pushes a new update whenever the base image has relevant security fixes.
You are betting that whatever you host doesn't live as long as the upgrade cycle because it'll probably be a pain when the upgrades finally arrive. I'd rather have smaller version jumps more often than a huge jump with everything changing after a long time.
It usually doesn't live until the end of the support cycle. And if it does I will probably migrate it to a fresh VM instead of upgrading the distribution.
I'm not worried about upgrading. I'm worried about the whole environment being potentially several versions newer than the old one. All shared libraries. All services. Everything new. And now you have to make a software that has had little upgrades run on that. Have fun.
Completely agree. A fresh install beats an in-place major version upgrade every time. Less hazardous and gives an easy path to clear out all the accumulated crud.
Probably Debian or Ubuntu. The question is...why do you care that much?
I've upgraded Debian stable (both pure and with some cherry-picked backports) and Ubuntu (non-LTS and LTS) systems in place and rarely broken anything, for years and years. When stuff has broken it's been a quick google and then slapping myself for not having read the upgrade guide.
I do generally wait about 2-3 weeks before upgrading, giving time for them to catch stuff that was missed until the great masses were set loose on it.
Not the OP, but I support Ubuntu as desktop and server OS for an engineering collage and have for 10ish years. Some LTS upgrades don't require many changes (mostly minor package name changes) and some take months of work to get rolled out (mostly for workstations, the server upgrades are usually quick.). Not everything gets upgraded every new OS release. If we had to upgrade everything every 6-12 months it would eat up a significant amount of time for our small team.
Only using ubuntu rn, but when the server is mostly running docker, it is simpler upgrade nowadays with so little dependencies. But then the problem just moved to the container image updates.
I have a machine that has been Fedora since twenty-something to current 44, and upgrading yearly is a breeze. Three commands, and just wait for a download and the reboot. The only thing that breaks if you forget that the upgrade needs attention is the system Postgres, until I migrated to Podman images.
I recently upgraded to Fedora 44 from Fedora 43 and I wouldn't say its a breeze, it can be difficult, especially if you've enabled extra repos.
If you use Copr (Nvidia Drivers, Non-Free Stuff) you need to ensure all your Copr packages work fine in the next version of Fedora. A ton of packages haven't been updated for Fedora 44 and this will cause issues.
I've had issues with Ubuntu/Debian upgrades more than once. Some third party binaries breaking with the update. Or some specific config tweaks that break, because the structure of /etc changed too much.
For some small VM with a specific purpose I prefer a distribution that changes as little as possible for as long as possible. Less work, more uptime.
I won't touch ubuntu unless forced to by some obscure work requirement. I've had enough bad experiences with repos being shut down, updates/upgrades breaking unanticipated, obscure things, and I hate snap.
The naming conventions drive me crazy as well. When you deal with 2 things that have dumbshit naming conventions, like ubuntu and ROS, its really obnoxious to pretend to case enough to keep track of.
Ive had nothing but issues doing that. I think I’ve had a Debian upgrade actually succeed maybe one time? (After some manual intervention to fix some issue other booting on my work server)
For updates, Debian and Ubuntu are great. For upgrades… not so much for me.
Alma and Rocky if you want fully free or have a lot of machines. RHEL if you are okay with registering with them; they give ten machines free access to their updates for each Registered account in their system.
RHEL is definitely the most stable major distribution. Alma and Rocky are essentially downstream clones of RHEL.
I'd say not much: you update the channel, run nixos-rebuild switch, fix all the warnings/errors due to renamed/changed options until it succeeds and you're done. If you have a database like postgres you may have to do a schema upgrade manually, since the default version is updated every 4/5 releases or so.
It's very rare to find something that prevents you from directly updating. Nixpkgs tries very hard to no require new Nix features, so it evaluates with even Nix versions from a decade ago. Also, NixOS options and packages are frequently changed, but the automatic migrations (mkChangedOptionModule, mkRenamedOptionModule, alias, etc.) are never removed in practice.
Since the binary cache has never been cleared since its creation (2002?), it should actually be easy to install a super old NixOS release and upgrading it to the latest to see what happens.
By the way, there are LTS versions of NixOS, just not officially supported. See https://docs.ctrl-os.com/.
And when it happens, that there are new Nix features used in Nixpkgs, then you can download the closure for the new Nix executable, directly from the build farm, and update your OS from this new Nix version.
> a rolling release like NixOS is exactly the opposite of an LTS distro
NixOS is not rolling release. This is a common misconception. You can use the unstable channel, which is a rolling release, or the regular channels which get released twice a year. These are really stable and move very slowly. You can also mix and match, running software from different channels.
> I actually wonder what would happen to a NixOS installation frozen in time for 5 years that then you want to update to latest all of a sudden
I have done this recently as I kept an airgapped machine, which I decommissioned, connected to the Internet and updated to the latest channel. Everything worked just fine. I just had to change a couple of options in my configuration which had become outdated. Nix is functional, so it's much less prone to all stateful issues that plague other package managers.
Technically it's not rolling but you get substantial updates during the stable channel lifetime, unlike Debian or Ubuntu. And when the stable channel is deprecated (every 6 months) you need to manually change it and get a bigger version bump of most softwares all of a sudden. There is no LTS concept where you can leave almost on autopilot a distro version for 5 years.
Earlier today, I tried to run a simple nix tool a colleague made. 3 hours into the build, it crashed. Something about a missing python import? I ran the exact same ‘nix develop’ again. 2 hours later, it worked.
Keep in mind: this was just a simple rest server. But for some reason it needed to (nondeterministically) build the word from scratch to send that single request.
I've only been running NixOS (in any serious capacity) for three years, but I have installed it on every computer that I am allowed to install it on now.
It has been the most headache-free Linux I've used, simply because I'm less scared to play with and fix stuff. The fact that rollbacks are trivial and snapshots are automatic, and since everything is declarative in a text file anyway, I am way braver. If I do something like screw up the video driver, or the wifi driver or make it so the system doesn't boot anymore, all I need to do is reboot and choose a previous generation.
> simply because I'm less scared to play with and fix stuff.
The main reason of a LTS distribution is not having to play around and fix stuff. Install something once, and it keeps running without any changes, but still gets security updates.
Yeah, but I find that particularly with laptops, even with LTS releases, there's almost always something you need to fix.
For example, there's a weird quirk with my laptop that if I am using a USB keyboard and stop typing for more than a minute, it "powers down", and if when I start typing again it misses the first four or five characters, which is very annoying.
The solution involved putting a few boot parameters and then it works fine and as expected, but I would be reluctant to do that with Ubuntu or really any non-NixOS distro, because if I screw up a boot param I get into a situation where the computer won't, you know, boot, meaning I'm stuck screwing around with grub commands and trying to fix things, which is annoying. With NixOS, if I screw things up it's like a minute of rebooting and choosing the old generation.
Not to mention that if you have a non-declarative OS, it can be hard to know what exactly is on the computer. When I ran an Ubuntu LTS server, I eventually had installed dozens of packages that I don't think were being used but it was hard to know for sure which ones were necessary and which ones weren't. When I'm using NixOS all the packages are unambiguously in the configuration.nix. "Uninstalling" a program (including its transitive dependencies) is just removing that package out of the configuration.nix and rebuilding.
I have nothing against LTS releases, but I do think that at least for laptops (which can have kind of arcane hardware quirks) it's better to use NixOS.
I would never put a LTS system on a general purpose desktop.
This would only make sense for some corporate environments, where the hardware purchases are aligned with the driver support of the LTS distribution. And even then it's questionable.
LTS distributions are mainly used on servers or on (network) appliances.
I run nixOS as well on my home infrastructure (gateway/firewall, a couple of internal servers).
But I have had, uh, non-trivial breakages happen also when I upgrade the system itself to the next yearly release. Non-bootable kernel kind of breakages.
But I will give you that I can just boot from the generation before the upgrade, and it works again. So there's that :)
I have run NixOS for about eight years on server and desktop and been a nixpkgs maintainer. Yes, most of the time I would agree with you. The fact that you get warnings in the terminal for a lot of incompatibilities and changes when upgrading is a really nice touch and upgrades tend to be smooth. I do not use rollbacks much, but when you do need them they are really handy. Having every configuration in a single file makes you more bold to play around with configurations, which felt really empowering when I first got into NixOS, as I knew it could roll things back and I no longer had to keep notes on how each box was set up to refer to in the case of a reinstall or migration.
However, I have had one machine become unbootable as it could no longer mount its encrypted disks after an upgrade, forcing me to mount a rescue image remotely, mount the disks manually, lift the data out, and do a complete reinstall (migrated the box to OpenBSD at that time). Similarly, NixOS once messed up systemd (or vice versa) so badly that I could not even reboot without forcing a power cycle. Lastly, I have had a package break for my use cases by maintainers enabling so many custom flags by default for a package that they enabled one I have never seen enabled by any other packaging team and that then broke RTSP in "funny" ways. Ubuntu did tend to break things like graphics between releases at times back when I used it, but I have never had any other distribution or operating system throw curve balls like the three things I mentioned here.
My general impression of NixOS is that the core is solid, but that nixpkgs just has such a large number of things that it supports that the maintainers struggle to test them all and can not anticipate the interactions between all the packages and options. The default Julia package being so broken that it produced incorrect mathematics due to nixpkgs' insistence on allowing you to swap out the Blas library and also having turned off the unit tests for example springs to mind. This was shipped to end users for a long time before I noticed it by accident by enabling the unit tests and stepped in to clean it up. It all feels very "Gentoo", which was indeed an inspiration for NixOS by the way.
Now, return to that last sentence in the first paragraph that I wrote about feeling empowered to tinker, ultimately, I feel like you should try to resist that urge as it is what pushes you into the untested fractal of possible configurations that NixOS allows you to explore. My other main operating system is OpenBSD, where the mentality is "Stick to the defaults or suffer the consequences"; with NixOS, I feel like everyone's box is more or less a tailored suit, which comes with both its ups and downs.
Eh nix flakes are a nightmare to configure. Far more verbose than a docker compose. They rely on some caches which keep pre-compiled packages and you better make sure you have the caches with the particular flakes you need set up. Yikes
5 years is not a lot. It releases every 2 years, so it requires upgrading at least every 4 years. In the worst case it's just 3 years of support, if you install right before the next release.
ELTS is 10 years and paid. It's great that it exists, but not relevant for my toy projects.
I feel there is a balance to be struck between a project that is popular (where if you run into problems, you will get good support), and one that technically gives longer-term support (but if things go wrong, that support might not be very good).
I haven't used a lot of different distros, but for me, Debian has been a good balance of those factors. You may need to do more upgrades per decade, but the ones that you do are more liable to go smoothly.
I don't work on a server team, but in network/network security. My company made an announcement that they are extending our product's software lifetime to four years: 3 years standard support + 1 year high sev patches.
It seems to me in the 2020s that 5-7 years is plenty of support for a single OS release, and that OS support teams should be nimble enough to roll out new instances and migrate data at that cadence.
So there is a project that you care enough about to keep it alive, but 1-2 hours every FOUR YEARS is too much? At some point I just have to call you lazy dude.
Either the 1-2 hours is a drop in the bucket compared to what you spend on it anyway (like a blog you still regularly update), or you don't actively update the project but still care enough about it to spend half an evening every few years, or you should just admit you don't care about it enough anymore to do even that. In the last case just delete the project.
> So there is a project that you care enough about to keep it alive, but 1-2 hours every FOUR YEARS is too much? At some point I just have to call you lazy dude.
I want the machine that serves my static blog pages to have, ideally, 0 maintenance.
It needs to do one thing, serve some static HTTP pages and have new pages pushed to it.
Quite frankly I wish some of those "minimal docker first OSs" had taken off.
If you want 0 maintenance, then you don't want to run your own infrastructure. Go give NearlyFreeSpeech or some other shared host a few cents every month and you'll be much happier.
But then you have constant maintenance. I prefer rolling distros, don't get me wrong. But it does mean you will get the latest of every package constantly and some cause problems.
For a box that sits in a corner doing its joband you don't want to pay attention to it's not a good choice IMO. On a desktop you want the latest of everything on and you have time to keep up it's the best.
I need to enable automatic updates, because I don't have the time to manually update. I have a few machines on Open SuSE Tubleweed, and stuff just randomly breaks. A few months ago there was a weird Kernel bug that just froze all of them. They update and reboot every day, and suddenly it all worked well again. A bit too exciting for me :)
You can always try openSUSE Slowroll (in beta), which is a rolling release that updates less frequently than Tumbleweed. It advertises better stability.
I have a friend who doesn't have a sense of smell since birth. It's more of a problem than one would think.
His diet is rather plain, and he doesn't enjoy a lot of food. It's mostly meat, fried things and sweets he enjoys. Most vegetables and low-fat dishes he just can't enjoy at all. Luckily he doesn't get a lot of pleasure from eating and that's what keeps him from getting obese.
It also gives him a lot of anxiety that he or his clothes smell bad. He often just can't assess it from other clues. He often needs to ask people to smell him during the day, which leads to some hilarious situations sometimes, but it's not by choice. It's driven by the fear of smelling bad and not realizing it.
It can also get dangerous in some situations, not being able to smell a gas leak, only noticing smoke once it got so thick it will hurt when breathing, and not being able to smell when food goes bad.
>He often needs to ask people to smell him during the day, which leads to some hilarious situations sometimes
Smell and taste seem to be the last two senses/modalities we can't really work with using technology. Vision (cameras) and sound (microphones) have existed for a long time but it's only within the last decade that they've become ubiquitous in the form of a smartphone, and only within the last 5 years that ML is good enough to work across them (ocr, stt).
But for some reason (maybe lack of easy commercial opportunities) we haven't even come close to making "artificial noses" to record raw input. Maybe as part of the push for "embodied humanoid AI" (e.g. Figure) we'll find a way to do that.
Two notes on this - one is that smell and taste are the earliest senses we have. The first thing organisms began to sense about their external environments were chemical gradients, and that’s in essence what smell and taste are doing.
The second is that what they’re doing is _fantastically_ complex from a physical standpoint compared to sight and vision - sight is the detection of photons of various wavelengths and energy levels; hearing is the detection of vibrations. Smell and taste are molecular docking problems: they are the detection and identification of the actual structures (or at least substructures) of molecules. The closest we have to that is mass spectrometry, which basically involves flinging molecules hard enough to break them and weighing the parts.
Ironic, since they are the oldest senses. The very most primitive cells can do chemotaxis, which eventually evolved into the chemical senses. But it also means sensing chemicals instead of energy, and it's harder to replicate mechanically.
>He often needs to ask people to smell him during the day
tell him to use Dry Idea antiperspirant (I'd say unscented), the stuff blows anything else away. no need to thank me. (no I don't work there, long term user who ever now and then runs out and is reminded how good it is)
what's up with vegetables though? I love vegetables, but if I were asked what was the thing I least liked about them, I'd say "the smell"
> It can also get dangerous in some situations, not being able to smell a gas leak, only noticing smoke once it got so thick it will hurt when breathing
I can smell just fine but I still have carbon monoxide and smoke detectors in my house to alert me if I am asleep and there is a gas leak or fire.
I wonder how the anxiety developed, I would think they would not be self-aware given they cannot understand it, so maybe they were bullied as a kid by smelling bad once and it created traumatic memories for him as it's sort of an unexplainable thing to his nose.
I can't smell much at all. one time when i was 17 my friend told me i was kinda smelly (i had just exercised). I've been stressed about it since. the human brain can latch on to the oddest things
I had loss of smell for 4 years after covid and developed similar fear. It is not because of bullying, but from constantly having "what if" you can't answer yourself.
What about drizzling the veg with some olive oil (or even lard), salt and a small pinch of sugar? This is what restaurants do to make veg more appealing (plus some acidity)
Better than subsisting on fried food and sweets - take the fatty and sweet element from that and apply to veg
My mother lost her sense of smell after surgery for nasal polyps in her teens. She was mortally afraid of fire breaking out in the night and not being able to smell it.
Maybe not reassuring at all: but we can't smell a lot while we are asleep. A bad smell won't wake us up. That's why fire alarms exist, noise (or bright light) does wake us up.
I've woken up at night to investigate weird smells. Maybe the smell didn't wake me up, or maybe it didn't wake me up quickly, but I smelled the smell as I was waking up and then did the find the vaguely burning smell game. Last one I remember was a neighbor's bonfire left going when they went to sleep inside.
My dad lost his sense of smell after having surgery for his meningioma. According to him he doesn’t even notice a reduction in the quality of his life. I asked if food tastes worse and he said he hadn’t really thought about it and no it doesn’t. It really is the least of the senses.
Having lost my sense of taste during a bout of covid I would say he’s absolutely the anomaly - or he only partially lost it. A complete loss of smell and taste is impossible to ignore. Imagine standing in the direct path of a bonfire and not noticing at all until your lungs start to hurt. You can’t not notice it.
I think people are different (also he only lost his sense of smell, not taste). It’s all about perspective. If you didn’t know that a lack of smell affects flavor you might not notice. It probably also helps that he is Asian and Asian food is significantly more flavorful.
When I had covid I noticed a difference in how food tasted but it was kinda irrelevant. Food still tasted very good. It might be genetic or something as well. For instance, I can have a double shot of expresso and go to sleep 30 minutes later.
Anosognosia is relatively common following different causes of brain injury
The condition does not seem to be directly related to sensory loss but is thought to be caused by damage to higher level neurocognitive processes
This was 15 years ago, but he seemed to have all his faculties in order. The major change we saw was for about 3 to 6 months after the surgery he would lose his temper at the slightest thing. He was basically impossible to live with and then all of that just went away and he went back to being very normal.
Is a container breach really the relevant problem to solve for agents? VMs provide better isolation, that's true. But does it matter?
Even sandboxed agents usually have a lot of capabilities. Adding backdoors to code by installing breached packages, abusing some access tokens to cause harm, and much more.
> Adding backdoors to code by installing breached packages, abusing some access tokens to cause harm, and much more.
But it doesn’t mean stricter isolation (ie separate kernel space) is a bad thing. One less attack surface in other words. It’s 100% relevant and matters.
So the purpose of Omarchy was to get devices quickly set up with some opinionated defaults.
reply