I don't think this would accidentally eat at Apple's laptop market because the laptop-in-a-stick option would still need an external screen. If you're travelling for work or something, might as well just have your phone AND your laptop, instead of phone + external screen full of messy cables. but YMMV
I'm still waiting for the apple laptop killer (a 12h+ laptop with plain Ubuntu) but it's still brittle as fuck. I'm so frustrated by the current state of the mobile computing space. I have to have an Apple locked down device, which I hate, just because I want proper battery life.
A aarch64 Ubuntu vm inside MacOS runs faster and lasts more time than a booted up Ubuntu on arm in these devices. This is how far behind these things are.
and what bums me the most is that it's all about software. The hardware is great, but software on Snapdragon is taking a lot of time to catch up and it screams M$ lobby to me
Pretty sure there are plenty of traditional x86 Linux laptops that have north of 12h battery life. System76 comes to mind (mandatory "System76 is just a Clevo wrapper" comment).
My AMD Framework 13 running Fedora (an officially supported option: https://frame.work/linux ) also gets around that amount of battery life. And can run games surprisingly well.
My AMD Framework 13 running Fedora (an officially supported option: https://frame.work/linux ) also gets around that amount of battery life. And can run games surprisingly well.
Macs don't throttle when you unplug it. All AMD laptops do.
Even when plugged in, AMD laptops are quite a bit slower than Macs. When unplugged, it's not even close.
That puts you at just over 5W average on a 61whr battery. I find that very hard to believe. 5W is achievable if you drastically limit the CPU governor, physically disable the mic/camera, using a chart-topping power-efficient SSD, all while actually doing nothing. Just a single YouTube video in a single firefox tab will bring you up to at least 10W.
> Just a single YouTube video in a single firefox tab will bring you up to at least 10W.
10W for video playback is a lot. 5w average for light workloads is not unrealistic... I think your perception of power consumption is a number of years out of date at this point.
After all, Apple claims 18 hours from a 54watt-hour battery - you really think nobody else can get within 2x of that?
Clevo is their ODM. They work with Clevo to put together a laptop, and Clevo gets the right to sell a Windows variant. Their version differs, particularly in firmware but also possibly in chips.
Laptops with Intel Lunar Lake (i.e. 258V) CPUs get upwards of 12 hours easily, often in 15-18 hour range depending on the battery size. Just a quick search reveals for example Dell XPS 13 9350 (Core Ultra 7 258V) is Ubuntu certified [1], weighs 2.6 pounds, and has long battery life (17-18 hours video streaming on Windows).
Lunar Lake laptops throttle a lot when unplugged. They run benchmarks plugged in and in maximum performance mode but battery benchmarks in max battery mode.
True, but the throttled performance on battery is enough for office work / coding / browsing workloads. Is it matching Apple silicon, probably not. Is Linux matching MacOS on SW/HW optimization? Probably not either.
Microsoft has definitely put a lot of work into the arm surface laptops. I'm having a good time using a surface 15 inch. I picked the lowest spec model, only 16 GM ram and 256 GB drive. But I use it like a terminal: I run vscode server on either my desktop or a VM, and the vscode client on the laptop. So the actual compiling and I think also the LSP is running remotely, but I still have a responsive editor on the client. The result is phenomenal battery life, 16 hours if not more. It also has the side effect that any build artifacts are produced directly on the server, no more uploading multi-gigabyte containers over my home Internet to the cloud. But of course, it assumes 24/7 internet connection.
I would appreciate a native Linux arm laptop, but this setup works for me in the meantime.
> I'm still waiting for the apple laptop killer (a 12h+ laptop with plain Ubuntu) but it's still brittle as fuck.
Try Intel's Lunar Lake. My Zenbook 14S (S is important here!) does 12h+ on VS Code, browser & meetings (but compilation is remote). The screen is better than on Macbooks (it's high-res OLED), overall build is good. You probably won't be able to run Ubuntu LTS without installing latest kernel, but regular version should do just fine.
If you don't like ASUS, you can also try Thinkpad X1 Carbon Gen 13. It's a bit on the smaller side and costs twice as much, but it's a pretty neat device.
In an alternate universe my hope was AMD builds a killer mobile/embedded Arm APU instead of the failed Opteron A series. Of course this would never happen because what software would run on it? Apple on the other hand steers the entire ship so they had the ability to produce the entire stack. Even MS could not build an Arm ecosystem.
> I have to have an Apple locked down device, which I hate, just because I want proper battery life.
Chicken and egg. The Linux vendors don't have the power to drive ODMs nearly as much as Apple because everyone keeps buying Windows and slapping Linux on it (then complaining online when they have to be the systems integrator themselves, fixing the inevitable razor cuts)
We learned one simple lesson, the past 10 years: if you want good ARM support, it has to come from the vendor. Nobody else can reverse-engineer devicetrees or GPU drivers with a remotely comparable release cadence. Linux has supported new x86 chipsets on day-1 since forever now; compare that to Broadcom or Apple Silicon's "best effort" community support that often takes years to boot into a graphical environment. Forget about stability or regression testing, it's a tinkertoy.
This is a shame because all the ARM licensees worth buying hardware from always have higher margins on smartphones or services. They have no commitment to supporting the PC or server market, let alone the software they use or featureset they depend on. It's no wonder that ARM adoption is stalling on the runway while Power11 gets upstream kernel support and RISC-V displaces integrated ARM ICs. Their only stakeholder is making their money off iPhone apps, not professional software.
Get a recent AMD or Intel laptop, add Linux, and install TLP. Idk if you'll get 12hr or not, but my Asus PX13 survived a 9hr+ intercontinental flight while working on a C++ codebase including compilation in Sublime Text with clangd LSP plugin (and no, I can't fall asleep on planes lol)
> but software on Snapdragon is taking a lot of time to catch up and it screams M$ lobby to me
On Linux?
The hard reality is that Apple invests in SoftBank, the owner of ARM's IP, and nobody in the Linux (or Windows) world does the same. They really just don't care. There aren't entrenched hardware manufacturers that want to reprise the featureset of UEFI on ARM. You will be waiting forever if you demand an ARM laptop that works like an x86 one with Linux.
ARM has been like this forever, and it's unlikely it will change due to Asahi or Apple Silicon. ARM lives or dies based on Apple's treatment of it, no other corporate stakeholder has comparable control over the ISA.
I'd suggest that top non-Apple businesspeople try using a MacBook for a few weeks, hopefully it sparks some fresh thinking and decisions. Like it or not, Apple's advantage in battery life (and processor efficiency) is remarkable. If I recall correctly, Samsung made a real dent in the iPhone's lead with the Galaxy S2 around 2011, four years after the iPhone launched in 2007. But with the M1 chips released in 2020, Apple's lead this time around seems poised to last even longer.
Well, there's your leading qualifier. Covid taught us that businesspeople can do their work on an iPad with Google Docs if they had to. It's not much of a surprise to anyone that they can do their work on a Mac with a souped-up iPhone processor.
My shock with Apple Silicon is how it collapses with non-browser-oriented tasks. The moment I stop watching YouTube it's like I'm back on Linux in 2008 again, trying to run everything through a Windows VM. My old Pro Tools plugins? Gotta use a VM, Rosetta won't work. A modern OpenGL program? Gotta wrestle depreciation flags to compile it. Even my old Homebrew casks had to get rewritten because Apple Silicon had to switch stuff around again.
By the time people insisted "try the M2 for a few weeks!" I was already dailying NixOS. MacOS is continuing the frying-pan-to-fire arc it started ever since 10.14.
Offtopic: This is awesome, but oh my god, my heart almost skipped a beat when I thought it would be Renoise itself going opensource. I've been tracking with Renoise for the past 14 years and I love it to bits.
This. If you are running your agent loop, MCP does nothing.
MCP is an inter-process (or inter-system) communication standard, and it's extremely successful at that. But some people try to shoehorn it into a single system where it makes for a cumbersome fit, like having your service talk to itself via MCP as a subprocess just for the sake of "hey, we have MCP".
If you own your loop AND your business logic lives in the same codebase/process as your agent loop, you don't need MCP at all, period. Just use a good agent framework like PydanticAI, define your tools (and have your framework forward your docstrings/arguments into the context) and you're golden!
Hi! I am a bit lost in all of this. How do you create your own agent and run your own loop? I've looked at PydanticAI but don't get it. Would you please give me an example? Thanks!
My time to shine! I'm a computer programmer but I've been making music digitally for about 15 years now
The software you want is called a DAW - Digital Audio Workstation. There are 300 DAWs, you need to find the one that fits your 'style' or 'workflow'. There are a multitude of paradigms, as making music is not a single technique.
Once you find your DAW, my recommendation is to just make lots of music. Make the music you imagine in your head. Make the tracks that don't exist but you wish they did. Your first 100-200-300 tracks will all be extremely crappy in hindsight, but when you finish them you'll think they are, at the time, a magnum opus each. Keep iterating that process over and over and after many years, you'll start making something that you'll feel semi-proud enough to be able to show your friends!
Your enthusiasm is shining through. For someone wanting to do exactly what you said "just make lots of music. Make the music you imagine in your head." and faced with the issue of "There are 300 DAWs, you need to find the one that fits your 'style' or 'workflow'.", how do I choose? I am not a music maker, I have never made music - I would like to though. I don't even have a style or workflow. I don't know how to start.
Start by starting! Pick a DAW, if you can't pick one, pick one of the most famous. Ableton Live maybe?
Just put some notes down and hit the play button. That's the whole feedback loop. Everything else is just honing your skill and repeating this feedback loop 80 thousand times until you start getting stuff out that you semi-like :)
PS: My background is also as a computer programmer with previously zero music making experience. My first tracks were absolute garbage, and that's fine. Every new track is 0.01% better (read: less worse :') than the last one, and that's it. Rinse. Repeat.
I found that design decision a bit odd as well, as the author states multiple times that he's interested in cycle-accurate emulation. When people go for a cycle-accurate emulator, they are purposely eschewing performance for accuracy. e.g. the Higan emulator which focuses on accuracy/code readability, but it's one of the slowest SNES cores out there (and it's fine)
I took that to mean it takes less pico cpu power to reach the same cycle-accuracy.
Esp since there arent graphics routines in the c64 to speak of! There are no plot, screen clear, line, etc. Every program rolls its own.
As a joke a real freak could polyfill/hijack e.g $ffd2 output single char to cursor position in native pico code instead of 6502 to accel basic programs. That could be weird and phone to speed up all thise routines... but at that point just clock it all faster :)
The 0. prat is irrelevant in MAME, you can see that both projects simply increment the number on every release. They could just as well do v<timestamp> and reap the same monotonically increasing thing with a temporality aspect as well.
