It's quite fast if you use qemu-user.
2,917 karma · joined April 21, 2019
I do this every day from a Linux x64 host using qemu-user. What problems are you hitting ?
> Second biggest complaint is deploying Jetsons in production environments. > > Third biggest complaint is having to flash Jetsons manually.
I don't think these two use cases are the goal of the Jetsons. Feel like more the goal of the EGX devices, which can be programmed, updated, etc. fully remotely.
And this is why people suggesting what you are suggesting never manage to achieve the change.
> 99% of the software does not use the entirety of the std
Most Rust software uses most of it.
> You are suggesting moving something into standard that would make unicode software harder to update
How do you update the unicode tables for those stuck with Rust 1.0 ? If you are going to make this claims, back them up.
> It is not a "problem". In most commercial software, libraries and versions are vetted. Same applies for all languages. If something is in the std, then it is already in, that is why it is useful.
So your organization does support third-party packages, you are just to lazy to ask for vetting ? That's not what you claimed above (you claimed that your organization does not support third-party packages at all).
The answer to this is simple, ask your organization to vet this library. If that's too complicated and takes too much effort, improve your organization's process.
Suggesting that only because you are too lazy to vet a library that library should be in standard is a laughable proposal. Think about the trade-offs, evaluate them, weight them, and if you still think doing so is worth it, write an RFC. The process for putting things into standard is open.
But if your only argument is "me,me,me,me" that's not going to go anywhere.
These promises typically happen when people are doubting about signing the contract, and universities are more like "don't worry about the loan, you'll get such a nice job afterwards that you'll be rich and this will feel like pocketchange".
The student that finish university and aren't able to land a good enough job due to their education can sue and do often win.
That's much simpler to handle in court than the questions you are considering, but it requires actually finishing the degree.
The only one that can strip is the end user compiling a final binary, and the compiler often cannot do this for you because that requires whole program optimization and full LTO, which is super super slow.
Also, just because the final binary doesn't use a symbol, doesn't imply that the symbol isn't used. You can ship a library with a main function that can be run as an executable, or linked as a library. The linker doesn't know.
You would really need to go out of your way to strip your binary for your particular application. This is possible, and not that hard.
But the point remains: why should 99% of Rust users have to go through the trouble just so that those who need this don't have to write `cargo add unicode-segmentation` ?
Rust philosophy is "don't pay for what you don't use", so if your organization doesn't support third-party dependencies, they need a language with "batteries included", and not a language like Rust that comes without batteries by design.
Proposing to make Rust come with batteries included is proposing to change one of Rust's core values. Go ahead and write an RFC for that. I'll get my popcorn.
For distributed computing, you typically use message passing of some form via network sockets, that's "safe" by design. You can also use RDMA, and there usually your process needs to opt into that, create an RDMA readable/writable region, and you are back to the mercy of your network stack up to which kind of protection you can enforce there.
From Rust point-of-view, if you make the wrong assumptions about shared memory or RDMA regions, your program has a bug. The fix is simple, use appropriate atomic (or atomic volatile) to read/write from those regions. Even if another process is writing while you are reading, as long as the operations are the right ones (e.g. <128-bit atomic reads/writes), you can avoid memory unsafety and data races.
This won't protect you from deadlocks or race conditions, etc. but that's not something that any programming language does. Rust has deadlock protection within a process, but that's not required for safety, so it is an extra feature on top.
Have you tried doing that in C++? Doing that in a cross-platform way (or even in a single platform) is anything but easy, because you don't have a tool like cargo, you have to change your build system, do the dependency resolution manually, etc.
So no, such a library existing does not imply that using that is easy.
In Rust, you just need to write `cargo add unicode-segmentation` once in a project, and then you can directly use the library API. There is literally nothing else for you to do.
That's a pretty low barrier of entry, and something you will need to do 100s of times per project anyway, because the standard library is minimal by design.
If you prefer languages without a minimal standard library, then Rust isn't for you. Go try Python, where half of the standard library has a warning saying "deprecated: use this other better external dependency instead; adding this to the standard library for convenience was the worst idea ever and now we need to maintain all this code forever".
Adding unicode segmentation to the standard library and making all Rust binaries, most of which don't do unicode segmentaiton, 20 Mb larger by unnecessarily bundling the unicode tables, makes no sense.
As you see in the other thread, the problem the parent poster has is that their organizaiton doesn't let them use crates from crates.io.
That's a stupid policy for a language like Rust, and the solution isn't "move all crates of crates.io into the standard library". The solution there is for them to write their own unicode-segmentation code (and async executor, and http stack, and linear algebra, and... the whole world), since that is what their organization wants them to do. That's a stupid policy, but it is their own stupid fault.
Most organizations either allow using crates from crates.io, or have a vetting policy, where you just submit a 1 liner email saying "I need to do unicode-segmentation and there is only one library for that that's used by Firefox here: ...". Somebody then checks licenses and stuff, and gives you approval in a couple of days. If their organization doesn't have such processes, then i'm sorry for them, but I don't see how this is in any way the standard library fault.
Whatever their reasons are "my org doesn't allow us to use cargo" isn't a good reason to move something into the standard library.
That's what everybody already does? You are proposing to, instead of doing that, move that library into the standard library where it cannot ever change.
> You can provide standard Unicode handling that is good enough for 99% software out there.
That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because it doesn't deal with unicode at all.
You are suggesting moving something into standard that would make unicode software harder to update, and would make the standard library huge (>20mb larger) for all programs (the unicode tables take a lot of binary size), even those that don't use unicode, to try to solve a problem that does not exist.
> I work in such an organization and no, we cannot use third-party packages
If a Rust user cannot write `cargo add unicode-segmentation`, they have bigger problems than not being able to handle grapheme clusters. You can't run async code because you don't have an executor, you can't do http because the standard library doesn't support that, you can't solve partial differential equations, or do machine learning, or pretty much anything interesting with Rust.
That's bad for you, but the solution isn't to make Rust bad for everybody else instead.
If your organization doesn't let you use third-party packages, then write your own: that's what your organization wants you to do.
Some organizations want all code in CamelCase, they can't use the standard library at all. But the solution isn't to make Rust case insensitive, or to prove a 2nd standard library API for those organizations.
In general, Rust allows you to write software that doesn't break silently. That's a quite good value proposition for large scale software, where other languages often require programers to be super careful with refactorings, while in Rust you can really refactor all the things.
The reason people are afraid to do large refactorings in say C++ is often "security-related": fear of introducing segfaults, memory errors, undefined behavior, threading errors, etc. but one can also see these fears as "productivity-related" (hours and hours of debugging), or through many other lenses (shipping bugs to users, having a segfault in the middle of a demo that costs you a client, introducing a segfault one day before the release of your game, etc.).
In general, every programmer wants to have a certain degree of security that their software "works" for some definition of "works". For some this security might be actual network security, but for others it might mean that they don't want their data-science app that has been running for a week burning thousands of dollars to crash due to a segfault while writing the results.
Of course it does. Many software users are stuck on multiple-year-old toolchains for various reasons, yet these systems still need to be able to handle unicode properly.
> They can easily update it if needed.
No, they cannot. Many users are stuck in older windows versions, linux versions, LTS linux versions, etc. because of their organization or their clients requirements.
Telling a client that you can't develop an app for them because their 2 year old Ubuntu is too old is often not a very successful business model.
> and keep updating the stdlib one.
These updates would only apply to newer Rust toolchains, that many users cannot use. Unless you are suggesting the release of patch versions for the soon to be 100 old Rust toolchains in existence every time the unicode standard is updated.
This is too much trouble and work for little gain, given that one can still use a Rust 1.0 compiler to compile the latest version of the unicode-segmentation crate without problems.
We had (and still have) 100% code coverage on Windows MSVC, Windows GNU, MacOS, iOS, Android, Linux, FreeBSD, NetBSD, DragonflyBSD, Solaris, WASM, and many other platforms, as well as all possible hardware (ARM32/64, x86/x64, ppc32/64/be/le, sparc64, mips32/64/be/le, mips64, riscv32...).
The OpenBSD parts of our code base weren't tested at all; they weren't even compiled.
In practice that meant that pretty much every PR broke the OpenBSD support in some subtle way, and people would only discover those failures during the release process, which took a lot of time to fix, usually from somebody that did not care about OpenBSD at all, requiring them to create a VM to be able to develop and test from OpenBSD itself.
So yeah, we decided to unanomously require that code that cannot be tested be removed, and gave the OpenBSD devs the chance to fix it. Starting with requiring OpenBSD contributor on their PRs to add testing support.
It wasn't practicable because their platform is designed to prevent non-OpenBSD users to develop for it. So we removed the code, and this became some OpenBSD user group problem.
This solution actually worked better for them, because it became up to them to decide when new versions of our project got released for OpenBSD, so they could get the latest release, apply patches, test that it compiled locally and passed tests, etc. before doing a release for OpenBSD, something that we did not care about doing.
We believe that code that isn't compiled doesn't compile, and that code that isn't tested doesn't work correctly. Our OpenBSD parts were living proof that this is 100% true.
I find it quite ironic that this project is security related, and some of the bugs that hit OpenBSD were CVEs that were completely preventable. This CVEs only hit OpenBSD because it was the only untested platform. In a sense, OpenBSD users actually were quite lucky, in that most releases broke compilation for OpenBSD, and that saved them from many CVEs. Unluckily for them, not all bugs result in compilation errors.
> Finally, surely you get plenty of patches which do small useful things like cleanup but which it would likely be impossible to write a test for.
We have 100% code coverage. All our functionality is heavily tested and fuzzed. The modifications in a cleanup PR are exercised by many tests, and therefore tested.
If someone submits a bugfix, that means we were missing a test, so we require users to add one. OpenBSD devs weren't able to do that, so we stopped accepting their bugfixes, and at some point removed all the code.
If you don't think that bugfixes should be accompanied by tests that check that the fix works and the bug cannot be reintroduced again, then I disagree with you, and hope I never have to use your software.
The two main issues I see with #![no_std] are:
* its a flag for "doesn't link the standard library" but the standard library is often too high-level for bare metal apps that want to be in precise control about everything that gets linked
* it isn't a contract of any kind, so you can't rely on it for anything. In fact, this code is correct and works as intended:
#![no_std]
extern crate std;
So I agree with you that #![no_std] isn't a silver bullet. I think it is still useful in that it lets you avoid linking the standard library by default, which is necessary condition for embedded development. It is not a sufficient condition, in that in practice you actually want to forbid the standard library and other libraries from being linked, and not just "don't link them by default, but do so by accident".
> You'd need a third-party crate, at which point it's less "easy in Rust" and more "someone did the hard work for you"
"Someone did the work for you" is true of all code that you did not write yourself, independently of whether that code is easy or hard to write, or whether it is in the standard library or not.
unicode-segmentation is pretty much the only library of its kind in Rust, is super easy to discover (google "Rust grapheme cluster", "Rust unicode segmentation", etc.), and using it is as easy as just typing "cargo add unicode-segmentation".
The library is maintained by a Rust core team member, a Rust standard library team member, is used by servo and firefox, and is the only unicode segmentation library that people use.
Since many programs don't need to do any kind of unicode segmentation, making it part of the standard library sounds like a bad idea. In particular, given that unicode is a moving standard, it would mean that people stuck on old Rust toolchains (e.g. LTS linux distros) cannot create binaries that do proper unicode segmentation, which does not make sense.
The underlying problem is that many programmers do not know that they need to do unicode segmentation in the first place. Moving this into the standard library does not fix that problem either.
Maybe you are just using different no_std libraries that I am using, but pretty much all of the no_std libraries that I use have `libc` as a direct dependency.
Not only for malloc, many of them just needs to write something to stdout or a file, generate random numbers, ..., and that's hard to do without libc. Why they advertise themselves as no_std escapes my comprehension.
Doing this is quite easy from Rust.
Its far from clear that doing that is, in general, worth it.
It does. If both are NaN a NaN is returned. Note, however, that when Rust says that a NaN is returned, this means that any NaN can be returned. So if you have min(NaN0, NaN0) the result isn't necessarily NaN0, it might be another NaN with a different payload.
In Go, beyond the limits of your imagination, you'll also hit other limits, like those of the garbage collector.
If you have thousands of remote sensors collecting Gbs and GBs of real time data, for ~1000$ you can add a "streaming" supercomputer to your sensor to analyze the data in place and save on network and storage costs.
Notice however that the announcement is for an Nvidia AGX product, which is for autonomous machines. The Nvidia "edge" products for processing data on the sensors are called Nvidia EGX.
For autonomous machines, you often need to analyze the data in the machine anyways, e.g., you don't want a drone falling if it looses network connectivity.
Bad developers don't, but many developers do. The Rust project itself has hundreds of contributors, to the point that it feels that it has more contributors than LLVM itself (I work on both, and this is an unbacked feeling I get from the velocity of the contributions).
Point being, if developers wouldn't care about Rust, they wouldn't be developing it.
"Could be useful for" (FTFY).
Unfortunately, for the reasons mentioned above, most #![no_std] libraries aren't useful for that, because they link libc and other libraries.
Most people don't do this intentionally. The compiler doesn't complain about:
#![no_std]
extern "C" { fn malloc(...) -> ...; }
When you then go and build a #![no_std] binary, and run it in a platform when libc is not available, only then you get an error. And at that point, good luck figuring out which of your 200 dependencies has the error.
In particular, if you are running `#[test]`s, doing that links standard, so if your program implicitly depends on libc somewhere, tests won't reveal that, because while testing, libc will be linked.
How did you come to this conclusion?
People using Rust rely on libc a lot.
For example, #![no_std] means "no standard-library", but it doesn't mean "no libc, no libunwind, etc.".
So a lot of people like to advertise their crates as "#![no_std]" compatible, because they compile with #![no_std], but then the first thing the crate does is linking against libc, against liballoc, against libm, .... or even the standard library itself...
So... if you are trying to build a binary that does not depend on libc or libstd, then there is no language feature to help you there.
#[no_std] binaries are not only unstable, but also probably not what you want, since that won't prevent you from linking any library that links libc, or the standard library, etc.
If you want to avoid libc, you have to enforce that, e.g., by checking in your build system that your binary doesn't contain any libc, libstd, etc. symbols (I just use nm for this). #![no_std] helps a bit here, but making sure you don't link any library that violates this is up to you.
The TL;DR is that safe Rust is only sound, if the safe APIs it uses are sound, which requires their implementations to be sound (Derek Dreyer et al. [0]). That is, the soundness proofs a Rust's compiler gives you only apply to Rust programs with sound unsafe code.
If you exchange the malloc implementation with an unsound one, then the soundness proofs the compiler provides just don't apply to your program anymore (they apply only to programs with a sound malloc implementation).
---
Being able to worry about soundness in this space is kind of a luxus problem, but probably still one the most interesting aspect of Rust. Like, with C or C++, there is little discussion about soundness because most of the language is already unsound. Like, not even MISRA C tries to make a subset of C sound, just "less dangerous" or "less likely to make mistakes".
The big deal of Rust is that it modularizes soundness proofs, allowing users to prove different modules of their program "conditionally sound", e.g., sound _if_ everything they use is also sound. Most Rust code on crates.io is close to 100% safe Rust code, and that code is already "conditionally sound". This means that you only need to manually prove the remaining 1% of the unsafe Rust code correct, which is a much more tractable problem, than trying to prove 100% of the code correct.
This allows people to refactor that 1% of the code into tiny modules, that each can be proven correct in isolation, and that allow changes to be more precisely scrutinized.
The impact of this is huge. You can refactor pretty much all code you write without worrying about soundness, only needing to worry about it if you need to change one of those tiny modules.
* What kind of contract is it? (e.g. IG Metall? or if not, what's the pay range?).
This is what I do and works perfectly. My dev machines are 82 cores xeon platinums with Terabytes of RAM or nodes with 8 V100 GPUs attached, etc.
I don't know of any workstation, much less laptop, that could be a replacement for any of that.
For the stuff I do on the laptop itself (Word/Powerpoint/Outlook, web browsing, using an editor to edit files remotely, etc.), more power wouldn't hurt, but my macbook is a macbook air 2013... so I can't imagine that a 2020 macbook would be underpowered.
Walking your bike 200m to the closest bike shop?
With 50 EUR, every bike shop does the usual tear fixes: changing tubes, adjusting gears and brake levers, changing break pads, changing the handlebar tape, centering the wheels, and cleaning / oiling.
Those 50 EUR can't cover major damage, but lots of people in Europe have multiple bikes in their basement that are just "rusty" / flat tire / etc. and that they didn't needed during the winter.