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

Are you sure? I can see the image loading much later on mobile: https://pagegym.com/compare/uu5641qndi/4d3ifzdbxk

To not preload, yes

I could not find this hack documented or discussed anywhere, that's what I meant.

It’s not a hack, but you may find more documentation for the equivalent preload values expressed as a <link> tag. There is (near) parity between that and the HTTP Link header. The values used in the article should work in HTML as well.

> It’s not a hack

Yeah, this isn't a hack; this is what media queries were made for.

Now, this is a hack!

You had to do this to make :hover work correctly for IE6—IE8 [1]:

    body {
      behavior: url("csshover3.htc");
    }
[1]: https://pawelgrzybek.com/internet-explorer-just-hit-the-end-...

I agree, this was not a hack. It is combined behavior from documented features (preload with media and lazy loading).

The XML/config side of things just isn't for everyone. Sometimes Go's simplicity wins out.


One of the big features in .net 10 is the ability to do `dotnet file.cs` to run an application, with package import and assembly attributes directly in the file.


It is as simple as what you get with Cargo, and possibly even more readable.

.NET, unlike Go, has all needed management commands built into its CLI too: dotnet new {template}, dotnet add/remove package, dotnet sln add/remove, etc.


My dad does. He prefers older versions though (and he switched from FrontPage)



exa is abandoned. There is now a maintained fork called eza: https://github.com/eza-community/eza


I just ran `brew install eza` and I'm overwhelmed with amount of dependencies it installs. Among many others - openjdk, qt, node - what is going on?


You’re likely running on an old version of MacOS that isn’t able to use the precompiled binaries. So, brew is installing all the dependencies necessary to build eza from scratch.

Intel-era Mac?


But why would it need all of those dependencies?


Because all dependency managers at some point devolve to "install ocean, then boil ocean".

(If you care, "brew deps <package> --tree" will tell you.)


brew deps eza --tree prints:

eza

└── libgit2

    ├── libssh2

    │   └── openssl@3

    │       └── ca-certificates

    └── openssl@3

        └── ca-certificates


From what I can tell, it doesn't:

  $ brew deps --include-build eza
  autoconf
  automake
  ca-certificates
  cabal-install
  certifi
  cmake
  ghc
  ghc@9.8
  libgit2
  libssh2
  llvm@18
  lz4
  m4
  mpdecimal
  ninja
  openssl@3
  pandoc
  pkg-config
  python@3.11
  python@3.12
  readline
  rust
  sphinx-doc
  sqlite
  xz
  zstd


Because most of those are dependencies required to build the actual dependencies.

There's (generally) 4 types of dependencies:

    - Toolchains (frameworks, compilers)
    - Build (headers and libraries)
    - Runtime (libraries)
    - Test (frameworks, headers, libraries)
And those dependencies all bring their own dependencies...


MacBook Air M2 2022, macOS Sequoia 15.0


Your Homebrew may not be configured to pull only the runtime dependencies; as others in this thread have mentioned, it's pulling in all those dependencies becauase it's building "eza" (or something, perhaps one of "eza"'s few transitives) from source, which brings in quite the list, including openjdk as you saw.

Homebrew can accidentally end up configured to do this in a number of ways. Some of these may no longer be issues; this list is from memory and should be taken with a grain of salt:

- You might be running an outdated homebrew.

- You might have homebrew checked out as a git checkout, thus missing "brew update" abilities. "brew doctor" will report on this.

- You might have "inherited" your Homebrew install from a prior Mac (e.g. via disk clone or Time Machine), or from the brief transitional period where Homebrew was x86-via-Rosetta on ARM macs, thus leaving your brew in a situation where it can't find prebuilt packages ("bottles") for what it observes as a hybrid/unique platform. Tools, including your shell, which install Homebrew for you might install it as the wrong (rosetta-emulated) architecture if any process-spawning part of the tool is an x86-only binary. More details on a similar situation I found myself in are here: https://blog.zacbentley.com/post/dtrace-macos/

- (I'm pretty sure most issues in this area have been fixed, but) you might have an old or "inherited" XCode or XCode CLT installation. These, too, can propagate from backups. Removing Homebrew, uninstalling/reinstalling XCode/CLT, and reinstalling Homebrew can help with this.

- The HOMEBREW_ARCH, HOMEBREW_ARTIFACT_DOMAIN, HOMEBREW_BOTTLE_DOMAIN, or other environment variables may be set in your shell such that Homebrew either thinks the platform doesn't have bottles available or it shouldn't download them: https://docs.brew.sh/Manpage#environment

- Perhaps obvious, but your "brew" command might be invoked such that it always builds from source, e.g. via a shell alias.

- Homebrew may be unable to access the bottle repository (https://ghcr.io/v2/homebrew/core/), either due to a network/firewall issue or a temporary outage.


Your (awesome) comment reminds me...

Noob me has had to troubleshoot homebrew. Like keeping laptop and desktop in sync. Like fixing stuff I've somehow borked.

So I tried a handful of GUIs (wrappers). Like these two top hits:

https://corkmac.app/

https://aerolite.dev/applite

But sort of bounced off.

Noob friendly homebrew seems like such a great idea. I especially want just one strategy which spans both utils and apps (casks). Versus cobbling together Apple App Store, SetApp, and homebrew.

Those GUIs would be even more useful if they spotted and explained the config issues you listed. (I have no idea if "brew doctor" suffices.)


Thank you for such a comprehensive guide! I’ll try to resolve the issue today with your help


You’re welcome! One more issue that I missed calling out: a bottle may not yet be available for your platform (Sequoia) as it is very new. In that case, patience.



There is also https://github.com/ChrisTitusTech/winutil, which works for Windows 10 too


In comparison, Meld is not stable, nor fast, especially for big diffs. The UI is also more limited. Araxis Merge and WinMerge are good alternatives


Yea I found Araxis Merge better than BeyondCompare, FileMerge, DiffForm, and Meld (mostly based on diffing prose rather than code, though).


Araxis Merge is ~4x the price of BC though. What does it do that makes is 4x better?


Well, whether it's worth it is going to depend both on the use case and on the user. (I figure for many folk in this thread, the difference in price is going to be pretty negligible for a tool they use ~weekly.)

For me, I eliminated BC immediately because I was often diffing prose and it didn't have word wrap; that ability is apparently available now in the beta version of BC5, but it wasn't when I was testing it. I suspect it will continue to be non-optimized for prose in how it handles long lines.


I also did something similar 14 years ago. It was a php website that allowed you to subscribe to online newspapers and get the news sent to your Kindle, in MOBI format. It worked but it was basically calling calibre under the hood. I never made it public (and I remember a similar website existed already at that time that did not work well)


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

Search: