If VR takes off you'll have plenty of other uses besides gaming. Scientific visualizations, vertical applications and whatnot. You'll want to support Linux as an OS just like NVIDIA supports it for GPGPU, workstations and embedded applications. That it gives Linux desktops 3D gaming ability is just a small bonus.
Any language that could replace C and assembler would need to be statically compiled. So for Java, C#, Python and so on you'd have to define a subset that does not require a runtime parser or standard library. And you'd need extensions (or a static module system) that allows you to add assembler for direct hardware access. And a new compiler that can generate static code instead of the intermediate VM they target now. Not impossible by any means and probably a fairly interesting exercise too, but the languages would end up rather different and more restricted than the full versions people are used to.
Rather, I expect and hope that something like Rust will eventually supplant these languages in this space. Rust gives you the best of both worlds, with a statically compiled binaries and good memory safety at compile time, rather than runtime. You pay for it by having to be much more explicit about ownership than in these languages though. I've followed that project for a good while and it's clear that targeting small embedded systems is a struggle even for such a language; Java and friends would be much more difficult still.
FORTH is the rare language that tends to be even more memory efficient than C. The runtime interpreter is truly minimal (really just following a bunch of jump tables); you can have a small environment and application code in less than 8K.
On the other hand - and I say this as someone who likes FORTH a lot - you'd be hard pressed to find people claiming that FORTH is any higher-level (or easier to develop in) than C or assembler.
On the third hand - and off-topic here - it's quite a fun little language to use. Just like you can say that Scheme is programming directly in an AST, using FORTH is writing code directly for a stack machine. It's probably good for you to have a bit of experience even if you never do anything "real" with it.
The high-level VMs and the drivers to drive the specific hardware isn't developed by magical Low-Level Elves in Happy Rainbow Fairly Land. Every IoT device is going to have their oen special hardware stuff, and somebody needs to write the low-level code to interface with it. That is done in a combination of C and assembler.
Also, at volume the price difference between a MCU that can run a VM and one that can not will be on the order of tens of cents (either currency). If you plan to make on the order of a million devices, then 20 cents per unit will more than pay for a programmer that knows to use the small MCU over a Java hack that does not.
I still even have a 10.6 workstation because the scanner software for my film scanner I have is PowerPC.
Vuescan works OK and is available for OSX, Windows and Linux. It supports a huge range of scanners old and new. I've been using it for many years and I can say it gives quality results, while the UI is at least no worse than other scanner software (not a high bar to clear, of course). And since it's cross-platform it's one less thing to lock you in to any specific system.
BTW, the part about knowing who's going to use the door and who isn't is probably doable with cameras and enough processing power.
It is possible, and it has been built. A couple of colleagues in Sweden did just that for one manufacturer, more than fifteen years ago. The idea was to reduce the amount of heat lost from unnecessary door openings in winter, and to a lesser extent from cooling losses in summer.
It would recognize who was aiming for the door versus those that just walked past. It wasn't fooled by dogs or kids (would open for kids, but not dogs) or things like suitcases or prams. During development they built a version that would only open if you did the Vulcan hand sign thing.
But it was too expensive. Automatic doors are not a high-margin business - there's many competitors - and the actual savings did not make up for the higher price. The actual energy losses are pretty minimal for most shops, and door openings are usually not in error. Those that have a real problem with it tend to use revolving or double doors already.
Also, it didn't help that the shops might have needed permission to mount what is effectively a camera pointing out on the street.
Today the hardware would be cheaper, and cameras are far more acceptable. But from what I heard customer interest would still be small.
Not sure what MS' motivation is, but it's good news for a lot of scientific software developers. Small teams or single researchers rarely have enough time to even keep the main development going, never mind keeping up with multiple OS targets. With this everybody can simply focus on Linux, and tell Windows users to just run it under the Linux layer and stop asking about a native port.
This is why when strangers photograph me, I flip them the bird, not a peace sign. Then they don't get my fingerprint, since it is not facing them.
Most parts of your skin has distinctive, unique patterns. You can get a unique print from your elbow, wrist, knuckles, knees... And you tend to leave such marks around too, if less commonly than fingers.
Finger prints are fine for identification, not verification. They're your username, not your password. If you do use them like that they are not dangerous.
But of course nobody does; US, Japan and other countries all use fingerprints to verify the password identity for instance. And as a result they catch multiple people here in Japan every year that entered the country with fake fingerprints. And since they just catch people that happen to get arrested for some other reason, it probably means there's hundreds entering the country using other peoples' ID and fingerprints each year.
The only real option, baring some fundamental breakthrough [...] is massively more and simpler cores
The problem with that approach is that most problems are not infinitely paralleliseable, and some important problems fundamentally do not parallelise at all. You rapidly hit diminishing returns for more cores, and that's before you consider that you need to go beyond a shared-memory architecture beyond a dozen cores or so.
The newest generation of supercomputers already have big problems finding jobs that actually use all the hardware, and for the next generation people have more or less thrown their hands in the air already and say that except for a few very specialized workloads, the machines will be shared systems, not used for single jobs at a time.
It's time to start thinking about how a society which want a social safety net can incentivize people people to not have children they can't afford.
Because we have such a problem with criminal lawlessness and uncontrolled breeding among trust-fund kids?
You already have a segment of people with, effectively, no need to ever provide for themselves. They don't seem to be causing any more trouble overall than anybody else, and most of them seem to manage to find something worthwhile to do with their lives.
At least Toyota already has this in their hybrid vehicles. And in Japan you have a toggle to temporarily turn it off (for when you arrive home late, for instance, and want to minimise noise). The "whine" you hear from a Prius or Aqua at low speed is actually the speaker; with it turned off they're almost completely silent.
The only reason Linux is perceived as more secure than other operating systems is because most hackers don't care enough to spend time working to crack it, so there are less attempts.
Linux is a major server OS (arguably the largest), very big in embedded systems, and completely dominant on smartphones. Hackers are spending very significant time working to find exploits.
I'm using LTS for all my work machines. The last round I rarely felt I missed out on anything compared to my updated machine at home. I think it's perfectly reasonable to stay with LTS if you want. You can still update to newer versions of, say LibreOffice and similar applications using snaps if you need it.
The first generation Xperia phones actually did something similar. They kept the battery at above 90%, by charging up to 100% then letting it fall to 90% again before recharging it again. Much better battery lifetime than keeping it at 100%.
But lots of people complained that Sony had a lousy battery charger system that couldn't even keep the battery topped up. So to avoid the bad press they changed it and kept it at 100% all the time, like the rest of the manufacturers.
Well, yes and no. You're limited to 100Mbit/s, which is if course a lot slower than gigabit ethernet, But normally a scientific cluster (which is what I'm interested in) isn't really limited by bandwidth as much as by latency. Going through the USB subsystem for all packets is going to give you worse latency than dedicated hardware. But then, I also use a cheap switch that's probably not a speed demon for retransmitting packets either.
And the thing is, the Pi is a fairly slow computer. I suspect that as a ratio of computing speed to transmission delays, the Pi has as effective communication as a "real" cluster of server systems connected with high-end hardware. The CPU is even slower than the network if you will.
Any particular reason not to just do it in software, e.g xenserver or virtualbox? Virtual networking is kind of messy, but it leaves less cables around:)
VMs would work well, I agree. But this way I also get real(ish) network latency and delays in the same way a full-size system does. And an actual tiny cluster on my desk is a lot more fun:)
It's really easy to set up. Take a few Pi's, add a small switch (get one that takes 5V). Connect them up, and use a single larger power brick that can power all Pis and the switch. Either make some kind of enclosure, or - as I did - rack them up with spacers, drill holes in the switch lid and mount the rack of PI's to it.
One wrinkle is that you probably want to keep the switch only for the internal network. I use a USB-Ethernet dongle on the login node for external communication. it's just as fast as the on-board Ethernet in practice (it's internally treated as a USB device anyhow), and you can set up the login node to act as router and gateway to the other nodes.
Then you can install and play with whatever cluster-related software you like: Slurm, OpenMPI, Ansible, GNU Modules, XscalableMP, ZeroMQ and so on.
It's fairly common in complex robotics to have a set of tiny MCUs like the AVR (that Arduino is based on) to control one or two joints, then a larger single-board computer to send commands to those units, and receive status updates about angles and speeds.
The Arduino and Raspberry Pi are well suited to those two roles.
I just finished a small Raspberry Pi cluster, with two RPi 3 compute nodes and an Rpi 2 front-end node. Not because it has such great computational capabilities - it doesn't - but because it's a low-cost way to get a "training system" that I can abuse without messing up anything on the real cluster I also use.
These new Pi's would be even better; could have a single backplane that the nodes slot into. Ideally you'd be able to route both power and ethernet through the backplane as well, but I don't know how feasible that'd be.
Slashdot Mirror
If VR takes off you'll have plenty of other uses besides gaming. Scientific visualizations, vertical applications and whatnot. You'll want to support Linux as an OS just like NVIDIA supports it for GPGPU, workstations and embedded applications. That it gives Linux desktops 3D gaming ability is just a small bonus.
Fortran is still very much in use for mathematical programming.
Any language that could replace C and assembler would need to be statically compiled. So for Java, C#, Python and so on you'd have to define a subset that does not require a runtime parser or standard library. And you'd need extensions (or a static module system) that allows you to add assembler for direct hardware access. And a new compiler that can generate static code instead of the intermediate VM they target now. Not impossible by any means and probably a fairly interesting exercise too, but the languages would end up rather different and more restricted than the full versions people are used to.
Rather, I expect and hope that something like Rust will eventually supplant these languages in this space. Rust gives you the best of both worlds, with a statically compiled binaries and good memory safety at compile time, rather than runtime. You pay for it by having to be much more explicit about ownership than in these languages though. I've followed that project for a good while and it's clear that targeting small embedded systems is a struggle even for such a language; Java and friends would be much more difficult still.
FORTH is the rare language that tends to be even more memory efficient than C. The runtime interpreter is truly minimal (really just following a bunch of jump tables); you can have a small environment and application code in less than 8K.
On the other hand - and I say this as someone who likes FORTH a lot - you'd be hard pressed to find people claiming that FORTH is any higher-level (or easier to develop in) than C or assembler.
On the third hand - and off-topic here - it's quite a fun little language to use. Just like you can say that Scheme is programming directly in an AST, using FORTH is writing code directly for a stack machine. It's probably good for you to have a bit of experience even if you never do anything "real" with it.
The high-level VMs and the drivers to drive the specific hardware isn't developed by magical Low-Level Elves in Happy Rainbow Fairly Land. Every IoT device is going to have their oen special hardware stuff, and somebody needs to write the low-level code to interface with it. That is done in a combination of C and assembler.
Also, at volume the price difference between a MCU that can run a VM and one that can not will be on the order of tens of cents (either currency). If you plan to make on the order of a million devices, then 20 cents per unit will more than pay for a programmer that knows to use the small MCU over a Java hack that does not.
Vuescan works OK and is available for OSX, Windows and Linux. It supports a huge range of scanners old and new. I've been using it for many years and I can say it gives quality results, while the UI is at least no worse than other scanner software (not a high bar to clear, of course). And since it's cross-platform it's one less thing to lock you in to any specific system.
It is possible, and it has been built. A couple of colleagues in Sweden did just that for one manufacturer, more than fifteen years ago. The idea was to reduce the amount of heat lost from unnecessary door openings in winter, and to a lesser extent from cooling losses in summer.
It would recognize who was aiming for the door versus those that just walked past. It wasn't fooled by dogs or kids (would open for kids, but not dogs) or things like suitcases or prams. During development they built a version that would only open if you did the Vulcan hand sign thing.
But it was too expensive. Automatic doors are not a high-margin business - there's many competitors - and the actual savings did not make up for the higher price. The actual energy losses are pretty minimal for most shops, and door openings are usually not in error. Those that have a real problem with it tend to use revolving or double doors already.
Also, it didn't help that the shops might have needed permission to mount what is effectively a camera pointing out on the street.
Today the hardware would be cheaper, and cameras are far more acceptable. But from what I heard customer interest would still be small.
Bring it up with Microsoft? What do Windows app developers do when Wine doesn't run their application correctly?
Zero extra work and no need for a separate box or VM, and a Windows licence, to test the build.
Not sure what MS' motivation is, but it's good news for a lot of scientific software developers. Small teams or single researchers rarely have enough time to even keep the main development going, never mind keeping up with multiple OS targets. With this everybody can simply focus on Linux, and tell Windows users to just run it under the Linux layer and stop asking about a native port.
Most parts of your skin has distinctive, unique patterns. You can get a unique print from your elbow, wrist, knuckles, knees... And you tend to leave such marks around too, if less commonly than fingers.
Finger prints are fine for identification, not verification. They're your username, not your password. If you do use them like that they are not dangerous.
But of course nobody does; US, Japan and other countries all use fingerprints to verify the password identity for instance. And as a result they catch multiple people here in Japan every year that entered the country with fake fingerprints. And since they just catch people that happen to get arrested for some other reason, it probably means there's hundreds entering the country using other peoples' ID and fingerprints each year.
The problem with that approach is that most problems are not infinitely paralleliseable, and some important problems fundamentally do not parallelise at all. You rapidly hit diminishing returns for more cores, and that's before you consider that you need to go beyond a shared-memory architecture beyond a dozen cores or so.
The newest generation of supercomputers already have big problems finding jobs that actually use all the hardware, and for the next generation people have more or less thrown their hands in the air already and say that except for a few very specialized workloads, the machines will be shared systems, not used for single jobs at a time.
Well, you do also have retirees, people on disability, housewives and other people that by and large manage to stay both occupied and out of trouble.
I really think people are far more worried about this issue than they need to be.
Because we have such a problem with criminal lawlessness and uncontrolled breeding among trust-fund kids?
You already have a segment of people with, effectively, no need to ever provide for themselves. They don't seem to be causing any more trouble overall than anybody else, and most of them seem to manage to find something worthwhile to do with their lives.
At least Toyota already has this in their hybrid vehicles. And in Japan you have a toggle to temporarily turn it off (for when you arrive home late, for instance, and want to minimise noise). The "whine" you hear from a Prius or Aqua at low speed is actually the speaker; with it turned off they're almost completely silent.
Linux is a major server OS (arguably the largest), very big in embedded systems, and completely dominant on smartphones. Hackers are spending very significant time working to find exploits.
I don't see the problem. "There is bugs. And here is elmer. And over there is daffy." Seems grammatically fine to me.
I'm using LTS for all my work machines. The last round I rarely felt I missed out on anything compared to my updated machine at home. I think it's perfectly reasonable to stay with LTS if you want. You can still update to newer versions of, say LibreOffice and similar applications using snaps if you need it.
The first generation Xperia phones actually did something similar. They kept the battery at above 90%, by charging up to 100% then letting it fall to 90% again before recharging it again. Much better battery lifetime than keeping it at 100%.
But lots of people complained that Sony had a lousy battery charger system that couldn't even keep the battery topped up. So to avoid the bad press they changed it and kept it at 100% all the time, like the rest of the manufacturers.
Well, yes and no. You're limited to 100Mbit/s, which is if course a lot slower than gigabit ethernet, But normally a scientific cluster (which is what I'm interested in) isn't really limited by bandwidth as much as by latency. Going through the USB subsystem for all packets is going to give you worse latency than dedicated hardware. But then, I also use a cheap switch that's probably not a speed demon for retransmitting packets either.
And the thing is, the Pi is a fairly slow computer. I suspect that as a ratio of computing speed to transmission delays, the Pi has as effective communication as a "real" cluster of server systems connected with high-end hardware. The CPU is even slower than the network if you will.
VMs would work well, I agree. But this way I also get real(ish) network latency and delays in the same way a full-size system does. And an actual tiny cluster on my desk is a lot more fun :)
It's really easy to set up. Take a few Pi's, add a small switch (get one that takes 5V). Connect them up, and use a single larger power brick that can power all Pis and the switch. Either make some kind of enclosure, or - as I did - rack them up with spacers, drill holes in the switch lid and mount the rack of PI's to it.
One wrinkle is that you probably want to keep the switch only for the internal network. I use a USB-Ethernet dongle on the login node for external communication. it's just as fast as the on-board Ethernet in practice (it's internally treated as a USB device anyhow), and you can set up the login node to act as router and gateway to the other nodes.
Then you can install and play with whatever cluster-related software you like: Slurm, OpenMPI, Ansible, GNU Modules, XscalableMP, ZeroMQ and so on.
It's fairly common in complex robotics to have a set of tiny MCUs like the AVR (that Arduino is based on) to control one or two joints, then a larger single-board computer to send commands to those units, and receive status updates about angles and speeds.
The Arduino and Raspberry Pi are well suited to those two roles.
I just finished a small Raspberry Pi cluster, with two RPi 3 compute nodes and an Rpi 2 front-end node. Not because it has such great computational capabilities - it doesn't - but because it's a low-cost way to get a "training system" that I can abuse without messing up anything on the real cluster I also use.
These new Pi's would be even better; could have a single backplane that the nodes slot into. Ideally you'd be able to route both power and ethernet through the backplane as well, but I don't know how feasible that'd be.
Induction motors have lower torque and worse efficiency, though.