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

With the cold snap in the eastern US I'm quickly learning EVs range and charging short comings in below freezing weather.

They do? It's pretty limited but if you tap your profile photo at the bottom of Music and then tap your profile photo in the menu again it'll bring you to a "Apple Music profile" of sorts you can follow people with.


Orpheus and Redacted existed but it's kind of hard to beat the convenience of streaming for the low price in 2025.

Granted you can set up automated *arr systems with PLEXAMP to get a pretty seamless "personal Spotify" setup IME getting true usefulness out of trackers of What's quality always required spending real money - to obtain rare records/CDs on marketplaces - or at least large amounts of time if you went the "rent CDs from the library" route. I personally haven't ran into much RYM releases lacking on Apple Music and what is lacking I can find on Bandcamp or YouTube.


The $2000 daily driver died with covid.


Do you have a good guide/video/write up on this?

I’ve been putting off remaking my GPG and SSH keys using a Yubikey.


This guide [1] mostly follows the practices the previous poster outlined.

[1] https://github.com/drduh/YubiKey-Guide


At https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#co..., these options are not the most secure one.

  personal-cipher-preferences CHACHA20 AES256 AES192
  personal-digest-preferences BLAKE2B SHA512 SHA384 SHA256
  personal-compress-preferences Uncompressed
  personal-aead-preferences OCB EAX
  default-preference-list BLAKE2B SHA512 SHA384 SHA256 CHACHA20 AES256 AES192 Uncompressed OCB EAX
  cert-digest-algo BLAKE2B
  s2k-digest-algo BLAKE2B
  s2k-cipher-algo CHACHA20
  s2k-count 65011712
  charset utf-8
  no-comments
  no-emit-version
  no-greeting
  keyid-format 0xlong
  list-options show-uid-validity
  verify-options show-uid-validity
  with-fingerprint
  require-cross-certification
  require-secmem
  no-symkey-cache
  armor
  use-agent
  throw-keyids
  weak-digest SHA1 RIPEMD160 MD5
  disable-cipher-algo 3DES CAST5 IDEA BLOWFISH TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256
  disable-pubkey-algo RSA1024
  trust-model tofu+pgp
  keyserver hkps://keys.openpgp.org
  keyserver-options no-honor-keyserver-url
  keyserver-options include-revoked
  keyserver-options auto-key-retrieve
  force-mdc
  require-compliance
  compliance de-vs
These are the most secure options (correct me if I am wrong). The only drawback you may encounter is that you need GnuPG 2.3+, and some compatibility tradeoffs.


On second thought, you may want to remove this line:

  compliance de-vs
Because DE-VS only recognizes AES/3DES for ciphers and SHA-2 for digests; conflicts with CHACHA20 and BLAKE2B and will reject operations using these algorithms.


You can buy refurb M1s for $379 at Walmart.


Has a proprietary bootloader that Apple can lock in an OTA update. Also doesn't support Linux as well as Intel or AMD chipsets, unfortunately.


Last I heard asahi ran pretty well on M1/M2. Is that not the case?


It runs well but battery life is quite a bit worse than on macos.


That’s not particularly surprising to be honest. A lot of what makes Apple tech what it is is the concert between their hardware and software. Not trying to put it too poetically here, but that’s what it’s always seemed like to me.

In general when I install Linux on an Apple device I just assume there isn’t the same level of performance. I remember installing mint on a 2016 intel MBpro and the limitations/cons didn’t surprise me at all because I just kind of expected it to perform at 70% of what I expected from macOS but with far more free freedom/control. It ran very smoothly but you definitely lose a lot of functionality.


> A lot of what makes Apple tech what it is is the concert between their hardware and software.

That's very cute, but it's not why Apple laptops run Linux poorly.

Apple Silicon has terrible and inefficient support because Apple released no documentation of their hardware. The driver efforts are all reverse-engineered and likely crippled by Apple's hidden trade secrets. This is why even Qualcomm chips run Linux better than Apple Silicon; they release documentation. Apple refuses, because then they can smugly pride themselves on "integration" and other plainly false catchisms.

And on Intel/AMD, Apple was well known for up-tuning their ACPI tables to prevent thermal throttling before the junction temp. This was an absolutely terrible decision on Apple's behalf, and led to other OSes misbehaving alongside constant overheating on macOS - my Intel Macs were regularly idling ~10-20c hotter than my other Intel machines.


>That's very cute, but it's not why Apple laptops run Linux poorly.

I have no doubt you have good information after this, but this sentence makes me not want to read any further.


Okay, that's your call. You can't phone Craig Federighi for the straight dope, so you're stuck hearing it from internet douches or product leads on prescription SSRIs.

And yes, your statement was a cutesy catechism with no actual evidence provided. A big reason why Apple tech doesn't work like a normal computer is Apple's rejection of standards that put hardware and software in-concert. ACPI is one such technology, per my last comment.


i don't think either of those is really true?

https://asahilinux.org/docs/platform/open-os-interop/


Literally the first step of the boot overview depends on a proprietary and irreplaceable Apple-controlled blob:

  iBoot2 loads the custom kernel, which is a build of m1n1
Apple decides whether or not m1n1 ever loads.


Only if you boot into macOS and connect it to the internet. iBoot2 never changes by itself, you, the user, decides if you want to boot into recovery or macOS and run an update.

So can Apple stop signing new iBoot2 versions? Sure! And that sucks. But it's a bit of FUD to claim that Apple at arbitrary points in time is going to brick your laptop with no option for you to prevent that.

Granted, if you boot both macOS and Asahi, then yes, you are in this predicament, but again, that is a choice. You can never connect macOS or recovery to the internet, or never boot them.


> You can never connect macOS or recovery to the internet, or never boot them

In other words, you're completely fucked if you brick your install. I consider iBoot a direct user-hostile downgrade from UEFI for this reason.

YMMV, but I would never trust my day-to-day on an iBoot machine. UEFI has no such limitations, and Apple is well-known for making controversial choices in OTA updates that users have no alternative to.


> In other words, you're completely fucked if you brick your install. I consider iBoot a direct user-hostile downgrade from UEFI for this reason.

That's a bit of a creative perspective, isn't it? You have no control over the UEFI implementation of your vendor, same can be said for AGESA and ME, as well as any FSP/BSP/BUP packages, BROM signatures or eFused CPUs. And on top of that, you'll have preloaded certificates (usually from Microsoft) that will expire at some point, and when they do and the vendor doesn't replace them, the machine might never boot again (in a UEFI configuration where SecureBoot cannot be disabled as was the case in this Fujitsu - that took a firmware upgrade that the vendor had to supply, which is the exception rather than the rule). For DIY builds this tends to be better, Framework also makes this a tad more reliable.

If anything, most OEM UEFI implementations come with a (x509) timer that when expires, bricks your machine. iBoot2 is just a bunch of files (including the signed boot policy) you can copy and keep around, forever, no lifetimer.

Now, if we wanted to escape all this, your only option is to either get really old hardware, or get non-x86 hardware that isn't Apple M-series or IBM. That means you're pretty much stuck with low-end ARM and lower-end RISC-V, unless you accept AGESA or Intel ME at which point coreboot becomes viable.


Basically your counterpoint is that I'm absolutely right to be concerned, but I'm wrong because UEFI can also be implemented with the same objectionable backdoors that Apple implements.

We're done here, have a nice day.


It's not a counterpoint, it's a display of your factually incorrect statement.


except apple silicon notebooks are notably unbrickable[0]? you can always do https://docs.fedoraproject.org/en-US/fedora-asahi-remix/trou...

[0](through any user-accessible software action, obviously)


M1 mac minis or macbooks?


MacBook Air, though the $379 price does seem to be a Black Friday deal: https://www.walmart.com/ip/Restored-Apple-MacBook-Air-13-Lap...


Just note that listing is for an item from a third-party seller. Walmart's website includes listings from their third-party marketplace unless you explicitly filter them out.


I was just telling my buddy the same thing. It was our first SSD in HS. Mine eventually died with double the guaranteed TBW.


Aren't most micro-transactions like those purely cosmetic?


Yes for Valve, but that hasn't stopped a secondary market transacting tens of thousands of dollars or more for them in some cases.

> https://dmarket.com/blog/most-expensive-csgo-skins

> https://tradeit.gg/csgo/store


They are in Valve's own games. But items drop at different rates, which creates artificial scarciry and items can also be traded for money.


Definitely worth replacing for the performance at this point but is it possible it just needs a repaste? Thermal paste would’ve definitely dried out over 10 years and cause overheating symptoms.


I'm running one daily for the past ~12-13 years and the stability is impeccable but the performance is as you'd imagine. More likely that the motherboard age and degradation of various components would lead to instability, than the CPU itself.


Good point. I was kind of itching to upgrade that box anyway, but maybe I should repaste it and make it a backup server.


Isn’t this d-brands original business model?


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

Search: