WTF is with some of the tests using a 6144 x 2560 resolution?
What the hell kind of display are they using?
The only one I could find at that weird-ass resolution was a 52 inch?! dell monitor.
Is anyone seriously using a 52 inch display?
I think they should probably be using normal resolutions for all the tests so they don't end up benchmarking some weird corner case optimisation issue that no one is going to run into.
Respectfully disagree.
Gnome is the environment not implementing Server-side window decorations.
That makes everything harder for app developers since they have to implement client side window decorations to make apps movable just for Gnome.
When apps can't be moved around on Gnome because they don't have a window handle to drag, it doesn't really fit the "it just works" requirement.
Also: January is not always the 1st month, sometimes it is the 0th.
1/1/2026 can be both Jan 1st, and Feb 1st.
For the downvoters, try it in your browser's terminal:
let test = new Date("1-1-2026");
console.log(`Year: ${test.getFullYear()}, Month: ${test.getMonth()}, Day: ${test.getDate()}`);
// Prints -> Year: 2026, Month: 0, Day: 1
//
***
---
***
---
***
---
***
---
// test.getFullYear() returns the year, but test.getYear() only returns the number of years since 1900
// test.getMonth() returns the month, but the first month is 0-indexed
// test.getDate() returns the day, 1-indexed, but test.getDay() returns the current day right now and not the day of the date object
Deno's packaging can be confusing (is this dependency installed in node_modules, the global cache or somehow both across module boundaries?)...
... But damn, its permission system is fucking amazing. Just run your code like normal and watch what permissions it asks you for.
What's that?
Oh, you'd like permission to read the env file and network access? Begone namesquatted malware!
What's that?
Oh, you want write permission to /.., fuck off slopped out pull request!
I tried porting a project back to node (v24) to see what it was like (since I heard node had a permission system now) and because some devs wanted to stick with what was familiar to them.
First thing I noticed, my watch/rebuild/serve script went from 0.2 seconds to 3-5 seconds with no code changes and using the same dependencies that were originally written for node.
Second thing, Node's permission system doesn't work because it's broken by design. Permissions cannot ever be opt in. Everything needs to be locked down and you need to explicitly get permission to access things.
In node's design, a junior dev could "opt in" to the network permission to disable network requests, but they wouldn't think to block subprocesses (which could call cURL/wget and get it to make network requests on the main processes' behalf). It's utterly broken and shifts the blame to the developer for not knowing better.
I instantly switched the project back to deno.
it’s good at answering questions like that
Are you sure about that: https://www.youtube.com/watch?v=JtBI2BvPKBQ
Remember: if you don't know enough about the topic in question to grade its answers then you're not judging its ability to answer accurately, you're judging it's ability to convince you.
Ah yes, the ol' people are annoyed at the actions I chose to take, so I'll call it a joke defence
It's for the best.
Learning how code works is better than getting an LLM to produce convincing looking code without anyone having an understanding of how it works.
LLMs just teach students to paint themselves into a corner without them even realising why bad things keep happening to them.
How is that my problem
Well let's break it down...
You thought:
Yeah, it’s called .deb
Was an acceptable response to:
Because it’s nice for devs to have a single package type to build per OS
Your problem was your stupidity.
But now your problem is everyone knowing about it.
More like “why the fuck would I walk all the way across the city now that I own a car”
That's a bad analogy.
Using an LLM for coding gives you an initial speed up with the trade off being skill atrophy, and a build up of cognitive debt in the project.
A better analogy would be the Greek government before their national debt crisis. It would have been better to invest in themselves, not lie about their own finances, and not kick the can down the road. But they kept lying and kicking the can down the road because it was easier in the short term. Of course, we all know how that turned out in the end.
They published a release without release notes.
The release notes came later.
Why not find a way to automate this,
Why not find a way to automate every single change that the vscode team makes that may break something?
Or why not let users do whatever?
Ultimately, users can do whatever.
But when they need help, they come to me.
I have a recommended list of settings for things that should already be defaults, to guide them away from footguns, and to prevent themselves from needing my help in the first place. But I also sometimes need to go around with a critical (usually temporary) list of changes for when a vscode update truly borks something up.
My concern was potentially needing to go around the office once a month for those critical fixes to once a week.
This is why I suggested multiple release channels. Have a weekly release for developers who are okay with the trade-off of more frequently broken setups for newer features faster, and have a monthly release for developers who want more stable environments.
It'd be a lot easier for me to run the weekly channel to be kept abreast of any changes, and I can support other coworkers on a monthly cycle.
The first month is inputted with a 1 and exported as a 0.
The first day is inputted with a 1 and exported as a 1.