It is actually. It's been shown that longer books make more sales as they are considered more trustworthy, so authors are incentivized to artificially drag them longer than they actually require
The money isn't from book sales. The money is you can charge higher consultant fees because "you wrote the book". If you don't play the game of course you won't make money, but writing a book is one step. (the full game has lots of different paths, there are other ways to make a lot of money without writing a book)
I imagine if I'd managed to actually memorize all of C++'s initialization rules, I'd probably have to write a book too just to get it all out, or I'd lose my sanity.
Not reliably. It can only drive Whisper quickly enough to appear real-time because of the GPU, and without that you're limited to the tiny/small/base models to get latency into single-digit seconds.
Edit to add: this might not be true since whisper-large-v3-turbo got released. I've not tried that on a pi 5 yet.
google docs and sheets have 99% of the features that an average home user would want to use for a word processor and a spreadsheet.
The things that docs don't have are things like templated designs, and other typesetting features that a professional document creator would want to use. It also isn't completely compatible with office document formats (some formatting and alignments are wrong). I would imagine similar with spreadsheets.
Uhm. You probably haven't seen the crazy Google sheets that exist out there.
They are really stretching what you should be doing with a spreadsheet and they are fully collaborative/multi-user. At some point it got really old to wait fifteen minutes for the sheets to recalculate.
It has the worst commenting and track history I've seen. My company went to Google docs about 5 years ago and I have steadily walked the work product of engineers go downhill because of it.
For what reasons? I've used both and never seen such a thing. In fact I'd argue the simplicity and collaboration features of Google Docs gives it an edge.
One issue is information density of the UI, the other is that text edits are embedded as comments.
I think it is great for planning a birthday party. Less so for critical engineering documentation when lives are on the line. My experience is that sloppy imprecise tools lead to sloppy imprecise work.
I used this to onboard to the PyTorch team a few years ago. It’s useful for understanding the key concepts of the framework. Torch.compile isn’t covered but the rest of it is still pretty relevant.
To understand a complex system, sometimes it better to understand a (simpler) model system. Sometimes an older version of the same system is that good model system. This is not true always but a good rule of thumb.
I have deployed and developed on their Triton inferencing server and it was amazing. All very good C++ and well architected. This one has Rust, Go, Python and C++. Seriously? First, not many Rust devs in the AI community. How do you think you'll get community involvement. Ok, may be you don’t need it. Second, good luck maintaining such a polyglot system. I prefer at most 2-3 languages - main language (C++/Java), Python for extensibility and Shell, etc for deployment.
Triton sits between CUDA and PyTorch and is built to work smoothly within the PyTorch ecosystem. In CUDA, on the other hand, you can directly manipulate warp-level primitives and fine-tune memory prefetching to reduce latency in eg. attention algorithms, a level of control that Triton and PyTorch don't offer AFAIK.
MLIR is one of those things everyone seems to use, but nobody seems to want to write solid introductory docs for :(
I've been curious for a few years now to get into MLIR, but I don't know compilers or LLVM, and all the docs I've found seem to assume knowledge of one or the other.
(yes this is a plea for someone to write an 'intro to compilers' using MLIR)
It is written in Python itself and emits efficient CUDA code. This way, you can understand what is going on. The current focus is on inference, but hopefully, training workloads will be supported soon. https://github.com/hidet-org/hidet
> Software engineers would rather quit than return to the office
Either the level of entitlement is shocking or the article title is delusional. There are thousands of ppl in the market looking for a job and would happily take one to feed their family. It's high time techies get a grip of real life than live in their echo chamber.
Or they just have different experiences than you do? For the positions I've been in, the drive into the office is just a waste of time. Most of the people are in different locations resulting in virtual meetings anyhow. Companies are realizing this and are going remote where they can because they find it difficult to find people locally or convince people to relocate. The "entitled" are just exercising their option to work places which better fit them.
The average job tenure in the tech industry is what, ~2 years now? If return to office means a return to precovid norms, most people aren't returning to the same jobs they had because it's been almost 5 years.
The video you're responding, as well as every other usage of the phrase, includes these people in the definition of "return to office", so I'm not sure why you're intentionally trying to use a different, somewhat nonsensical definition.
I'm not sure why you're intentionally trying to redefine the word "return" or miss the point.
If you were never somewhere, you can't return to it. Period. Your assertion about "every other usage of the phrase" is absurd.
If people were hired with the assurance that the job would always be work-from-home, then they have a legitimate gripe. They are the ONLY ones who have a legitimate gripe.
I'm not sure if there's some English as a second language issue going on, but descriptive phrases don't have to be strictly literal. In this case, the subject is the workforce as a whole "returning", not the individual employees.
