mmstick

Not if the gigabit ethernet adapter is also a USB3 hub, like so: https://www.amazon.com/USB-Ethernet-Splitter-HUB-Network/dp/...

They sell high end Linux systems, and maintain the Ubuntu-based Pop!_OS Linux distribution. The Lemur Pro — and other Intel-only laptops — are running open source firmware developed by System76 in collaboration with Intel.

Who buys computers from System76? People that care about buying hardware that's guaranteed to work with Linux, from a company that supports Linux. That ranges from web developers to NASA.

Options like so exist: https://www.amazon.com/USB-Ethernet-Splitter-HUB-Network/dp/...

You can purchase a USB3 to 1G ethernet adapter for $10.

Do you support the 19.10 release? The inability to compile or package every version and variant of TF, and GCC9 conflicts with both the CUDA SDK and Tensorflow, is precisely why we created Tensorman.

It did not have serious memory bugs. All of the unsafe code in Redox, of which only a small fraction is unsafe, is neatly compartmentalized so that it's easy to audit.

Having written Rust code for 4 years, I'd say it's not the biggest feature of Rust. It's just one of many good points. Among my favorite are the explicit & rich APIs, high level concepts (ADTs, pattern-matching, trait-based generics), and Cargo. The safety does play a big role in shaping some of the features though, and enabling some powerful APIs and optimizations.

He was given a notification by System76 back in January that we were busy with moving into the new warehouse, hardware testing, and developing our 18.04 release. Getting our firmware to work with his tool is not a high priority.

Rust doesn't have a runtime, so there's no runtime code to ship in the first place. It's as low level as C, but with a modern syntax and accompanying core and standard libraries. Thread support is done by using existing OS primitives for threading.

We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.

Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.

I landed a job w/ Rust, and the programming challenge I was given was a simple C programming challenge to implement a parser to parse gzip headers, to which I did it in both C and Rust.

Nobody hiring for a position that's largely Rust is going to ask you to write linked lists, trees, and graphs. They're going to want you to build something more complex & practical.

He's referring to how the language and it's ecosystem will evolve from this point forward in comparison to the C++ ecosystem. In addition, the programs that are there should be just fine. There is a lot of room for advancing the Rust compiler to generate more efficient routines from the same code. The Rust compiler, after all, is not taking full advantage of all of the available compiler information. A significant volume of information is simply discarded at the moment. C++ compilers don't have the same degree of headroom for possible future optimizations.

It doesn't really matter that Mozilla's a small organization. All they had to do was provide strong leadership and management expertise, and entice the open source community to voluntarily join and advance the project accordingly. Which thereby lead to not just Mozilla, but a few other organizations joining in with developers of their own to collaborate together amongst each other, including an army of rogue volunteers that aren't backed by any organizations. That's just not something you'll ever see from a corporation that has to answer to greedy shareholders that only care about ROI figures, especially short-term ROI figures.

You can mix them if you take your Options and convert them into Results with the Option::ok_or(E) method.

    do_this(x).ok_or(CustomError::ThisError)?;

I personally went from Go (slightly mingling with it) -> Rust 1.0 (wrote my first applications with it) and found it to be incredibly easy to learn in comparison to C, C++, Java, and even Python and JavaScript. Everything's pretty explicit and straightforward, and the API documentation and associated resources are stellar.

What's funny is that if you ask different people the same question about Rust's selling point, you'll get a different answer most of the time. Rust has a lot of features, and it's the sum of all the parts that make the whole, rather than a specific part in particular.

Sounds like what you want is more along the lines of the Ion shell[1], rather than Elvish. It's written in Rust, and the performance well exceeds Dash (written in C), despite having a lot of features that Dash is unable to do efficiently. Go's just not a good a language for writing a shell, especially once you get into job control and signal handling, or if you care about performance.

Some of the great features you won't find in Bash or Zsh are the string and array methods[2], first class arrays[3], slicing syntax[4], tuple assignments[5], optionally type-checked assignments[6], ability to use functions within pipelines, typed function parameters, a much simpler syntax, and more. Many of the best ideas from Fish, Oil, Elvish, Bash, Zsh and other shells have been implemented or are in the process of being implemented.

- [1] https://github.com/redox-os/ion/

- [2] https://doc.redox-os.org/ion-manual/ch05-05-method.html

- [3] https://doc.redox-os.org/ion-manual/ch04-02-arrays.html

- [4] https://doc.redox-os.org/ion-manual/ch06-00-slicing.html

- [5] https://doc.redox-os.org/ion-manual/ch04-00-variables.html#M...

- [6] https://doc.redox-os.org/ion-manual/ch04-00-variables.html#T...

If you have ideas, then you should pitch them on the corresponding GitHub projects.

Here in Northern Virginia, near the DC area, it was so hot that winter never came. Grass, bushes and trees were still green during winter. It didn't snow this year. And it's been incredibly hot through spring and summer. Temperatures have been consistently rising each month for many years.

The more experience you gain with Rust, the less you fight against the compiler, and the less you'll opt for the unsafe keyword. Fighting the compiler is just something that happens the first few weeks.

You should use crossbeam for #1. And as for strings, I wouldn't think of them as duplicate types any more than u32 and &u32 are duplicate types. They are semantically the same. Referencing a boxed type returns the reference type.

You say that, yet you're still running a ton of software written in C and C++.

Nice assumption. Much of the software I use is actually implemented in Rust. And soon, I'll be using an operating system that's 100% written in Rust, with a 100% Rust Servo-powered web browser. It's only a matter of time.

In addition, I've also implemented my servers (web server included) in Rust, and they have zero dependencies upon C/C++ software, so your entire point is rendered invalid.

Rust refactor times are significantly faster than C++, and solutions can be implemented and deployed to production at a much faster rate, without the need to wait for Coverity scans to verify PRs. It enforces proper idioms at compile-time; makes it easier to implement and debug issues with threads; enables the capability to enforce correct API usage (See how Vulkano > C++ Vulkan; or Glium > C/C++ OpenGL) with the aid of additional type information and compile-time state machines; encourages developers to push towards zero to minimal-allocation designs due to the move semantics / borrow checker; opens the door to a wide range of compiler optimizations not possible in C/C++; enables rapid software development through automatically pulling Cargo dependencies from Crates.io, and making it simple to push crates of your own to the repos for others to use, resulting in much less reinventing the wheel, and more extensive testing of community solutions; not to mention the ADTs and pattern matching, and a significant number of additional features that C++ just doesn't have.

It seems that you have a very misguided view of what Rust offers to the table. The main selling point of Rust is not safety. Safety is just a side effect of lowering the bar to achieving concurrency/parallelism, which has proven time and time again to be a major problem with C/C++. I can tell you right now that, among the top reasons that people choose Rust for, safety isn't even among the top three.

For many, Cargo is the main selling point of Rust. Then there's the ADTs, move semantics and move-semantic-powered features(borrow checker & compile-time-checked state machines), compile-time static code analysis, FP capabilities, traits and trait-based generics, pattern matching, and the miscellaneous tools and communities surrounding Cargo / Rust. None of which you can obtain with C++. Not to mention how much better the syntax of Rust is compared to C++ -- being able to succinctly express complex patterns in simple, human-readable terms with no room for context-based ambiguity.

Rust has made major strides in the cryptocurrency industry. Cryptocurrencies are largely becoming powered by Rust, because with cryptocurrencies, there is no room for error.

Using a programming language does not force you to join a community; and what is the Rust community, anyway? Which Rust community? The Code of Conduct pertains to the official venues of communication, not the language itself. All communities have rules. And the rules are quite normal of any community that wants something resembling civility.

Rust does much more than reducing bugs. It is able to reduce memory consumption, decrease the required amount of CPU cycles, and increase maintainability / adaptability. ADTs aren't a joke, and neither is Cargo, move semantics by default, and the borrow checker / borrowing and ownership mechanics as a whole. Shipping solutions in Rust can be done at record speeds, and integrate with existing software. Rust is wildly successful, and there's no way of stopping it.

This is one of the main issues of open source - people tend to work on what seems fun/interesting/rewarding. As a result a lot of people work on different implementations of the same things instead of coming up with one good solution and creating new things on top of it.

Creating new things is better than sitting on a sofa watching TV or playing video games all day. Furthermore, it often opens the door to possible new, unforeseen use cases, concepts, and success. Open source has a natural evolutionary path. Survival of the fittest, rather than survival of the richest.

Maybe you can explain to me why I am supposed to cater to other's whims as if my personal blog was a commercial project. It's not. Nobody is trying to teach me things here. They are simply demanding that I do what I have already clearly expressed that I am not going to do. This is my personal blog, not yours. I get to set the rules, not you. Perhaps you can take a hint and not demand others to do things for you even after they've expressed that they don't want to? If anyone is polluting the thread, it's your kind. Snarky, combative, argumentative, and ignorant. If you want to be an asshole, you'll get what you ask for from me.