WTF Bites

dcon

it pops up an annoying banner of "It looks like you haven't started Firefox in a while"

This is one reason I haven't bothered putting FF into my VMs and I just stick with the pre-installed Edge.

Edit: Well, that and of course...

Gąska

On a meeting right now where we're discussing whether not being able to set multiple cookies (because the HTTP request headers are stored in a simple name->value hashmap) is a problem worth fixing in an application framework.

Arantor

@Gąska there are almost certainly at least two issues with your application framework already...

Gąska

@Arantor there are at least two issues with every line of code I've seen at this place so far.

HardwareGeek

@Gąska said in WTF Bites:

@Arantor there are at least two issues with every line of code I've seen at this place so far.

Current build:
Errors: 0 Warnings: 189087

dcon

@HardwareGeek said in WTF Bites:

@Gąska said in WTF Bites:

@Arantor there are at least two issues with every line of code I've seen at this place so far.

Current build:
Errors: 0 Warnings: 189087

We finally turned off the compiler option that complained about clang-format related issues. In system and 3rd party headers. :whew:

PleegWat

@dcon I'd have assumed it differentiates between -I and -isystem header paths, just like gcc does? It tends to be rather option compatible.

dcon

@PleegWat said in WTF Bites:

@dcon I'd have assumed it differentiates between -I and -isystem header paths, just like gcc does? It tends to be rather option compatible.

Beats me - it's so deeply hidden down in cmake files and docker images... I just know it generated so much noise that it was hard to actually find a real error.

PleegWat

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

dcon

@PleegWat said in WTF Bites:

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

It's weird. I actually miss working on Windows with Visual Studio now.

Gąska

@PleegWat said in WTF Bites:

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

I worked in a project that used hand written makefiles extensively. Several thousand lines. No, the alternatives aren't worse.

Benjamin Hall

@Gąska said in WTF Bites:

@PleegWat said in WTF Bites:

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

I worked in a project that used hand written makefiles extensively. Several thousand lines. No, the alternatives aren't worse.

Could be xCode, where the project files break if you try to do anything and then try to merge them. But then again, xCode is the epitome of "it could always be worse (because it could be xCode)"

Parody

@dcon said in WTF Bites:

@hungrier Yeah. 97.0.2 released. Then 3 days later, they released 98. Which then reset the download option. FUCK YOU, I HATE FF's PDF handler. And, no, I like being prompted for what to do with a file because I do different things based on the file. (Some PDFs I just want to browse/print. Some I want to save.)

PDFs in browsers have been a thorn in my side forever. Early on it was Adobe's plugin that caused viewing or printing problems so I always had to tell people to download them first. Now it's these Javascript-based viewers built in to the browsers. I've got everything set to Ask where to download the file.

PleegWat

@Benjamin-Hall And even if it's xcode, it could be tomorrow's xcode instead of today's.

sebastian.galczynski

New chapter in the package-lock.json saga. We (me, the lead dev and the bluehairs at the npm hq) have now created the following situation:

if I do npm install without package-lock.json, with old version of npm (on my machine), everything compiles and package-lock is created.
if I do the same inside the docker container (used by the CI pipeline), which uses newer version of npm, it installs some other version of something, or fails to apply a patch, anyway stuff doesn't compile.
if I push my locally generated lockfile into the container and then run npm install, it prints a bunch of warnings about incompatible lockfile version, 'fixes' the lockfile somehow, and then installs the "correct" versions.

I tried to understand how this stuff works, but it seems that the authors themselves can't agree on this issue.

I hate the antichrist.

sebastian.galczynski

@Gąska said in WTF Bites:

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I've written some C and never even thought of that. The only place where I've seen literal shift is bash scripts.

Gąska

@sebastian-galczynski it's done by the same people who think while(p++=q++); is cool.

sebastian.galczynski

@Gąska said in WTF Bites:

@sebastian-galczynski it's done by the same people who think while(p++=q++); is cool.

I once met a TA (not in CS department) who taught people to write like this and showed her students the IOCCC. 'But why would you do that?' 'Well, this way it's more cool'

sebastian.galczynski

@Gąska said in WTF Bites:

On a meeting right now where we're discussing whether not being able to set multiple cookies (because the HTTP request headers are stored in a simple name->value hashmap) is a problem worth fixing in an application framework.

Did you try the workaround with different case? HTTP headers aren't case sensitive, but a hashmap
probably is, so you can stuff a lot of 'Cookie', 'cOOkie' etc in there.

Gąska

@sebastian-galczynski the current workaround is that we only need a single cookie per request right now, so it's okay for the framework to not support more. It's been noted as a second-lowest priority improvement ticket.

Bulb

@sebastian-galczynski said in WTF Bites:

New chapter in the package-lock.json saga. We (me, the lead dev and the bluehairs at the npm hq) have now created the following situation:

if I do npm install without package-lock.json, with old version of npm (on my machine), everything compiles and package-lock is created.

if I do the same inside the docker container (used by the CI pipeline), which uses newer version of npm, it installs some other version of something, or fails to apply a patch, anyway stuff doesn't compile.

if I push my locally generated lockfile into the container and then run npm install, it prints a bunch of warnings about incompatible lockfile version, 'fixes' the lockfile somehow, and then installs the "correct" versions.

I tried to understand how this stuff works, but it seems that the authors themselves can't agree on this issue.

I hate the antichrist.

npm is . A huge .

… that said, the CI pipeline should be using npm ci instead of npm install which installs what is in package-lock.json or croaks, and will start by nuking the node_modules, so it shouldn't have “incompatible versions” present. Also, consider just using the same container for development, that's what containers are for.

sebastian.galczynski

@Bulb said in WTF Bites:

… that said, the CI pipeline should be using npm ci instead of npm install

I know, but with this setup it means that the lockfile should be created inside the container, and then commited to the repo. Can be done, but

Tsaukpaetra

@topspin said in WTF Bites:

@Zecc said in WTF Bites:

I've kept reading ().

It will still be possible to configure it to Always Ask, except it's per file type and it will be reset during the update.

Because who needs to keep their settings, anyway, right?
By now I assume most Mozilla employees started working there later than when I first set up my firefox at work, which is almost ten years now. And every time I start it, it pops up an annoying banner of "It looks like you haven't started Firefox in a while" (which is obviously a lie) and wants me to reset everything. Um, no, I don't want to lose my stuff, TYVM.

(Of course there's some about:config hackery for it but )

Yeah, it's extremely entertaining to see that message on fresh installs in Linux. Like, fuck, why the hell ever would anyone want to delete their profile on a regular basis?

Tsaukpaetra

@dcon said in WTF Bites:

@PleegWat said in WTF Bites:

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

It's weird. I actually miss working on Windows with Visual Studio now.

Reminds me of a ticket I recently made, in which the response is "well did you set your environment variables?" fuck you, the installer should have done that! And if it needed a reboot to fully apply (because fuck you Windows) it should gorram say so!

Tsaukpaetra

@Tsaukpaetra said in WTF Bites:

the installer should have done that!

And apparently I got hit with . Serves me right for following an online tutorial?

Vue-cli doesn't actually install? · Issue #7011 · vuejs/vue-cli

Version 5.0.1 Reproduction link [None](Can't create a project, thus there is no code to reproduce) Environment info Unable to comply, vue-cli doesn't get installed. Running Windows 11 22000...

sebastian.galczynski

The $bigClient grabbed the last tiny bit of our testing infrastructure and switched it over to production.

You know what? I'll tell you what: now I'm gonna crash one of your prod devices to see if a notification gets sent somewhere.

He pulled the same stunt at the very start of the project (by attaching hist production servers and devices to our staging), after we implemented a prototype of one feature (without any UI, tests etc) which he needed urgently. Then we set up another server and slowly persuaded him to set some devices to use it. Now again he moved everything to prod (formerly known as stage-1).

Of course, for the cash he's paying us he could buy a whole container (not in the docker sense) of this junk. But no, too precious to assign a dozen or so for testing purposes permanently and bring them to an office.

MrL

@sebastian-galczynski said in WTF Bites:

The $bigClient grabbed the last tiny bit of our testing infrastructure and switched it over to production.

You know what? I'll tell you what: now I'm gonna crash one of your prod devices to see if a notification gets sent somewhere.

He pulled the same stunt at the very start of the project (by attaching hist production servers and devices to our staging), after we implemented a prototype of one feature (without any UI, tests etc) which he needed urgently. Then we set up another server and slowly persuaded him to set some devices to use it. Now again he moved everything to prod (formerly known as stage-1).

Of course, for the cash he's paying us he could buy a whole container (not in the docker sense) of this junk. But no, too precious to assign a dozen or so for testing purposes permanently and bring them to an office.

Obligatory:

Bulb

@sebastian-galczynski said in WTF Bites:

Of course, for the cash he's paying us he could buy a whole container (not in the docker sense) of this junk. But no, too precious to assign a dozen or so for testing purposes permanently and bring them to an office.

That is unfortunately as common as it is wrong. Hell, just consider the sheer absurdity of two people (tech lead and project lead), in Germany, spending an hour discussing whether they can afford to buy an 80€ device used for the test rig and whether not to buy a cheaper alternative that requires another extra hour or two of assembly by senior engineer…

Bulb

@MrL said in WTF Bites:

Obligatory:

Surprisingly we do. At least on some projects.

Arantor

@MrL I work for an agency with a total of 5 people where going from a client's $60/month hosting down to $40/month hosting would be a tangible benefit, and we have staging environments for everything.

Gribnit

@Arantor said in WTF Bites:

@MrL I work for an agency with a total of 5 people where going from a client's $60/month hosting down to $40/month hosting would be a tangible benefit, and we have staging environments for everything.

Containers don't count

Arantor

@Gribnit Containers? I'd love to have containers. I'm using good old fashioned VPSes.

sebastian.galczynski

Well, the device crashed, but the notification didn't get sent, because the home-baked hash-o-signature doesn't match. What can be wrong? Are they hashing a newline? UTF BOM? They pretty-print the json and then hash? Nobody knows, since they won't show us their implementation. But it certainly isn't just what they described in the email.

Gąska

@Tsaukpaetra said in WTF Bites:

@dcon said in WTF Bites:

@PleegWat said in WTF Bites:

@dcon Ah, yes. While plain old make can be pretty horrible to work with, I get the impression that all the alternatives are worse.

It's weird. I actually miss working on Windows with Visual Studio now.

Reminds me of a ticket I recently made, in which the response is "well did you set your environment variables?" fuck you, the installer should have done that! And if it needed a reboot to fully apply (because fuck you Windows) it should gorram say so!

Which tutorial? Which installer? Which reboot?

There are two things at play here:

vue-cli didn't do anything wrong.
yarn did everything wrong but made it look like vue-cli's fault.

So understandably, vue-cli's devs are annoyed by you shouting in their face when you should be shouting at yarn.

Also, whether you need a reboot or not varies by platform. You need it on Windows. You don't need it on Linux. Did you follow a Windows-specific tutorial, or a generic tutorial that assumes Linux? Are you absolutely sure there was no mention of "refresh environment" or "reload .bashrc" or anything of that sort at any point in the tutorial?

Your case looks like a classic case of PEBKAC and not knowing your own tools (the operating system, not vue-cli). Except I realize documentation in JS ecosystem is pathetic at best, and non-existent on average, so I'm willing to cut you some slack. Still, you yelled at the wrong people.

Bulb

@Gąska said in WTF Bites:

Also, whether you need a reboot or not varies by platform. You need it on Windows.

You don't need to reboot windows to get new environment variables. In fact you don't even need to log in again, just close the terminal, or even just issue a command I don't remember that reloads the cmd.exe's environment from the registry. Linux does not have the last option and terminals often just inherit the environment rather than reading the init script, so there you usually do need to log out and back in.

Zerosquare

@Gąska said in WTF Bites:

Also, whether you need a reboot or not varies by platform.

This is you're talking to. The computer certainly needs a reboot, and the user probably does as well.

Gribnit

@Arantor oddly, those do at least barely count, since there's less impetus to take a fairly literal giant shit into it and stir until barely-working, with a VPS than a container.

Gąska

@Bulb said in WTF Bites:

@Gąska said in WTF Bites:

Also, whether you need a reboot or not varies by platform. You need it on Windows.

You don't need to reboot windows to get new environment variables. In fact you don't even need to log in again, just close the terminal, or even just issue a command I don't remember that reloads the cmd.exe's environment from the registry.

Must be a new thing. I'm certain this didn't work on Windows 7 and you had to reboot after every change for new cmd instances to pick up changes. I've messed a lot with my env vars back in the day.

Linux does not have the last option and terminals often just inherit the environment rather than reading the init script, so there you usually do need to log out and back in.

That's only half true. Yes, the global init scripts aren't re-run and the global env changes aren't inherited (but there's a lot of asterisks here; env vars on Linux are generally a big mess). However, yarn and other dev tools usually set up env vars inside .bashrc, and .bashrc does get reloaded every time you launch the shell, regardless of method (also asterisks here). You can also reload it manually with source ~/.bashrc (only one asterisk here).

Gribnit

@Bulb said in WTF Bites:

terminals often just inherit the environment rather than reading the init script, so there you usually do need to log out and back in.

You can also often just source your profile file, if it's hooked such that it invokes system inits when not initialized. If you're a legit user, that is, and your PATH starts out absolute...

Bulb

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

@Gąska said in WTF Bites:

Also, whether you need a reboot or not varies by platform. You need it on Windows.

You don't need to reboot windows to get new environment variables. In fact you don't even need to log in again, just close the terminal, or even just issue a command I don't remember that reloads the cmd.exe's environment from the registry.

Must be a new thing. I'm certain this didn't work on Windows 7 and you had to reboot after every change for new cmd instances to pick up changes. I've messed a lot with my env vars back in the day.

Pretty sure it did work in 7 and I think even in XP.

Linux does not have the last option and terminals often just inherit the environment rather than reading the init script, so there you usually do need to log out and back in.

That's only half true. Yes, the global init scripts aren't re-run and the global env changes aren't inherited (but there's a lot of asterisks here; env vars on Linux are generally a big mess).

Indeed.

However, yarn and other dev tools usually set up env vars inside .bashrc, and .bashrc does get reloaded every time you launch the shell, regardless of method (also asterisks here).

If the shell is bash. Mine is not.

But really, tools assuming they understand how to add a variable setting and/or thinking they should are a pain the bum. They should just ask where you want the scripts to be linked (with default to ~/.local/bin, though the XDG standard does not (yet) know that one) and tell the user it should be added in PATH if it isn't already.

You can also reload it manually with source ~/.bashrc (only one asterisk here).

Indeed. Or just set it. But really, it shouldn't be done anyway. Windows is holding PATH wrong. It shouldn't have a million entries. It should have a handful only and all the executable commands should simply be put or linked there.

dcon

@Bulb said in WTF Bites:

It should have a handful only and all the executable commands should simply be put or linked there.

We went thru that already. I'd rather have a long PATH then the hell of everyone installing into \windows and \windows\system(32). We know how installer authors can't do that shit right.

Gąska

@Bulb said in WTF Bites:

@Gąska said in WTF Bites:

However, yarn and other dev tools usually set up env vars inside .bashrc, and .bashrc does get reloaded every time you launch the shell, regardless of method (also asterisks here).

If the shell is bash. Mine is not.

Then .zshrc or config.fish or whatever. Also, ZSH and most other Bourne-compatible shells read .bashrc by default unless changed. There's also .profile and .bash_profile and /etc/profile and a bunch of others which may or may not be read on launch and may or may not be relevant to your particular shell in your particular configuration when launched in a particular way by a particular user. Linux environment setup is the biggest YMMV in the known universe.

But in general, .bashrc does get reloaded on launch.

But really, tools assuming they understand how to add a variable setting and/or thinking they should are a pain the bum.

Agreed. But only because Linux is so broken regarding variable setting. Windows apps add their own env vars all the time and it works just fine.

They should just ask where you want the scripts to be linked (with default to ~/.local/bin

That's actually a terrible idea (which makes it on par with everything else regarding Linux application setup, so I'll give you that). I don't want my programs overwriting each other, and blindly dumping everything in the same location is a great way to end up with programs overwriting each other. And yes, I do realize you only said to drop symlinks there and have the real programs in separate directories. That's still terrible and still leads to overwriting each other.

But really, it shouldn't be done anyway.

Linux in nutshell.

Windows is holding PATH wrong. It shouldn't have a million entries. It should have a handful only and all the executable commands should simply be put or linked there.

In terminal-first systems like Linux, yes. In GUI-first systems where the terminal exists mostly as a compatibility shim for Linux devs who couldn't be arsed to port their programs to Windows properly - it's totally fine as the first order of business is to isolate applications from each other as much as possible. And part of that is putting each and every one in a separate directory.

Gribnit

@Gąska Consider busybox, iirc, which links one binary a billion ways, more or less. It then expects those to end up on the path. Being able to see my parent process environment change after spawn would be, a security complication. Being able to modify the current environment and/or override variables for specific commands, along with tools that work together, allows for composability.

Not that Windows doesn't have, for instance, Tile or Snap Edges modes, those are kind of like composability.

@Gąska said in WTF Bites:

And part of that is putting each and every one in a separate directory.

And also everything in a single giant binary registry.

Bulb

@Gąska said in WTF Bites:

end up with programs overwriting each other.

They end up doing that in Windows too.

The real proper solution is to have some kind of package format and the package manager to take care of collecting entry points, be it executables or .desktop files or .service files or whatever. That's one thing that MacOS is doing right with the app bundles. As usual, Linux vendors couldn't agree on one format, so we have flatpack and snap, and zeroinstall and something else I can't remember the name of that builds single-file executables embedding all resources, and most advanced, but most incompatible and thus not used, nix. Because Linux is and always has been like:

… but Windows isn't even in the game. It got the store, but almost nobody uses it and it does not cover most of the use-cases anyway, so everybody still ships hacky installers that fiddle with environment.

Luhmann

@MrL
but releases probably go straight to production

MrL

@Arantor said in WTF Bites:

@MrL I work for an agency with a total of 5 people where going from a client's $60/month hosting down to $40/month hosting would be a tangible benefit, and we have staging environments for everything.

And I work for a billion-dollar-corporation, and we have no staging. So there, I win. Or loose, rather.

Tsaukpaetra

@Gąska said in WTF Bites:

Still, you yelled at the wrong people.

@Tsaukpaetra said in WTF Bites:

And apparently I got hit with . Serves me right for following an online tutorial?

Well duh.

@Gąska said in WTF Bites:

Also, whether you need a reboot or not varies by platform. You need it on Windows. You don't need it on Linux. Did you follow a Windows-specific tutorial, or a generic tutorial that assumes Linux? Are you absolutely sure there was no mention of "refresh environment" or "reload .bashrc" or anything of that sort at any point in the tutorial?

I believe it was Windows-specific, and yes I actually did reboot just in case. Didn't help.

@Gąska said in WTF Bites:

you should be shouting at yarn.

Oh I will be. Because it worked fine two years ago and now it doesn't. But again,

@Tsaukpaetra said in WTF Bites:

Serves me right for following an online tutorial?

I'll stick to just downloading the fucking source and compiling straight instead of assuming shit that's been packaged and sent for distribution actually works in any way shape or form. At least that way I'll know where the files actually end up at.

MrL

@Luhmann said in WTF Bites:

@MrL
but releases probably go straight to production

It's the only environment that works, so of course they do.

Oh, you were joking

Zecc

@MrL Beats working in dev but not prod.

MrL

@Zecc said in WTF Bites:

@MrL Beats working in dev but not prod.

You mean like our last deployment?