Are you seriously suggesting hobbyists should tapeout an ASIC instead of use an FPGA?
1. For one-off designs (quantity=1) ASICs will never beat a high end FPGA on unit price.
2. As a hobbyist, you want to EXPERIMENT. You cannot do that with an ASIC. Hobbyists want to do something simple, test it on real hardware, and slowly build up from that. I don't have the time nor expertise nor motivation to spend months writing verification to get it right the first time for a tapeout.
"Just use a microcontroller"... I will concede that microcontrollers do cover 90% of hobbyists use cases (that number increasing by the day). But for hobbyists sometimes you want to learn HDL or digital logic or computer engineering. You can do this hands on with a FPGA much more effectively than in software.
> It's probably cheaper for them to maintain Windows for one reason or another.
They already need to maintain the Linux build for all the other paid tiers?? These are the same software with different features locked behind a license key. It costs them NOTHING to keep the build enabled for free tier.
> Are you seriously suggesting hobbyists should tapeout an ASIC instead of use an FPGA?
No. I said the low-end of FPGA sales is getting eaten by microcontrollers and the high-end of FPGAs sales is probably about to get eaten by custom ASICs.
Although the cost of making an ASIC is high, in the larger nodes it's not that high, and getting ever cheaper at FPGA performance levels and logic densities. FPGAs are terribly inefficient with their HW they're very easy to beat with an ASIC. They only get away with it because the NRE today is lower. But it's not an order of magnitude lower and I'm not sure how much longer that will be the case in nodes at 28nm and larger based on what I know Universities pay in tape-out classes.
Will there be very low qty projects where the NRE of developing an ASIC overwhelms that of an ASIC, sure. But will there be enough business in that niche to sustain the business of AMD, Intel and Lattice? Not obvious.
And I don't think the FPGA hobbyist market of people who "want to learn HDL" spends enough money to affect what's coming and this decision from AMD reflects that.
> 1. For one-off designs (quantity=1) ASICs will never beat a high end FPGA on unit price.
Never say never. These guys were able to convince investors you're wrong about that. :)
> No. I said the low-end of FPGA sales is getting eaten by microcontrollers and the high-end of FPGAs sales is probably about to get eaten by custom ASICs.
You have absolutely no idea what an ASIC costs compared to a FPGA. A FPGA that can compete with a tinytapeout chip costs a few dollars at most in extremely low quantites. Something high performance would need probably TSMC 12nm or similar at a minimum. At that point, you're talking $1M+ between licensing fees and direct costs to just go on a shuttle. If you want to make your own higher volume run or can't wait for shuttle spot, you're looking easily $5-10M minimum for your first 6 wafers. Comparatively, FPGAs competitive with TSMC 12nm run from a few hundred dollars up to several thousand dollars each. So for low volume, they're very competitive.
Are you sure you actually know what you're talking about?
FPGA unit costs keep doing down and they usually tend to use a recent manufacturing process. Meanwhile the fixed NRE costs of ASICs keep going up the more advanced the manufacturing process is.
An FPGA consists of non programmable logic components such as DSPs, block RAM, NoCs, SERDES/configurable IO, that keep scaling with the manufacturing process.
If you try to replicate this with an older process to cut costs, you will have an area and energy efficiency penalty.
This means that FPGAs have become more relevant over time.
How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.
> Middle management is where the institutional knowledge sits on how to actually get shit done despite challenges & broken processes/systems.
Really? In my experience it's the rank-and-file employees who have this knowledge of how to get on with it without ceremony and politics. And the broken processes and politics are created BY the middle managers.
> On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.
Pro tip for enjoying your life at work: this also applies to you work projects. Once you realize this, you can have a lot more fun at work and even coerce work projects to be more like your for-fun/side projects. Of course this is detrimental to the company as a whole, but your company almost definitely does not care about you and you might as well extract as much enjoyment as possible.
If your coworkers are actually passionate about programming (i.e. not drones or PM brains running flowchart to increase quarterly profit), you can even make work more enjoyable for them.
Things like unconventional language choices, over-engineering of systems, unusual coding styles, obscure protocol/library use, and of course a ton of NIH can really spice up a mundane codebase.
Even stretching an "easy" module into a masterfully crafted program and going 4x over estimation can be fun sometimes (without any of the bad design choices suggested above).
Yes I stand by this bad advice, and it's allowed me to play with so much technology I would never otherwise touch at day job.
I'm pretty sure he has used gradient descent in previous videos to optimize systems, maybe this time it was just easier to hand tune rather than set up an optimization feedback harness around MuJoCo.
I was curious what information I could glean from these for some popular repos. Caveat: I'm primarily an low-level embedded developer so I don't interface with large open source projects at the source level very often (other than occasionally the linux kernel). I chose some projects at random that I use.
*Mainline linux*
Most changed files: pretty much what I expected for 1 and 2... the "cutting edge" of Linux development over other OSes -- bpf and containers. The bpf verifier and AMD GPU driver might get a boost in this list due to sheer LoCs in those files (26K and 14K respectively). An intel equivalent of amdgpu_dm is #21 in the list (drivers/gpu/drm/i915/display/intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules/blobs?).
10399 Christoph Hellwig -> I only know his name because of drama last year regarding rust bindings to DMA subsystem
8481 Mauro Carvalho Chehab -> I also know his name from the classic "Mauro, shut the fuck up!" Linus rant
8413 Takashi Iwai -> Listed as maintainer for sound subsystem, I think he manages ALSA
8072 Al Viro -> His name is all over bunch of filesystem code
Buggy files: Intel comes out on top of GPU drivers this time (twice). Along with KVM for x86(64), the main allocator, and BTRFS.
Buggy files: DWARF debuginfo generation, x86 heuristics tables, RS6000(?!) heuristic tables. I had to look up RS6000, it's an IBM instruction set from the 90s lol. cp-tree.h is an interesting file, it seems be the main C(++) AST datastructures.
*xfwm4*
Most changed files: the list is dominated by *.po localizations. I filtered these out. Even after this, I discovered there is very little active development in the last few years. If I extend to 4 years ago, I get:
1. src/client.c - Realizing this project is too "small" to glean much from this. client.c is just the core X client management code. Makes sense.
2. src/placement.c - Other core window management code.
This has not told me much other than where most of the functionality of this project lies.
Bus factor: Pretty huge. Not really an issue in this case due to lack of development I guess.
Files with bug commits: Very similar distribution to most changed files. Not enough datapoints in this one to draw any big conclusions.
I think these massive open projects (excl xfwm) are generally pretty consistent code quality across the heavily trodden areas because of the amount of manpower available to refactor the pain points. I've yet to see an example of "god help you if you have to change that file" in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.
Big projects tend to self-correct. These commands hit differently on private codebases with 3-10 contributors, where high-churn usually means one person patching the same thing repeatedly.
The shell.c ouroboros is really cool. Being able to bootstrap trust through an entirely different language family (shell → C → shell) adds genuine value to the trusting-trust problem beyond just technical novelty.
He implied replacing nano was the first step, before using it for more complex (software development) tasks. First use it just for quick one-off edits of /etc/blah.conf then graduate to using it for longer editing sessions.
Rather than being about fast/simple/cheap, I think using SSN as a key was more about the fact that SSN is the only common identifier that almost all US citizens have.
I think you're using the word "key" differently than OP. You're talking about identifiers, and they're talking about security.
SSNs were a good potential identifier, until the people that needed security cheaped out and started using SSNs as a bad implementation of security. Now they're bad at both purposes!
Sure, but splitting "atomic" operations across a reboot is an interesting design choice. Surely upon reboot you would re-try the first `mv a b` before doing other things.
1. For one-off designs (quantity=1) ASICs will never beat a high end FPGA on unit price.
2. As a hobbyist, you want to EXPERIMENT. You cannot do that with an ASIC. Hobbyists want to do something simple, test it on real hardware, and slowly build up from that. I don't have the time nor expertise nor motivation to spend months writing verification to get it right the first time for a tapeout.
"Just use a microcontroller"... I will concede that microcontrollers do cover 90% of hobbyists use cases (that number increasing by the day). But for hobbyists sometimes you want to learn HDL or digital logic or computer engineering. You can do this hands on with a FPGA much more effectively than in software.
> It's probably cheaper for them to maintain Windows for one reason or another.
They already need to maintain the Linux build for all the other paid tiers?? These are the same software with different features locked behind a license key. It costs them NOTHING to keep the build enabled for free tier.
reply