Hacker News new | past | comments | ask | show | jobs | submit | lilyball's comments login

I have to ask: so what? Most of the stuff here is rather specific to the test suite conflicting with security or features and does not adversely users or developers who care about UNIX behavior (SIP is really the only thing that may get in the way, but anyone who cares can disable it). For example, the fact that spotlight might update file access times is presumably not itself a violation of the UNIX standard, it's just something the test suite isn't expecting. The weirdest thing here is the uucp stuff, but that's an obsolete and rather dead technology so I see no reason to complain about macOS not giving those binaries the setuid bit, especially when the workaround so trivial.

The "move a branch" command is `git push .`. Yes, you can push to the current repo. I have a script called git-update-branch which just does some preflight checks and then runs `git push --no-verify . +$branch@{upstream}:$branch` to reset a branch back to its upstream version.


> The "move a branch" command is `git push .`. Yes, you can push to the current repo.

Wouldn't that copy a branch rather than moving it?


"move a branch" means changing the commit the branch points to. `git push . $sha:$branch` will update $branch to point to $sha (you'll probably want to force this, unless you're just fast-forwarding the branch).

The reply is encrypted. Apple doesn't know what it says. Neither would the police.


The weak force is weak not because it has "short range" but because its range "dies off at distances ten million times smaller than an atom".


Besides the fact that stiffness shows up as a term in the equations, stiffness is a concept that can be demonstrated via analogy with a rubber sheet, and so lends itself to a somewhat more intuitive understanding.

Also, the math section demonstrated how stiffness produces both the short-range effect and the massive particles, so instead of just handwaving "massive particles is somehow related to the short range" the stiffness provides a clear answer as to why that's the case.


I'm running NixOS on a raspberry pi and I deploy to it with deploy-rs¹. This works pretty well for me. My dev machine is an Apple Silicon laptop with nix-darwin installed and I use its nix.linux-builder module to run an aarch64-linux VM as a remote builder to build the rpi's system. All this means the rpi never has to do any building itself, and doesn't even need the nixpkgs source installed either.

If you want to do this yourself, I recommend using https://github.com/nix-community/raspberry-pi-nix so the system is configured much more closely to how the stock raspberry pi image works. The benefit of this is better reliability of stuff like bluetooth.

¹https://github.com/serokell/deploy-rs


You can run generic Linux stuff if you install nix-ld¹, the only tricky bit is having to customize the set of libraries given to nix-ld for your use-case. It includes various common libraries by default, but depending on what you want to run you may have to add to it.

¹https://search.nixos.org/options?channel=unstable&show=progr...


Interesting, I didn't realize that that was an option.

I've been getting by with buildFHSenv and Flakes, which, despite my complaints, really isn't that annoying. My goal at this point is to eventually compile all my flakes and take on Lutris.


Interesting, I didn't realize that that was an option.

As a fellow daily driver of NixOS, you’ve just summed up my biggest problem with it. You can do almost anything, and once you’ve figured out how and why you do it a certain way, that way often makes a lot of sense and the NixOS design can offer significant benefits compared to more traditional distros without much downside. But NixOS is out of the mainstream and its documentation is often less than ideal, so there is a steep learning curve that is relatively difficult to climb compared to a more conventional distro like Ubuntu.

The shared object problem in particular comes up so often, particularly if you use applications or programming languages with their own ecosystem and package management, that I feel like having nix-ld installed and activated by default with a selection of the most useful SOs available out of the box would be a significant benefit to new users. Or if including it in a default installation is a step too far, many users would probably benefit from some HOWTO-style documentation so they can learn early on that nix-ld exists, how it helps with software that was built for “typical” Linux distros, why you don’t need or want it when running software that was already built for NixOS such as the contents of nixpkgs, and how to work out which shared objects an application needs and how to find and install them for use with nix-ld.

I haven’t yet felt confident enough in my own NixOS knowledge to contribute something like that, but one nice thing about the NixOS community is that there are some genuine experts around who often pop up in these discussions to help the rest of us. I wonder if there’s scope for sponsoring some kind of “Big NixOS Documentation Project™” to fund a few of those experts to close some of those documentation gaps for the benefit of the whole community…


I felt this comment so hard


I would probably still use buildFHSenv if I was trying to package up a third-party binary for installation in my configuration. My usage of nix-ld is actually to solve the problem of using VSCode Remote to connect to my NixOS machine, and in particular to allow it to run binaries it downloads onto the machine for extensions (typically LSP servers).


There’s also nix-alien which does this but tries to be more automagical.


nix-alien is an older, worse approach that is not that well maintained


nix-alien used nix-ld under the hood.

Why would you say it is worse, older (does this one really matter?), or not well maintained?


> It seems very cool that you can roll back in the case of a catastrophic upgrade failure, but has that every happened to you? Not me.

Rollbacks saved me from completely destroying my entire system. I managed to fill up my boot partition in a way that deployed successfully but left the whole system unbootable after reboot, and the only way I managed to save it without having to completely wipe and reinstall from scratch (which means losing all my data) was to load the SD card onto my laptop, fix the boot partition by hand to ensure the kernel from the previous generation was valid, and edit the bootloader config to delete the offending configuration (because accidentally trying to boot it would re-corrupt the boot partition).

I've also used rollbacks in other less catastrophic situations, such as when I broke wireless (since I build remotely on a much more powerful machine and deploy over SSH).


I use NixOS on my home router and rollbacks also saved me from a Firewall misconfiguration that broke all network connectivity.


> Worse still, as the attack exploits behavior at the system level during the conversion process, no standard library in any programming language can fully stop our attack!

What happens if the standard library updates its shell escaping to also escape things like the Yen character and any other character that has a Best-Fit translation into a quote or backslash? Which is to say, what does Windows do for command-line splitting if it encounters a backslash-escaped nonspecial character in a quoted string? If it behaves like sh and the backslash simply disables special handling of the next character, then backslash-escaping any threat characters should work.


Backslash is a valid path character (you can use / or \ as the path separator on windows) so if the backslash isn’t actually escaping anything it is left as-is.


> What happens if the standard library updates its shell escaping

If the executable is linked statically with the CRT then nothing changes until you re-link it with the newer CRT. If it links with the UCRT then if the UCRT changes its rules then the program will too.


That drug is not a drug designed to put you to sleep though (I mean it kinda does, but that's not its purpose). The purpose of that drug is to change your sleep architecture during the night. I'm on the newer form of that drug (because of idiopathic hypersomnia) and most nights I still take 1–2 hours to fall asleep.


Lumryz? GHB is metabolized very quickly and would be out of your system within 2 hours. Lumryz is supposed to process slower. I have had a few bad nights on xyrem, but mostly it puts me sleep quickly enough. And more importantly puts me on a better sleep cycle so I'm actually sleepy at bed time by dint of being awake during the day.


Xywav, with the 2-dose schedule. My impression based on how I feel waking up at various times in the morning is each dose produces effects that last somewhere around 3–5 hours. My understanding is most people taking this drug are falling asleep much more quickly than I am, and I do feel it trying to make me sleepy shortly after taking it, but not enough to defeat my delayed sleep phase disorder and various insomnia issues. But my point was that "falling asleep quickly" is not a direct goal of the drug, even if it is a common effect, the goal of the drug is to change what your brain does while you're asleep.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: