My first thought was similar, though followed quickly by "...but it's Apple, so what's the catch?" The relevant extra things to know are that the SSD is soldered, there are no slots for extra SSDs, and choosing a sensible (1TB) drive is >4X the price of buying similar storage at retail. Still a no from me, then.
(The only thing I do often that's CPU-limited is compiling, being faster at that saves me maybe a few minutes in a full working day; I don't care. I am frequently limited by RAM and I really hate shuffling things around to make space on drives.)
Seriously. What does "screen time" even mean if it doesn't include the 9 hours a day I spend staring at 8 square feet of monitors and the ~45 mins the TV is on during meals?
If they mean "phones" say "phones". If they mean "social media" say "social media". Oh but then all the bullshit about stuff being close to one's face wouldn't make "sense" (I wear glasses, I must be constantly terrorising myself.)
It may be a very slight overreaction but my first thought is that everybody in the entire faculty that produced these findings should be re-employed doing something actually useful like grocery deliveries.
I'm not sure I'd even call "local debt" technical debt in ordinary circumstances - realistically there's always going to be mess somewhere, and encapsulating it away where it can't hurt anyone is normal. If it probably never needs to change unless requirements change (in which case any other implementation would also need to) it's fine.
Perhaps if 24 minion instances constitute an actual problem (rather than just inelegance) their example for it is actually foundational debt related having a "minion" being the simplest primitive that would do the job when maybe something lighter could have existed.
The article goes into it a tiny bit, but the cost is the mental cost of when you do need to work on it, understanding it, and I would add keeping the tooling the same.
Encouraging devs to have their changes include all modules, even those that are old and mature and don't need to be touched, is a good way of ensuring this doesn't build up to where it becomes a problem.
I've done the same, and my experiences also match those in the article.
Using a LLM as an autocomplete (typescript, kotlin) I found it'd be right about 10% of the time, very obviously wrong ~30% of the time, but mostly (~60%) *plausible*. Plausible is the worst, because if I don't spot the error immediately it'll come back to bite me in the coming hours/weeks and it takes me much longer to fully comprehend existing code than it does to write new code myself.
Asking questions fares better, but I never have easy questions and for difficult ones it'll usually be wrong. Like, if I'm asking an LLM a question I'm usually at a point where I've read the docs and there's something I don't understand - so it's not that surprising that the LLM won't understand it either. Occasionally pointing out the flaw will get a better answer, but more often it just leads to a circle of flawed answers. I feel like people who say this is some sort of revolution are perhaps people who weren't very good at finding information themselves.
The only places where this stuff seems to be an unqualified success so far is for jobs where the quality of the output is not very important.
I agree with this entirely, and have griped about it to people (and here) before.
But I would never, under any but the most egregious circumstances, complain directly to a colleague who does it or (especially) send them this link.
People are different, and most people are different to me. I'm getting paid partly to deal with other people, so that's what I'll (sometimes grudgingly) do. If they're doing this all the time to each-other, my productivity is still going to be relatively high anyway.
> I would never ... complain directly to a colleague who does it
True. Nor would I. I would push for the company to publish guidelines about remote and asynchronous communication. And then if someone repeatedly communicated badly, I'd provide constructive feedback either directly to them or to their line manager.
I hit some sound issues in the Linux version, for anyone else with the same problem telling Steam to use Proton to run the Windows version instead is a workaround.
My only minor peeve with the sequel so far is that the logistics of moving stuff back to the central platform is pretty fiddly and time-consuming compared to the first one. I think there's an unlockable upgrade I'm nowhere near getting which might fix that though.
Yup, I too had issues with sound, the game seems to just use the first sound interface available, but it is relatively easy to change after starting (via KDE sound panel for me, but I imagine pavucontol should also work). The issue seems to be with Unity/FMOD on linux not the actual game. Newer versions of Unity seem to not have this issue and author was saying they are trying to see if they can upgrade.
PS I was attempting to make a pipewire LUA script that would auto connect the FMOD output to default interface but got stuck on querying and linking audio ports and interfaces, if someone has more Pipewire-Fu I am all ears!
What I definitely would like to see is a requirement to preserve a working VM containing source code, assets and build tools, set up to compile everything without an internet connection. It'd be much more useful to have than old binaries when all this stuff eventually becomes public domain.
Alternatively, it's just entertainment and movie DRM is at worst annoying and counterproductive.
In X years time when humanity is struggling to rebuild civilisation in a radioactive wasteland I don't think the main problem will be the inability to find a copy of "Dumb And Dumber To". The real heroes will turn out to have been the contributors to Open Source and Open Access projects - Linux, Wikipedia, etc.
There are better things (often unpaid) developers could be doing than implementing DRM but also much much worse things.
There is quite a spectrum between Dumb and Dumber and the great works of art of our time. What runs in common is that both cases are often withheld from the public due to copyright.
reply