pnt12

A touchscreen Mac would compete with iPads so that's a no no.

For the foldable phone, it may just have to do with aesthetics.

I agree they aren't building great user products anymore but gemini is solid (maybe because it's more an engineering/data achievement than a ux thing? the user controls are basically a chat window).

I asked for a deep research about a topic and it really helped my understanding backed with a lot of sources.

Maybe it helps that their search is getting worse, so Gemini looks better in comparison. But nowadays even kagi seems worse.

Cool tech, wrong company.

The tech is impressive, but people are already getting concerned about excessive screen time via zombie doomscrolling. Moving it from the pocket to literally in people's face will only worsen it.

And by Meta of all companies, with concerning privacy practices and of course motivated to hold your attention to serve you more ads.

Agreed with first sentence ( and only). That's why the state must legislate and fiscalize rules that benefit the population.

I don't even condemn businesses (too much). For a single business to be more eco friendly it must raise costs anf lose competitiveness. For a state to mandate these stuff, all businesses will be on the same level - and they'll have to compete for practical or cheaoet ways to be eco friendly.

It's the tragedy of the Commons, and the only way to win is to enforce rules for everyone.

That's a bit pedantic: lots of python programs will work the same way in major OSs. If they don't, someone will likely try to debug the specific error and fix it. But LLMs frequently hallucinate in non deterministic ways.

Also, it seems like there's little chance for knowledge transfer. If I work with dictionaries in python all the timrle, eventually I'm better prepared to go under the hood and understand their implementation. If I'm prompting a LLM, what's the bridge from prompt engineering to software engineering? Not such direct connection, surely!

I mean, this sounds like survivor bias in action?

Google also bought Motorola for 12 billion and Microsoft bought Nokia for 7 billion. Those weren't success cases.

Or more similarly, WeWork got 12B from investor and isn't doing well (hell, bankrupt, according to Wikipedia).

I don't think it's ironic: maybe it's not intuitive / not easy to do!

But there's utility in talking about it. If you teach people that good engineers prepare for Google scale, they will lean towards that. If you teach that unnecessary complexity is painful and slows you down, they will lean towards that.

Maybe we need a Rosetta stone of different simple and complex ways to do common engineering stuff!

As a fan of the early seasons, I get lots of suggestions for Got clips. I assume that's done by the author to get around copy right blocks. Quite often they also add music, which would make it easier to get around sound detection.

I haven't noticed it outside copyrighted material, so it's probably intentional.

Late to the party, but thanks to the author for this: I learned a lot from this article, although I have mixed feelings about it.

The good: cool to know more about the agents loops, different types of LLMs, ideas for prompting. I definitely wanna try it - would be cool to prompt the agent to build some feature, have it in a loop of building, testing, reviewing and, go have breakfast, come back and only have to tweak a reasonably legible and working code.

The bad: some of these concepts, maybe they are bit meant to mislead, buy really trigger my 'snake oil alert'. The AI compass? Agentic VS non agentic LLMs? People who are getting work done between meetings? Maybe this is more of a vibe thing, so it's not trivial / logical to explain, but in this space there's so many loosely defined concepts that that really trigger skepticism in me (and others).

The ugly: 1 word slides ;p

I switched to ruff for the great linting. When they introduced a formatter, I gave it a try and: - got similar results - but runs faster - I could delete one dev dependency

Given black's motto (any color as long as it's black), now I pick ruff and go with whatever formatting it produces.

Those would be all articles posted in HN :)

Nowadays that's actually Switzerland (at least I hear great things about Zurich, except the cost of living).

But those are technicalities.

I imagine the intended feature is learning about who read some information, and who modified it.

The implementation varies, but on a CRUD app it seems easy: an authenticated GET or PUT request against a file path - easy audit log.

If you are copying information to another place, and make it accessible there in a lossy way that is hard to audit... you broke your auditing system.

Maybe it's useful, maybe it's a trade-off, but is something that should be disclosed.

I'm not a hater, but also not the biggest fan of bash. What do you consider its pros and cons?

Pros: easy to interact with different tools, included in many Unix OSs, battle tested.

Cons: complex stuff gets messy, with weird syntax, hard to do logic, hard to escape everything correctly

It sounds different to me - a regular git submodule would keep all history, unlike a file storage with occasional snapshotting.

OK turns out it was not a summary, just a preview paragraph that mixed headers and text from the original, leading to strange casing and reading. I'd suggest not to include headers there or distinguish them!

Example (had to search on kagi with site:minifeed.net):

You Can Either Steal Great Developers or Farm Them To grow software development teams, you can either steal excellent developers or you can develop them internally.

Also when going back the page, I don't see that post anymore - it was featured in random blogs, so I lost it.

It's a cool idea, but maybe a improvement could be to select a random handful per day, and let them stay there for a while? Fewer surprises this way!

I was surprised that I started reading one blog on your site, and it was badly written. Only afterwards below the text, did I notice it was a summary!

I'd advise to put it at the top, before the text, to let people know beforehand and not be caught off guard. Then you can have a big button saying "read full article in website" or something, to make it easy for people to see both options.

(sorry for the bad Matrix analogy)

To me, it's the opposite. In Python, every time I see 'requirements.txt' without lock files, I cry a bit.

A: You're handling problem X and then unrelated problem Y suddenly arises because you're not locking package versions thoroughly. It's not fun.

B: Now the opposite. You lock all versions of the libs you use. You use renovate or schedule time for updates periodically. You have a thorough test suite that you can automatically exercise when trying the new updates. You can apply the updates and deoy the new version to a test environment to run a final test manually. Things look good. You deploy to production and, quite often, things go smoothly.

A is the blue pill, easy to taste but things are out of your control and will bite you eventually. B is the red pill: you're in control, for the better or worst.

This is baffling. Those files are the most important information the car contains after an accident.

Let's not be naive, or deceptive, about a malpractice from a multi billion company owned by a multi billionaire.

A guide to using uv, ruff, reorder-python-imports and pytest to manage packages, formatting, static analysis and testing - all under a centralized configuration that is easy to re-use across CI/CDs, CLIs, IDEs and scripts.

Well, the money doesn't appear with magic, so someone is paying: the government (forfeiting taxes) or the consumer (more pressure to tip).

To me, the bad part is the tax reductions only appear in behavior I don't agree with: high overtime and tipping (when it's semi mandatory).

I'm not American, but this is also showing up in my country.

"It’s worrying how much research seems to operate from the premise that they do."

They are testing an hypothesis, we don't know if they're optimistic or pessimistic about it. Is it even relevant?

They have studied that LLMs can be easily confused with non-sequitors, and this is interesting. Maybe prompts to LLM should be more direct and foccused. Maybe this indicates a problem with end users interacting with LLMs directly - many people have difficulty on writing in a clear and direct way! Probably even more people when speaking!

Cool! 27 here! And I thought of myself as a connoisseur!

On YouTube, I follow:

- Steve the bartender - How to drink - Cocktail time with Kevin Koz - The educated barfly - Anders Erickson

Good recipes, sometimes adding new things, but usually tasteful.

But maybe they're better to search for than to strictly follow regularly; there's so many cocktails that is impossible to buy all ingredients or try all of them.

A decent bartender will measure the drinks regardless of ice. I've been doing them at home and a generous amount of ice leads to better results, especially if you like ice cold drinks!

I did some work in this area, concerning data pipelines, and it was a fun experience.

It's really satisfying to optimize (or any kind of refactor) on well tested code. Change the code, run the test, fix if it fails, keep it if it passes. Sometimes the code was not well tested, but it was slow, so there was double the reason to test and improve.

Having deterministic data for comparison is also good in a different perspective: slower feedback loop, but usually more variety, with edge cases you didn't think of. Transforming thousands of data points and getting 0 diffs compared to the original results is quite the sanity check!

Measuring can be difficult but really rewarding. I was doing this very technical work, but constantly writing reports on the outcomes (tables and later plots) and got great feedback from managers/clients, not only about the good results (when they happened, not always!) but also about the transparency and critical analysis.

We didn't really work with acceptance levels though. It was usually "this is slow now, and we expect more data later, so it must be faster". But it makes sense to define concrete acceptance criteria, it's just not always obvious. We'd go more in terms of priorities: explore the slow parts, come up with hypothesis, chase the most promising ones, depending on risk/reward. Easy fixes for quick wins, long stretches for potential big gains - but try to prototype first to validate before going on long efforts that may be fruitless.

A quick summary that does it for me: a log is something you read, a metric is something you measure.

Usecases:

Log: search, get context, read

Metric: measure, plot dashboards, define alerts

My theory for the concepts being so mixed up together: you use both to troubleshoot, and I think the old school way to emit metrics was to parse logs and turn that into measures.

Kubernetes is really complex but I'm surprised by this - for a simple setup, I think those 2 resources are not that difficult.

I'd describe a really simple setup as this:

Pod: you put 1 container inside 1 pod - you can basically replace the word "container" with "pod". Let's say you have 1 backend in python and 1 frontend in React: you deploy 1 pod for your backend, and 1 pod for your frontend. The simplest way to deploy pods is not with "Pod" but with "Deployment" (1).

Service: Kubernetes really doesn't want you to connect directly to pods, it wants you to have a service in between. This is sensible because pods are ephemeral - they can be killed due to crashes, updates, etc. You define a service, point towards the pod, and all internal requests should be sent to the service, not to the pod. (2)

(1) https://kubernetes.io/docs/concepts/workloads/controllers/de...

(2) https://kubernetes.io/docs/concepts/services-networking/serv...

Note: technically, a pod is a group of containers. It can get more complex than this, but it's not unusual to have a group of 1 pod, especially in simpler setups.