Hacker Newsnew | past | comments | ask | show | jobs | submit | e12e's commentslogin

If this is a concern, why not compress at the filesystem level?

> the watch has a publicly reachable IPv4 address

Attacker reachable, presumably? Like from a hacked cable modem or wifi router?


I guess I managed to mention everything but what I was actually, specifically fishing for: I wanted to confirm this claim and claims like it:

> The watch had an insecure network service that anyone could access via the internet.


It's nice to be able to authenticate sudo via biometric id with the help of Pam, or unlock your password manager like bitwarden.

I don't think an apple watch would help there?


> I don't think an apple watch would help there?

You can authorize via Apple Watch everything you can authorize via Touch ID. You get the notification on the Watch, and you need to press the button twice to auth.

I don't remember if it works every time, or only when MacBook is closed and connected to external display/keyboard.


I've got this functionality in linux with the framework laptop, and it really isn't much faster than typing in a password.

either you have killer typing speed or your password isnt long enough or your fingerprint scanner is slow

It can be, if your typing is impaired.

Wait, one can wire up sudo to touch ID? I don't know how I never learned that before


It's been possible since Big Sur at least, the method for enabling it just changed woth Sonoma


Interestingly enough, even ChatGPT has this to say about how the Trump administration might side-step the language about fully autonomous weapons:

https://chatgpt.com/share/69a439b3-dfe4-800d-926e-39db221fba...

AI;DR

> So in summary: a future administration could attempt to sidestep those guardrails by altering the underlying legal/policy framework they’re tied to, redefining oversight requirements, or asserting emergency powers — effectively opening a path for more autonomous weapon deployments without facially violating the letter of the current contract text.


> a reliable mechanism for disabling

Note that the bar is pretty high for reliable here. Say 1 in a thousand isn't disarmed or destroyed.

Would you encourage your child to play in an area where ten thousand mines were dropped? A thousand? Five hundred?


Someone who was raised in such an area talks about their experiences elsethread: https://news.ycombinator.com/item?id=47194668

> A filesystem with snapshots makes software installation transactional. You take a snapshot, install some software, and if it doesn't work right, you can revert to the snapshot. (With very slightly more flexible snapshots, you can limit the snapshot to just some part of the directory tree, but this is not essential; it merely permits more flexibility.)

Eh, you don't typically have a lock mechanism for the filesystem equivalent to that of a database.

Who's to say something like this doesn't happen:

  - snapshot fs
  - op/system adjust firewall rules
  - "you" install updates
  - you rollback
  - firewall rules is now missing patches
Don't get me wrong zfs is great - but it doesn't come with magical transactions.

A snapshot is taken before installing updates, so you'd get two snapshots from your example. Rolling back would leave you right after adjusting firewall rules.

Not if someone else modified firewall rules while you were installing updates? (Eg: someone else being a Cron job).

That's an easy thing to account for.

> Don't get me wrong zfs is great - but it doesn't come with magical transactions.

I never said it did!

But if you have a snapshotting FS underneath, transactional software maintenance becomes an order or two of magnitude easier to achieve.

The underlying philosophies of Unix are "keep it in files" and "keep it simple". That's why it didn't even have a file-hiding mechanism -- the dot-file thing was an accental, emergent property.

Keep it simple, keep it visible, keep it human-readable and human-fixable.

Because the more complex you make it, the more likely it is to go wrong, and some poor sap is going to have to fix it. Do not get in their way. Instead, think about them, allow for that, and help keep their life easy.


Sony used to be surprisingly good on this - but I'm uncertain what the current status actually is:

https://developer.sony.com/open-source/aosp-on-xperia-open-d...

> Note: New devices XQ-CT62 (1Ⅳ US variant) and XQ-CQ62 (5Ⅳ US variant) do not support bootloader unlock.

https://xdaforums.com/t/unlock-bootloader-and-root-guide-xpe...


Fish is probably a good idea for an interactive shell. Osh/ysh might be a good idea for scripting:

https://oils.pub/

I'm still using bash out of habit, though. My one nod to modern tooling is using fzf for shell history search...


I think looking at some of the documentation for oils (née oil sh) and ysh - as well as [looking at using] these two projects [in place of bash] - is also a good idea today:

https://oils.pub/


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

Search: