Slashdot Mirror
Ditch Linux For Windows 10 On Your Raspberry Pi With Microsoft's IoT Kit
An anonymous reader writes: Partnering with Adafruit, Microsoft has announced the Windows IoT Core Starter Kit. The $75 kit comes comes with an SD card preloaded with Windows 10 IoT. According to the Raspberry Pi blog: "The pack is available with a Pi 2 for people who are are new to Raspberry Pi or who'd like a dedicated device for their projects, or without one for those who'll be using a Pi they already own. The box contains an SD card with Windows 10 Core and a case, power supply, wifi module and Ethernet cable for your Pi; a breadboard, jumper wires and components including LEDs, potentiometers and switches; and sensors for light, colour, temperature and pressure. There's everything you need to start building."
why the hell would I want to do that?
Build your own Raspberry Pi kit. It will be cheaper.
Why would I run windows on it? One of the main advantages of Windows is all the programs compiled for it, but those are all compiled for x86 windows, not Windows 10 on Arm. Apparently it won't even run office.
SJW n. One who posts facts.
How much would you pay to have a software development platform that is more difficult to use? $25? $50? no, for only $74.99 you too can run a limited subset of Windows kernel on Raspberry Pi! (plus $0.01 handling)
This is sort of like the opposite philosophy of Ardunio, instead of a simple IDE where people can get things done you can have a hairy ball of software and expensive tools where few people (if any) get to making their projects go.
Linux on the target plus eclipse/emacs/vi/whatever on the host is all you really need to make a RPi go. There are cross compile suites for Windows and Mac, and they tend to integrate with most IDEs (maybe not so well with Visual Studio, but if you really want that option I guess Window IoT is made just for you)
“Common sense is not so common.” — Voltaire
With all of the lemmings flocking towards the cliff in their haste to get their computer sending all they do to BigBrother err.. Microsoft, I suspect those who still suck on the MS tit AND like to mess with IoT stuff will love this.. Those of us who no longer have any use for MS products, will not...
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
I remember when Microsoft used to try to compete against us with Windows NT replacing OS/2 (OS/2!!!) on ATM machines. It took them a very, very long time.
I remember when Microsoft used to try to compete against IBM embedded PC/DOS on handhelds. It took them a very, very long time.
Now I shudder at the thought that they might just impact on IoT. They've started late, and it may take them a very, very long time but they are a relentless, well-funded and Government approved software company. This is a genuine threat, people and you shouldn't just laugh it off.
You jest, but Windows is far and above king of backward compatibility as far as APIs are concerned.
Right. Like the amazing job they did with winsock?
Except that this is Windows running on ARM with severely limited functionality. You should probably go look at what Windows on a Pi actually is, hint there is no desktop. The attack surface is very small as there are almost no running services by default and you don't even have options to run most of the typical insecure windows services that you're complaining about.
It pains me that your post is modded informative as it is clearly ignorant.
If you're going to bash it, bash it based on reliability instead of security which is as yet unknown since it is a completely different code base which is completely incompatible with x86 software written for Windows that you know and clearly love.
Of course reliability improved dramatically between the test releases and the full release. BSODs were quit common on start in the earlier releases.
Basically it's just a pi that can run powershell with a pretty slick web management interface.
You jest, but Windows is far and above king of backward compatibility as far as APIs are concerned.
We can start with Office95 breaking backwards compatibility with all previous versions of Office, and the attempt to do the same with Office 2010. Then you can go look up how .NET's incompatibilities between versions cause havoc. Don't forget to look up Win32 System API calls, especially in the security area. Finally, finish off with retraining everyone on every release of a MS product because the GUI has randomly been redesigned, and I use "designed" as a concept loosely here, other than maybe to cause maximize confusion in users as a primary goal.
Backwards compatibility? Only enough so they can use it as a marketing bullet by saying you don't "have" to upgrade your other latest MS software....
The cesspool just got a check and balance.
To start with, I have to dedicate a PC to Windows 10 in order to do Windows development for my Pi 2?
.NET APIs, viruses, trojans, and whatnot infesting on the Windows 10 ecosystem.
Or, I can continue to run Raspbian (Debian) on the Pi and host development on the Pi, or do cross-development on other Linux hosts or my Mac.
I know the overhead/footprint Raspbian imposes, and I know how to carve out the bits I don't need.
How do I do that with Windows 10?
Easy! Stick to Raspbian!
Oh, I realize I won't have access to the latest development tools like Visual Studio,
Thanks, I'll stick with Raspbian on the Pi, and not having to support a separate Windows 10 box as well.
The "change" in Linux is mostly invisible, and backwards compatible. For one thing, the POSIX API is there and remains unchanged, and is identical across all Linux variants, not to mention all the BSDs variants. POSIX is the #1 reason to stick with Linux or an open source variant. All this systemd non-sense? As an embedded and appliance developer, I couldn't care less. Systemd, BSD RC, it doesn't make any difference to me because I don't make any assumptions one way or another--you have to _actively_ work to become dependent on something like systemd. If daemonizing or logging is a chore, you're doing it wrong; and you can never go wrong by supporting a mode where you don't fork and simply print logs to stderr, which makes you compatible with every service framework ever invented.
The APIs for the desktop and GUI crowd are more volatile, but the beautiful thing about open source is that 1) nobody can ever force to move away from a framework and 2) it's much easier to move to a newer framework because you have access to the code, allowing you to hack together intermediate solutions until you're upgraded.
Windows offers none of those things.
Of course, lots of developers on Linux rely too much on non-standard GNU extensions, niche Linux kernel APIs, and make a host of other bad decisions which will come back to haunt them in the future. Indeed, many of those developers come from the Windows world where using and abusing hidden APIs is something of right of passage. But that was their decision to make. The rest of us who take a long (decades long) view know how to steer clear of dangerous dependencies, or how to isolate dependencies on such APIs so they don't poison the entire codebase.
This would be a better argument if not for the plethora of distributions and the constancy of change on the Linux [actually: GNU] side of things.
FTFY. Your argument might be true for the unix clone(s), but the real unices (and that doesn't mean "Trademark UNIX" but "source code ancestry") do not welcome change just for sake of changing something. Quite the opposite.
CLI paste? paste.pr0.tips!
I just had to post something against the classic /. hivemind. What do I do to myself. You see, I mentioned APIs specifically, because I was talking about their APIs. Not Office. Not their latest shiny UI throw up. Their APIs. I'm a dev, I've been using their APIs extensively for close to two decades, and that's the perspective I wanted to give. I wasn't commenting on the quality of Linux vs Windows IOT, or the benefits (or lack thereof) of backward compatibility.
you can go look up how .NET's incompatibilities between versions cause havoc. Don't forget to look up Win32 System API calls, especially in the security area.
Yes, you can.
Newer .NET versions tend to, in the vast majority of cases, be backwards compatible with apps compiled for older versions. They have broken this in some very niche cases, but only where strongly justified. Their wont for backward compatibility is so great, they will leave in bugs and even keep the internal structure of objects the same to ensure any apps relying on that continue to work. I've submitted my share of bugs that ended up in the "won't fix" pile due to this.
Their Win32 API is probably the single largest working example of "backward compatible" you'll find in an API. The thing is for better or worse riddled with deprecated functionality, "Ex" functions to replace it, and structs which need to know their own size. Run an old Win32 app from the Windows 95 days and there's a really good chance it'll still work today. There are very few cases where they've made something specifically not work, and that has sometimes been because people have been using it wrong to the detriment of the user (i.e. retrieving the Windows version).
Their driver side tends to fluctuate a bit more as they make performance or safety enhancements by replacing the various APIs, but there's really no way around that.
As a developer with >20 years of embedded experience, nothing makes me sadder than seeing desktop developers (like your .Net monkeys) programming in an embedded environment. They don't understand multi-threading. They don't understand being efficient with CPU cycles and with memory. They struggle if luxuriously rich API's and libraries are not available.
Whenever I see a kiosk or a bank ATM with a BSOD or windows error dialog on the screen, I know that the wrong kinds of developers worked on that project.
Slashdot: come for the pedantry, stay for the condescension.