It's the nature of high fashion brands. a $2000 item may cost $200 to create. The high margin is based on exclusitivity. They would rather destroy it than sell it at $300.
> They would rather destroy it than sell it at $300.
This is exactly it. The actual landed cost is 1/10th of the sales price, and most of the rest of the margin pads the marketing and exclusivity machine. If for instance LV starts selling their $200-landed Neverfull bags at $500 or even $1,000, all the infrastructure sustaining the image becomes unsustainable.
Related note: aren't Louis Vuitton bags being made so crap nowadays that even their own anti-counterfeiting staff can't tell what's real and what's not? I remember hearing of someone who made wallets out of discarded LV bags and got harassed for it by the company.
My personal opinion is that the business model of selling status items - specifically those which only have status because of an artificially limited supply they control - is inherently predatory and should be restricted. Not because I'm the morality police and want to stop people from buying a bag that says "I spent $2000 on a bag", but because there is nothing that stops the company from cost-reducing that to oblivion. If you are going to sell a $2,000 bag, it should be marketed on quality, not a cult.
Agents are excellent for reverse engineering. I was also recently working on a BLE reverse engineering exercise and followed a similar path. I ran into lots of headaches with BLE on my Mac and tabled it.
Author or others who know, did you perform this on Linux? I imagine it lacks the tooling challenges I had with BLE on MacOS.
What sort of tools did it use? I suppose the path mine took may have been a dead end. The Tuya app (I was also using decompiled APK) downloads the BLE definitions on-demand and weren't embedded in the app. It wanted me to capture traffic on a device with the app. I punted but plan to resume with an emulator setup or real device connected with adb.
Quite a few things use STARTTLS. I imagine the same technique could be applied to those other protocols, giving users some options as they fight hostile networks.
Just curious - how much of this was AI generated? The readme has crazy emojis & the code was all checked in at once, which is usually my telltale for these kinds of things. Didn't see anything crazy in the source files.
I think its polite to indicate AI agent usage in security related projects like this since they can have huge holes if they're just being vibe coded.
-- Edit: Intended to post this on the board root, sorry.
High emoji use is something I've noticed a certain generation/subgroup of developers just default to. Keeps things informal/quirky. The AI had to steal that style from someone, after all. This repo is actually very low on the emoji side.
Looking through the code itself, I can't tell if it's AI generated or not, but I wouldn't assume the use of emoji automatically mean AI wrote the text.
It's a fair question but I had a bit of a chuckle at the idea having a shit ton of emojis in your GitHub readme was the first flag it might be AI. Mostly because I always assumed the opposite - that GitHub readmes were a big part of the emoji ridden listicle training data (the other being slop "news" site/social media listicles) for AIs in the first place. After all, they are decently well written and come with grabbing the code to train from anyways.
Before the rise of AI, I had not seen much GitHub content with emojis at all, much less overused; I suspect their source is actually the latter of what you noted. Either way, it's a negative signal.
I'm surprised there's no mention yet of carrier activation fees. Isn't that half the point for carrier's? They can bilk you for another $36 for the privilege of issuing a new eSim for your new phone.
My favorite and most painful issue was a bug in USB charging. Sometimes it would fail to charge from my monitor (USB-C) yet it would believe it’s connected. The battery would eventually run to zero and the machine would shutoff without warning. No low battery warning would be shown because it believed it was charging however it was not. Resolved with my M3.
Also fun with that generation is that you can’t plug in a dead laptop and start using it right away. Takes about ten minutes of charging before you can power it on.
Also fun, it would not establish power delivery with my monitor in this state. I’d have to plug it in with a regular charger to bootstrap it. Also resolved with my M3.
Now that it’s aged, the super capacitor for the clock no longer holds charge and the time is usually wrong on cold boot. I wish that was serviceable.
I'll make up another one to pile on. Perhaps the police would have had a visible, deterrent presence if they weren't lazily relying on cameras, and that would have prevented the assault in the first place.
Anyhow, if you read the flock database, they're overwhelmingly not using them for the purposes of public safety or random crime.
It's even worse when you start finding you're staffing specialized skills. You have the Postgres person, and they're not quite busy enough, but nobody else wants to do what they do. But then you have an issue while they're on vacation, and that's a problem. Now I have a critical service but with a bus factor problem. So now I staff two people who are now not very busy at all. One is a bit ambitious and is tired of being bored. So he's decided we need to implement something new in our Postgres to solve a problem we don't really have. Uh oh, it doesn't work so well, the two spend the next six months trying to work out the kinks with mixed success.
This would be a strange scenario because why would you keep these people employed? If someone doesn't want to do the job required, including servicing Postgres, then they wouldn't be with me any longer, I'll find someone who does.
No doubt. Reading this thread leads me to believe that almost no one wants to take responsibility for anything anymore, even hiring the right people. Why even hire someone who isn't going to take responsibility for their work and be part of a team? If an org is worried about the "bus factor" they are probably not hiring the right people and/or the org management has poor team building skills.
Exactly, I just don't understand the grandparent's point, why have a "Postgres person" at all? I hire an engineer who should be able to do it all, no wonder there's been a proliferation of full stack engineers over specialized ones.
And especially having worked in startups, I was expected to do many different things, from fixing infrastructure code one day to writing frontend code the next. If you're in a bigger company, maybe it's understandable to be specialized, but especially if you're at a company with only a few people, you must be willing to do the job, whatever it is.
Because working now at what used to be startup size, not having X Person leads to really bad technical debt problems as that person Handling X was not really skilled enough to be doing so but it was illusion of success. Those technical debt problems are causing us massive issues now and costing the business real money.
reply