jwoglom

I love that the black trash cans say "Microsoft" on them, for some reason.

This has actually already been done! It just needs some love: https://github.com/classilla/kopenray

I never had much more than a passing familiarity with Solaris, so setting up SunRay's with OpenIndiana isn't something I've ever tried -- but the SunRay Server software actually supported Debian Linux! It is, obviously, similarly broken in the modern era, but I imagine it's possible to get working... some of the required files are at https://github.com/jwoglom/srs

This apparently works on Pro versions of Windows, but not the Home versions which don't support domain-join.

We’re removing the bypassnro.cmd script from the build to enhance security and user experience of Windows 11. This change ensures that all users exit setup with internet connectivity and a Microsoft Account.

"enhancing security and user experience" -- what a ridiculous, bold-faced lie. Bravo Microsoft.

This is an incredibly inflammatory and culture war-charged take. Even if you think the people working at this government agency were politically driven, there is public evidence to support that they did good work and were helping modernize government IT in a very cost-effective manner.

Stelo is essentially a binned, feature-restricted version of the G7 that’s available OTC without a prescription. If you qualify for getting a G7, need readings more frequently than every 15 minutes, or have any need for high/low glucose alerts, then you shouldn’t consider Stelo at all, IMO —- it’s strictly an inferior version of the G7.

I think this might be the video you're talking about, in case anyone is also interested in a brief history of quick boot operating systems and UEFI: https://www.youtube.com/watch?v=ssob-7sGVWs

There is an entire open-source ecosystem around having direct access to your diabetes data, which predates the commercial availability of things like sharing glucose data live with others. The Nightscout Foundation (https://en.wikipedia.org/wiki/Nightscout) and Tidepool (https://www.tidepool.org/about) are two nonprofit organizations who lead development on open-source products (Nightscout and Tidepool, respectively) which help with this.

While the manufacturer-provided ecosystems function okay, they give you limited data mobility in case you switched to a different diabetes-related product like a CGM or insulin pump. They also introduce a dependency on on a cloud SaaS platform managed by said manufacturer, which can impose limitations, such as not allowing for real-time access to your data (Dexcom requires an approval process to get real-time data from their API: https://www.dexcom.com/webapi) and can have uncertain reliability (Dexcom had a notable outage in 2019, for instance: https://www.wsj.com/articles/diabetes-blood-sugar-data-outag...).

Conversely, you can run a Nightscout server on a Raspberry Pi in your home, or on a cloud server, for yourself and have full access to your data.

Are you familiar with Loop? I believe they are currently just intercepting the Dexcom notifications rather than connecting directly over BLE by default for the G6/G7. However the xDrip + xDrip4iOS projects have gotten the G5/G6 BLE protocol to a state of being fairly well understood.

Loop, an artificial pancreas system for diabetics, has a long history in terms of its development, but for a brief summary which might be of interest to the HN audience: It began as a home-brew system, built by diabetics who reverse-engineered insulin pump firmware and control software in order to gain control of the devices which keep them alive. If you've heard of OpenAPS or the Nightscout projects, this was born out of the same community. Insulin pumps, until several years ago, could only be configured statically to adjust the insulin dosing amount which keeps a patient's blood sugar values in range. But when paired with a continuous glucose monitor, a "closed-loop" system can be created to attempt to keep sugars in range algorithmically. A group of engineers launched Tidepool, a non-profit, in an attempt to get full regulatory approval for the software which thousands were running on their devices to expand it to a wider audience, and along they way they have been able to get buy-in from insulin pump manufacturers to develop an open and interoperable ecosystem. Now, 4 or so years later, the system has received FDA clearance -- the first of its kind, not created by one specific insulin pump manufacturer or corporation but instead by a group of developers with backing from this non-profit.

Full press release: https://www.businesswire.com/news/home/20230124006085/en/Tid...

Like some other commenters mentioned, this is a cool idea, however by storing JSON data inside base64, the length of the URL blows up very quickly as you start storing more state.

While technically URLs have no formal length limit, various sources suggest that URLs with more than around 2,048 characters start causing issues in browsers, and around 8,196 start causing issues in CDNs (https://stackoverflow.com/a/417184). You can work around this partially by not storing this state information in the query string (path/to?<state>) and instead using a hash string (path/to#<state>), and then extract that data in JavaScript such that it's not sent to the server at all.

IMO, the canonical way to solve this problem is using protocol buffers, which you can then serialize into a much smaller number of bytes, which is then base64 encoded. For example, as mentioned in another comment in this thread (https://news.ycombinator.com/item?id=34314578), Yahoo Finance has a 1,616 character-long URL with 1,572 characters of base64-encoded JSON state:

{"interval":"week","periodicity":1,"timeUnit":null,"candleWidth":4.3486590038314175,"flipped":false,"volumeUnderlay":true,"adj":true,"crosshair":true,"chartType":"line","extended":false,"marketSessions":{},"aggregationType":"ohlc","chartScale":"linear","studies":{" vol undr ":{"type":"vol undr","inputs":{"id":" vol undr ","display":" vol undr "},"outputs":{"Up Volume":"#00b061","Down Volume":"#ff333a"},"panel":"chart","parameters":{"widthFactor":0.45,"chartName":"chart"}}},"panels":{"chart":{"percent":1,"display":"F","chartName":"chart","index":0,"yAxis":{"name":"chart","position":null},"yaxisLHS":[],"yaxisRHS":["chart"," vol undr "]}},"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}},"lineWidth":2,"stripedBackground":true,"events":true,"color":"#0081f2","stripedBackgroud":true,"eventMap":{"corporate":{"divs":true,"splits":true},"sigDev":{}},"customRange":null,"symbols":[{"symbol":"F","symbolObject":{"symbol":"F","quoteType":"EQUITY","exchangeTimeZone":"America/New_York"},"periodicity":1,"interval":"week","timeUnit":null,"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}}}]}

The un-base64'd JSON dictionary is 1,162 characters long, 569 of which is composed of just the key names (48 percent!), and most of the remaining fields likely contain their default value. If this was instead encoded in protobuf, the key names wouldn't need to be included, since fields are referenced by their field ID, and default field values would take up little-to-no space since when the default value is present it isn't encoded into the structure. I presume that, if done efficiently, you could likely make an equivalent representation in protobuf that is 1/4th or even 1/8th the size. You also get, for better or for worse, what is essentially obfuscation for free (yes, you can read out the packed format, but without an equivalent protobuf struct definition it's still hard to tell what field is which, and the entire operation becomes much more labor-intensive).

Take a look at https://github.com/jwoglom/pumpx2, I’m working with the AndroidAPS folks currently to make it more broadly available. xDrip integration would happen via AAPS.

While I’m not a certified security professional, I have looked pretty closely at Tandem’s mobile pairing and remote bolus implementation and it seems to have been designed in the right way. After initializing a Bluetooth connection, the phone and pump complete a handshake wherein a 16 character alphanumeric key appears on the pump screen and you need to enter it on your phone, which then uses it as a shared HMAC symmetric key. Status information and responses then occur in cleartext once authenticated, while bolus operations require messages to be signed with the initial key.

That being said, on the chance that there is a security flaw here I’m willing to eat my words…

I mean, companies like Twitter have already been bitten (and fined!) for using phone numbers collected for 2FA purposes for advertising and monitoring purposes, which is more or less exactly your concern: https://arstechnica.com/tech-policy/2022/05/twitter-pays-150...

Yes -- this is a follow-up investigation into how that bug might have occurred by looking at recent commits to AOSP.

Definitely seems a bit disappointing that 5-6 years after the original Pi Zero there's still only 512MB of RAM. Regardless, I'm excited to see what new projects will become feasible with the extra CPU performance.

I just finished watching your YouTube video, so thanks for providing all of this insight. A new Pi Zero will certainly make small handheld emulators a lot more promising...

I would argue that the most recent principal has likely done far more destruction than the Lodal -> Glazer transition did, but I have heard that sentiment before from older alumni. (I was a student near the end of Glazer's tenure.)

As to the latter point, the school has definitely been trending in that direction. In my time, I would wager that around 50% of students had primarily a science interest, 35% had primarily a technology interest, and the remaining 15% had no strong inclination between the two. (From what I have heard, in more recent classes the tech has become more popular than the other sciences.)

At the end of the day, though, as long as the curriculum still requires sci-tech rigor, it's entirely beneficial that the school also have strong humanities and arts programs. 13 year olds are applying to this school, and people's interests change throughout high school in unpredictable ways.

That domain's not available, unfortunately. trump.care wasn't available either. I figured Ryancare was the best name to go with -- the bill has already been branded as that name in some circles.

Github: https://github.com/jwoglom/ryancare

It's pretty simple, just a static site. But aren't dumb things like this exactly what the Internet was designed for?