Yeah I don't even agree with the conceit that public investment is causing companies to make bad games. You don't make 'good returns' as a video game company with bad video games, I don't care how fancy your financial engineering is. And private investors care about returns just as much as public investors do.
If anything a lot of this is on gamers for continuing to buy shitty games that they complained even at the time were shitty games.
If they'd stopped buying games the lousy companies would have folded, their investors would have eaten a loss, and the game companies that remained would care more about the investors who'd shown more of a long-term focus.
In this particular case, injecting content into the image to make someone read a false message doesn't seem possible. The pixel <img> tag has width and height set to one. This overrides whatever the image size is. No altered message will be readable.
This is true up until the point that someone finds a security issue with an image parser that’s present in a browser engine, and suddenly you have an RCE.
If you have access to an exploit and want to compromise someone with an image, you'd usually just send it to them directly via e-mail or SMS or AirDrop or whatever, or all of the above. And it'll even work if your image is linked in an email via HTTPS.
Trying to MITM an existing tracker pixel when they're connected to public WiFi sounds like practically the hardest way to do it.
The harder it is to do, the more the targets guard will be down
In this case, sending your malicious image through a fake email might get flagged, or even not opened by someone whos been trained in infosec enough to be suspicious of these things. But a tracking pixel in an email that is verifiably from a trusted entity will be opened no problem. Type of thing that will look pretty slick if you read about it being used
It's incredibly easy to get people to open emails. This isn't asking them to download an attached .zip or .exe file or follow a suspicious link, which is what people are trained against. This is just an embedded image.
No, I don't think so, not unless there's some feature of Haskell type classes I'm completely unaware of.
If anything it's closer to SFINAE in C++ where it tries to implement methods but then doesn't consider it an error if it fails. Then infers type-classes based on the outcome of the SFINAE process. Or the macro analogy another poster made isn't bad (with the caveat that it's a type system aware macro - which at least in rust is strange).
I am not sure how Haskell works but I think what the previous poster meant is that the types get determined at compile time. Closures are akin to macros except you can't see the expanded code.
Users matter a ton to windows. Specifically, the users with a hundred thousand or more licenses. Their unhappiness threatens Windows' profits in a meaningful way. Why do you think all the new secure boot and TPM features were added to Windows 11? All that work wasn't free to implement. But big businesses really want that degree of secure fleet management, and they're the customers who matter.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
Large entities asked Microsoft to stop simply bundling Copilot with all those services and instead relabel the services so that their usage could be counted as AI usage in their quarterly report whether or not they actually engage with the AI features?
I think it's clear the source comment was referencing end users. It's patently obvious at this point that a large number of people who directly use Windows are frustrated with it, and perceive it to be degrading rather than improving over time.
A corporate end user isn't a customer. The customer is the corporate department of purchases. What I mean in my original comment is that if you as an end user purchase software, then you will be listened to by developers.
It's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.
That's a fair observation, and yet anecdotally I agree with the parent comment. In my career I fixed quite a few bugs about dates being passed around and unexpectedly modified, while I struggle to remember the same problem with objects in general (could be a case of selective memory).
If I had the guess, I'd say it's a combination of:
- the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object)
- most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant
So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted.
Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.
What parent commenter meant was language level support of immutable objects. There is const, in for example JavaScript, but it supports only immutability of variables, not objects themselves. That later one is possible in C++ for example, where const can be used for both. Of course, it’s still possible to fake immutability with interfaces in some languages, or have a real one forced by implementation (like with Temporals), but it’s much nicer to have an indicator forcing that.
I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.
You've described three different features with three different sets of semantics. Which set of semantics is honored? Unknown!
This is not software engineering. This is an appeal to faith. Software engineering requires precise semantics, not whatever the compiler feels like doing. You can't even declare that this feature has no semantics, because it actually introduces a vector for UB. This is the sort of "feature" that should not be in any language selling itself as an improved C. It would be far better to reduce the scope to the point where the feature can have precise semantics.
Typically it's configurable. For example C++ 26 seems to be intending you'll pick a compiler flag to say if you want its do-nothing semantics, or its "tell me about the problem and press on" semantics or just exit immediately and report that. They're not intending (in the standard at least) to have the assume semantic because that is, as you'd expect, controversial. Likewise more fine-grained configuration they're hoping will be taken up as a vendor extension.
My understanding is that C3 will likely offer the coarse configuration as part of their ordinary fast versus safe settings. Do I think that's a good idea? No, but that's definitely not "Unknown".
Any idea how the situation is handled where third party code was written to expect a certain semantic? Is this just one more rough edge to watch out for when integrating something?
I mostly agree with your sentiment, but saying "math is not art" is the same as saying "writing is not art". Calculation isn't art. But math isn't calculation. Math is a social activity shared between humans. Like writing, much of it is purely utilitarian. But there's always an aesthetic component, and some works explore that without regard to utility. It's a funny kind of art, accessible to few and beautiful to even fewer. But there is an art there.
Incorrect. Art is practice. It's literally what the word means historically. Put in "Etymology of the word 'art'" in your favorite search engine or LLM.
If someone is entering a prompt to generate an image in a model I have access to, I don't really need to pay them to do it, and definitely don't need to pay them as much to do it as I would an actual artist, so it is deceptive for them to represent themselves as someone who could actually draw or paint that. If the product is what counts then truth in advertising is required so the market can work.
I would die of embarrassment if I had bad code in a project for me. I am at my limit for tolerating bad code in projects for others, where the economics don't support taking the time that would be required to fix the deep problems. Code for me is going to be good. I won't accept anything less. I need a countervailing force, reminding me of the beauty of clear expression of complex ideas.
Basically irrelevant to taxpayers. Their salaries or triple their salaries will add up to a difference of a couple dollars on the average tax bill. Doge didn't actually cut any of the big expenses. It was only intended to cut the effective things.
Handling negative feedback on a PR is a necessary skill for a developer. A manager should only get involved if it becomes hostile. Negative is very far from hostile.
Handling negative feedback doesn't involve going to anybody - neither the manager, nor the person who gave the PR. Someone giving negative feedback is not supposed to be a conflict in need of resolution. We are talking about a situation where there is a conflict that needs to be resolved, ie that it has already become hostile.
If they are going to their manager, and then the manager, rather than convincing them that they are over-reacting, is instead going to you and telling you that there's something wrong with the feedback you gave, you should handle that negative feedback.
It doesn't matter what I consider a conflict. The fact is someone went to their boss with a conflict because it rose above their threshold of what a conflict is. If one of the parties involved feels there is a conflict in need of mediation, then there is a conflict in need of mediation. Very likely the issue is that the second party didn't realize what they said would cause conflict, which is exactly why the boss should be talking to them.
No one is saying that the boss should be looking for and trying to mediate "conflicts" no one wants them to resolve.
I’m pretty sure the top comment thread was edited because I can’t figure out what we’re debating.
I think the original comment said something to the effect of “employees shouldn’t ever resolve their own conflict, their boss should do it for them”.
I was only trying to illustrate that there are some people out there who are incredibly sensitive and will make a conflict out of the color shoes you’re wearing. Sometimes it’s good to empower an employee to speak their mind about their coworkers hideous color shoes, no need to force boss man to relay the message.
reply