Hacker Newsnew | past | comments | ask | show | jobs | submit | jeffrallen's commentslogin

Super interesting. I use data center GPUs at work, but I didn't know anything about this stuff.

I also use Qwen 3.7 27b at work and I agree with the author: it is perfectly capable of the jobs I give it.


My aunt had her American Express die on vacation and they had a new one in her hands, in her hotel room, at 8 am the next morning.

Priorities. Sigh.


I wonder if it would be possible for a business to exist that was like super double ultra premium T1 diabetes support. Maybe it's really expensive and not many people can afford it, at least at first, but it'd be like you can call up an on-call desk any time, day or night, 24x7x365, and immediately talk to somebody who can pull up your full situation and history and do anything necessary to fix any possible problem. Get anything you need shipped to you anywhere next-day, get you premium service at any local pharmacies or hospitals, already set up to do exactly what you need before you even get there, sweet-talk the tiny local mom-and-pop pharmacy, produce all of the right papers and work the right angles at the huge national chain pharmacy, track down the one that actually has or can do what you need, etc. What would it be like if you were able to actually throw enough money at the problem to create a perfect worry-free experience for at least some people.

It sounds possible, but insurance probably won’t cover it. So this super double ultra premium T1 support will probably be only for the people rich enough to not need insurance.

Thanks for highlighting this story.

Failure is not only an option, but is required. The more smaller failures you have, the more big successes you can have.

Well, they just had a failure, so that spells great success, right?

I'm unclear on the point of why having a rocket blow up when you're being slow and careful is more of a setback than having one blow up when you aren't.


Information theory. If you are doing lots of small, incremental tests, burning through a lot of hardware doing all sorts of characterization and qualifying tests, learning a little bit from each one, you can make steady progress, finding your mistakes as you go.

If instead you try to work out everything in painstaking detail, build a small number of prototypes that your calculations assure you should work, and one blow sup, you learn that...your calculations are wrong.

Imagine developing software with no CI tests, where you only get to run one full system test every couple of months. Slow and careful means avoiding lots and lots of early learning opportunities.


Necessary and sufficient are different concepts.

ah, yes ... there's no success like failure, and failure's no success at all.

Space elevators!

It should not be a surprise that if you hire Ive to design something, it's gonna look like an iPad. It should not be a surprise that Ferrari stakeholders don't want an iPad car.

This is just gross incompetence all around.

Above all, Ive had an ethical responsibility to protect his clients from harming themselves by refusing the commission.


Given it's Ive I'm surprised he didn't try to make the car as thin as possible


The squircles and rounded triangles kill the interior for me.

Or arbitrarily remove something that everyone takes for granted. Like the glove box or the door handles.

The jokes practically write themselves, right? :)

And you have to flip it over and charge it from the underside.

Let' just hope it doesn't bend.

I mean, if Rolex hired Apple and gotten the Apple Watch then nobody except Jony Ive would have been happy either.

Nope. For production, you want to reduce risk and variation. DACs are already available in about 5 sizes up to the max 7m length, why would you terminate any other size in the field?

I did spec a couple of 7m dacs a few months ago to run between two adjacent bays, but normally for more than 2m I'll just drop a SM sfp and run a preterminated fibre cable.

In the field its the armoured fibre on a reel, 100m, 200m, 500m etc, with opticon connectors, or some normal cat5 typically for APs


Some network guys I know prefer fibre even within the rack, just because they don't want the weight and the obstructions in the rack. Apparently more than once the weight of the DACs and the bulk of the cable bundle has caused a problem with NICs.

Personally that surprised me, but I can see where they're coming from.


If you start doing bonded links with DACs or if you have a bunch of servers, the cable management situation gets ugly in a hurry, and the usual solutions like patch panels and keystones aren't applicable. Source: my basement

> the usual solutions like patch panels and keystones aren't applicable

Why not ?


You can't punch down twinax and the connectors are too big for keystones.

Yep, I did this for my little DGx spark cluster because 100-200gb copper cables are very thick, heavy, and annoying.

Support brackets would be 10x cheaper than fiber.

Admittedly I'm not buying Enterprise Grade(TM) stuff, but...

For simplicity I just use 10G LR modules everywhere. A pair of fiber transceivers is $25. Pretty sure last batch of 3M pre-terminated fibre cables I was grabbing were like $3 a piece or something. So we'll round up and call it $30.

I can get a 3M DAC for about $20.

So yeah it's cheaper, but the price isn't _that_ different. I was using DACs in quite a few places (and still am), but in general I've found it easier just using fiber. (For one, I've had a few devices that didn't get along with various DACs but worked just fine with the fibre transceivers.)


The fibre and sfps are a tiny price of the entire solution

DACs will be cheaper than fibre in a bay, but between neighbouring bays about the same.

A 7m passive 40g qsfp dac is £80. A pair of multimode 40g is £66 and 7m multimode cable is £10.

A 2m dac is £28, so fibre is 3 times the price.


If you do it only once and would never touch it - yes.

But the time spent on digging around and occasionally debugging what and where exactly came off and no longer links (at best) or there is still link up but the are too many errors, add some SLA on top of it... No.


Too bad they didn't mention that while the cable is direct attach, the ends each have an EEPROM in them saying what the cable is. This EEPROM can be a source of immense frustration, if it's got the wrong data in it, or if both ends do not agree.

This should be higher up for anyone considering DACs for homelab use. I had a lot of issues due to this when mixing Aruba switches with Intel nics in my rack. Ended up going to fiber and SFPs.

I just told a colleague no to a new dashboard she was proposing. In the process of explaining why, we realized that the automated system had a new interesting edge case that we could program it to investigate automatically and report - the same thing she wanted the dashboard for.

A no that turns into a yes is the best kind of no.


It would be better on the original latin.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: