kion

I'm not a biochemist, so I can't say with any authority, but presumably its to do with the 3rd antagonist and its impact on glucagon. Most of what I have heard is through Reddit communities for the on-market drugs (1st and 2nd gen peptides). The anecdotes from Retatrutide sound like it has way less impact on appetite and for some people that's actually a downside even though the weight loss effects appears to be significantly more powerful.

retaglutide is the next gen (3rd) GLP-1 which is in phase 3 trials now. It is a triple antagonist (current are dual GLP-1/GIP). It adds glucagon, and apparently that comes with not only greatly increased weightloss, but also wicked sugar cravings.

These things do way way more than just appetite and craving suppression.

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.

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.

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.

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.

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.

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.

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.

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.

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.

> "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.

> If you don’t have a problem with user quality then sure, avoid the verification step. But if you have a good reason for the verification step then don’t sweat the drop-off rates.

If you have any contact method for the user (email, SMS, phone) you should be doing some level of verification on it. Users are clumsy, some of them don't know or mistype their own email addresses, phone numbers, etc. Verification ensures you're talking to the person you expect to be talking to.

> Only 38% of people did this. If I had instead captured everyone as soon as they showed enough interest to leave an email address, I could’ve increased my conversion rate by 250%.

How many of these were real losses and how many were people who put the wrong email address in the box, only to realize when they didn't get the verification email?

I have a very early gmail address, first initial + last, name. I can't tell you how many verification emails I get that I never signed up for. Those aren't the bad ones though, the bad ones are when I get emails about Kay's upcoming surgery and follow-up appointments, Kim's yarn orders and Ken's mortgage documents. (All of these are real examples).

Strong email verification flows aren't just anti-bot. They're a level of defense against clumsy users.

This appears to have been fixed since the posting. Links in the search results work again in lynx.

Not if you include CA state taxes and property taxes. You can pretty easily hit 50% somewhere north of 250k, which for a 2 income household in the bay isn't outlandish.

So don't look at it as percentages. Look at it as a question of how comfortable is your situation. I'm in roughly the same position as you tax wise. We pay slightly less, about 48%, to taxes of one form or another. However we're comfortable. Minus the mortgage we're debt free, our lifestyle isn't extravagant but we rarely can't do or have the things we want due to money. Solidly upper-middle-class (for SF).

I'm perfectly happy to pay more than most to support others, because I make more than most in income. I can't honestly say that in my day-to-day life I work harder than the person delivering the mail, or someone unloading crates. I was given the advantage of good and cheap education and a safe environment to grow up in (Marin) due in part to high taxes on the wealthy. I feel it's important to do what I can to return the favor.

I also strongly believe that those above a certain threshold of wealth, especially those who hoard that wealth, are doing damage to the economy through income inequality. If taxes are the means to undo some of that damage then again, I'm happy to contribute.

Chrome on iOS has some input handling issues inside the iframe.

To answer the 2nd part of the question:

vmnix was the name of the Linux kernel module that was loaded during the Service Console's boot process.

The terms "Service Console", "Console OS (COS)" were at times used interchangeably and referred to the Redhat distro you logged into at the terminal.

VSphere 4.0 had 2 versions: ESX (with COS) and ESXi (without COS). In 5.0 the COS was removed entirely.

Nope, that stuff is all gone with the ESXi product. The vmkernel can bootstrap itself now.

Basically the old 1.0 - 4.0 process for _ESX_ was like this:

* Bootloader

* Linux Kernel boot

* Load VMnix module.

* Load VMkernel

* hardware control passed to VMkernel

* Linux continues running as a sort of 'super' VM with some limited hardware access.

For _ESXi_ from 4.0 - now :

* Bootloader

* VMkernel

vmnix aka Service Console aka Console OS aka the Fuzzy part, was part of ESX, which was discontinued with the 5.0 series of ESX products.

This is the sort of thing I hope to see a lot more of from Rust. Things that would traditionally be done in C/C++ moving to a new language with modern features. I'm very hopeful this trend will continue.