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


That's not transferring the bitcoin, that's giving potentially temporary shared access to the bitcoin.

The other party then needs to transfer the bitcoin to make sure the original party doesn't use it.


You can also buy some for less than $100.

I can vouch for the reTerminal: the build quality is excellent, and they come with a battery, sd card reader, and some sensors: https://www.seeedstudio.com/reTerminal-E1001-p-6534.html


Gonna piggyback here to second this and chime in to say I went with the BYOD screen linked within your link for $49 (SKU 104991005). It's definitely more barebones and probably not even as cost-effective if you're still planning on buying the "lifetime" TRMNL API access.

I don't have easy access to a 3d printer, so I just have mine sitting on an extra phone stand I had lying around that can be had for a few bucks from Amazon.

I couldn't be happier with it and am thoroughly enjoying my complacent, lazy solution :)


FWIW you need to pay for the trmnl key ($50) to use your own device with their servers, but if you run a server yourself you don’t need to pay.

I’m very tempted, a lot lower resolution than a kindle but it’d be pretty cool.


i could have been clearer about that. but yeah, even for what i paid, i was happy to immediately be off to the races designing the couple panels within their web portal and having something functional and useful to me without any real friction from having to figure things out.

moving on to the self-hosting side is probably now backburnered indefinitely, even if i do have some grander ideas in the longer term. unfortunately, i'd need more than a weekend project's timeframe to bring them to fruition.


you can point a higher def Kindle to TMRNL, either our closed source web app or free to an open source server.

https://github.com/usetrmnl/trmnl-kindle https://github.com/usetrmnl/trmnl-koreader


> a subtle data race and a rare deadlock

That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).


For Go, there is https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks. There are some missing things from C++ Thread Safety annotations, but those could be added.


Go has a pretty good race detector already, and all it (usually) takes to enable it is passing the -race flag to go build/test/run/etc.


No language protects from dead lock.


Not true! There are a fair number of them, and they're even reasonably general-purpose, e.g. https://www.ponylang.io/

Most that can recall achieve this by simply not having any locks at all. That's feasible with some careful design.

Outside proof-oriented languages though, I'm not aware of any that prevent livelocks, much less both. When excluding stuff that's single threaded but might otherwise qualify, e.g. Elm. "Lack of progress" is what most care about though, and yeah that realm is much more "you give up too much to get that guarantee" in nearly all cases (e.g. no turing completeness).


I probably agree that they don't protect you from all deadlocks, but some languages protect you from some dead locks.


You should be using rust... mm kay :\


Doing concurrency in Rust was more complex (though not overly so) than doing it in Golang was, but the fact that the compiler will outright not let me pass mutable refs to each thread does make me feel more comfortable about doing so at all.

Meanwhile I copy-pasted a Python async TaskGroup example from the docs and still found that, despite using a TaskGroup which is specifically designed to await every task and only return once all are done, it returned the instant theloop was completed and tasks were created and then the program exited without having done any of the work.

Concurrency woo~


Yeah, I'd really have liked to see something like [Trio](https://trio.readthedocs.io/en/stable/) gain mid more attention in Python. Structured approaches can prevent a huge amount of those issues, and Python code is absolutely riddled with concurrency problems in my experience. Much more so in practice than other languages except maybe javascript (when including async ordering mistakes). It makes it a real nightmare to try to build anything actually reliable.


The person I was replying to sounded exactly like the Rust zealots roving the internet trying to convince people to change.


So you are trying to explain concurrency to the folks who implemented CSP in both Plan9 and Go. Interesting. I should return "cspbook.pdf" back.


One day, maybe today, you will learn to read


(eval) rather than (read), then.

On concurrency, Go has the bolts screwed in; it basically was 'lets reuse everything we can from Plan9 into a multiplatform language'.


does that only include SSDs, or does it include HDDs as well?


It includes all forms of storage except for USB devices, GPUs and high end CPUs. The latter you can still get but you're going to have some severe sticker shock.


Maybe shucking USB HDDs is the short-term answer.


Is that still possible? Aren't they native USB with no adapter?


Those drives are SATA inside the case.


That depends on the brand. The lower priced brands, yes, those can be SATA, the more vertically integrated companies also make custom PCBs that just have USB-C without any SATA interface exposed internally.


I've shucked WD MyBook drives, just a plain SATA inside. I guess that it's cheaper to have a stock drive and a cheap SATA-USB adaptor in a shell than do custom electronics. I've not heard of any that are otherwise, but I've only done a few. I suppose it's possible that they could solder them in or have custom electronics but I would have thought that rare. It's frequently discussed on Reddit too, so there's plenty of folk doing this.


Do you mean the big ones or the SSD ones?


The big ones with a separate power brick, I've not looked inside the smaller USB-powered ones. My interest was in the >8Gb desktop drives. I'd imagine they're the same deal, but hard to say from the outside. I did have a part of one at one point, a USB-to-SATA circuit board that was useful for adhoc connecting 2.5" drives, but I can't recall if that came from an prebuilt or an old BYOD enclosure.

I have a old WD small one that's kinda faulty (plugged it in then put it down heavily, it's not been right since), I should pop it open just to see what's inside, but it's older than the USBC models so could easily have changed. In any case, I don't think AI is eating the stock of slow laptop HDDs, so I'm not sure there's any need to buy these just for shucking.


Ok. So I have a bunch them here, different sizes, both SSD and spinning rust. The big ones are all consumer grade drives with a little adapter board like you describe. The small ones are a mix of a single custom board with a USB connector and adapter board based ones. The tell tale is the outer dimension in the length, if the case is a little bit longer than a standard drive you have a very good chance of having one with an adapter board if it is the same or even smaller than the standard format then almost all of them are custom boards. The really nice ones have NVME guts in them that you can immediately repurpose.


I popped open a WD 'My Passport' drive, 4TB. It's exactly that - no SATA connection at all, only a USB on a custom board. I should have guessed this, it really is too short to have much in the way of other electronics. Thanks for confirming about the larger models, it's always good to know where we can source spares in an emergency. Top tip about NVMe - I would never have guessed this was an option.


YW, good luck with the hunt!


It's probably feasible to make a "mass storage USB in, SATA protocol out" smart adapter board.


I see, but if you plan on shucking you obviously get ones you know are able to.


I read it as both, but UK suppliers have stock of various SATA HDDs available in large and small sizes. It's hard to say if prices will rocket or availability decline, or both. I don't normally advocate panic-buying, but if it's needed now is the time. I have one NAS spare on hand, I don't want or need a drawer full of them, but it'll be a royal pain if I do and can't get parts.


Lower performance/capacity consumer drives might be comparatively safe because there's Chinese end-to-end production capacity for those. Of course the price can still increase, but probably not that much.


Admittedly I've not been tracking price, only availability, and only in the size I might need.


Interesting, they flipped the problem around.

The UI toolkits in game engine usually suck hard, so here they started from a good UI toolkit and made it possible to make relatively performant games.

There's more info at https://www.reddit.com/r/programming/comments/1r0lx9g/fluori...


Qt Quick 3D in Qt is I guess a similar value prop.

They have a fun demo of a 3D shooter in it.


OK, I didn't know about this. This is cool.


> National pride and competing banking interests repeatedly sabotaged attempts at unification.

That's exactly the problem. Several actors have won the market of their country, but only of their country.

Will Trump be enough to make the europeans realize that they need to work together, and that an italian win is just as good as a german win?


But more importantly, that walled gardens should be abolished and portability and compatibility of user accounts should be enshrined into law and protected at all costs.


That's a great point. With more open systems there can be multiple winners, instead of a single winner that takes all.


> and that an italian win is just as good as a german win?

For someone from france, sure.

For both italians and germans, it matters who wins (and i'm not making a pun here).


>and that an italian win is just as good as a german win

I agree with you

However that specific example somehow feels off and déjà vu


If somebody wants to hurt you while you are traveling in a car, there are simpler ways.


Another reason he wants fewer people buying AI chips is that less demands leads to smaller price, which would reduce the capex of his company.


They thought that the word "server" was not overloaded enough.


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

Search: