JWTs are the poster child of fragile signature design. If something is like JWTs, you should reconsider. Many implementations allowed JWTs with a null signature scheme, completely bypassing any security!
11,905 karma · joined May 21, 2009
There are problems with Uber and Lyft, but they were both such a huge improvement over traditional cabs that it's not surprising that they quickly became popular.
The same is not really true of the NOTAMs, at least as far as I can tell. They're much less standardized, being mostly just plain text with weird awkward abbreviations and all caps that make them slower to scan. There's all kinds of mostly irrelevant metadata; and a lot of the time there are so many of them, most of them not really relevant, that it's really easy to lose track of what is important.
So, I don't think there's much pressing reason to change the METAR format, but oh god do they need to reform the NOTAM system, both the format and better filtering for actual relevance.
Note that this is coming from a student pilot, but I've also seen more experienced pilots express similar frustration with NOTAMs.
If it's "the feature is nearly ready but just needs some polish" there's an argument to be made that maybe you were just being a bit too hopeful. But "years and lots of fundamental research away, and we're not even sure what sensor systems were going to rely on", that's just fraud. You're looking for early stage investors, not customer preorders, at that point.
The same thing has happened in the free software movement in general; some folks have called for copyleft-only, and the rest of the world has largely ignored them and is fine with shipping BSD licensed software along with GPL licensed software.
So yes, there are shareholders, and there are creditors, it's just that in the private equity world, "caveat emptor" applies, they are expected to be sophisticated and wealthy enough to not need the protections given to investors in publicly traded companies.
And yeah, that's a huge improvement in safety. So while the general shape of airplanes, and range and speed might seem similar, the airplanes themselves and the whole ecosystem around them (pilots, maintenance, airline and airport ops, air traffic control, and so on) are far safer.
However, there have been huge improvements in other areas, like efficiency and safety. Take a look at this fatal accident charts, and remember that aviation usage has been growing in the meantime, so rates per passenger and per passenger mile have been improving even more than this shows.
https://aviation-safety.net/graphics/infographics/Fatal-Acci...
The thing is, Rust is a bit more novel and interesting than JavaScript or Python. They are both over 25 years old, well established, just about everyone has used or interacted with them. They come from somewhat similar language backgrounds, of dynamically typed garbage collected languages that try to be approachable, with optional static typing these days. Rust is much newer, only being publicly announced a bit over 10 years ago, and stable for seven years, and it offers some unique features that very few other languages outside of academia or very niche fields offer, while also being intended to actually be used as a production language, not just an academic curiosity.
This novelty and distinction makes Rust an interesting topic of discussion; not just for folks promoting it, but also skeptics of the approaches it takes. And Hacker News being a discussion site, it's not terribly surprising that a language that is novel, and polarizing, is discussed more often than ones that are pretty much ubiquitous at this point. That doesn't mean it's used more by HN users, but it certainly is discussed more, because it's more interesting to discuss.
Unfortunately, they require either a very large area to dig very shallow, or they require drilling down very deep, or they require a pond.
I got quotes for the drilling once, and it was prohibitively expensive.
It's funny how the meta-game works here. Fleecing the casuals is, of course, the way the pros make money; so it's basically the point of the game. But I can see how fleecing the casuals slowly is probably a better long-term strategy, that will ultimately extract more money from them, than doing it quickly, draining their bankroll, which may stop them from playing or get them to play less consistently.
The gauges on that particular one have been removed; on others, they may have been replaced, or the radioactive paint stripped off, or the dose deemed low enough to not be worth worrying about.
But we are also concerned with CTOL performance; in order to add more flexibility, CTOL performance is something that we are focusing on heavily, as if a runway is available you can do a takeoff and/or landing with lower energy use and thus get more range, so we're designing to be able to takoff and land either CTOL or VTOL. For example, one of our use cases is cargo, such as UPS getting packages from an airplane at the airport, to its distribution center. At an airport, you have a runway available for takeoff, so you might do a CTOL takeoff, and then a VTOL landing at the distribution center, and vice versa for the return trip.
And what I'm saying is that our aircraft, at least, won't have crosswind capabilities that are terribly high when doing CTOL takeoff and landing. It's pretty light and floaty and has a strong weathervaning tendency, and control surface sizes are kept limited in order to save weight and drag. It will be able to handle the minimum and maybe a bit more, but I wouldn't expect it to do well significantly above what the demonstrated crosswind velocity is. Ours is designed more as a glider that happens to have electric propulsion and lift capabilities, rather than a conventional powered aircraft, in order to be able to eke more range out of our batteries and provide a greater safety margin in the event of loss of propulsion power, but there are some tradeoffs to that design.
Also, I should say that I'm a software guy, this is my first aviation related job, and I only have about 2 hours in my logbook for dual received, and our certified design is not finalized and we are still doing some trades on things like control surface sizes, so anything I say here might be wrong now or in the future. But right now, we have a fairly limited crosswind envelope.
We are following ARP4754A and 4761, yes. We are still in the process of doing our safety assessments at the aircraft and systems levels and finalizing our type certified design, so I can't say which systems are going to be required to be DAL-A, but I expect that the pilot inputs, flight controller, battery systems, high voltage distribution system, low voltage distribution system, lift motors, and control surface servos will be designed to that level. Our strategy is to build ourselves the critical components for an electric aircraft, so we are doing the battery, high voltage distribution, and electric motors, while we are buying the other components (pilot inputs, flight control computer, control surface servos, primary flight displays, etc) from existing suppliers who already have experience in this space.
In the meantime, we are also learning a lot from flight test of our experimental proof-of-concept airframes, which we can feed into this process. We've already built one experimental eVTOL under a previous design, and then two proof of concept airframes with a design much closer to the type certified design that we're now working on; so while we go through the process of breaking down the requirements per 4754A and doing safety assessments per 4761 and working on our final type certified design, we're also learning a lot about operational concerns and refining our design on our experimental proof of concept airframes.
As for the V22 line, well, our aircraft can't autorotate, but it's not bad as a glider. That was a primary design criterion; it should mostly be a glider that happens to have electric power. We recently did a cross-country trip halfway across the country on our PoC aircraft in CTOL configuration (https://evtol.news/news/beta-alia-250-prototype-flies-cross-...), with a number of stops on the way, of course, our range is limited by physics, and the majority of that trip was done such that there was an airport within the glide cone of our aircraft; we did allow for a few legs in which that wasn't always the case, and we would need to ditch in the event of power failure, but for most of the trip there was an airport within our glide cone if we had a power off event.
https://en.wikipedia.org/wiki/Helicopter_height%E2%80%93velo...
In an eVTOL, if you have enough height or velocity, you should be able to glide on the wing. So you'll be wanting to keep yourself in the appropriate region of the HV curve, and your emergency engine out procedure will be much more like a conventional fixed wing aircraft, rather than a helicopter.
However, many aircraft do that testing to a higher level than is required. For instance, for a Cessna 172, 20% of Vso would be 8.2 knots, but it has a maximum demonstrated crosswind velocity of 15 knots.
Anyhow, all I'm saying is that at least for our aircraft, it looks likely that the maximum demonstrated crosswind velocity will be on the low side; at least the mandated limit based on Vso, possibly a few knots higher, but like most small aircraft, much much lower than what you have for big jets.
You are right, eVTOL cannot autorotate, but electric motors can be far more reliable than internal combustion engines, with many fewer failure modes. Additionally, they are much lighter, and so you can have much greater redundancy. There is considerable redundancy in the lift motors on these aircraft, so one or in many cases more than one lift motor can fail while still providing safe and controllable flight. The exact level of redundancy needed is verified via probabilistic risk analysis, considering failure probabilities of different components, and as mentioned the target failure rate will be lower for these than for equivalent sized conventional aircraft due to their novelty.
While there's still a lot of design and development work to do, I'd be very surprised if these didn't end up much more reliable and less prone to failure than helicopters and single engine airplanes.
Note: I work for one of these startups, so I may be a bit biased, but I also have insight into the design process and safety and redundancy of systems are absolutely a top concern.
We are focusing on a slightly different market than the other entrants; we're focusing initially on cargo rather than passenger transit. One initial customer is United Therapeutics, for transporting organ transplants and artificial organs to hospitals. Another is UPS, for getting air freight from airports to distribution centers; cutting out the truck trip can save a ton of time there. We are also making a passenger variant, but since the regulatory and NIMBY concerns for the passenger air taxi market present a lot of risk, we're not betting solely on that market like a lot of the other companies are.
This helps with a lot of the concerns raised in this thread. In fact, another one that I'm not sure has been brought up is vertiport design and siting concerns; right now standards on vertiports are still a work in progress, and there are questions about whether it will be feasible to get them installed, because even with vertical takeoff and landing you generally need to keep approach angles of about 15° clear, which means once a vertiport is installed you need to limit the heights of any surrounding buildings to keep the approach clear.
To address a few of your other concerns: we're located in northern Vermont, we know cold weather. Actually, for our use case hot weather tends to be more of a concern; batteries and motors heat up when used, especially in the very high power vertical lift phase, so our limitations there tend to be thermal and cold air provides better cooling.
Our charging stations also include air for cooling and warming the batteries; so you should be able to avoid the issues with batteries being cold on startup with our air system.
All aircraft have limitations on weather that they can be flown in; crosswind limits for takeoff and landing, etc. As very lightweight aircraft, with high lift/drag, these will be somewhat lower than the limits for your big jumbo jets, but will be high enough to be useful in a lot of weather. All aircraft have requirements for design and testing for HIRF (high intensity radiated field/lightning), so these will all be certified to the same standard there. Aircraft can optionally be certified for flight into known icing conditions (FIKI); I believe our plan is to have the capability, but as an optional add on, as it requires a number of heating elements which add weight and complexity. But overall, the weather concerns shouldn't be too much different than for other small aircraft.
As far as safety goes, that's obviously a concern in any aircraft. One advantage of electric aircraft is that electric propulsion systems are far mechanically simpler, with far fewer moving and wearing parts. The only real wear item of concern are the main bearings on the motors, and the landing gear. So maintenance intervals can be much longer than with ICE aircraft, and I expect reliability to be considerably higher. Additionally, electric motors can be much smaller and lighter, and thus can be made redundant. Each propeller on our aircraft will be driven by multiple independent motors (probably can't say the exact configuration at the moment), so that motor failures can be tolerated without catastrophic consequences.
Some are via temporary work visas, some are via undocumented immigrants. The fact that they are undocumented immigrants means that they have very few legal protections, which makes it a lot easier for employers to exploit them.
So, what's the book for learning that?
This is probably because you have the following in your HTML:
<link rel="canonical" href="https://www.anyleaf.org">
You shouldn't have canonical link relations to pages which are meaningfully different.
Edit: ah, I see that someone else pointed this out and you've fixed it already.
Now, some of that is just a matter of learning curve; once you have learned the Rust-in-Linux abstractions the above will probably be somewhat more readable.
Coming from someone who's more familiar with Rust, and less so with the kernel, here are a few notes.
* It might not be the best idea to post the example drivers with inferred types, for this familiarization reason. While there are a few types (such as those involving closures) that you can't write and can only use via type inference, or others that are too large to want to write out, these types should be fairly easy to write and it would improve readability during the familiarization process
* A lot of these things that you were having trouble with look like they are basically just dereferencing and accessing some data contained within the spinlock, and casting what is only guaranteed by the API to be an immutable (shared) reference into a mutable (unique) reference in an `unsafe` block. This is a place where trying to use simple Rust wrappers over core kernel structures which weren't designed for Rust makes things a bit more difficult to read, as you need to do a bit of an unidiomatic dance to tell the compiler "yes, the language and type don't gurantee uniqueness, but I promise this reference is unique and I won't misuse it."
* One of the small little humps to get over when learning Rust is to learn that "mut" actually means "unique", and unmarked (immutable) references means "potentially shared." But since you do need to sometimes write to objects that are potentially shared, it just means that you need to either guarantee yourself or use some kind of synchronization mechanism to ensure that at any given moment of time that data is only mutable in one place at a time.
So, I don't know the details of these APIs myself, but when I look at this here's what I see
* we're constructing some device data object protected by a spinlock
* we're providing some brief justification for why this particular usage is safe, since the API and compiler can't guarantee that it's safe
* we're extracting a mutable reference from it, for which we need to uphold the single exclusive access principle without assistance from the compiler
* we're wrapping that in a new reference to device data type which presumably provides a more idiomatic interface than what the raw primitives provide
I'm guessing that the following code which actually uses this Ref::<DeviceData> object will then be a bit more readable and require fewer uses of unsafe, as it looks like this code is what is providing that translation between some core kernel primitives which are not terribly idiomatic to use in Rust and a safer, more idiomatic wrapper.
For instance, Tier 3 support for m68k-unknown-linux-gnu was recently stabilized in rustc as a result of m68k support landing in LLVM (https://github.com/rust-lang/rust/blob/master/RELEASES.md#co...), which has been one of the previous sticking points for Rust packaging on Linux distros, some of which still support m68k architectures.
Most of "tuning the kernel for specific applications" consists of making changes to the kernel config or compiler settings. Rust won't change the kernel config system, and compiler settings for Rust are quite similar to those for C, as Rust uses LLVM as its backend, and LLVM is used by Clang which goes to a lot of effort to provide a mostly GCC compatible interface.
> in the end, you still need to understand what you are doing, and rust is not going to change that.
If think you understand what you are doing in C, you probably don't. C is a fantastically difficult language to write correct code in at scale; even the best developers make simple mistakes all the time.
I understand the frustration at seeing something else you might have to learn and deal with that might make things a bit trickier during a transition, but that's pretty much the nature of keeping up with any kind of ongoing development process. It's not like the Linux kernel sprang fully formed out of Linus's head on day one and it's just been a matter of adding drivers and making small incremental fixes. There are all kinds of changes that require you to change and adapt, like the removal of the Big Kernel Lock, or pretty much any internal API work, and yeah there can be work to keep up, but that doesn't mean you should hold back progress.