Live data from Hacker News

Ode to the M1

fabiensanglard.net

31–40 of 286 posts

Re: Ode to the M1

#31
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

“640k ought to be enough for anyone.”

Re: Ode to the M1

#32
post #30

Earlier quoted context omitted.

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

Decent developers can do that in C++

Decenter developers can do that with a magnetized needle and a steady hand

Re: Ode to the M1

#33
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

>I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Yes, so we can go back to writing a hundred lines of imperative code to render hello world.

4 in c. 11 in assembly. Not so bad, really.

https://i.imgur.com/r2WRnZk.png

Re: Ode to the M1

#34
post #26

Weird, I've had the exact opposite experience with UTM. I need to get Ubuntu up and running with virtualization (emulation is too slow for GUI work), but the install simply hangs. If I forcibly reboot, the installed OS simply blackscreens and does nothing. I've spent a good few hours trying to get it to work (including turning off the display and trying to use the old tty terminal output), but eventually I gave up.

Have you tried updating UTM to the latest version? Many of these bugs have been fixed in newer versions. UTM doesn't auto update, so you have to check for updates yourself on their GitHub releases page: https://github.com/utmapp/UTM/releases

Re: Ode to the M1

#36
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

A machine that is 99% idle isn't running at 1% utilization all the time. It's idling 99% of the time and running flat out 1% of the time. The user pushes at least one core to the limit with every action they take, even if only for microseconds.

This is why performance matters even with a machine that is mostly idle. A faster system will respond faster to events. It will have lower latency when communicating over a network. It will handle user inputs faster. Users will complain that a program takes a second to respond even if the load average is 0.01.

(I know CPUs enter lower-performance states when lightly loaded. They can go from idle to their highest performance state in much less time than it takes for the user to notice latency.)

Re: Ode to the M1

#38
Still running a M1 Air 13“, now into my third job since, and refusing to bother with company provided computers. Still feeling as great as 3 years ago… will only upgrade if the next gen is substantially better (read: not just %faster somewhere).

Can comfortably develop on my lap for a full day if needed, only MS Teams draws power like crazy, but apart from that 8 hours+.

Best computer I ever had I think.

Re: Ode to the M1

#39
post #30

Earlier quoted context omitted.

Decent developers can do that in C++

Decenter developers can do that with a magnetized needle and a steady hand

I wonder if there is a name for the idea that the more you earn the lazier you get.

Sysadmins used to know a lot but earn pittance compared to “devops” or “SRE”; then those more expensive folks outsourced the majority of their hard work to cloud vendors who charge 5-11x the cost for compute.

Developers earn 5-10x more than 15 years ago, yet continue to choose solutions for their own convenience and time saving. Stating that its better for the company if they have to work less.

Surely at some point its just your job to consider the entire ecosystem and your contribution to it.

Otherwise why are you worth all that money?

Re: Ode to the M1

#40
post #8

Orbstack I thought https://orbstack.dev/ is what people are using these days instead of UTM. Am I mistaken?

Edit: The project does not run on "docker machine" as per the graceful correction by OrbStack's developer below[2].

It's a proprietary container interface that - as far as I could tell - runs on the outdated and unsupported "docker machine"[1]. An alternative would be to run a more recent container runtime of your choosing in a VM through UTM which works beautifully.

[1]: https://github.com/docker/machine

[2]: https://news.ycombinator.com/item?id=37107233

Post reply on HN