• 0 Posts
  • 60 Comments
Joined 1 year ago
cake
Cake day: June 4th, 2025

help-circle








  • Pretty much every response you get is going to be telling you to go and see a doctor, because that is the next logical thing to do. You don’t need to tell them you think your neighbour is causing it, just that you’re feelling this imbalance, and describe the symptoms.

    There’s a variety of things that could be causing these sensations, and you’ll need to rule out the obvious ones first.

    Vertigo could give you these sorts of sensations, and can be triggered or worsened by stress, which you’re clearly feeling, as well as a variety of other medical issues, which your doctor should investigate. Things like an inner ear infection can be treated, but it could also be a symptom of something more serious, such as a mimor stroke or other damage.

    Another aspect to check is your physical environment. Make sure you have a carbon monoxide alarm properly installed near any appliance that burns fuel, and also get your hone checked for gas leaks. Both can cause unpleasant effects, and both are very dangerous too. Get your electrics checked too, as something wrong there could also be causing an effect, like buzzing at a high frequency, the manifests itself in weird bodily sensations. Whilst you’re at it, check your neighbourhood for any new industrial or manufacturing that might be releasing noxious fumes. Walk around and smell for any gas leaks outdoors too, just in case.

    If you’ve ruled out physical health concerns and environmental issues, the most probable cause is psycological. To be clear, this doesn’t make the symptoms any less real, or suggest you’re just imagining them. Stress, and it clear that you are very stressed by the situation with your neighbours, can manifest in a variety of unpleasant ways, including the sorts of symptoms you’ve described, and worse. Talking to a mental health professional would be a good step to helping you deal with all of this, even if it’s not a reaction to the stress of the unplesant situation you find yourself in with your neighbours.

    Whatever the cause, I hope you manage to resolve it.


  • A big problem is that vibe-coded stuff tends to be much harder to maintain as the ‘author’ diesn’t actually know how it works, and the code was not built for humans to understand. That’s not a problem that’s unique to LLM generated code, but it is common place in code that is, so “was this generated by LLM/AI” becomes a useful proxy question for “is thus codebase likely to be harder to maintain, and thus be less likely to be maintained well?”

    There’s also the sociatal level costs of using these models to consider. At present, they use significant amounts of power and cooling, both of which lead to adverse environmental effects. It serms quite appropriate to ask if a project using them, and to make the choice to avoid those that are, out of principal as well as technical concern.






  • It may be getting a second opinion from a differrnt optometrist, and make certain you are visiting one who can scan the shape of your cornea. If that is slightly out of round (for instance, a condition called Keratoconus) you’ll find that glasses can’t completely correct it, but hard contact lenses can.


  • It’s goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.

    Amutable’s approach is a bit vague, but their homepage states: ‘We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time.’ I read that as starting in a trusted state, presumably via a secureboot verified bootchain, then ensuring that the software running on the OS is in a ‘trusted’ state at all times. In particular, they also say “Build integrity, Boot integrity, Runtime integrity, That’s Amutable” as a tag line, which reinforces the runtime nature of the validation.

    What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.

    I could have been clearer there, I’m referring to OS vendor or distro maintainer. Someone has to be in control of what is “trusted”, and it’s either the administrator of the machine, or the OS vendor. If it’s the administrator of the machine, a malicious actor has an attack route to update the list to include their own malware, and if it’s not the administrator you end up in a Android type situation, where the OS vendor decides.

    But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.

    Secure Boot secures the boot chain, but after that has no part in maintaining the integrity of the system. I agree that it would not make sense to make this some sort of DRM like system, but that does not mean that they will not try. Pottering seems to have the ears of people who are influential enough that even his bad ideas get far more traction than they should.

    And distros already control what you can and cannot do by how they choose to build the OS.

    Not really, they might make some things naturally harder to do, but they all run the same kernel and can load ELF binaries. Even the most locked down, immutable, system can be made to do things the distro maintainers didn’t expect.

    My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don’t need to worry about the software being signed with some third party’s key to boot.

    Indeed, verifying the boot chain does not, necessarily, limit what the admin if the machine can do. My concern is that Amutable seem to be seeking to go a lot further than that, and verify what is being executed at runtime. Depending on who controls the keys we may, very well, “need to worry about the software being signed with some third party’s key” if not to boot, then to run.


  • It really isn’t. It feels fancy and like it does allsorts of clever stuff, but actually what you have is a massively over complex architecture, a non-deterministic (or perhaps a better term would be unpredictable) boot order, binary logging, excessively verbose configuration, and still some fundamental bugs in important daemons. You can fix almost all of that, but you shouldn’t have to. We had a solid, simple system before, now we have an over complex mess.


  • The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective. If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now.

    Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution, takes years to implement, and doesn’t actually provide much or any benefit over what existed before. Any benefit that does occur tends to be the sort of thing that could easily have been added to the previous system, but noone had because it wasn’t actually a pressing concern. One need only look at his history with PulseAudio and systemd to see examples of this. He also tends to be quite rude and dismissive to anyone questioning him, or pointing out architectural issues.


  • I’m with you on that, it’s massively over complex, intrudes into systems it has no place in, and has way too many bad design choices. The designers made the fundamental mistake of wanting it to do everything okish, rather than one thing well. The worst part is that pretty much everything people poibt to as benefits could have trivially been added to tools like sysvinit and rsyslogd.

    It’s probably a lost cause, and I don’t think there are many of of us left who remember how to work with the tools that embody the “do one thing, well” philosophy, or how that led to stable, predictable, and easy to manage systems.