The Y piece (part C in the photos) seems a little silly. Surely there are commercially available hose fittings which would be suitable - possibly even ones which a hospital would have on hand?
> I still don't love how CGI uses environment variables.
Neither do I. They really only make sense in the context of a request which was actually to a CGI script resident in a document root - they're an exceptionally awkward way of describing other HTTP requests, especially ones which aren't being served from a document root. And there's a lot of information lost in translation, like the order and original capitalization of HTTP headers. (Not that these things are supposed to matter, but still.)
The underlying tcmalloc issue is interesting - the library was relying on an implementation detail of the rseq kernel API which was never guaranteed, and which already generated warnings in previous versions.
> $100 for a somewhat specialized, durable medical device...
And one which is treated as a status symbol, at that. Part of the reason a good stethoscope costs more is because it looks nicer, not just because it works better.
It's a demonstration. If a domain name and a quick bit of Wikipedia vandalism is all it takes to make an LLM start spouting nonsense about a "surprisingly serious tournament circuit" or a "massive online community" for an obscure card game, consider what an unscrupulous PR team or a political operative could do to influence its output on more important topics.
Oh boy... it is the other way around. Those "computing environments" are filthy toxic, they should not even exist and they broke what was rather sane. With their "computing environments', you get planned obsolescence (they call that 'innovation', lol), dev and vendor lock-in using non pertinent complexity, etc.
There is nothing more sane than trying to fix that. This is a complex matter, and those guys are pure evil with their 'computing environments", won't going to be easy, I guess you may be one of them, or a one of their brain washed soldiers, or here an AI bot. Because, many fresh and young guys in the field are just getting scre... as f... with their washed super clean brain (in academics, those "teachers" who would not be even there without those toxic 'computing environments', yep, this toxicity is their bread and butter, it is a problem).
A lot of money is being channelled in those scams, I guess this is their primary reason to force them onto people. Once you get a simple, but good enough to the job, and stable in time alternative technical apparatus, toxicity levels go back to something bearable, namely their absurd and grotestely complex for no good reasons "computing environment" is just, gone. That said, it is more about control than money, because "big money" follows "control" almost mechanically.
Those guys look like near real mafias (often with big investment funds behind them, like vanguard and blackrock for instance). I just discovered, that here, they literaly dictate their will to our presidents and prime ministers which they used as carpets (they are getting clean brain washed or maybe they are deep into some '$$$' schemes). The rabbit hole seems to be going reaaaally deep.
So for mistral, where are the public tokens to be used with a properly documented web API? I could generate some tokens, using a mistral account, which I should be able to create with a classic web browser (noscript/basic (x)html), and if required with my self-hosted email server on IPv6 without DNS, namely email addresses with ipv6 literals which are stronger than SPF since you drop all emails which ipv6 addresses from the email addresses of the envelop and/or the header do not match. It could be some documented simple network protocol to interact with their inference service. And we all know, those protocols should be stripped to the simplest as possible, because with an online service most of the work does happen in keeping it safe and available, and their 'computing environment' complexity is making that mechanically a pain, this is common sense.
As I said, if you are one of them, namely not being one of their brain washed soldiers aka one of the evil ones, this is pointless to argument anything.
Snow is great for what it is, but it's limited (for now) to a small set of early Macintosh systems, up through part of the Macintosh II series. Basilisk II and SheepShaver are still the best option available for later Macintosh systems.
That's two of them - there's also a "redundancy coprocessor" which implements security features like stack canaries and flow control assertions. (As well as the standard ARM single-precision FPU.)
Speed certainly certainly isn't an issue for AX.25. The protocol typically runs at <10 kbps; the overhead of processing packets in userspace is negligible.
It most commonly runs at 1200bps, used for APRS these days.
You can do a neat trick with this if you set up IP over AX.25, particularly with softmodems. Since you've got IP you can do SSH or TLS over it, right? At least, if you set all the timeouts really long, because some of those packets take a while at 120 bytes per second.
So then you can tune the tones to be a little off the normal frequencies of one side, and play them through speakers with two PCs connected together. When you ssh from one to the other, you will hear the establishment packets and the flurry of packets for every keypress pingponging backwards and forwards between the two systems.
Absolutely brilliant for demonstrating how things like TCP works with retries (plug a mike into it too, shout some interference) and how UDP doesn't, and stuff.
And then you'd be able to hear the difference in the chat between the two machines! That's an amazing demo :-)
I used to use mosh and tmux over 9600bps AX.25 before I had 3G data, a very long time ago. Strictly speaking SSH over amateur radio breaks the rule about encryption but 144MHz is a big place with no-one in it, and you can't pay Ofcom to take an interest in what people do on amateur radio.
reply