> 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.
Insane expectations. Imagine buying a brand-new Mac Mini with an extremely new processor (ARM is not like x86-64, every single SOC has its own distinct way to bring up the machine) and blaming Apple that your favorite Linux distro didn't immediately flawlessly work
> and Microsoft is losing money on the ... hardware as well
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.
> 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.
Having lots of features != being of high quality. If Eclipse was "slower than molasses", then VS was a brick - as many a poor computer of mine from back then can attest, fans a-spinning at speeds that made hurricanes feel like gentle breezes all because I'd double-click on some random file that VS decided "hey I can open this therefore I should be the default" (and thanks to all that feeping creaturism, that was a lot of files).
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.
This may be obvious to you, and I am trying not to put words in your mouth.
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.
> Windows was the dominant operating system for developers for nearly two decades.
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.
Unrealistic and unfair expectations here. Microsoft isn’t doing anything to stop you from booting other OSes on this device. OpenBSD devs did the work, so OpenBSD boots on it. Linux devs now need to do the same if they want to support this dev kit. Not Microsoft’s problem.
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.
Okay. Anyway, OpenBSD works, proving that there’s nothing stopping Linux from working except the time and interest of Linux developers. I’m sure they are interested and the necessary modifications will be made soon enough.
Embedded-looking systems usually need an FDT blob for booting Linux, this seems to be the missing piece according to the article. It shouldn't be hard to provide it on the hardware developer's end, while a bit more complicated to infer from the OS developer side.
And yet, somehow, OpenBSD works just fine already. Perhaps relatedly, this device is UEFI based, so unlike most ARM devices, it has a standard boot process and hardware enumeration mechanism.
>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.
It’s not a scathing attack or anything, but it is in fact critical of Microsoft.
Fair enough, but those were a couple sentences out of a multipage article. I just get tired of comments for any article that involves Microsoft in some way turning into generic arguments over whether people should like or hate Microsoft, overshadowing the actual content of the article. The arguments tend to rehash the same tropes over and over and are pretty tedious and not interesting.
But I guess I'm just adding to the problem by turning it into an equally tedious meta-argument. I'll stop now ...
> 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 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.
That's an ARM platform sold by Microsoft. It's supporting Windows alright, but it's a hardware platform at the end of the day.
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.
> 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
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."
Not providing the device tree for including in the Linux kernel is breaking by negligence in my book.
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.
No, being an ethical company they shouldn't actively hinder it. Linux people will give the necessary effort to support it.
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.
I don't see it going anywhere nearly as far since their bootloader situation is still so broken. There just isn't any one size fits all solution for booting linux on arm, even on machines that do have open bootloades. At that point it only works if the manufactueres explicitly help to allow such a thing (or on phones they get custom recoveries), which makes it just as bad if not worse than x86's status quo.
About 10 or 12 years ago I said that the future of Linux on the desktop is as a VM running under a Windows hypervisor. It took longer than expected but that future is within sight.
> Dev kits are unlimited/unlocked machines by historical definition.
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".
If we're putting this Dev kit to the same category with non-general computing devices' dev kits, the outlook becomes a much more bleak:
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.
Windows is a general computing OS. I'm not sure where you're getting the idea that it's not. Even in the article it states that WSL2 seemed to run fine.
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.
All the dev kits you point are not dev kits for general purpose computing devices. So, the point is moot.
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.
The HW is intended for and can be used for general purpose computing. I think you seem to think that for something to be general purpose it has to be able to run everything. I've never heard that definition before and honestly, if that's the case then there is no general purpose computing HW in existence. The standard definition is that it can run, in a reasonable way, most consumer/productivity workloads. It's not about saying "This HW doesn't run Linux" or "It doesn't run Adobe Premiere 12.2".
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.
> We're running Linux on computers bundled with Windows out of the box.
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.
> We have the option of buying Linux preinstalled. It would be nice if we didn't collectively squander the opportunity.
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.
I don't think it's true that all hardware is certified for Windows.
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.
> GPLv3 came to being because of TiVO pulled off a similar thing, and required its kernels to be signed by their own private key.
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.
Nope. It’s just an ARM PC, sold by Microsoft. Not different from a Dell desktop PC, or anything in the same category which comes with Windows pre installed.
"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."
For starters those hackers can start by supporting OEMs that care about doing business selling hardware with Linux, develop the next PI clone with RISC-V or something.
Not every developer is a UNIX developer, and not every piece of hardware has to run a POSIX clone.
Trusting your experience, can you please give me examples to OEMs which support Linux on their customer accessible hardware by default for the last two decades, and can you also detail on which devices we run Linux mainly for our daily needs, and what these devices are designed and certified for?
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).
Can you rlaborate why do you think MS killed them?
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.
You refuse to buy from a company that hasn't been selling linux-focused hardware for several decades? Do you think that's the right approach for getting companies to enter that market? I personally don't think many companies in the space are much interested in a 20 year ROI.
No. Instead I buy highly curated, cutting edge DIY systems. These systems come with rough edges, which are smoothed over in a couple of years, and I use the system with all of its features for seven years or so.
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.
I don't think many have ever applauded people complaining that products designed, marketed, and sold for one purpose are not fit for some other purpose, but rather for making them work anyways.
Many do applaud the people who jailbreak iOS, unlock game consoles and android phones by major manufacturers, reverse engineer systems to add features they need or repurpose old/legacy or bleeding edge systems to do what they need.
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.
why compile for a dead market. F'n hell no. I will tinker with this thing nonetheless, just for the fun of it and to learn something. FreeBSD(or was it OpenBSD?) already boots on this thing, which should make writing up a device tree not impossible.
Surprised that OP managed to disable secure boot (implies there is a normal UEFI boot style firmware), managed to at least attempt to boot certain Linux versions and got OpenBSD working. Seriously I thought this thing was going to be locked to the bone or restricted by black magic arcane hardware like the M1.
> Surprised that OP managed to disable secure boot (implies there is a normal UEFI boot style firmware)
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 haven't tracked Windows ARM beyond the IoT editions, but you are mostly right. I see it as good re-use of something that makes complete sense if you want to match Intel configuration and hardware security options.
I'm a bit biased here, but trying this kind of thing on a machine that is both completely new and designed to be a Windows development kit has somewhat predictable outcomes.
(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).
Since this keeps getting upvoted and downvoted in waves and is thus obviously garnering some attention, allow me to point out that the Khadas Edge 2 is a pretty amazing ARM SBC that runs Ubuntu just fine, and would most certainly have been a much better experience for the OP.
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).
What an interesting device. Sadly, it is available only in the US and maybe a few other countries. If you try to access the MS store page from, say, Switzerland, they are very passively-aggressively saying "Page not found". I hate so much these availability restrictions.
FWIW whilst it doesn't run Linux directly at the moment, it runs WSL2 just fine, and you can setup Windows OpenSSH server to launch WSL2's bash on connection, so you can use it for remote Linux work ok.
A friend of mine has one. Have yet to get my hands on it, but he reports great battery life and calls it "very snappy". Then again, he is not a developer (he's a salesperson in the medical industry), so YMMV.
Meanwhile, of all the boards around meant to run Linux, and there's a boatload of them, I fail to see a single one that prevents to install Microsoft software on purpose.
Tl;dr: it boots OpenBSD successfully already, so getting Linux to run can't be that hard even though mainline support is obviously not here yet. Someone will figure out how to boot a Linux kernel on this, probably the PostmarketOS or Asahi folks.
"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.
It is very good that it is possible to boot non-Windows OSes.
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.
Freedreno already has OGL 4.3 for supported devices and I believe people have confirmed it's working on the ThinkPad X13s, so graphics isn't that far off. Wifi I think works as well by now with the latest kernels/dbt, but other stuff like power management or audio I don't know about. The nice little NPU is almost certainly never going to go anywhere either (I know of no reasonably usable NPU with any open source linux driver.)
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.
> 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
Unfortunately you're right, reverse-engineering Adreno would take monumental effort.
> 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.