wasyl

I mean, it's right there as the first highlight in the docs

A single tool to replace pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more.

Why is it interesting? The image does not look like anything, and you need to skew it (by looking at an angle) to see any letters (barely).

Seems like repopack only packs the repo. How do you apply the refactors back to the project? Is it something that Claude projects does automatically somehow?

The numbers are debatable as usual but they're not taken from thin air

A 2023 survey conducted by Payroll.org highlighted that 78% of Americans live paycheck to paycheck, a 6% increase from the previous year. In other words, more than three-quarters of Americans struggle to save or invest after paying for their monthly expenses.

Similarly, a 2023 Forbes Advisor survey revealed that nearly 70% of respondents either identified as living paycheck to paycheck (40%) or—even more concerning—reported that their income doesn’t even cover their standard expenses (29%).

https://www.forbes.com/advisor/banking/living-paycheck-to-pa...

The numbers are debatable as usual but they're not taken from thin air

A 2023 survey conducted by Payroll.org highlighted that 78% of Americans live paycheck to paycheck, a 6% increase from the previous year. In other words, more than three-quarters of Americans struggle to save or invest after paying for their monthly expenses.

Similarly, a 2023 Forbes Advisor survey revealed that nearly 70% of respondents either identified as living paycheck to paycheck (40%) or—even more concerning—reported that their income doesn’t even cover their standard expenses (29%).

https://www.forbes.com/advisor/banking/living-paycheck-to-pa...

Can you clarify which laws and opinions you have in mind?

I don't read it as _bypassing tests_. They have tested the interpreter (`template type`) when it was first released, and they have _validated_ the new template instance (via `content validator`) and assumed this is enough, because it was enough in the past. None of the steps in the usual process were bypassed, and everything was done by the (their) book.

But it looks to me there's no integration test in the process at all. They're effectively unit testing the interpreter (template type), unit testing (validating) the "code" (template instance), but their testing strategy never actually runs the code on the interpreter (or, executes the template instance against the template type).

Shown as a hierarchical bar chart, this would suggest 'b' is problematic.

But it's not necessarily `b` that's problematic:

- it may be `a` because it does a lot of stuff on its own, and depending on what `a` is, it might not be expected

- it could be `d` if it's supposed to be super fast (e.g. a logging method)

- it could be `c` because it takes a long time

- it could be `b` if `c` is external code or if calling `c` from `b` is not appropriate for what `b` does

- it might be nothing because there's nothing to optimize anymore, things just take this long

in fact, `b` is the last method I'd look at here

Why don't you grow your own food? Why don't you just write your own payment processor?

I find that usually if someone says "why don't X _just_ do Y", they haven't really considered what it takes to _just do Y_. Similarly,

I know the UI/UX isn't the best, but that could probably be fixed pretty easily

could be expanded into 50 points of why exactly it wouldn't be _pretty easy_ to to "fix IRC UI/UX".

Honestly I don't know what answer OP expected here. If it's easy to set up/maintain Slack alternative based on IRC, with fixed UI/UX and appropriate for _most companies_, they should simply start a Slack competition for half the price and rake the profits, I guess

I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions. Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL queries makes little sense. But for internal APIs, whitelisting whatever queries current clients need isn't any less convenient

A while ago I went into a rabbit hole looking for something to support my hunch (which I now confirmed by installing old macos) and found some discussions about graphics/OpenGL APIs being deprecated and removed over time. I have a very uneducated guess that new-macos-on-old-hardware runs some translation for all graphics operations/APIs, which causes perceptible lag when doing _anything_, because everything draws on the screen. It does feel as if the OS is constantly struggling with some background tasks

Software just becomes larger and more complex and thus slower on older hardware.

So every major OS update is larger and more complex, so it's to be expected that after ~4 of those my machine lags when doing literally everything? It's not that I'm running tons of background apps, it's a powerful machine lagging on a clean install of a recent macOS version when doing basic operations like opening a webpage.

My 2021 MacBook Pro 14" is still lightning-fast though, I never wait for anything.

I suppose it's Apple Silicon? Because that would still be in line with Intel-based macs becoming less performant over time

I'd guess not the latter — anecdotally, my intel mac has been increasingly sluggish after each macos upgrade, even after a clean install. I finally decided to revert to the oldest macos version possible (and then update by just one major version since unfortunately some apps I need don't support Catalina anymore) and the difference is night and day — my memory was right and my laptop _was_ faster before. And it's not hardware getting old or battery problems, it's the OS.

So I don't know if older macs are intentionally crippled or they're just ignored during QA, but I don't believe they're actually intentionally supported

Thank you for this! I wondered why image search is barely usable on mobile Firefox - turns out it's just Google hampering the competition!

It does remove songs, or at the very least disables some (you can toggle a setting to see disabled songs) presumably due to copyright/licensing issues. But worse, it sometimes _replaces_ a song with a different version, with no warning and no recourse

Is it? https://www.jetbrains.com/idea/ has a link to a download page (https://www.jetbrains.com/idea/download/) which clearly advertises free community version. What would be not _well hidden_ in your opinion?

I'm not saying _nobody_ uses those devices, I'm just saying they're sufficiently old that saying _my app supports Android 3.x_ is moot, because the usage on that API will be near 0 anyway, so you never really know if you _support_ that version outside of any testing that you might be doing. Android 4 and lower have estimated share of 0.3%-0.7% depending on a source ([1], [2]). Of course HN users will be more likely to have those devices too. And then of 0.5% users that maybe will install the app some will have no issues, some will have issues but not notice, some will notice but not bother reporting.

[1] https://apilevels.com/ [2] https://www.composables.com/tools/distribution-chart

curious how one ensures compatibility with ancient versions; actual testing, a compatibility linter, other?

Android linter does check that access to APIs added in newer versions is gated behind a version check, for example. But frankly I feel like compatibility with any Android version less than 4 (or even 5) is in practice a non-issue, simply because there are no users with such ancient Android. And the few that would use such devices are so far and between that any issues don't surface

It's not difficult to write sub-10Mb release APK for a production app with lots of features while using all the compat libraries and other useful dependencies (that do make life a lot easier). Our app is ~7Mb, and we don't even heavily optimize for APK size.

IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯

There is https://languagetool.org

By that logic you could call regular ad blocking censorship, because it does exactly the same thing as parent described, only without AI and less effectively. I see a difference between algorithmic feeds that I have no control over that are designed to boost the companies goals, and an opt-in tool (hopefully an open one) running locally and modifying the content presentation to remove things I don't want in the first place

At this point what Apple is ahead with is hype that M Macs are that fast, and the developers targeting them because things just work. Plenty of people should be able to run these models locally but there's close to no nice software that does that out of the box for Windows or Linux

Interesting, how old was it? Do you recall how many cycles the battery was at? Unfortunately throttling is unlikely in my case, at least for the lagging I observe day-to-day, I don't see any throttling via `pmset -g thermlog`. I did wonder if changing thermal paste would help, but since I don't observe throttling I'm not sure it would

Thanks for the suggestions, this all sounds plausible, however: - I routinely clean, or at least de-dust everything accessible after removing back cover - the lag is there always, even right after resuming the mac, before any thermal throttling should be kicking in. I also don't observe throttling with `pmset -g thermlog` - I'm not using an external monitor

At this point the most likely culprit is the battery, mine is at 789 cycles although the condition is reported as "normal". I wish it were possible to confirm whether battery is an issue before spending couple hundred $ on replacement though

I wish someone did an analysis to determine why my intel-based macbook is so incredibly laggy all the time, even after fresh system installation. I can't shake the feeling that Apple Silicon is so much faster that performance issues just got into the system without anyone at Apple bothering to fix them, and Intel macs suffer as a result.

Can you elaborate on some of the reasons why you regretted the purchases?

Feels like this is true only for Apple Silicon macs. Intels are getting more are more terrible with each upgrade, most noticeable is insane UI latency when doing literally anything — opening an app or a window can take seconds. Changing the tab in Settings app takes a second before the new one is rendered! And that's with a fresh system installation and no resource-hungry apps opened. And it's definitely not just me — colleagues have the same issues and internet is full of such reports.

True, although given there's no real competition to Reddit, I personally find it difficult to believe this particular scenario

something more obvious right now given how bad the astroturfing campaign is. one word reviews?

I imagine one doesn't have a good way of making sure they'll get good, quality fake reviews from farms in 3rd world countries. But also, it's about as bad (in terms of PR) as spez's communications and interview so

Is it that big of a stretch to assume Reddit boosted their own apps ratings with fake/paid reviews, given one of the main arguments is that their apps still suck while they're killing third party ones?

I can’t imagine anybody has time to do all the random stuff they’re being accused of.

Employees are probably not happy but they are still working. And you can literally find a page offering paid reviews in seconds, add an item to _a basket_ and pay with a credit card

The Apollo dev said that he would have to charge every user $2.50 a month to cover costs of the API

He did not say that, he said

Apollo's price would be approximately $2.50 per month per user

which is an estimate of how much they'd have to pay Reddit for each user in API costs alone. But it doesn't take into account cost of Apollo's own servers and infrastructure, Apple's fees, or the fact that there are people with paid for yearly subscriptions that'd have to be served:

Even if I added 12,000 new subscribers at $5/month (an enormous feat given the short notice), after Apple's fees that would just be enough to break even. Going from a free API for 8 years to suddenly incurring massive costs is not something I can feasibly make work with only 30 days. That's a lot of users to migrate, plans to create, things to test, and to get through app review, and it's just not economically feasible.

(quoted from https://old.reddit.com/r/apolloapp/comments/144f6xm/apollo_w...)

All in all it's a much different thing if Reddit said they want to charge the users $2.5/mo for API access, given them their own key and let use whatever 3rd party app they want. They want to charge the 3rd party apps directly, which is a whole different story that can't really be summed up as to "$2.5 is not that high if people really want to use third party apps"