Attempting Linux on Microsoft Dev Kit 2023
blog.alexellis.io
blog.alexellis.io
> Whilst I enjoy this kind of tinkering, it was disappointing that a "Dev Kit", built for developers can neither boot Linux, nor enable a custom Linux Kernel for WSL2.
> What's that I hear Hacker News and Reddit cry? "It's a Dev Kit for Windows, you moron!" That may be the case, but Microsoft "Loves Linux", and clearly has worked hard to make WSL2 available out of the box on these devices.
If something is named "Dev Kit" does it have to revolve around supporting a monoculture right out of the box? Secure boot is trivially unlockable, and Microsoft is losing money on the R&D and probably hardware as well. Someone will probably figure out how to get Linux natively running.
Looks like they're just not happy that they're not able to immediately (ab)use the hardware meant for Windows on ARM developers for dozens or hundreds of cheap CI/CD machines for their commercial operation, which would prompt MS to raise the price for everyone or make it closed for verified Windows devs only(like Xbox Dev kits).
I respect the grind, and Hacker News is all about using and abusing hardware in unintended ways, but I don't like the attitude and expectations in the quoted parts that everything should revolve around their niche use case of being able to run cheap CI/CD servers just because it has dev in it's name.
What we expect next? BSA to raid my home because I run Linux on my Microsoft branded hardware, or connect Microsoft mouse to a Linux box?
The irony of saying this in the context of Windows is thick enough one could cut it and use it to build a sizeable home.
Up until about a decade ago, Microsoft arguably made the world's only good IDE. (ignoring some relics from the 80s!)
It isn't as if Windows is some developer wasteland.
This is rather my point.
It's still the case that, in many businesses, nobody got fired for buying Microsoft. And, despite the increasing importance of Linux on the server, there's a _lot_ of software that ties its users to Windows. Too nad WSL doesn't live up to its name.
If you're referring to Visual Studio then I think you and I have very different definitions of "good".
Go to 2010 Linux and find me an IDE with:
1. A functioning graphical debugger that works across multiple languages, both native and JITed
2. A fully featured WYSIWYG UI editor that can generate backing code in multiple languages
3. Comes with a SQL engine setup and ready to use for development, that it can seamlessly connect to for testing out code locally[1]
4. Can step from your code into SQL statements and back again
5. Can step from code you are debugging on a remote box, to SQL code running on yet another machine, and back again
6. Has functional, production ready, data binding that works with arbitrary data sources, that also fully integrates with the GUI builder
7. Integrates with source control
8. Integrates with task/work item management
9. Enables the workflow of you get an email about a fault on a server in a test environment, you click a link, and the IDE connects to the remote machine, downloads symbols, and starts up in the debugger
10. Automatically fetches the proper debugging symbols for the version of code you are debugging
And again, this was all doable across a multitude of languages.
IIRC Eclipse was the nearest "competitor" and it was slower than molasses and didn't have anything near the same feature set.
Visual Studio is an impressive piece of software. Has it had some buggy releases? Yeah. Does it feel super outdated now? Yes it does, in comparison, VS Code's ability to navigate around files/projects is incredible.
But I had a better developer experience using Visual Studio and C# a dozen years ago (!!!) than I have with Node JS now.
[1] The modern cloud version of this is such a disaster.
Linux and UNIX doesn't build tooling this way, because they believe that you make one tool to do one thing well, and these things you mention while related are not one thing. You'd use the OS as an IDE in this context.
The mindset is changing over time, systemd, vscode, etc.
No commercial UNIX has ever followed that mantra.
No commercial UNIX besides macOS/iOS has enjoyed anywhere near GNU/Linux's success, either.
Meanwhile, Emacs worked fine. Netbeans worked fine. Eclipse worked okay. Qt Creator existed (though I can't attest to how well it worked then). There were definitely options, and while sure, they lacked a lot of those fancy bells and whistles, at the end of the day were those really worth turning computers into passenger jets?
> But I had a better developer experience using Visual Studio and C# a dozen years ago (!!!) than I have with Node JS now.
That bar is so low that even ants have to duck to get under it.
I prefer to use 'not earning' in this situations. This device were never intended to bring money directly in the first place and anything successful [developed with the help of this device] can bring thousands and millions of revenue. It's investing for a revenue multiplier.
It doesn't appear they did anything specific for this kit, nothing obvious in the changelog anyway. Perhaps just some combination of things they've done for other UEFI bootable Arm64 hardware. OpenBSD arm64 uses u-boot, so also maybe just some support that was already there.
What's that I hear Hacker News and Reddit cry? "It's a Dev Kit for Windows, you moron!" That may be the case, but Microsoft "Loves Linux", and clearly has worked hard to make WSL2 available out of the box on these devices.
It’s not a scathing attack or anything, but it is in fact critical of Microsoft.
But I guess I'm just adding to the problem by turning it into an equally tedious meta-argument. I'll stop now ...
If people start buying MS Dev Kits to run Linux CI agents on them this defeats the whole purpose of having a dev kit: getting more people to write programs on and for Windows 11 on ARM.
Dev kits are unlimited/unlocked machines by historical definition. They should allow experimentation. Locking Linux behind WSL2 is Microsoft's dream, and being oblivious about it won't help us in the future.
People get crazy when people point out that Microsoft is deprecating it's 3rd party CA slowly, or making secure boot permanent step by step, or systemd slowly adds support for closed down hardware platforms which doesn't allow running unsigned/unsanctioned kernels.
GPLv3 came to being because of TiVO pulled off a similar thing, and required its kernels to be signed by their own private key.
Now why we allow another company do it and applaud them for doing so?
If we want general computing to live, we need to have mechanisms to allow us to tinker with our own devices, and shouldn't need a company to sanction a specific kernel behind closed doors.
It's 90s all over again, sigh.
> If people start buying MS Dev Kits to run Linux CI agents on them this defeats the whole purpose of having a dev kit
We're running Linux on computers bundled with Windows out of the box. So, are we defeating the purpose of the devices we buy with our own money? Same for installing ROMs to android devices, and Jailbreaking iOS devices.
The device is mine. I paid for it. I should be able to do whatever I want with it.
No all of us are. Fortunately, it's not the 90s, let alone the early 00s. We have the option of buying Linux preinstalled. It would be nice if we didn't collectively squander the opportunity.
The wider point, though, is spot on. Hardware should obey its owner, not the company or companies that made it. Fortunately, the hardware that best supports Linux also often best supports user modification, so the two interests go well together.
Of course you're right, but all hardware is certified for Windows at the design stage, and only a subset (EliteBook, ThinkPad, XPS, etc.) is designed and verified against Linux kernel. Kernel needs to workaround a great deal of cut corners or shenanigans (incomplete ACPI tables, anyone?) to be able to function on these systems.
Yes, most hardware is not designed nor verified for running against Linux. Most hardware doesn't run OSX either.
The solution, as with Mac, is to only buy systems with Linux pre-installed and supported.
> Kernel needs to workaround a great deal of cut corners or shenanigans (incomplete ACPI tables, anyone?) to be able to function on these systems.
Yes, exactly. Just like with Macs, one should buy systems where the firmware (including ACPI) is designed to run Linux. Hackintoshes are interesting, but few seriously consider that the main way of running OSX.
All in all, we're on the same page. The rest is being pedantic about word semantics. :)
> The solution, as with Mac, is to only buy systems with Linux pre-installed and supported.
Yes!
"Windows Dev Kit 2023 (code name “Project Volterra”) is the latest Arm device built for Windows developers with a Neural Processing Unit (NPU) that provides best-in-class AI computing capacity, multiple ports, and a stackable design for desktops and rack deployment. Purpose-built with everything you need to develop, debug, and test native Windows apps for Arm."
We repurpose many purpose built things for other ends. People called as hackers for doing that back in the day, and we applauded them.
Why the change now?
Not every developer is a UNIX developer, and not every piece of hardware has to run a POSIX clone.
Of course not every developer is a UNIX developer. I don't expect that.
But, I just need an example for a device which I can buy for the last two decades and which is primarily designed for running Linux, and accessible by ordinary developers (i.e. not costing two kidneys and an arm, has a home/portable form factor, and is serially produced).
Because all of the desktop systems provided the big manufacturers are either not Linux ready or very limited in hardware & configuration flexibility or both (most of the time).
Since the systems are not Linux friendly, I always rolled my own from components which are designed to work with Windows.
My Asus 1215B netbook for travel purposes has been sold with Linux on it.
Too soon! I miss the netbook days. Too bad Microsoft killed them.
Google OSes cost zero, with a proper experience and a store Joe and Jane care about.
For me it was a shitty hardware (Intel Atoms coupled with slooow HDDs or tiny and slow eMMC SSDs) with the market eaten by smartphones (for always on Internet connectivity) and iPads/tablets for anything requiring a bigger screen but not yet a full notebook.
Netbooks are nice devices, but they were never intended for developers.
Developers use whatever they can, including crap Chromebooks as thin clients to cloud instances.
Not every developer can/want to use cloud instances, like not every developer is $OS_OF_CHOICE developer.
Developer is someone that writes code with a programming language, that is all.
Thanks again.
We everyday try to convince people that hacking is not malicious by nature, but means to make things do things which are not designed to do out of the box.
Every day, everywhere, incl. this very site. Which is called Hacker News, BTW.
Yeah, but not people whining that iphones don't run Ubuntu out of the box.
> People get crazy when people point out that Microsoft is deprecating it's 3rd party CA slowly, or making secure boot permanent step by step
I've long thought WSL and friends were a stalking horse for precisely the sort of locked-down environment I hate, and I've been expecting this incremental approach ever since XP started requiring activation. However, I'd notice that this particular bit of kit doesn't forbid you from disabling "Secure" Boot. It sounds more to me like there's some sort of kernel/device tree issue here and not Microsoft being dickish (at least directly).
I'd suspect that Microsoft will support Linux on it in much the way Apple "supports" Linux on M1 hardware, that is, "We won't stop you, but you're on your own, and if you break it you own both pieces."
Looks like ARM and RISC-V will be the next open frontier for Linux in the near future. x86 is going to the way of intense lock down in an accelerating pace.
ARM also supports these technologies, but at least it'll be more accessible and more diverse, I hope.
They allow Secure Boot to be disabled, which is nice. Expecting anything more from them is absurd.
No manufacturer ever openly supported Linux in their consumer systems, and never supported Linux in their professional lines (ThinkPad, Compaq NX, EliteBook, XPS, etc.) openly, to not sour their relations with Microsoft.
Linux happened to work by miracle because of well laid out hardware and high quality BIOS implementations. In fact, they were vetting the hardware/software to be compatible with Linux, but never acknowledged it.
Microsoft is trying to close that hole by forcing secure boot and retiring 3rd party CA.
Wait, what? That seems to be very wrong, at least in my experience. Going back to the original Sega Dev Kits and the Atari Jaguar Dev Kit, and now to the XBox and PS dev kits -- none of those make it easy to run whatever you want.
In my experience Dev Kits are targeted toward a specific set of use cases. And they're meant to enable those -- anything else is "you're on your own".
So, Windows is not a general computing OS and the platform running Windows is not a general computing device anymore.
So, we're ending the era of most ubiquitous general computing platform (PC), and the general computing itself, and converting Windows to a firmware for a very closed platform.
Acknowledging and accepting this is a great step forward for walled gardens and a huge step backwards for us.
I for one don't welcome our computer controlling, platform limiting, Linux loving overlords.
The issue is if the DevKit is intended for any and everything. My point is that they never were. Were the original iPhone dev kits set up to easily run Windows Mobile? Are car devkits that can accomodate Apple Car Play or Android Auto, easily able to run their Windows equivalent?
All these kits have platforms in mind when building them and are tested to support them. Anything above and beyond is use at your own risk.
If Windows is a general computing OS, the hardware is also general computing hardware. If the hardware is not intended to be used for general computing, then the thing running on it is not a general computing OS, but just a firmware to fulfill some tasks.
My argument is accepting that "Microsoft Dev Kit" is built to run a specific piece of software brings us to a slippery slope that any and every Windows certified system is also won't be a general computing hardware from now on, esp. on ARM platform.
Hence we can see that Dev Kit 2023 is the first step of locking down the platform for once and for all.
If we see the platform as a general computing platform, and Windows as a general computing OS, then we shouldn't get offended by the effort to run Linux or other OS on it, and similarly we shouldn't get offended by the request.
WSL is just a virtualization platform. Accepting that WSL2 works fine also brings us to the slippery slope that future hardware doesn't need to support Linux on bare metal, because we have already have WSL2.
What happens when (not if, but when) the 3rd party CA expires/gets discontinued or Microsoft discontinues (or intentionally breaks) WSL2 or both to cripple or block Linux from running on bare metal on consumer devices?
Will we run x86 servers at home to run Linux, then?
I don't believe that Microsoft envisions a future where Windows capable platforms have the ability boot anything other than Windows. It'll be a firmware in the proverbial sense, not an OS, because we won't have a general computing platform which can run any OS which understands that hardware.
I think you simply want to run other OSes on a device. That's a fine thing to want, but I think you're conflating that desire with other concepts.
Actually TiVO didn't do that, instead they made their proprietary software running on top of Linux break when you modified Linux. The GPLv3 doesn't prevent that either, even though RMS wanted it to. Also, even GPLv2 requires users to be able to modify, rebuild and reinstall the vendor installed GPLed software.
https://events19.linuxfoundation.org/wp-content/uploads/2017... https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...
Agreed with everything else in your post though.
You are absolutely right, of course. It just doesn't mean Microsoft should help you run whatever you want on it.
You are absolutely right, of course. It just does mean I expect Microsoft to not spend effort to hinder the possibilities.
I just don't want a second season to Halloween Documents, that's all. Keep the platform open. We (the developers) will do the rest.
Color me (pleasantly) surprised.
Windows RT tablets had UEFI/ACPI. I Assume it was easier to bolt Intel baggage onto Arm machines so they didn't have to change core windows kernel components which are probably deeply anchored to the PC architecture.
(I suspect it will eventually be a click-through process, but to flip the script I don't typically try to run Windows on my Raspberry Pis -- and have reasonable expectations of the outcomes if I do, even with WoR)
That said, I would _definitely_ buy one for myself if it was available in my country, to run WSL2 and do some ARM development (full disclosure: I'm an MS FTE who's primarily Linux and Mac-centric, _and_ writing at taoofmac.com for 20 years, so I try to have an even stance in these things).
It's on my list of prospective Xmas "self-presents", although I would still need to spend a little more to match the devkit specs (although it is available in a "pro" config that is closer).
I wish there was a reference to that. I’d love to read an up to date report on how hardware support for that arm laptop is coming along.
Anything interesting to report about that?
"Patrick Wildt, an OpenBSD maintainer replied to one of my tweets and told me he had OpenBSD 7.2 up and running on his, so I thought I would at least try that out."
And on twitter he mentions it's unmodified OpenBSD..."@bluerise told me OpenBSD would work just by flashing a USB pen drive. He was right..."
So it's likely possible with some experimentation.
Nevertheless, using this computer will require a lot of reverse-engineering work for various devices, e.g. the GPU, the WiFi interface and many others. For now, OpenBSD can use only a frame buffer for display.
There was not long ago a presentation from Lenovo about the support of Linux on their products.
They make a laptop with the same Qualcomm chip. After some efforts, their Linux team has succeeded to boot Linux on it, but many of the peripherals are not working yet and they do not intend to provide official support for Linux on it, because there is no help or documentation from Qualcomm.
Unfortunately you're right, reverse-engineering Adreno would take monumental effort.
Patrick Wildt posted the boot log for OpenBSD if anyone's curious what else OpenBSD sees on the device (and doesn't see).
Honestly the reality is that people will still buy this for Linux usage, even if some of the peripheral support is bad, because the options for UEFI-capable "desktop class" ARMv8 is still pretty bad. You can't buy anything with reasonable upstream support that is ARMv8.2+ capable, and almost no easy-acquirable ARMv8.2+ silicon exists even without upstream support -- except Apple, of course. Maybe the best alternative I know of is those NXP Layerscape processors. But this comes stacked with RAM and NVMe out of the box, compared to those.
These things are relatively fast, completely integrated OOTB, and can fit under your desk and so it'll still be a hit because it ticks all those boxes even if like, the camera doesn't work. It's honestly a very good price for an all-in-one CI machine that you could throw in a closet or whatever.