“Good portion of the world” is probably a handful of people.
Her full quote btw:
“Once upon a time, I was the centerfold of Playboy,” says the former model in the new documentary Losing Lena. “But I retired from modeling a long time ago. It’s time I retired from tech, too.”
Well, for instance, it's the official policy of the IEEE to not allow this image in new publications. And they're far from the only journal (or set of journals) that have this policy.
Given that it's use is banned in most academic journals dealing with imaging/graphics, you'd be wrong.
And as several journals have brought up in the banning, it's not even good at what it purports to be for these use cases. It's a pretty poor quality image to start off with due to being scanned to a digital file with 1970s technology.
At this point the ones defending its continued use are the vocal minority on some weird anti-woke crusade that doesn't even make sense on technical grounds.
You’re using vocal minority framing right now. When I care about it, I’m a weird crusader for caring and noticing. But then you organize a campaign to change it.
There is a large body of literature using these images so it’s helpful to have a comparison which is persistent through time and familiar.
> Given that it's use is banned in most academic journals dealing with imaging/graphics, you'd be wrong.
I found a contradicting statement where she said that she doesn't mind her picture being used in tech. Maybe even in the wikipedia article you got this quote from. I don't have the time to find it right now but here for example she says she's proud of the picture: https://archive.is/fIRoG
"Lena doesn’t harbor any resentment toward Sawchuk and his imitators for how they appropriated her image; the only note of regret she expressed was that she wasn’t better compensated. In her view, the photograph is an immense accomplishment that just happened to take on a life of its own. “I’m really proud of that picture,” she said."
No I think the social context is inappropriate. However I do not think possessing or liking such a picture is perverted. I also do not thinking a cropped version of the picture which has no sexual content is inappropriate.
This article isn't about languages. It's about the protocol for two or more languages to talk to each other. There is no specification for this.
The System V ABI is as close as we get to an actual specification but not everyone uses it and in any case it only covers a small part of the protocol.
HA is not about exceeding the limits of a server. Its about still serving traffic when that best server I bought goes offline (or has failed memory chip, or a disk or... ).
Postgres replication, even in synchronous mode, does not maintain its consistency guarantees during network partitions. It's not a CP system - I don't think it would actually pass a Jepsen test suite in a multi-node setup[1]. No amount of tooling can fix this without a consensus mechanism for transactions.
Same with MySQL and many other "traditional" databases. It tends to work out because these failures are rare and you can get pretty close with external leader election and fencing, but Postgres is NOT easy (likely impossible) to operate as a CP system according to the CAP theorem.
There are various attempts at fixing this (Yugabyte, Neon, Cockroach, TiDB, ...) which all come with various downsides.
All parts seem true to me. Most kids think they were more gifted than they were. Learning to work hard and be persistent was actually more important. A lot of talk about being gifted was an obstacle to that.
People were literally buying horse dewormer when their doctors wouldn't prescribe it for them. "Influencers" were selling it. So the media were being accurate. To the extent that this made people look dumb, the intent was mostly to shame them into trying something more effective.
You dropped my words "into trying something more effective". Steering people into treatments found to be more effective is, precisely, giving people the best available information. Ivermectin is great if you have a parasitic infection. It doesn't help against viral infections.
I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.
There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."
What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.
If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.
And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.
Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.
Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.
A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.
Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.
I agree. Just because you can buy some piece of software doesn't mean you should -- there is a lot of software that exists just to sell more consulting hours and will never fit the business. It's actually not hard at all to code and maintain much simpler alternatives.
Actually having to support multiple businesses with commercial software is hard. I've written a ton of custom software that far surpasses the capabilities of commercial offerings but if were to turn that into it's own commercial offering it would be large undertaking.
1. No. The point of having engineers is to build product and make you money. They cannot make you money if you waste their time on building internal apps that do not make you money.
There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue. We get paid the big bucks because we can make companies a lot of money.
2. Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
If you write the tool, all of that is on you to do. If it goes down, you have to fix it. If it screwed up data, you have to fix it. Any time anyone has any questions? Guess what, you're the one they'll ask. All of that costs the company money, because you don't work for free. When you quit, the app is now useless and can't be fixed unless you did a lot of work beforehand.
It's best to think of DIY apps like those really really sticky noxious tarpits. It might look safe or easy to get into, but good luck getting out of them. You might end up at the bottom with the bones of everyone else who thought that DIYing it was a good idea.
> The point of having engineers is to build product and make you money.
You're making the assumption that all software development is for software products. My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
> There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue.
If the SaaS app is $20K, I would agree. Probably the cheapest we have is $30K per year, most are an order of magnitude more than that. And it doesn't take a $100K of developer time to replace some of them.
> Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
Haaaa no, that's 100% not how that works. You buy a SaaS product then you pay them to install, configure, customize it. That can a small amount or a large amount. That can take a small amount of time or years. You can maybe hire people who have worked on that system, but probably not, and it's mostly bespoke knowledge that only a small amount of people have. They aren't cheap. But you might be entirely dependent on the vendor.
If it goes down, you have to put in a support ticket. You wait. Everyone is still on your case but you can't do anything about that. If you have access, sometimes you can fix it yourself -- and you do -- because waiting for support to do it properly is awful. If it's screwed data, good luck, they're not good at fixing that. Anytime anyone has any questions? Another support ticket. None of these people work for free; expensive support contracts. The level of support you get is completely divorced from that cost. You can't pay less if the support is terrible, you can't pay more to get better support (not that you would want to).
If I write the tool and it goes down, I can fix it. Awesome. If it screwed up the data, I'm more than capable of fixing that. If anyone has any questions, guess what, I actually know the answers. The company pays me for these services. When I quit, the app can be easily fixed because it's all standard technologies that lots of people know. Those SaaS tools? They're the black box that nobody knows how to configure, customize, or fix. The vendor isn't interested in doing anything more than the minimum needed to close the ticket.
> It might look safe or easy to get into, but good luck getting out of them.
Just try and switch away from your cloud SaaS product. You might not even be able to get your data out.
> You buy a SaaS product then you pay them to install, configure, customize it.
Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
The entire point of SaaS is you don't install it on prem. SaaS directly competes with what you're talking about.
Before you go declaring an industry is dead, at least understand what it is.
> My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
Sure. The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
Replacing some tinkertoy nobody relies on is easy. If your app is in the hot path, congrats, you're now critical infrastructure lol. This is the Bad Place.
> When I quit, the app can be easily fixed because it's all standard technologies that lots of people know.
I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue. It's figuring out all the random decisions and details and load-bearing parts and reverse engineering someone's weird tooling without breaking things. It sucks real bad because you don't know what you don't know.
> Just try and switch away from your cloud SaaS product. You might not even be able to get your data out
Sure you can. Getting the data is the easy part. In the very worst case, you might have to pay them or get someone in management to scream at them, but it's the easiest part of that kind of project.
It's the rest of that kind of project that's tricky. Replacing a critical live system without downtime is Srs Bizness.
> Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
I didn't mean to imply on-prem. "Install" was the wrong word; call that "onboarding" instead. There is always some integration component as well because nothing lives entirely on it's own. Some SaaS providers are really good; no complaints on this part. Some are terrible. I believe one new vendor is going to try and charge us almost $100,000 to integrate their product with our other products. The entire purpose of this product is the integration. This is one I'm pushing to do internally because it's so fiddly.
> The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
So? You seem to think SaaS software doesn't go down, break it weird ways, get slow for no reason, etc. Across everything we probably had half a dozen small outages last month. But none of our internal (also cloud) products went down at all. Hell, one of the biggest most common SaaS products in our industry released an undocumented change last month to their API that subtly returned incorrect results. As far as I can tell, they still haven't acknowledged it.
I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better.
> I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue.
Good developers produce good results. I have a new intern on my team who's currently still in school and she's absolutely killing it working on our apps. So maybe the problem isn't internal development, it's just shitty developers. Those exist in SaaS products as well; I look at some of their shit and I wonder what we are paying for. It can be well hidden behind nice marketing and big brands but it's still crap.
One vendor tried to sell us a product that was actually sneakily split into two pieces -- one developed in North American in .NET and the other half in India in PHP! They nightly sync the data between them. At the time, we had multiple products for this job and we were looking for one integrated product to replace them. I just happened to notice when looking at the URLs during the sale pitch and that's what caused them to spill the beans. We didn't buy that product.
While a lot of our internal development is complete products, a good chunk is actually filling out the functionality holes or working around bugs in our SaaS products.
> Sure you can. Getting the data is the easy part.
The last one we dropped, we definitely didn't get our data out. In fact, as soon as we cancelled the contract (3 month lead time) we were basically dead to them.
> I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better
If you staff an entire team to build apps, update, maintain and deploy changes to them, and run a call rotation, and that's all you do, there's no problem. You just have an internal development team. That's completely fine.
What's not fine is the people going "how hard could it be to replace Y" and slapping something together. Those sort of skunkworks projects have a couple common common failure modes:
1. the project fails after a lot of wasted effort
2. the project succeeds...but is never productionized. The person who wrote it is now stuck writing it forever. Which they might like, but it's miserable if they quit or retired or get hit by a bus aka the bus factor.
If the bus factor is one, that is pretty much always pain.
The point of SaaS and service-contract type enterprise software is not that they are perfect and great and not buggy. Enterprise software sucks a lot. SaaS is usually "you get what you get".
The point is you can't halfass it. Either you go whole ass and staff out a big enough development team (with all the expense and difficulties implied) or you go none ass and buy.
Startups have no users and no data to start with, and if they fuck up security, well, they just fail sooner than expected.
Once you get past a certain size, you have very different sorts of problems. Any idiot can vibe code a facebook lookalike, but the real one has to handle hundreds of millions of users and posts while being a target for state actors.
Her full quote btw:
“Once upon a time, I was the centerfold of Playboy,” says the former model in the new documentary Losing Lena. “But I retired from modeling a long time ago. It’s time I retired from tech, too.”
reply