> I have a product with an addressable market of something like 300 to 500 units per year. That puts me in the Defense/Aerospace/Medical area, where unit economics are completely insane.
I have manufactured in that area and while you are not going to be in the mass volume pricing levels, you don't have to be in the defense level either. You just have to build the product with the right trade-offs and design the appropriate manufacturing processes. Few seem to know how to do this.
Edit: let me expand. Don't injection mold if you can avoid it. Do resin castings or thermo-forming, neither require as expensive of tooling. 3D print parts with a good material like PC CF. Metal fabrication is easy and cheap these days. You can get a shop to laser cut, form, insert PEMs and powder coat for very reasonable prices. We are starting to get a lot of machined parts from China. You can source wire harnesses from China also. Do assembly with a small team. Use as much off-the-shelf electronics as possible, but don't be afraid to make small and simple PCBs if it makes your product cheaper and simpler. Leave the complex boards to a vendor initially because while they might seem simple to design, they can be complex to debug and production test properly.
I've burned tens of thousands of dollars with them. They have tons of sales, little to no support. They have zero ability to stick with a vendor who does good work. They're a total crap shoot on quality and no responsibility when it fails.
The problem is that it started out as any but stable and reliable. It asserted on received data, which in a network application is a super newbie mistake. When I looked at it, the pub/sub socket would hang forever if the other end interrupted the connection. So the zeromq guide which said "look how easy it is" was only true if you ignored errors. If you are writing network code and ignore errors, well, good luck. That was a long time ago (~10yrs) so if it is better now, good for them. Also, both founders have left the project. One passed from cancer, the other didn't like what he built and started over in C. Not that they can't be replaced, but transitions can be hard and take time.
What I mean is literally have an assert with incoming data as the parameter:
> assert(data_buf[4] < 8);
While your protocol might guarantee that data_buf[4] should always be a value less than 8, you don't use assert() to check it because it aborts the program if the check fails. The proper thing to do is a range check that returns an error for a protocol error (malformed data, etc.).
ZeroMQ literally called assert and any bad data coming in over the wire would cause your app to abort. Insane.
I literally meant the library would call assert() on incoming data. I am fairly certain that has been removed for a long time, but it can be hard to get past first impressions.
Because the product engineering isn't as important as the community and organization. I got excited about Firefox when it forked from Netscape, but since then I have been unimpressed.
Rambus is an interesting company. I can't vouch for their crypto offerings, but they have been around since the 90's and at one point pioneered high-speed DRAM interfaces. Lots of what we see in DDR today is based on ideas and concepts they pushed forward in their proprietary interface. Early on, they definitely did innovative work.
IIRC, their interfaces were used in some Sony play-stations and also some Intel systems.
Have you never walked into a store and they said you can't use a CC because their reader is down? It is nice to have a few dollars in your pocket for times like that.
I dont think I have ever encountered this in my adult life honestly. A more common occasion is encountering a business that is cash only (usually small market stalls) and is infinitely more annoying as I have to go and take out a amount of money greater than the product I want to buy, leaving me with a rather annoying amount of loose change.
Agreed. Especially when there's no ATM for 5 miles.
Plurality of payment methods is always more desirable and more
robust. If one is serious about business, why would you not take,
cash, cheque, credit and debit cards, contactless, NFT phone, and
bitcoin? Even if some of those are suboptimal, a sale is a sale.
The ability to negotiate and adapt is what makes the world go round.
One example; I was caught in an emergency needing to get a taxi to an
airport. On the way I explained the situation to the driver, and ended
up negotiating the fare as a mix of US dollars, Danish Kroners, and a
good bottle of wine, where the official expected currency was Euros.
The problem comes with cashiers and managers who are not business
owners and are terrified to do anything unusual. They are tied to
procedural rote and unable to think dynamically. It's all about what
they can't do even when evidently agreeable and favourable options
are on the table.
> If one is serious about business, why would you not take, cash, cheque, credit and debit cards, contactless, NFT phone, and bitcoin? Even if some of those are suboptimal, a sale is a sale.
For some businesses, the overall cost of accepting some of those methods may be higher than the expected revenue from customers who won't use another method. Buying new payment readers. Having to convert the bitcoin immediately to currency to avoid losing money due to its constant price fluctuations. Higher per-transaction fees for some types of payment. Increased susceptibility to fraud (for cheques in particular).
> The problem comes with cashiers and managers who are not business owners and are terrified to do anything unusual. They are tied to procedural rote and unable to think dynamically.
You would be too if you were barely making ends meet, the expected outcome for "a customer asked me to accept an unusual form of payment" was almost always "it was a con, the 'customer' got the merchandise/service for free", and you'd most likely be fired as a result.
> You would be too if you were barely making ends meet, the expected outcome for "a customer asked me to accept an unusual form of payment" was almost always "it was a con, the 'customer' got the merchandise/service for free", and you'd most likely be fired as a result.
Just the millionth example of why trust is a critical component in society. Its presence allows things to be flexible and efficient. Lack of it makes things suck for everyone.
As a former manager of a liquor store, I didn't want my staff to do anything unusual. That was for me and the owner, per the owner's instructions.
It wasn't that they couldn't think about creative solutions, it's that we generally didn't want them to. There were serious implications for wrong decisions. For example, we couldn't sell a product for less than wholesale. The staff had no idea what the markup was and so couldn't know if a discount was above or below wholesale. If a product was sole for less than wholesale, the owner could have lost his license.
The wildest we got was when the computers crapped out. I told the staff to write down every transaction. Each transaction included the cost of the item, bottle deposit, and tax. On a Friday/Saturday night, we knew the top 10 item totals by heart and we were also good at counting back change.
When I was a regular run of the mill staffer at the store, I was happy to stay in my lane. The expectations were clear and that was good for everyone even if we, or customers, were sometimes inconvenienced.
> why would you not take, cash, cheque, credit and debit cards, contactless, NFT […]
Well, all other significant concerns aside, NFTs are not fungible, it is literally in the name. Transactions are made through fungible methods.
Example: a $10 bill is exactly the same as any other $10 other bill or the same as having a $10 in your bank account. Same applies to BTC, any bitcoin is an equivalent of any other BTC.
This fungibility is what gives them the baseline feasibility as a common transaction method. Fungibility is just one of the many requirements for something to be useful as a common transaction vehicle, but it is one of the most fundamental ones, and if it isn’t satisfied, the rest of it doesn’t really matter. Sure, BTC is too volatile to be useful for transaction purposes in a lot of cases, but volatility is further up the chain of concerns, and BTC indeed satisfies the fungibility requirement. Sure, common AAPL shares are fungible as well, there is exactly zero difference between shares of AAPL that you can buy and the ones i can buy, but they aren’t fit as a common transaction method for many other reasons too.
Meanwhile, any given NFT is not an equivalent to any other NFT. They are explicitly intended to be unique and non-fungible/non-replaceable. There is no price for 1 NFT, just like there is no price for 1 painting, each NFT and painting is their own non-fungible entity. So everything else aside, NFTs are explicitly and by their definition are hard-disqualified to be a common transaction medium on the very fundamental level. In contrast, BTC doesn’t have such fundamental problems, but more in terms of practical problems (transaction speeds, transaction costs, high volatility, etc.)
Sorry I'm a complete idiot, that was confusing. Meant "Near Field
Xfer/Coms = an archaic way of saying "contactless" from about 10 years
ago. I forgot there is also "Non Fungible Tokens" for bored apes and
whatnot. :)
True. The only time I have walked out of store (maybe once or two times) is when I have already used card few times previously with unplanned $50+ purchases. Now this time I only need $5 thing, & they say there's charge of $0.50 for card.
I also was in your similar example. In US I have a car, so very rarely I use public transport which is not Bart. I landed in Toronto at 2am, got into Bus Google Maps told me, Bus driver said $2.50 fare, cash only. I gave him American 3 dollars, and he gave me Canadian $0.50 change back.
In most Norwegian supermarkets the card readers (chip and pin and contactless) still work even if disconnected from the network. In my local one they just print two copies of the receipt and ask you to sign one just in case the reconciliation process fails when the network comes online again. Some small stores have an account with Vipps so if their readers actually are down but the phone network is up then they just ask you to pay with Vipps (https://www.lifeinnorway.net/what-is-vipps/).
It used to be that many companies that accepted credit cards would have a backup carbon copy imprint machine to capture a rubbing of your card alongside your signature as an offline credit card capture mechanism that was reconciled later. They made a satisfying KA-THUNK sound.
Now that many cards no longer use raised numbers I expect such mechanisms wouldn’t work as well.
I have literally called ahead to order food then arrive to pick it up and be told that the card reader has not been working all day. Had no cash so I just ended up leaving.
I live in a low-trust society, so they wouldn't have accepted something like that. Had they offered, I might have said yes and gone back later. But I was mostly just pissed they didn't mention it on the phone.
Fun anecdote: I walked into a Capital One (BANK) where they have a Café, and the gimmick is that if you pay with your Capital One card, you get a reduced price.
They said their payment terminals were down so they could not take credit cards. I said oh... I don't have any cash, oh well no coffee for me.
They said well... we can comp you one drink per person if you don't have cash.
Neither I nor they considered the option of me walking over to the nearby bank ATM and withdrawing cash.
Your comment and mine are basically the same. This is what I call terrible engineering judgement. A random co-worker could review the simple solution without much effort. They could also see the corner cases clearly and verify the tests cover them. With this code, not so much. It seems like a lot of work to write slower, more complex, harder to test and harder to review code.
I don't understand. There are 7 suffixes, can't you pick the right one with binary search? That would be 3 comparisons. Or just do it the dumb way and have 6 comparisons. How are two log() calls, one pow() call and ceil() better than just doing it the dumb way? The bug being described is a perfect example of trying to be too clever.
The author says at the beginning that it’s not actually better than the loop.
Also 6 comparisons is only if you’d have the max value which seems unlikely in actual usage. Linear could be better if most of the time values are in B or KB ranges
Depending on how you define "randomly", you might have just decided no more phones, laptops, etc. Bad batteries can sneak into even the best supply chains and cause fires.
I don't like this. I recently sold some networking equipment to somebody for a bit more than this amount and asked for cash. Made the whole transaction simple. Things like this just keep taking power from the people and moving it into the government and private companies.
