WTF Bites

[boomzilla]

@bulb said in WTF Bites:

@gąska said in WTF Bites:

BitBucket doesn't let you see closed Mercurial branches. You can still browse commits just fine - just not the branch itself.

There is no such thing as closed branch.

hg

In the options section for hg commit:

--close-branch mark a branch head as closed

[Gąska]

Today in Software That Makes Europeans Not Want To Live On This Planet Anymore:

Firefox 59 on Ubuntu 16.04

*twitch*

[hungrier]

@gąska

Fuck you dicksource why can't I have ą properly aligned

[ben_lubar]

@gąska said in WTF Bites:

Visual Studio Code package name for Debian is "code". Not "vs-code" or "visual-studio-code". Just "code". Better yet, this name doesn't conflict with any other package.

It makes sense. The package name for the package that adds /usr/bin/gcc is gcc. Why should the package name for the package that adds /usr/bin/code not be code?

[Zecc]

static void Main(string[] args)
{
	CheckDotNetVersion();
	if (!Is45Installed)
	{
		DialogResult dr = MessageBox.Show("Microsoft .Net frame 4.0 needs to be installed", "Prerequisite", MessageBoxButtons.YesNo);
		if (dr == System.Windows.Forms.DialogResult.Yes)
		{
			System.Diagnostics.Process.Start("https://www.microsoft.com/en-us/download/details.aspx?id=30653");
		}
		else
		{
			// ...
		}
	}		
}
	
public static CheckDotNetVersion()
{
	var keyName = @"SOFTWARE\Microsoft\NET Framework Setup\NDP";
	var installedVersions = Registry.LocalMachine.OpenSubKey(keyName);

	var versionNames = installedVersions.GetSubKeyNames();

	foreach (var version in versionNames)
	{
		if (version.ToString().Trim() == "v4.0")
			Is45Installed = true;
	}
}

Note: the link's to .NET Framework 4.5 download page.

[Gąska]

@ben_lubar said in WTF Bites:

@gąska said in WTF Bites:

Visual Studio Code package name for Debian is "code". Not "vs-code" or "visual-studio-code". Just "code". Better yet, this name doesn't conflict with any other package.

It makes sense. The package name for the package that adds /usr/bin/gcc is gcc. Why should the package name for the package that adds /usr/bin/code not be code?

TRWTF is naming your non-core program with a common word like code.

No - TRWTF is having a single directory for all binaries in the system!

Anyway, Microsoft is being assholes for using common word as an identifier in a global namespace.

[ben_lubar]

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

You do know that $PATH exists, right? It's just that all the packages from your package manager usually go in /usr/bin.

[Gąska]

@ben_lubar said in WTF Bites:

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

You do know that $PATH exists, right?

I don't maintain Ubuntu, so it's irrelevant whether I know this or not. Canonical maintains Ubuntu, and it's sad they don't know that $PATH exists. It doesn't seem to be common knowledge among maintainers of any distro.

[ben_lubar]

@gąska installing a package generally doesn't modify every user's configuration files on the entire system. and generally it doesn't require logging out and back in to use a package you just installed.

[Gąska]

@ben_lubar are you saying $PATH doesn't solve the problem I've mentioned at all?

[bb36e]

@ben_lubar it's just a weird name. plus, this isn't always the case. for example, neovim installs nvim. and for a few years, ffmpeg would install avconv.

[anotherusername]

@cursorkeys I mean, the very first thing it says in the doc for mysql_connect is...

[anotherusername]

@atazhaia said in WTF Bites:

Google Earth Pro really wants me to know I can use it to manipulate and export GIS data.

You knew that you could visualize, manipulate, and export GIS data. But did you know that you can manipulate and export GIS data?!

Also why is that the only Swedish that I can understand?

[anotherusername]

@hardwaregeek said in WTF Bites:

Eating lunch and there's a TV on in the lunchroom. Sound is off, but the caption says

Woman who gouged her own eyes out says life is more beautiful now

I think we have a whole thread about that in the Garage.

[anotherusername]

@polygeekery said in WTF Bites:

I am sure it has already been covered, but the latest Windows updates are setting Edge as the default PDF viewer. Goddamn that pisses me off. Stop pushing your shit on us like that. Pop a window if you want and give users a choice, but if you do that then the default should be to leave things how they are.

That sounds kind of anti-competitive...

[Gąska]

@anotherusername it gives Edge a chance to compete with other products!

[blek]

This time I'm TR.

Some time ago a friend of mine mentioned that her laptop hasn't been working in ages. Apparently the fan started making weird noises and the laptop would shut down before it even finished booting; she took it to a repair shop, they charged her roughly the equivalent of 150 US dollars to fix it, and the fix lasted a month. I offered to fix it since it was clearly a busted fan that should be simple to repair.

So I took the laptop, ordered a new fan for $13.22 with free shipping, and this evening I poured myself some shitty rum with shitty coke knockoff and got to work. I started disassembling the thing, but when I tried to take off the bottom cover I couldn't.

It took me literally at least 40 minutes of trying to get the fucking off to realize there was one more screw, hidden under a "warranty void if removed" sticker. There's even another screw in the exact same spot on the other side of the cover. Aaaaaaargh.

Also now that I replaced the fan and put it back together and got it to boot, it's the slowest fucking laptop I've ever seen. The specs aren't bad, it's an old Core i5 with 6 gigs of RAM, but it's starting a million pointless things on boot. This friend of mine is 30. My retired mom's laptop isn't this bad, and it's an even older, bottom-of-the-barrel budget model and she installs a bunch of stupid shit and clicks Yes to everything. I guess I'm now spending Friday evening getting rid of bloatware. Holy shit, why does Avast take this long to get rid of?!

[pie_flavor]

@polygeekery E_NO_REPRO.

[Gąska]

@blek said in WTF Bites:

This time I'm TR.

I Am TRWTF Topic is that way

[pie_flavor]

@blek Do you think she'd notice if you backed up the documents and did a full Windows reinstall?

[pie_flavor]

@gąska said in WTF Bites:

[Gąska]

@pie_flavor if she hasn't used it in ages, chances are she doesn't even know what's in documents, much less the rest of the system!

[blek]

@pie_flavor Probably not, but she has a shitload of stuff on the hard drive and I don't have anything to back it up to at the moment, so I'll have to do it the harder way.

[Tsaukpaetra]

@gąska said in WTF Bites:

@blek said in WTF Bites:

This time I'm TR.

I Am TRWTF Topic is that way 

FTFY.

[blek]

OK, what the fuck is this. I'm trying to download CCleaner. I open Chrome, go to the site, hit Download for the free version. The .exe downloads in about 2 seconds. Then, Chrome pops up a warning that "a site wants to download one or more files" or something like that, I click Allow, and it downloads the same file again.

[Bulb]

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

No, that's not a WTF at all. It's more efficient and it does not cause any additional problems anyway.

@gąska said in WTF Bites:

are you saying $PATH doesn't solve the problem I've mentioned at all?

No, it does not. All binaries in $PATH need to have unique names to be reasonably invokable from the shell anyway, so how many directories they are actually spread over changes nothing.

Actually, having more of them makes things worse, because now the system must search more places to find the command. It actually tends to be an issue on Windows which are quite slow in listing directories, tend to have long $PATH (or rather %PATH%) and tend to have a lot of junk alongside the binaries.

[Rhywden]

@anotherusername said in WTF Bites:

@polygeekery said in WTF Bites:

I am sure it has already been covered, but the latest Windows updates are setting Edge as the default PDF viewer. Goddamn that pisses me off. Stop pushing your shit on us like that. Pop a window if you want and give users a choice, but if you do that then the default should be to leave things how they are.

That sounds kind of anti-competitive...

Is that from the school of: "Windows may not include any default programs for any type of data file ever"?

[Gąska]

@bulb said in WTF Bites:

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

No, that's not a WTF at all. It's more efficient and it does not cause any additional problems anyway.

Actually, having more of them makes things worse, because now the system must search more places to find the command. It actually tends to be an issue on Windows which are quite slow in listing directories, tend to have long $PATH (or rather %PATH%) and tend to have a lot of junk alongside the binaries.

On Windows, there isn't that much that you have to put in %PATH%. I'd argue it's the same on Unix, except Unix has million times more programs that depend on a particular program in a particular version with a particular name being in $PATH.

And $PATH listing can be easily optimized. It definitely would have been optimized if there was a compelling case to do so. I even have a pretty good idea how to do it in user-space software, without any OS support.

[Bulb]

@gąska said in WTF Bites:

@bulb said in WTF Bites:

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

No, that's not a WTF at all. It's more efficient and it does not cause any additional problems anyway.

Absolutely serious.

Actually, having more of them makes things worse, because now the system must search more places to find the command. It actually tends to be an issue on Windows which are quite slow in listing directories, tend to have long $PATH (or rather %PATH%) and tend to have a lot of junk alongside the binaries.

On Windows, there isn't that much that you have to put in %PATH%. I'd argue it's the same on Unix, except Unix has million times more programs that depend on a particular program in a particular version with a particular name being in $PATH.

It does not, really. If you are using just the office stuff, the names and locations don't really matter on either and development tools put a lot of stuff in path on both. Ok, Visual Studio only puts them there if you explicitly import it into that shell—but it's an awfully long list then.

And $PATH listing can be easily optimized. It definitely would have been optimized if there was a compelling case to do so. I even have a pretty good idea how to do it in user-space software, without any OS support.

Oh, Linux is pretty optimized. It wouldn't really matter. But it would not help anything anyway. And on Windows, well, it is not optimized there.

[anotherusername]

@rhywden said in WTF Bites:

@anotherusername said in WTF Bites:

@polygeekery said in WTF Bites:

I am sure it has already been covered, but the latest Windows updates are setting Edge as the default PDF viewer. Goddamn that pisses me off. Stop pushing your shit on us like that. Pop a window if you want and give users a choice, but if you do that then the default should be to leave things how they are.

That sounds kind of anti-competitive...

Is that from the school of: "Windows may not include any default programs for any type of data file ever"?

It's from the school of "Windows may not automatically replace one of the default programs that I've configured with something else".

[Gąska]

@bulb said in WTF Bites:

@gąska said in WTF Bites:

@bulb said in WTF Bites:

@gąska said in WTF Bites:

No - TRWTF is having a single directory for all binaries in the system!

No, that's not a WTF at all. It's more efficient and it does not cause any additional problems anyway.

Absolutely serious.

You don't see any downsides of having a flat directory containing everything in your system, each thing having to have unique name?

Actually, having more of them makes things worse, because now the system must search more places to find the command. It actually tends to be an issue on Windows which are quite slow in listing directories, tend to have long $PATH (or rather %PATH%) and tend to have a lot of junk alongside the binaries.

On Windows, there isn't that much that you have to put in %PATH%. I'd argue it's the same on Unix, except Unix has million times more programs that depend on a particular program in a particular version with a particular name being in $PATH.

It does not, really.

It really does. There's shitload of Unix programs if you don't have Bash executable literally as /bin/bash. Lots of Python programs assume your python is Python 2, and there's a few that assume it's Python 3. And those that properly call python2 and python3 don't even try to make sure the minor version is right.

development tools put a lot of stuff in path on both.

Only bad ports of Unix tools and otherwise fully retarded applications really put stuff in Windows %PATH%. I'm on my dev PC right now which is a bit over 4 years old and had hundreds of random tools installed, and my %PATH% consists of:

• PhysX
• Python 2.7
• Java
• A bunch of stuff from C:\Windows and other system paths
• grep (my own addition)
• C:\Users\<username>\.dnx\bin, whatever it is (the path doesn't exist)
• Windows Performance Toolkit (which isn't actually a development tool IIRC)
• MSSQL Server
• TortoiseGit
• Skype
• OpenSSH

Ok, Visual Studio only puts them there if you explicitly import it into that shell

As it should be!

—but it's an awfully long list then.

So? It's not like you're launching more than one process per second.

And $PATH listing can be easily optimized. It definitely would have been optimized if there was a compelling case to do so. I even have a pretty good idea how to do it in user-space software, without any OS support.

Oh, Linux is pretty optimized. It wouldn't really matter. But it would not help anything anyway.

It would help with name conflicts. It would also help if Unix programs didn't depend on everything being in %PATH%.

[HardwareGeek]

@bulb said in WTF Bites:

All binaries in $PATH need to have unique names to be reasonably invokable from the shell anyway

The project I'm currently working on uses a bunch of special versions of standard programs (e.g., a shell that's been patched to allow longer command lines — no, 4k characters aren't enough). Of course, it relies on $PATH to find the versions before the normal ones. Which is a right royal pain sometimes. For some unknown reason, the version of less is completely broken, and I have to type /usr/bin/less to look at any files.

[HardwareGeek]

@gąska said in WTF Bites:

And $PATH listing can be easily optimized.

At least some shells already do. They only search $PATH when it changes and cache the results. So they know that foo is /bin/foo and bar is /usr/local/bin/bar without having to search the entire path to find them. The downside, of course, is that they don't notice when you add, delete, or move an executable unless you tell them to update their cache.

[HardwareGeek]

@gąska said in WTF Bites:

It would also help if Unix programs didn't depend on everything being in %PATH%.

I've never seen any Unix program that depends on %PATH% at all. In fact, that's a syntax error in just about anything I can think of that runs on Unix.

[topspin]

@anotherusername said in WTF Bites:

That sounds kind of anti-competitive...

I have it on good authority from one of our forum members that Microsoft doesn't break the law.

[topspin]

@polygeekery said in WTF Bites:

@mott555 said in WTF Bites:

Does this even work? My work PC keeps doing this, but Edge either crashes or freezes when it tries to open a PDF.

Knowing Microsoft...probably not.

Ten bucks says it doesn't.

Not just because it's Edge, but because Adobe Reader supports a bazillion things in PDFs that really shouldn't be in there, JavaScript, videos, all kinds of shit. Normal forms in PDFs work fine in most Linux viewers I use, but then you get some stupid shit from HR which uses who-knows-what and you can't even fill out a stupid document because it displays the moral equivalent of <noscript>Please use Adobe Reader DC or Marvel or whatever!</noscript>.

[PJH]

@gąska said in WTF Bites:

You don't see any downsides of having a flat directory containing everything in your system, each thing having to have unique name?

Well, as long as the names aren't too similar...

https://what.thedailywtf.com/topic/10978/sometimes-i-am-trwtf/12

@djls45 said in Sometimes I am TRWTF.:

Conclusion: SQL Server Management Studio has the process label "ssms.exe", but the Windows Session Manager runs under the process name "smss.exe", and the latter is necessary for the system to run properly.

[Gąska]

@hardwaregeek said in WTF Bites:

The downside, of course, is that they don't notice when you add, delete, or move an executable unless you tell them to update their cache.

Adding, fair enough. Deleting or moving - sounds like a bug in your shell. Missing file at cached path should trigger regular lookup procedure.

@hardwaregeek said in WTF Bites:

@gąska said in WTF Bites:

It would also help if Unix programs didn't depend on everything being in %PATH%.

I've never seen any Unix program that depends on %PATH% at all. In fact, that's a syntax error in just about anything I can think of that runs on Unix.

Fuck you and your pedantry. You should be happy I've got capitalization right!

...At least I hope I've got it right.

[Bulb]

@gąska said in WTF Bites:

ou don't see any downsides of having a flat directory containing everything in your system, each thing having to have unique name?

No, I don't see any downsides of having a flat directory containing everything that needs to and would be in path anyway, each thing having to have unique name which it has anyway if it is to be used via path anyway.

@gąska said in WTF Bites:

It's not like you're launching more than one process per second.

I certainly would if Windows were up to it. Compilation usually runs many processes.

@gąska said in WTF Bites:

It would help with name conflicts.

Actually, it would make them worse. If the files are in the same directory, the package manager will notice and prevent you from installing both packages—unless you create a diversion and rename the files, which you can do. If they were in different directories, you'd only notice they are not working later when strange errors occur.

@gąska said in WTF Bites:

It would also help if Unix programs didn't depend on everything being in %PATH%.

Many don't. There is plenty of things in /usr/lib/programname and other places these days actually.

[Gąska]

@bulb said in WTF Bites:

@gąska said in WTF Bites:

ou don't see any downsides of having a flat directory containing everything in your system, each thing having to have unique name?

No, I don't see any downsides of having a flat directory containing everything that needs to and would be in path anyway

Average Linux distro has bazillion things in /bin and /usr/bin that have no business being in $PATH. Including every GUI application accessible via launchers (desktop icons, start menu, whatever else you've got). Though I admit, I used to use find ... | xargs grep ... | xargs medit to open files a lot at one point. But I don't think I'll ever need to do this with Firefox.

@gąska said in WTF Bites:

It's not like you're launching more than one process per second.

I certainly would if Windows were up to it. Compilation usually runs many processes.

On Windows, compilation usually doesn't invoke compiler processes through shell. And it's still less than one per second.

@gąska said in WTF Bites:

It would help with name conflicts.

Actually, it would make them worse. If the files are in the same directory, the package manager will notice and prevent you from installing both packages—unless you create a diversion and rename the files, which you can do.

This assumes you want both these files in your $PATH. Which assumes both these files are executables (there are collective directories for other types of files), and it also assumes both of these programs will be launched from command line by human (or by another program that doesn't know where the program you're installing is located and doesn't bother to ask user).

@gąska said in WTF Bites:

It would also help if Unix programs didn't depend on everything being in %PATH%.

Many don't. There is plenty of things in /usr/lib/programname and other places these days actually.

I don't know what it means exactly, but I have a feeling it means there's now two assumptions about where things are rather than just one. In other words, the problem has been doubled.

[HardwareGeek]

@gąska said in WTF Bites:

Missing file at cached path should trigger regular lookup procedure.

You are correct, of course; the shell will notice if it tries to launch an executable that doesn't exist, and searching the path is perhaps the most reasonable response. My point, though, is that it notices the missing file only at the point it tries to launch it, rather than noticing the change to the directory contents.

[Gąska]

@hardwaregeek yeah, it should definitely watch the directory itself. What shell are you using? I might be able to come up with PR.

[Polygeekery]

@topspin said in WTF Bites:

@polygeekery said in WTF Bites:

@mott555 said in WTF Bites:

Does this even work? My work PC keeps doing this, but Edge either crashes or freezes when it tries to open a PDF.

Knowing Microsoft...probably not.

Ten bucks says it doesn't.

Not just because it's Edge, but because Adobe Reader supports a bazillion things in PDFs that really shouldn't be in there, JavaScript, videos, all kinds of shit. Normal forms in PDFs work fine in most Linux viewers I use, but then you get some stupid shit from HR which uses who-knows-what and you can't even fill out a stupid document because it displays the moral equivalent of <noscript>Please use Adobe Reader DC or Marvel or whatever!</noscript>.

It doesn't. The client switched over to a web app LOB that generates PDFs for anything that needs to be printed. Adobe is literally the only one that displays them "correctly".

[HardwareGeek]

@gąska I made some assumptions based on observed behavior that may not accurately reflect the implementation details of any particular shell (and they don't all behave the same). I also realized that I don't have reliable observation of how any shell behaves when a known executable is removed, as that is not something I'm in the habit of doing. So it's entirely possible that some shells may indeed notice that the directory contents have changed, while others only report the exec failure, but I have no idea which exhibit which behavior. (Most of my problems are with the right directory not being in $PATH in the first place. Or not even existing, because the build script wants /snowflake/path/gcc.4.7.12-special_38q5.2a1b/bin/gcc and we only have /snowflake/path/gcc.4.7.12-special_37x5.1a2c/bin/gcc.)

[Gąska]

@hardwaregeek that's okay. I never had any intention messing with bash source anyway.

[Bulb]

@gąska said in WTF Bites:

Average Linux distro has bazillion things in /bin and /usr/bin that have no business being in $PATH. Including every GUI application accessible via launchers

That's just a handful of binaries. The majority is various utilities that are usually executed from scripts, or at least with execlp.

@gąska said in WTF Bites:

But I don't think I'll ever need to do this with Firefox.

I have a wrapper or two somewhere. And it's just one binary anyway. It makes very little difference. Especially in Linux.

@gąska said in WTF Bites:

This assumes you want both these files in your $PATH. Which assumes both these files are executables (there are collective directories for other types of files), and it also assumes both of these programs will be launched from command line by human (or by another program that doesn't know where the program you're installing is located and doesn't bother to ask user).

More or less, yes. If they are not executables, they won't be in bin.

@gąska said in WTF Bites:

On Windows, compilation usually doesn't invoke compiler processes through shell. And it's still less than one per second.

Compilation with clang does that everywhere. Also, even if it is not through shell (or with full path), keep in mind, that in Windows, %PATH% is also used to search for shared libraries. And that slows down all process starts.

@gąska said in WTF Bites:

Many don't. There is plenty of things in /usr/lib/programname and other places these days actually.

I don't know what it means exactly, but I have a feeling it means there's now two assumptions about where things are rather than just one. In other words, the problem has been doubled.

Oh, it's nobody's (except the owning package) to touch anything in /usr/lib/programname. That's the point. The binaries you don't care about are not in $PATH.

Also, assuming anything is in /usr/bin is wrong anyway. Only the things in /bin may be assumed.

@gąska said in WTF Bites:

@hardwaregeek yeah, it should definitely watch the directory itself. What shell are you using? I might be able to come up with PR.

The Windows dynamic linker does not seem to do that anyway.

[Gąska]

@bulb said in WTF Bites:

@gąska said in WTF Bites:

Average Linux distro has bazillion things in /bin and /usr/bin that have no business being in $PATH. Including every GUI application accessible via launchers

That's just a handful of binaries.

On an average desktop installation it's the majority of binaries. Especially considering there's a fair number of applications that consist of more than one binary.

The majority is various utilities that are usually executed from scripts, or at least with execlp.

I'd say it's utilities that there's just a handful of.

@gąska said in WTF Bites:

But I don't think I'll ever need to do this with Firefox.

I have a wrapper or two somewhere. And it's just one binary anyway. It makes very little difference. Especially in Linux.

Sound panel. Display configuration. Screenshot app. IM client. I could go on like that all day. Firefox was just an example of the many apps that will never get launched from script on 99% of computers.

@gąska said in WTF Bites:

This assumes you want both these files in your $PATH. Which assumes both these files are executables (there are collective directories for other types of files), and it also assumes both of these programs will be launched from command line by human (or by another program that doesn't know where the program you're installing is located and doesn't bother to ask user).

More or less, yes. If they are not executables, they won't be in bin.

They're be in "lib". Or "share". Or "etc". Or one of many other random collective directories Linux has. The problem is more general than just binaries.

@gąska said in WTF Bites:

On Windows, compilation usually doesn't invoke compiler processes through shell. And it's still less than one per second.

Compilation with clang does that everywhere.

See my post about shitty ports.

Also, even if it is not through shell (or with full path), keep in mind, that in Windows, %PATH% is also used to search for shared libraries. And that slows down all process starts.

Keep in mind that program's directory is searched before anything in %PATH%. Keep in mind the DLL resolution is cached.

@gąska said in WTF Bites:

Many don't. There is plenty of things in /usr/lib/programname and other places these days actually.

I don't know what it means exactly, but I have a feeling it means there's now two assumptions about where things are rather than just one. In other words, the problem has been doubled.

Oh, it's nobody's (except the owning package) to touch anything in /usr/lib/programname. That's the point. The binaries you don't care about are not in $PATH.

Sorry, I misinterpreted your post and what you mean by "programname". You know, you could've said "packagename" or "appname", or add a trailing slash.

Also, assuming anything is in /usr/bin is wrong anyway. Only the things in /bin may be assumed.

That's just as wrong. Unless the content of /bin is fixed and never ever changes after installation?

@gąska said in WTF Bites:

@hardwaregeek yeah, it should definitely watch the directory itself. What shell are you using? I might be able to come up with PR.

The Windows dynamic linker does not seem to do that anyway.

The Windows dynamic linker operates on assumption the user deletes random critical files on regular basis. I don't like their policy on that, but at least they have one, and they stick to it.

[HardwareGeek]

@gąska said in WTF Bites:

on assumption the user deletes random critical files on regular basis.

If that assumption is true, the user deserves to have his/her computer break irreparably.

[Gąska]

@hardwaregeek Microsoft has a long history of accommodating users too stupid to live.

[ben_lubar]

@bulb said in WTF Bites:

Also, assuming anything is in /usr/bin is wrong anyway.

What about /usr/bin/env?