As someone venturing in Tauri as primarily a web dev, I can relate to this so much. Rust is great and Tauri has some stellar benefits, but until you really master the borrow mechanics, it slows you down so much.
But in classic Javascript style, it's half-assed. Being able to assign anything to undefined makes the distinction between null and undefined pointless.
- A LOT of practice. One of that parts of becoming a good programmer is learning about potential pitfalls and bad practices; what better way is there of avoiding these than by making these mistakes yourself and learning from it.
- Studying and researching best practices for not just your current language or paradigm, but others as well. If you've got experience with Java, look into other paradigms than OOP such as Haskell / Elm that focus on Functional Programming. This can lead to learning about new ideas of programming in general, which is a good thing as it exposes you to more tools that you can use.
- Making your own things. Find areas in your life that could use some automation, or perhaps use programming as a creative outlet; the more tools you make, the more practice and experience you'll get which leads to the first point I made.
- Cringe at your old code. If it's really that bad, it's likely you've come a long way as a developer, which is good! Reflect from time to time about why you originally wrote code a certain way, and think about how you would approach the same problem now with more experience.
> How to solve self-driving for cars: build digitaly aware roads
Putting aside the physical aspects of replacing existing roads, how would a digitally-aware road work? A bunch of bluetooth devices? And in what schema would the road 'speak' to the car? Ideally it would be an open format, but who would decide upon that?
That's something I haven't thought about. I hand waived it with pretending that people be just as motivated to do this as they are with self-driving cars.
It is an interesting question though! I think of a few things that could be done quite easily:
Communication can happen via low latency with relatively little data. I wouldn't know what's best for that.
* Roads can broadcast. Roads can listen through sensors and determine the position of every car.
* Cars can broadcast. Cars can listen.
* Things can go wrong. There'd be huge demand for any distributed system engineer :P
A use-case sketch:
A road can determine if it almost goes out of bounds. A road can determine if two cars are about to collide, but so could two cars.
So this would work well in places where there are only roads and cars (e.g. highways and "road only" type of roads -- i.e. no bicycle lanes).
Cyclists can communicate as well. They need to chip their bike.
Pedestrians can communicate as well. They need to chip their coat. Though I'm not happy with that solution (what if the coat gets lost?).
Anyways that's my rough sketch. I'd need to research the technologies needed for this.
This would make for a fun systems design interview.
Whomever wants to brainstorm with me on it, feel free to email me. I don't think I'm particular talented in this area but I can be a rubber ducky.
I liked the idea of simply using mobile data services to update cars from a network. Keep a series of cat eyes or pressure monitors on regular tarmac roads, have a collector station every few meters and use that to relay information.
In areas without network you dont use self driving tech.
Driving data is cultural data, its not some natural phenomenon which is clean and periodic. If a truck transporting cows breaks down and there’s a herd of cattle running all over the highway, I seriously doubt the models are going to perfectly handle that situation.
Level 5 self driving is impossible, but with road data and external coordination, we can achieve the same effect.
Yeah, gaming on Linux has seriously come a long way thanks to the efforts of Valve and the wider community. My main issue with gaming on linux is cloud saves; while it generally will work with Steam, other platforms like GoG have no such capacity, and it's a real drag compared to Windows.
I recently set up Game Backup Monitor (http://mikemaximus.github.io/gbm-web/linux.html) for GOG games. The backup location is in OneDrive. I do have to import the backup manually, but the combination eases the pain.
I've personally tried some of those. Ubuntu simply works. I hate most of their defaults, most add bugs, Ubuntu is what most cloud providers use if you're a dev, every software provider targets Ubuntu if they target Linux, and so on.
You can install Ubuntu and it'll work. Easy. No other distro I've tried (Fedora, Suse, Manjaro, Mint, Mageia) is as easy.
I know we're just sharing anecdotes, but I dropped Ubuntu during the "Megalomaniacal Shuttleworth" days, and I still don't accept his vision for Ubuntu.
If you remember the earliest builds, they included a video of Nelson Mandela explaining ubuntu and implied it as a light, legally unencumbered OS for the world. I was helping build labs in East Africa at the time, and it was a fantastic choice for running scientific operations because of its relative UI cohesion and simplicity over Debian while allowing access to its vast repositories and package groups.
I kind of lost all faith when the power trips started happening across the GNOME Foundation and elsewhere and moved to less divisively ambitious distros that were more responsive to their users.
I've never had issues installing or using Linux on hardware I picked, but I understand the struggles of working around non-spec and proprietary chipsets without drivers. I don't use non-free drivers in most cases, so having hardware that doesn't struggle with them is paramount.
Mint and Pop are still Ubuntu based, not to ignore the Debian underpinnings of Ubuntu.
I've stuck with xUbuntu because it seems to be the most sane of the bunch when it comes to defaults and preinstalled software. Once installed, it does a good job of staying out of my way UI wise.
I love reading about the steady technical progress the team behind Qubes is making, despite never intending to daily drive the OS myself. It's incredibly fascinating to read up on all the security considerations that I, an average Joe, would never realistically need to concern myself with, but it's great to see an OS that really pushes forward for those that DO require such strict isolation and security.
I wish the Qubes OS the best of luck in future, and let's see how the GPU passthrough team goes.
> Of course, the CD-ROM only spins in one direction however. Crash Bandicoot programmers solved this issue by making it impossible to run backwards in the game.
I've been playing crash since I was a kid, and I never thought about why you couldn't run backwards. What a brilliant solution.
