I wish I could upgrade from my 13" mbp that's the last of the intel i5 series. My 16" M1 Max that I was issued at my last job was a dream, and now that I'm playing with SwiftUI and dealing with xcode, it's feeling slow and noisy. Unfortunately I was laid off, so no M1, and the ram upgrade to the 64gb or 96gb is insultingly expensive still. As nice as it is, it isn't a $4k boost in productivity.
Ode to the M1
131–140 of 286 posts
Re: Ode to the M1
#132Earlier 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.
From the fine article: "Remember when Photoshop opened in 1s on SSD?" I do remember. And it now takes A LOT longer on insanely fast CPUs and SSDs. And I hate it every time I have to wait for it.
So it’s not Electron that’s slow, but modern software?
Re: Ode to the M1
#133Earlier quoted context omitted.
The base model price is a little misleading. 256 and 8 gb are lowkey unusable for anything but a Facebook machine . I always look at the price for the 16/500 or 16/1t machine as the reference point
That’s not true at all. Have you actually used one? Edit: obviously if you need a windows vm you’re out of luck at 8gb ram
You’re out of luck if you need docker.
M1 Macs would make fantastic Linux laptops, because macOS is appallingly bad at backend development. It makes it up in sheer hardware power and efficiency, otherwise I’d be completely at loss why it’s so loved.
Re: Ode to the M1
#134Earlier quoted context omitted.
write a hello world application in gtk or qt and see how much assembly you get.
x86_64 assembly, gtk3, 21 lines / 19 instructions build with e.g. gcc hw.s `pkg-config --libs gtk+-3.0` .globl main;main: push %rbx xor %esi, %esi xor %edi, %edi call gtk_init@PLT lea .HW(%rip), %r8 xor %edx, %edx xor %esi, %esi mov $2, %ecx xor %edi, %edi xor %eax, %eax call gtk_message_dialog_new@PLT mov %rax, %rbx mov %rax, %rdi call gtk_dialog_run@PLT mov %rbx, %rdi call gtk_widget_destroy@PLT xor %eax, %eax pop…
Are you sure you couldn’t wrap that up in another library and just do everything in a single call?
Re: Ode to the M1
#135Earlier quoted context omitted.
x86_64 assembly, gtk3, 21 lines / 19 instructions build with e.g. gcc hw.s `pkg-config --libs gtk+-3.0` .globl main;main: push %rbx xor %esi, %esi xor %edi, %edi call gtk_init@PLT lea .HW(%rip), %r8 xor %edx, %edx xor %esi, %esi mov $2, %ecx xor %edi, %edi xor %eax, %eax call gtk_message_dialog_new@PLT mov %rax, %rbx mov %rax, %rdi call gtk_dialog_run@PLT mov %rbx, %rdi call gtk_widget_destroy@PLT xor %eax, %eax pop…
Are you sure you couldn’t wrap that up in another library and just do everything in a single call?
you jest, but in fact you could.
Re: Ode to the M1
#136Earlier quoted context omitted.
Money is only part of the equation. It's pretty wasteful to have to toss a computer because one component failed, when that specific component would be replaceable in other brands.
Apple has a tradein program where you can trade in your current Apple device for a discount on a new device.
Thats even worse! Tradeinn orogramm are insidious, their purpose is to drain the marlet of second-hand goods, so to increase sale of new ones.
Every time you sell a second. hand conouter you are cutting their sale of new ones.
Re: Ode to the M1
#137> 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…
Keep hoping, because it won’t happen. Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.
> Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.
And you know that because you’ve analyzed whole market and know opinion of users of every web software? Definitely not because you only live in bubble of other software engineers so you’re not exposed to complaints of common folk?
Re: Ode to the M1
#138Still 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.
I'm a bit confused by the "still". How often would you expect to upgrade hardware? Keeping a computer for three years is completely normal for most people.
So true, 4-5 years seems reasonable to me, 3 years isn't much
Re: Ode to the M1
#139Earlier quoted context omitted.
True… here I’m going wondering if it’s time to upgrade my 2017 MacBook Pro because a couple of keys started to fail and I’m having a hard time…
This year I upgraded from MBP 2015 to M2. I am still bothered by the notch on the M2.
I use a completely black background, I forget the notch exists plus I save a bit of battery.
Re: Ode to the M1
#140Earlier quoted context omitted.
Keep hoping, because it won’t happen. Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.
Consumers care but have no choice. Like consumers that want to buy a phone that fit in the hand… there is none at a reasonable price.
The demand for small phone is completely overblown online.