I've been dealing with missing drivers since Windows 3.11. In the case you're describing, I'd connect a USB mouse, or just 'tab' my way through setup.
631 karma · joined December 22, 2020
Is the author saying that some drivers are not included on the DVD image, or that there are drivers that Microsoft isn't making available at all, even via windows update?
We all have our preferences, obviously, but to assert that MacOS UI is 'a masterclass in bad design and lackluster features' is a grandiose exaggeration stated as fact.
As soon as I opened "yahoo.com", he asked "how am I paying to view Yahoo?". I said you're not paying anybody, you're just paying for the Internet connection. He nodded.
I then showed him Hotmail. He kept asking "ok so now, how did they charge me to view this page?". I kept telling him, "that's the beauty of the internet, you don't pay for each site you visit, you just have access to this enormous body of knowledge".
He was thinking of sites in terms of making long distance calls, since he knew the Internet used the phone line, so to him it was normal to pay for each "site call" (if that makes sense), because that's how phone calls worked.
This interaction stayed with me for a long time, because it was natural for him to think about paying for each website visit, but to me it was all 'free'. As social media and user data became more monetizable in the years after, we found out pretty fast that there was no such thing as free.
At times I wonder what would the web feel like if it worked like my uncle expected it to work back then. Websites could support their existence without ads, since each customer would be a paying customer. Ads would still be around, but perhaps people would have demanded a nicer experience once they know they are paying for the visit.
In many ways, that's the lense through which I look at web3. It might be too late to switch to a pay as you go system. It might be too late to educate people about the importance of staying anonymous and preserving their user data. Nothing about this payment system requires a blockchain, but internet-money is a good enough excuse to introduce an alternative pay-per-click approach to the Internet, because, to be honest, I think the Internet ended up being a cesspool of abnoxious ads, paid content, ads disguised as content, dark patterns, etc, like the world's dirtiest third world country bazaar.
Maybe if we paid for each click, the experience of using the Internet could be more like a supermarket.
It would certainly be different.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.
What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.
Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.
Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity.
If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
Risk-wise, I think nVidia has no choice here. They should assume the Verilog source will eventually be made available. The only question is whether the time between now and then is valuable enough to give in to the demands.
Sure, other languages have caught up or have improved on some of the features where C shines.
Let's remove portability and integration from the feature list, because that's strongly related to C's tenure.
Which one of the languages you listed matches the rest of the feature set I brought up?
* Small language
* Fast compile times
* Fast binaries
* Small binaries
* Great debugging experience
* Close to the metal
We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages.
If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't control) then it better be a wise tradeoff.
No other language has been battle tested for longer and more extensively than C.
Your kernels, OSes, drivers, databases, web servers and compilers are written in C.
If some of these features are not important to you, there are hundreds of slower, more complex and less portable languages to choose from, that provide other benefits instead, such as more convenience, more correctness and higher level abstractions.
If the Rust fanboy brigade could articulate actual criticism for C, such as the lack of imports, or eskewing the type system with void*, or the signedness of char, or any of the other topics beaten to death in online "C gotchas" power point presentations, then we could have a constructive conversation amongst craftspeople.
Those who aren't careful enough to free up allocated memory are the same types of people who leak memory in Java.
You can't fix lack of knowledge with a compiler. You can only catch accidental mistakes, but that assumes that the norm is for the person to know what they are doing and a lot of people have only superficial knowledge of the tools they are using.
We already have accident catching tools for C. What C doesn't have is a helmet, training wheels and padded walls, which is by design.
If at any point in time there is a way to tie your identity to _any_ of the transactions made in your lifetime, then all of your other transactions get deanonymized retroactively. Maybe you made a mistake, maybe a bug is introduced into the Bitcoin software, maybe the government passes a new law, etc.
Cash doesn't have this issue. The bills I'm paying with when buying coffee at Starbucks, don't give you visibility into all of the purchases I've made with cash for the past 20 years.
The only exception would be crypto like Monero, but it's not the rule. Bitcoin is the flagship coin which somehow got people to think it's anonymous.
All it takes is for the government to require you to use the same wallet that's tied to your identity and then every citizen's transaction, past or future, is traceable to a degree that is just not possible with cash. That's a dangerous capability and we, the people, should make sure not to slowly end up in such a situation.
Spoiler: because it's easier and cheaper for them to sucker you into doing work for IOUs.
Ask for the cash or a piece of the company. Once you hand over the code, you don't have a lot of leverage.
In many classes I chose what project to work on and I chose to push myself to work on difficult projects (e.g. I could have chosen to implement a basic stack machine with a small instruction set, instead I chose to implement an ARM CPU, which lead to many overnighters to meet the deadlines; the 3D game was my choice as well - I could have picked to implement an easy visualization in opengl).
In all honesty some of the intro courses were not worth the price tag, but the advanced ones I'd consider taking again just for fun. If your employer covers the tuition, then I'd say that any course taught by instructors at SEAS (Harvard's engineering school) is absolutely worth taking.
A job at Google won't bring you even close to be able to learn all of that on the job. The real world version of most of such projects are orders of magnitude more complicated, take years to develop and have tens to hundreds of people working on them.
Since you lack both the theoretical and practical knowledge of writing a kernel, for example, you will not be designing the solution for it at Google. At best you will learn to implement a piece of it, and it will take years (think of working on Fuchsia with no prior kernel experience).
A (master's) degree isn't an automatic ticket to becoming the lead developer on Fuchsia, but it gives you the chance to learn the theoretical portion of the domain and apply it in a controlled environment, at an accelerated pace, under the guidance of a person who specializes in teaching (not jaded Joe who's waiting for his RSUs to vest), so you have a large foundation on which to build the real world practical skills on the job.
Even if you switch teams every half, you will still not be able to cover the breadth of the material in a master's program on the job, not to mention having to perform to get a good enough rating to stay employed, while having essentially no prior knowledge of the topic.
You could supplement by taking some courses or reading books after work, but this would essentially be a diy masters without access to experienced professors, that would take much longer and be several times more stressful and inefficient.