In the USA they are classified as buildings. They even blink at the top and bottom of their circular flight path so that they look like radio towers to airplanes. As such, they are not regulated as aircraft, and for better or worse, have freedom in how much systems redundancy they add, how rigorously their software is tested, etc... In Europe, similar systems (i.e. like the one from Ampys) are regulated as planes, and have to use all aircraft certified stuff.
Soft kites have to be replaced quite often since the fabric wears out. SkySails can get away with it because the ships save more fuel than it took to manufacture the kite. It is cheaper to make them big, but that is offset by them being about 1/10 as aerodynamically efficient as a rigid wing.
Up until a year ago I was doing research in this field. Google/Makani is by far the closest to commercialization at utility scale. They are already on their 8th prototype, a 600 kW version. Nothing public is operating anything airborne in the Megawatts yet.
I'm living in Belgium so I can give a bit of context. Commercial street markets are routine here; they happen every week, and often aren't that well attended especially in winter. The climate protests in Paris were/are going to be massive, with many people traveling internationally to take part.
NixOS has a package manager that I think has a real shot at achieving scalability and repeatability in package management. Once something works in NixOS it will keep working on it's own, since specific versions of dependencies are tracked and can coexist, whereas in mainstream distros shit breaks all the time. The current model of freezing everything once in a while and patching up some of the most obviously broken stuff simply isn't keeping up with the pace of software development IMHO.
http://nixos.org/
For a real moonshot OS/language/decentralize_all_the_things project, check out Urbit:
http://urbit.org/
Github is really nice, but git itself is the core tech, and undermines the heck out of their lock-in. If they push too hard to monetize, a competitor will come along and everyone will just push their repos there or self-host. Some of the ticket stuff might not migrate well, but many of the nice activity plots, etc... that github provides are just visualizations of data that is in your repo.
I probably paid at least that back when I had private repos to hold my unpublished research while at uni. We used svn on university servers for a while, but corrupted server databases and difficulty backing up the repo were a never ending source of trouble. git and github were rock solid.
If you decide to get into Rust, please post about it from an Ada developer perspective! Almost nothing has been posted comparing the two; I think the intersection of high assurance software gurus and new language nerds is pretty small... a niche within a niche.
Yeah. I think the author considers smartphone apps to be "embedded". He also talked about making an entire iphone app as a way to teach someone about float vs. int...
It turns out that telling kids "you are special and talented and above average, etc" actually improves their performance in school. So that's a deliberate data-driven thing.
I would add that part of the problem is that in the mobile ecosystem, the march of technology isn't voluntary. Your phone is subject to a constant barrage of software updates that gradually make your phone slower and more crashy. Any software update that increases resource requirements ~should be regarded as a breaking change, but that is not the case. Since the entire smartphone industry works this way, the only real recourse for the user is to revert to a dumb phone, but that isn't terribly satisfying.
If you really have a significant amount of Ada experience, and spend enough time with Rust once it reaches 1.0 to get over the initial pain of a new language, please write a blog post about it, and be very constructive with your technical criticisms. I have yet to see an in-depth comparison between Rust and Ada; just a handful of short forum posts by the Rust devs saying that Rust has stronger safety guarantees for parallel code.
I attended an Ada talk at a high profile open source conference recently and was a bit underwhelmed; I came away with the impression that aside from ranged integers, the compile time safety features of Ada (beyond memory safety) are a bit kludgy, i.e. they don't fit will into the syntax, are vendor specific, or only work in restricted cases... Of course, that could have been a problem with the talk, rather than the Ada ecosystem.
Don't worry, nobody is going to make you program in Rust unless it really proves valuable in practice. One good litmus test for this will be if Servo gets productized and ends up being the only browser ~not getting hacked every year at the pwn2own. Rust has a steep enough learning curve that you pretty much already have to be a good programmer to even get started. You have to not only grok what pointers/references are, there is the additional overhead of mutability and ownership that you have to understand to write even trivial code. I think once Rust matures a bit it will still have a shallower learning curve that C++, though; I have a hunch new users will learn faster from Rust's compiler errors than from C++'s segfaults (and data races once you get to parallel programming).
Stuff like this makes me embarassed to call myself an electrical engineer. If you tell someone you've worked in the field of robotics or UAV's, there's a decent chance they're going to think something along the lines of "oh, so you're the kind of person who builds machines that rain death from the sky." Doctors take a pledge not to kill people; I see no reason why we engineers shouldn't hold ourselves to the standard.
While this is one of my favorite discussion topics, TFA is extremely badly written. If someone is not writing clearly and concisely, they are probably not thinking clearly either. Why is this below average blog post getting treated like a serious rebuttal to a report from a major financial instution?
It is unlikely the automation of cars willl be centralised to the point that they ~can't also work autonomously. The interstate highway system was built because fast road transportation for defensive forces was viewed as a military necessity. If all of our roads could be gridlocked by a cyber attack commanding all of the robot cars to stop in the middle of the road, I'm sure the military would have something to say about it.
I disagree with this sentiment. If we can figure out how to program planes to never crash into mountains/buildings/the ground, we absolutely should. If it's fault tolerance you're concerned about, apparently a single pilot with a head full of bad ideas is still a potential single point of failure. Maybe we're not ready to take humans out of the loop completely, but surely we can make it necessary to have consent from ~both pilots to disable the plane's safety features.
It is not just about reaction time (thought that sure helps stopping distance); it is also about sensors and reliability. Humans cannot shoot lasers out of their eyes to precisely and directly measure the distance to every object in every direction, know intrinsically where they are (GPS), how to navigate (google maps), where there are traffic jams (via other cars running google maps), where there are potholes (via the accelerometers in the smartphones in other cars), etc...
As for reliability, an autonomous car does not ever have to reach the performance of our ~best drivers, it just has to beat the performance of our ~worst drivers. Would you rather cross the road as a pedestrian in front of a robot car, or a human driver that is tired/drunk/distracted/half blind/stupid/enraged/hurried?
Things could get very interesting indeed if Apple opens up Swift. I'm not sure if Swift can cover all of the use cases that Rust does, but it can probably cover most of them, and Apple has worked very hard on Swift's ergonomics. Interactive REPL-style coding is a mere twinkle in some rust dev's eye right now; the closest we have is the playpen and the playbot in the IRC channel. The world wins if either of them catch on.
The main hot newness in Rust is the borrow checker. It is the source of Rusts most notable strengh and also it's most notable weakness, but you won't see it at all if you just look at a code example online, or download an already-working code example. It's also interesting since it's the first language to really target the remaining C/C++ strongholds in a long time, and it does have an interesting mix of good ideas from other languages.
As for graphical programming, I would have said that all the clicking (and not version controlling) puts an upper limit on program complexity, but who knows... people have designed some darn complex stuff in Minecraft; if someone designed a visual programming language for people with that temperament maybe they ~could write something like an operating system by clicking and dragging (and shoveling?).
Wow, Ada code looks nothing like Rust code to me. Ada looks like a mix of BASIC and python. I don't know Ada, but Rust supposedly makes stronger guarantees of memory correctness for parallel code. Rust just went beta yesterday; breaking changes up to now were to be expected. Once there are more people with real-world experience with both Ada and Rust, I'll be very interested in reading about their experiences. Maybe you haven't been following it closely, but Rust is not some one-developer toy scripting language. A team of brilliant engineers has been working on it full-time at Mozilla for years.
Wow, HN must be attracting a very special subset of rust folks if what you say is true. I've found the rust devs and everyone in the community to be consistently polite and helpful. There was one guy who would leave a mix of verbal abuse and insightful technical arguments, and the abuse the devs took politely before ultimately banning him was epic. If you get stuck on something, help in IRC or SO is almost immediate.
Give the ecosystem a few days to catch up
on
Rust 1.0 Enters Beta
·
· Score: 5, Interesting
Now is a good time to play around with Rust and explore the language features! If you build against the beta release and don't add external package dependencies, your code will most likely continue to function for the duration of the 1.0 release cycle.
However, now is probably a particularly ~bad time for new rust users to start a project and add a bunch of dependencies from Cargo/crates.io. Beta changed code dependencies on unstable features from warnings to errors, so a lot of common libraries in the ecosystem are broken at the moment, and will take a little while to get updated.
Happy hacking!
Really? I remember one that shined light on the top of the pool and gradually lowered the object / raised the resin level. I suspect growing the object from the bottom is novel, but I'm not sure. The thing with the oxygen acting as an inhibitor is probably also novel, but I imagine there are other ways to prevent sticking at the interface.... i.e. a water based resin of some sort coupled with a super hydrophobic surface treatment... or something that just erodes a bit but not enough to affect tolerances...
Slashdot Mirror
In the USA they are classified as buildings. They even blink at the top and bottom of their circular flight path so that they look like radio towers to airplanes. As such, they are not regulated as aircraft, and for better or worse, have freedom in how much systems redundancy they add, how rigorously their software is tested, etc... In Europe, similar systems (i.e. like the one from Ampys) are regulated as planes, and have to use all aircraft certified stuff.
Soft kites have to be replaced quite often since the fabric wears out. SkySails can get away with it because the ships save more fuel than it took to manufacture the kite. It is cheaper to make them big, but that is offset by them being about 1/10 as aerodynamically efficient as a rigid wing.
Up until a year ago I was doing research in this field. Google/Makani is by far the closest to commercialization at utility scale. They are already on their 8th prototype, a 600 kW version. Nothing public is operating anything airborne in the Megawatts yet.
I'm living in Belgium so I can give a bit of context. Commercial street markets are routine here; they happen every week, and often aren't that well attended especially in winter. The climate protests in Paris were/are going to be massive, with many people traveling internationally to take part.
NixOS has a package manager that I think has a real shot at achieving scalability and repeatability in package management. Once something works in NixOS it will keep working on it's own, since specific versions of dependencies are tracked and can coexist, whereas in mainstream distros shit breaks all the time. The current model of freezing everything once in a while and patching up some of the most obviously broken stuff simply isn't keeping up with the pace of software development IMHO. http://nixos.org/ For a real moonshot OS/language/decentralize_all_the_things project, check out Urbit: http://urbit.org/
Github is really nice, but git itself is the core tech, and undermines the heck out of their lock-in. If they push too hard to monetize, a competitor will come along and everyone will just push their repos there or self-host. Some of the ticket stuff might not migrate well, but many of the nice activity plots, etc... that github provides are just visualizations of data that is in your repo.
I probably paid at least that back when I had private repos to hold my unpublished research while at uni. We used svn on university servers for a while, but corrupted server databases and difficulty backing up the repo were a never ending source of trouble. git and github were rock solid.
If you decide to get into Rust, please post about it from an Ada developer perspective! Almost nothing has been posted comparing the two; I think the intersection of high assurance software gurus and new language nerds is pretty small... a niche within a niche.
Yeah. I think the author considers smartphone apps to be "embedded". He also talked about making an entire iphone app as a way to teach someone about float vs. int...
It turns out that telling kids "you are special and talented and above average, etc" actually improves their performance in school. So that's a deliberate data-driven thing.
I would add that part of the problem is that in the mobile ecosystem, the march of technology isn't voluntary. Your phone is subject to a constant barrage of software updates that gradually make your phone slower and more crashy. Any software update that increases resource requirements ~should be regarded as a breaking change, but that is not the case. Since the entire smartphone industry works this way, the only real recourse for the user is to revert to a dumb phone, but that isn't terribly satisfying.
If you really have a significant amount of Ada experience, and spend enough time with Rust once it reaches 1.0 to get over the initial pain of a new language, please write a blog post about it, and be very constructive with your technical criticisms. I have yet to see an in-depth comparison between Rust and Ada; just a handful of short forum posts by the Rust devs saying that Rust has stronger safety guarantees for parallel code. I attended an Ada talk at a high profile open source conference recently and was a bit underwhelmed; I came away with the impression that aside from ranged integers, the compile time safety features of Ada (beyond memory safety) are a bit kludgy, i.e. they don't fit will into the syntax, are vendor specific, or only work in restricted cases... Of course, that could have been a problem with the talk, rather than the Ada ecosystem.
Don't worry, nobody is going to make you program in Rust unless it really proves valuable in practice. One good litmus test for this will be if Servo gets productized and ends up being the only browser ~not getting hacked every year at the pwn2own. Rust has a steep enough learning curve that you pretty much already have to be a good programmer to even get started. You have to not only grok what pointers/references are, there is the additional overhead of mutability and ownership that you have to understand to write even trivial code. I think once Rust matures a bit it will still have a shallower learning curve that C++, though; I have a hunch new users will learn faster from Rust's compiler errors than from C++'s segfaults (and data races once you get to parallel programming).
Stuff like this makes me embarassed to call myself an electrical engineer. If you tell someone you've worked in the field of robotics or UAV's, there's a decent chance they're going to think something along the lines of "oh, so you're the kind of person who builds machines that rain death from the sky." Doctors take a pledge not to kill people; I see no reason why we engineers shouldn't hold ourselves to the standard.
While this is one of my favorite discussion topics, TFA is extremely badly written. If someone is not writing clearly and concisely, they are probably not thinking clearly either. Why is this below average blog post getting treated like a serious rebuttal to a report from a major financial instution?
It is unlikely the automation of cars willl be centralised to the point that they ~can't also work autonomously. The interstate highway system was built because fast road transportation for defensive forces was viewed as a military necessity. If all of our roads could be gridlocked by a cyber attack commanding all of the robot cars to stop in the middle of the road, I'm sure the military would have something to say about it.
I disagree with this sentiment. If we can figure out how to program planes to never crash into mountains/buildings/the ground, we absolutely should. If it's fault tolerance you're concerned about, apparently a single pilot with a head full of bad ideas is still a potential single point of failure. Maybe we're not ready to take humans out of the loop completely, but surely we can make it necessary to have consent from ~both pilots to disable the plane's safety features.
It is not just about reaction time (thought that sure helps stopping distance); it is also about sensors and reliability. Humans cannot shoot lasers out of their eyes to precisely and directly measure the distance to every object in every direction, know intrinsically where they are (GPS), how to navigate (google maps), where there are traffic jams (via other cars running google maps), where there are potholes (via the accelerometers in the smartphones in other cars), etc... As for reliability, an autonomous car does not ever have to reach the performance of our ~best drivers, it just has to beat the performance of our ~worst drivers. Would you rather cross the road as a pedestrian in front of a robot car, or a human driver that is tired/drunk/distracted/half blind/stupid/enraged/hurried?
Rust or Swift, that is... we're pretty screwed if the Rust playbot takes over the world :)
Things could get very interesting indeed if Apple opens up Swift. I'm not sure if Swift can cover all of the use cases that Rust does, but it can probably cover most of them, and Apple has worked very hard on Swift's ergonomics. Interactive REPL-style coding is a mere twinkle in some rust dev's eye right now; the closest we have is the playpen and the playbot in the IRC channel. The world wins if either of them catch on.
The main hot newness in Rust is the borrow checker. It is the source of Rusts most notable strengh and also it's most notable weakness, but you won't see it at all if you just look at a code example online, or download an already-working code example. It's also interesting since it's the first language to really target the remaining C/C++ strongholds in a long time, and it does have an interesting mix of good ideas from other languages. As for graphical programming, I would have said that all the clicking (and not version controlling) puts an upper limit on program complexity, but who knows... people have designed some darn complex stuff in Minecraft; if someone designed a visual programming language for people with that temperament maybe they ~could write something like an operating system by clicking and dragging (and shoveling?).
Wow, Ada code looks nothing like Rust code to me. Ada looks like a mix of BASIC and python. I don't know Ada, but Rust supposedly makes stronger guarantees of memory correctness for parallel code. Rust just went beta yesterday; breaking changes up to now were to be expected. Once there are more people with real-world experience with both Ada and Rust, I'll be very interested in reading about their experiences. Maybe you haven't been following it closely, but Rust is not some one-developer toy scripting language. A team of brilliant engineers has been working on it full-time at Mozilla for years.
Wow, HN must be attracting a very special subset of rust folks if what you say is true. I've found the rust devs and everyone in the community to be consistently polite and helpful. There was one guy who would leave a mix of verbal abuse and insightful technical arguments, and the abuse the devs took politely before ultimately banning him was epic. If you get stuck on something, help in IRC or SO is almost immediate.
Now is a good time to play around with Rust and explore the language features! If you build against the beta release and don't add external package dependencies, your code will most likely continue to function for the duration of the 1.0 release cycle. However, now is probably a particularly ~bad time for new rust users to start a project and add a bunch of dependencies from Cargo/crates.io. Beta changed code dependencies on unstable features from warnings to errors, so a lot of common libraries in the ecosystem are broken at the moment, and will take a little while to get updated. Happy hacking!
Really? I remember one that shined light on the top of the pool and gradually lowered the object / raised the resin level. I suspect growing the object from the bottom is novel, but I'm not sure. The thing with the oxygen acting as an inhibitor is probably also novel, but I imagine there are other ways to prevent sticking at the interface.... i.e. a water based resin of some sort coupled with a super hydrophobic surface treatment... or something that just erodes a bit but not enough to affect tolerances...