kion (u/kion) - Readit News

kion commented on Ozempic shows anti-aging effects in trial trial.medpath.com/news/5c... · Posted by u/amichail

smiley1437 · 21 days ago

Tirzepatide (and likely other GLPs) have limitations that are rarely brought up in the general media

- Patients have about 72 weeks to reach maximum loss, they don't lose any more weight after 72 weeks even on the highest dose.

- Patients appear to immediately gain the weight back as soon as they stop taking it.

It's right in the phase 3 trial outcomes paper:

https://pmc.ncbi.nlm.nih.gov/articles/PMC10667099/

I suspect that this info is intentionally down-played so that it doesn't affect sales.

kion · 21 days ago

I've been on Zepbound for ~25 weeks now and one of the first things my doctor told me was that this was a lifetime drug. He pointed out that I had a choice, of lifetime drugs. I needed to do something to get my cholesterol under control. That meant start statins now and likely add blood pressure meds and diabetes meds in the next 2-5 years. Alternatively I could start Zepbound, which would likely address all 3 and result in better quality of life in the next year. So far it seems like it is doing exactly that.

I'm sure some people are going into this without that knowledge, but people are being told this is a lifetime commitment. What you don't see a lot of is why people stop taking it. There's some cases of people losing and then stopping, but the majority are because insurance is forcing people off of it. Just look at the recent CVS Caremark forced switch from Zepbound (2nd Gen) to Wegovy (1st Gen) in July.

kion commented on Rust’s dependencies are starting to worry me vincents.dev/blog/rust-de... · Posted by u/chaosprint

bilbo-b-baggins · 4 months ago

Symbol culling and dead code removal is already a thing in modern compilers and linkers, and rust can do it too: https://github.com/johnthagen/min-sized-rust

kion · 4 months ago

Others have made similar comments, but tree-shaking, symbol culling and anything else that removes dead code after its already been distributed and/or compiled is too late IMO. It's a band-aid on the problem. A useful and pragmatic band-aid today for sure, but it fundamentally bothers me that we have to spend time compiling code and then spend more time to analyze and rip it back out.

Part of the issue I have with the dependency bloat is how much effort we currently go through to download, distribute, compile, lint, typecheck, whatever 1000s of lines of code we don't want or need. I want software that allows me to build exactly as much as I need and never have to touch the things I don't want.

kion commented on Rust’s dependencies are starting to worry me vincents.dev/blog/rust-de... · Posted by u/chaosprint

throwaway462663 · 4 months ago

> It's a terrible idea...

It's a terrible idea because you're trying to reinvent section splitting + `--gc-sections` at link time, which rust (which the article is about) already does by default.

kion · 4 months ago

The article is about Rust, but I was commenting on dependencies in general.

Things like --gc-sections feels like a band-aid, a very practical and useful band-aid, but a band-aid none the less. You're building a bunch of things you don't need, then selectively throwing away parts (or selectively keeping parts).

IMO it all boils down to the granularity. The granularity of text source files, the granularity of units of distribution for libraries. It all contributes to a problem of large unwieldy dependency growth.

I don't have any great solutions here, its just observations of the general problem from the horrifying things that happen when dependencies grow uncontrolled.

kion commented on Rust’s dependencies are starting to worry me vincents.dev/blog/rust-de... · Posted by u/chaosprint

dcow · 4 months ago

Further: I’ve never seen rust encourage anything of the sort. Module directory with a mod.rs and any number of files works just fine.

kion · 4 months ago

I probably mischaracterized this as its been a while since I did more than trivial Rust. AFAIK its not possible to depend on only a part of a module in Rust though right? (At least without an external build system)

For example, you can't split up a module into foo.rs containing `Foo` and bar.rs containing `Bar`, both in module 'mymod' in such a way that you can `use mymod::Bar and foo.rs is never built/linked.

My point is the granularity of the package/mod encourages course-grained deps, which I argue is a problem.

kion commented on Rust’s dependencies are starting to worry me vincents.dev/blog/rust-de... · Posted by u/chaosprint

nicoburns · 4 months ago

As far as I'm aware, LTO completely solves this from a binary size perspective. It will optimise out anything unused. You can still get hit from a build time perspective though.

kion · 4 months ago

LTO only gets you so far, but IMO its more kicking the can down the road.

The analogy I use is cooking a huge dinner, then throwing out everything but the one side dish you wanted. If you want just the side-dish you should be able to cook just the side-dish.

kion commented on Rust’s dependencies are starting to worry me vincents.dev/blog/rust-de... · Posted by u/chaosprint

kion · 4 months ago

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos.

This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painstakingly included parts of into your size constrained environment (fit it on a floppy). You probably picked apart that library and pulled the bits you needed, integrating them into your builds to be as small as possible.

Today we pile libraries on top of libraries on top of libraries. Its super easy to say `import foolib`, then call `foolib.do_thing()` and just start running. Who knows or cares what all 'foolib' contains.

At each level a caller might need 5% of the functionality of any given dependency. The deeper the dependency tree gets the more waste piles on. Eventually you end up in a world where your simple binary is 500 MiB of code you never actually call, but all you did was take that one dependency to format a number.

In some cases the languages make this worse. Go and Rust, for example, encourage everything for a single package/mod to go in the same file. Adding optional functionality can get ugly when it would require creating new modules, but if you only want to use a tiny part of the module, what do you do?

The only real solution I can think of to deal with this long term is ultra-fine-grained symbols and dependencies. Every function, type, and other top-level language construct needs to declare the set of things it needs to run (other functions, symbols, types, etc). When you depend on that one symbol it can construct, on demand, the exact graph of symbols it needs and dump the rest for any given library. You end up with the minimal set of code for the functionality you need.

Its a terrible idea and I'd hate it, but how else do you address the current setup of effectively building the whole universe of code branching from your dependencies and then dragging it around like a boat anchor of dead code.

kion commented on New Study: Waymo is reducing serious crashes and making streets safer waymo.com/blog/2025/05/wa... · Posted by u/prossercj

johnfn · 4 months ago

As someone who is often on SF city streets without a car - I bike and run a lot - I absolutely love Waymo. I am continuously seeing human drivers cut me off, perform illegal maneuvers (i.e. run red lights when I'm going through a crosswalk), and break various other traffic laws. All these things genuinely put people in danger. Just the other day, a guy started running a "no right turn on red" lane in SF, and when I pointed it out to him he floored his car - through the red - right in front of me and laughed at me as he sped away. To say nothing of all the times when cars will honk or give me the finger for doing normal things on a street, like walking on a crosswalk.

Waymo is like the most courteous, respectful driver you can possibly imagine. They have infinite patience and will always take the option which is the safest for everyone. One thing which really impressed me is how patient they are at crosswalks. When I'm jogging, a Waymo will happily wait for me to cross - even when I'm 10 feet away from even entering the crosswalk! I don't know if I even have that much patience while driving! I've had a number of near misses with human drivers who don't bother checking or accelerate for no reason after I'm already in the crosswalk. Can you imagine a Waymo ever doing that?

If I see a Waymo on the street near me I immediately feel safer because I know it is not about to commit some unhinged behavior. I cannot say enough good things about them.

kion · 4 months ago

The thing I dislike about Waymo is other drivers.

I've now had it happen twice that a car will fully blow through an intersection because they know a Waymo will slam on the breaks to avoid a collision. They basically abuse the car's reflexes.

Also in any sort of situation where the Waymo is being very cautious the biggest danger is the impatient people behind the Waymo who will break the law to go out and around it.

kion commented on SFMTA's train system running on floppy disks; city fears 'catastrophic failure' abc7news.com/san-francisc... · Posted by u/sidlls

markus_zhang · a year ago

I'd like to see a breakdown of that "hundreds of millions of dollars" and which companies provided the quotes, plus who owns the companies and who are their husbands/wives/uncles/nephews/nieces/etc.

kion · a year ago

I looked into this last year, a significant part of the cost is in new hardware, both on the vehicles, but also sensors spread through the system. They all need commercial grade RF systems that allow for 2 way signaling communication and integration into the vehicles control systems.

kion commented on California State University system sees unprecedented decline in enrollment msn.com/en-us/money/caree... · Posted by u/lxm

throwup238 · a year ago

CSU is the cheaper state university system in California. It costs like $6,000 per year for in-state students. If they were waking up to the con game, more would be going there.

kion · a year ago

Tuition and non-tuition costs have both absolutely skyrocketed and made CSUs unaffordable for a lot of people. I went to Cal Poly, my entire freshman year was ~$6000 in 1997. It was an even split between $3k tuition and 3k student housing/food. I could actually mostly pay my own tuition without finical aid, holding a part time campus job.

Today those numbers are $11.5k tuition and ~21.5k non-tuition (https://www.calpoly.edu/financial-aid/costs-and-affordabilit...) which is triple the inflation adjusted value from 1997. After 4 years (5 more likely) you're looking at > $125k in costs, which absolutely puts most people into massive loan debt. Even a part time job ($16/h) would offset barely a third of this.

CSU is just beyond expensive compared to 20 years ago.

kion commented on Starting in August, Google will require that they sign apps, not you twitter.com/dbrgn/status/... · Posted by u/mritzmann

GauntletWizard · 4 years ago

This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work.

There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped.

But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys).

I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.

kion · 4 years ago

> "too cumbersome" and require re-uploading the same app package repeatedly, but it would work.

This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device.

When specifically targeting a single device you have multiple axes to target:

* 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a]

* resource DPIs: [ldpi, mdpi, hdpi, xhdpi, xxhdpi]

* 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years).

* 80+ individual languages

If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs.

Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.