Ask HN: Let's generate some startup ideas in 2024
Yes, I know this is generally a fool's errand. We've all read the essays. Let's try anyways.
Subscribe to podcast feeds and/or blog RSS feeds. Podcasts get transcribed by some AI tool. Written feeds get transformed into audio.
You can "highlight" in either one, using something like Snipd's system for podcast snipping (which you can easily go back and edit because you have a written transcript too).
I read much, much faster than I listen, even on 2x speed or higher, and I retain it better, so the killer feature to me is more the transcript of the podcast than the audio of the blog post.
Bonus points if it has e-reader-friendly pagination as a scroll option. And if I can self-host it if I want. And if I can export my notes.
If I knew how to build things at all, I'd be working on it right now.
Maybe everyone is prevetted and there’s a service or AI that makes sure you’re compatible looks wise, etc.
The "no photos" part only stands to benefit unattractive to average looking men. Good looking men already do well on existing apps. Women aren't going to join an app where they're rolling the dice when they can have easy pickings on Tinder.
Physical attraction is a major factor in selection. Taking photos away before the first date is just going to result in a lot of wasted time and disappointment for both genders.
Uber using skateboards
FTX in biotech
Craigslist for hookups
Like Blue apron but they also ship you a Casper mattress
Put your kids on the blockchain
Upside: everything is pipelined, and memory does compute directly. Should be good for Petaflops
I raised $372.03 for my FPGA chip on my profile and I've only sketched out a rough mock prototype of what I want the architecture to be.
So far, it works with any amount of silicon defects, can be up to the size of a silicon wafer, and the larger it is, the more it can reconfigure itself in parallel, which is directly proportional to its size growth.
I find your ideas interesting, especially your strong interest in routing around any faults, but still ending up with a relatively usable compute fabric.
My approach is much, much simpler.... just a grid of cells, with the programming lines unspecified. Each cell has a 4 bits in from their neighbors, a 4x4 LUT, a latch on each of the 4 bits of output. Clocking on the latch is in 2 phases, like the colors on a chess board.... this makes everything deterministic, but fully Turing complete.
The fact that the logic does the routing means that you can route around anything at runtime. The homogeneity and simplicity of the fabric means the run-time libraries on the host computer could do that routing, provided it had a map of the defects.
Here's a write up as an Esoteric Language: https://esolangs.org/wiki/Bitgrid
Here's an emulator written in Pascal: https://github.com/mikewarot/Bitgrid
I think the best approach is for both of us to try to get our ideas in the next Google open source chip shuttle.
How would you improve my FPGA? I have two directions that I could take my FPGA architecture such as adding analog Logic Blocks and adding beamforming LUT interconnect.
Can you explain how you would go about getting an MVP manufactured?
A BitGrid is completely uniform, a grid of cells with I/O to each Cartesian neighbor. If you have a compiled program ready to load into the LUTs, it's easy to move things over a row or column, or flip it, rotate everything 90 degrees, etc. Routing around a bad cell should be trivial.
Because I add a latch to the I/O, and the clocking is in alternative phases, you can't have a race condition, it's stable. All "white" cells have I/O to black cells (which are latched at that time), and vice/versa.
This makes it very easy to reason about, while still being Turing complete. It also means that you can have 4 independent functions of the same 4 bits of input, if you need it, in a given cell. Because each cell is doing its compute directly on data, and all in parallel, you should be able to get at least 50% utilization out of the LUTs without too much effort on the part of a compiler.
If you have data flowing "right" on the grid through a number of cells, with carry and things sometimes going "up" and "down", you're not likely to use ALL of those signals. In that case, you could have a completely different stream of data and compute going "left" at the same time. It can get as tightly used as the compilers want to dedicate time to finding.
Google supported (and I think still supports) an open source chip shuttle program that will make a chip, provided the design is licensed open source. I intend to get the BitGrid design made through that channel. I'll likely prototype it on an FPGA along the way. I've already got the emulator, so I can start work on some form of language/compiler to use to program it.
---
As for your design, I think that it would be helpful to know how many % of chip defects are in what layers of the chips. If metallization almost never fails, then just using wires all the way across the chip in an X/Y grid isn't that likely to be an issue that needs to be solved.
If the metallization does fail frequently, your design offers an advantage. However, any disabled section will effect propagation delays, which might eliminate the value of routing around damage.
Firefox detected a potential security threat and did not continue to postbrainer.com. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.
The certificate is not trusted because it is self-signed.