Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ode to the M1

fabiensanglard.net

Post reply on HN
Print view View original

81–90 of 286 posts

Re: Ode to the M1

#81

Post by hbbio »

oars wrote: post #42
hbbio wrote: post #16

Earlier quoted context omitted.

We got it the same day! I coded >100k LoC (the whole core of the OKcontract codebase) solely on that machine, without any external screen. Working flawlessly since day 1.

Out of curiosity, is the poor posture which comes with using a laptop (mainly over extended periods of time) something you actively think about? This is the main reason why although I love my MacBook M1 Air keyboard and screen, I still use an external monitor and keyboard for the majority of my work.

Good point!

Honestly don't think too much about it... probably I should care more. Just tend to change places regularly and run/swim daily.

Also, I keep quite a large font to be able to be further away from the screen and having a small view into the codebase forces to know it better. (vscode fullscreen of course with clock/battery in status line, hidden dock)

Re: Ode to the M1

#82

Post by j-a-a-p »

travisgriggs wrote: post #2

I like UTM too. I must be doing something wrong though. I created both X86 Ubuntu and Debian 10 VMs. They are usable, but not quick. I have been blown away how fast Rosetta 2 x86 programs run my m1. The arm embedded gcc too chain compile code 4x faster than the native x86 MBPro from a year or so ago. But the UTM VMs run about 3x slower.

Yes, before installing read that UTM uses Qemu and did not pursue it any further. AFAIK only Mac runs on apple silicon, everything else is emulated.

Re: Ode to the M1

#83

Post by krono »

kdrag0n wrote: post #44
krono wrote: post #40

Earlier quoted context omitted.

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:…

Hey, dev here — not sure what you mean. OrbStack currently ships an official build of Docker Engine 24.0.5, which is the latest version as of writing. Previous versions used Alpine Linux's build. I did intentionally delay the update from 23.x to 24.x by a few weeks while I waited for things to settle, because last time I updated from 22.x to 23.x shortly after release and some users were hit by bugs that hadn't been…

I stand corrected! Glad you were here to do so.

My confusion must have come from mixed terminology being used by others than yourself on GitHub and in articles about your project I skimmed through when looking into it.

The project might still not be for me regardless of its underpinning, although I will have to say that it's immediately obvious that you persue high standards and care a great deal about delivering a quality product.

Re: Ode to the M1

#84

Post by bombolo »

tsimionescu wrote: post #66
bombolo wrote: post #30

Earlier quoted context omitted.

Decent developers can do that in C++

Sure, if they're calling into an Electron front-end. Otherwise, each front-end is different so no amount of C++ and dev exeperience is going to take your Android UI calls and transform them into iOS UI calls. So, you'll have to build your own wrappers over each native UI framework to interact with, costing more money.

Ah, you live in a parallel universe which is the same as ours but Qt and other frameworks to do exactly this but without wasting a ton of resources don't exist?

Re: Ode to the M1

#86

Post by rhaway84773 »

winter_blue wrote: post #62
zondafan1 wrote: post #28

Earlier quoted context omitted.

> 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. Web technologies are fine, but what we really need is some kind of lightweight browser which allows you to use HTML/CSS/JS, but with far lower memory usage. I found https://ultralig.ht/ which seems to be exactly what I am looking for, but the license is a major turn off…

What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an e…

We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps.

GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform.

HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS which was the original lingua franca of the web, and there are tons of libraries, frameworks, tools, components, etc available in the HTML/CSS/JS world that makes development easier and quicker.

Re: Ode to the M1

#87

Post by the_gipsy »

zarzavat wrote: post #69
mrd3v0 wrote: 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…

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there. The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

If somebody just made Electron into a HTML/CSS/JavaScript engine capable of opening just the HTML/etc parts from, say, an HTTP server, and then shipped it to all users worldwide...

Re: Ode to the M1

#88

Post by shujito »

melling wrote: post #68
aktuel wrote: post #59

Earlier quoted context omitted.

I am using my Dell XPS 13 now for almost ten years. Still works perfectly.

I have a 10 year old MacBook Pro that works perfectly too. Unfortunately, Apple doesn’t allow OS upgrades. I’ll probably get an M3 and use it for 8-10 years.

Ever tried OCLP [1]? It allows for patched MacOS installs on officially unsupported Apple hardware.

[1] https://dortania.github.io/OpenCore-Legacy-Patcher/

Re: Ode to the M1

#89

Post by j-a-a-p »

warvariuc wrote: post #5
travisgriggs wrote: post #2

I like UTM too. I must be doing something wrong though. I created both X86 Ubuntu and Debian 10 VMs. They are usable, but not quick. I have been blown away how fast Rosetta 2 x86 programs run my m1. The arm embedded gcc too chain compile code 4x faster than the native x86 MBPro from a year or so ago. But the UTM VMs run about 3x slower.

I use Ubuntu in UTM, but I installed the ARM64 server version, then the desktop packages.

Interesting, this results in a fully functional desktop version?

I have a M2 and the hardware is great, but the OS that came with it not so. If I could replace the OS with Ubuntu that would be great. (Windows would also be great, but I have no experience in installing that)

Re: Ode to the M1

#90

Post by [deleted] »

melling wrote: post #68
aktuel wrote: post #59

Earlier quoted context omitted.

I am using my Dell XPS 13 now for almost ten years. Still works perfectly.

I have a 10 year old MacBook Pro that works perfectly too. Unfortunately, Apple doesn’t allow OS upgrades. I’ll probably get an M3 and use it for 8-10 years.

[deleted]
Post reply on HN