WTF Bites
-
The national weather service can handle a maximum of 7 warnings for a region before overflowing.
For some bonus fun, these are all flood warnings.
Of course it overflows when there are 8 (or more) warnings for high flows!
-
WHY THE FUCK IS IT POSSIBLE TO NAVIGATE AWAY OR CLOSE PINNED TABS AAAAARRRRRGGGGGGHHHHHH
-
@HardwareGeek 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.
Those sound exactly like the sorts of thing a certain rare "technical" acquaintance of a certain local cyborg would do.
-
WHY THE FUCK IS IT POSSIBLE TO NAVIGATE AWAY OR CLOSE PINNED TABS AAAAARRRRRGGGGGGHHHHHH
I've wondered this myself.
-
Many of these are sometimes started by other applications.
From the same package. No reason to use $PATH to find each other.
No, by different package. Often via some additional tooling (e.g.
sensible-browser), so it has to actually search for them in one way or another.And "another" is the right thing to do. I don't know what "sensible-browser" is, but I know Linux (and Windows too, for that matter) lets you pick a default web browser/email client/music player from a list of installed programs that are known by the system (probably through manifests, though I don't know details) to be the particular kind of program. AFAIK they're started through full path to binary, so they don't need to exist in %PATH%.
In Windows, all installed applications are registered in the system registry (i.e. that file that RegEdit edits). Default apps and file handlers (and a whole load of other stuff) also resides in there. AFAIK, other OSes split that up so that default file type handlers are stored separately from the location where the program was installed.
Binaries that are only ever called by the package that installed them are, on Linux, generally not in
$PATHI find if hard to believe, but if you say so... I have no reason not to trust you on this one.
(while on Windows they often are, because the tools that add themselves in path often don't give a damn about any kind of hygiene and slap everything in the one directory they added there).
Only with tools that DO add themselves to %PATH%. Which is like the 0.1% of the most shittiest dev tools and other shitty software. Good - and even decent - software doesn't put itself in %PATH% at all - because there's no need to in most cases.
For one program to be able to find another, they must do at least one of (1) be in the same folder, (2) be registered with the operating system so the latter's location can be queried, or (3) be in a (set of) searchable location(s). #3 can be split into 3 methods: (3a) the entire file structure directory, (3b) a single common folder, and (3c) a small set of commonly-used searchable directories.
#1 can leads to lots of duplicated (library) files. #2 requires some sort of specialized installation process to tell the OS, "Here is this file in that location." #3a is prohibitively inefficient unless the entire file structure (including the OS) is guaranteed to be tiny. #3b requires coordination among developers and marketers and managers to prevent name collisions (
). #3c seems to strike a balance between having to search the whole system and having to specially install apps.Not strictly true. GUIDs exists - and once you have GUID, human-readable name doesn't have to be unique anymore. But that's a different discussion.
That's not a different discussion. Ok, we could name packages by UUIDs. And we'll have them all over the place as the packages do refer to each other. Or you'll have some other, human-memorable identifiers and you are back where you were.
Why does it matter if something that the user will never see - such as the identifiers packages use to refer to each other - will be in human-readable form or not? The assumption is that all identifiers that get shown to the user, get translated into their human-friendly names using package metadata.
And then you've got
prog1(UUID "abc") and anotherprog1(UUID "def"), but now which one is which, from the user's perspective? Are those different versions of the same app? Are they different apps? You've not really solved the problem; it's just been pushed back one step.
-
Their target audience is no one.
Alas, no. There are plenty of people out there with money to spend on stupid things and no common sense at all.
-
#3c seems to strike a balance between having to search the whole system and having to specially install apps.
Some operating systems allow an application to specifically nominate a place to additionally search (helpfully, in a way that can be fairly easily patched at installation time) so that their internal stuff doesn't need to be on a global path or all pitched into a single common place with lots of other apps.
-
Binaries that are only ever called by the package that installed them are, on Linux, generally not in
$PATHI find if hard to believe, but if you say so... I have no reason not to trust you on this one.
(while on Windows they often are, because the tools that add themselves in path often don't give a damn about any kind of hygiene and slap everything in the one directory they added there).
Only with tools that DO add themselves to %PATH%. Which is like the 0.1% of the most shittiest dev tools and other shitty software. Good - and even decent - software doesn't put itself in %PATH% at all - because there's no need to in most cases.
For one program to be able to find another, they must do at least one of (1) be in the same folder, (2) be registered with the operating system so the latter's location can be queried, or (3) be in a (set of) searchable location(s). #3 can be split into 3 methods: (3a) the entire file structure directory, (3b) a single common folder, and (3c) a small set of commonly-used searchable directories.
Of these, only (2) is The Right Thing To Do, with the modification that the registration and lookup doesn't necessarily have to be provided by operating system - you can have a single 3rd party service that all your programs use to find each other. Also, (1) is an acceptable compromise between rightness and convenience for programs from a single bundle.
#1 can leads to lots of duplicated (library) files.
Which isn't a problem at all in this day and age - as shown by Windows and OSX.
#2 requires some sort of specialized installation process to tell the OS, "Here is this file in that location."
In other words, doing the right thing requires doing the right thing.
#3a is prohibitively inefficient unless the entire file structure (including the OS) is guaranteed to be tiny.
So let's not discuss that.
#3b requires coordination among developers to prevent name collisions (
).Which is my main complaint against the Linux Way.
#3c seems to strike a balance between having to search the whole system and having to specially install apps.
And it also requires coordination among developers to prevent name collisions.
Not strictly true. GUIDs exists - and once you have GUID, human-readable name doesn't have to be unique anymore. But that's a different discussion.
That's not a different discussion. Ok, we could name packages by UUIDs. And we'll have them all over the place as the packages do refer to each other. Or you'll have some other, human-memorable identifiers and you are back where you were.
Why does it matter if something that the user will never see - such as the identifiers packages use to refer to each other - will be in human-readable form or not? The assumption is that all identifiers that get shown to the user, get translated into their human-friendly names using package metadata.
And then you've got
prog1(UUID "abc") and anotherprog1(UUID "def"), but now which one is which, from the user's perspective? Are those different versions of the same app? Are they different apps? You've not really solved the problem; it's just been pushed back one step.No, I totally solved the problem. The problem is that there CANNOT be two programs with the same name. It created another problem - that there CAN be two programs with the same name. I'd argue that probability of a user installing two programs that have the same name is much lower than probability of there being two programs with the same name at all. And it can be solved by letting the user rename the application. As long as programs use UIDs, renaming can be done at any time and never breaks anything.
-
Because no one wanted to work for you at all?
Alternative interpretation: All developers were made an offer they couldn't refuse.
Seriously, this sounds like: "No one ever left us. Except for Dave. No one talks about Dave anymore. No one, if you catch my drift."
-
Of these, only (2) is The Right Thing To Do, with the modification that the registration and lookup doesn't necessarily have to be provided by operating system - you can have a single 3rd party service that all your programs use to find each other.
Warning, some amount
incoming:Under linux, programs register themselves with the OS by placing themselves in /usr/bin/ et al..
(</
>)To be entirely honest, I think the OS that gets this kind of things the most correct is probably Mac OS X, where each application resides in a directory that contains all of the resources, including private dependencies, possibly multiple binaries, assets etc etc. Most (seemingly -- I don't use MacOS that much, and dislike it a lot for other reasons) applications can be installed by simply extracting/copying that directory into the applications folder. Done. (Shared dependencies are more of a pain, but then again, those are a pain regardless).
-
Shared dependencies are more of a pain, but then again, those are a pain regardless
Are they more of a pain in general, or compared to other operating systems? If the latter, then it looks like OSX solves the problem by not even trying to do anything.
-
WHY THE FUCK IS IT POSSIBLE TO NAVIGATE AWAY OR CLOSE PINNED TABS AAAAARRRRRGGGGGGHHHHHH
IMO pinned tabs should be global to all browser windows so that it's impossible to accidentally close the window they're in while you have another window open.
-
Because no one wanted to work for you at all?
Because they moved out of Poland to better paying countries?
-
Are they more of a pain in general, or compared to other operating systems?
Shared resources are just more of a pain in general. The OSX system update process isn't too awful.
-
Are they more of a pain in general, or compared to other operating systems?
In general.
One advantage is maybe that the OSX frameworks are against just directories, so they can contain multiple different versions of the actual shared library that makes up the framework. I think you can also pack assets and private dependencies into the framework, similarly to apps. (Somebody more familiar with the Appley world can correct me.)
-
Because no one wanted to work for you at all?
Alternative interpretation: All developers were made an offer they couldn't refuse.
Seriously, this sounds like: "No one ever left us. Except for Dave. No one talks about Dave anymore. No one, if you catch my drift."
And another alternative interpretation is: "We hire so shitty developers that they can't find jobs anywhere else".
-
#2 requires some sort of specialized installation process to tell the OS, "Here is this file in that location."
Mac Classic didn't use any kind of "specialized installation process"; it just snooped on the filesystem and whenever an executable was installed, it updated the desktop database with its path, file types, and creator codes. The user and app developer didn't have to do squat to make this work.
Of course being a good user-friendly simple design, it is now completely unknown to the modern IT landscape where only overly-complex and user-hostile technologies can be imagined.
-
@blakeyrat That's still a specialized installation process, but most of the specialized stuff is built into and occurs in the OS instead of in a separate installer executable.
Just out of curiosity, how did it handle programs that claimed to handle the same file type?
-
@topspin
At least Adobe Reader Marvel would have a coherent plot line and actually good special effects...
-
Today the boss sent out an email with 12 attachments for the meeting. One Excel spreadsheet and 11 PDFs. I dunno where the fuckup happened, but this is the (cropped) e-mail as displayed by Thunderbird. One line of "Hi!", one line of "Today we're going to go through these results...", 12 horizontal bars, then the ending "Best regards".
-
Just out of curiosity, how did it handle programs that claimed to handle the same file type?
That's what the creator code was for.
If you have 27 applications that all handle "TEXT" files (via the Macintosh file type system, which was 4 characters of meta-data, not a file extension), the creator code of the file would determine which application opened it by default. Although any application that claimed to support "TEXT" could open it if the creator code wasn't found on the system. (I don't know how it chose which application that was, maybe it was just first come, first serve. But it's not like it came up much.)
Going back to djls45's post point 3, Macintosh creator codes had a registry, and responsible application developers applied to take ownership of one before shipping their app. I actually have a certificate somewhere in my condo giving me ownership of the (IIRC) "BNMo" creator code.
-
Wow, Edge really has streamlined its user interface!
-
@anonymous234 it's the end goal of modern flat UI design. Somewhere a designer just creamed their pants.
-
@anonymous234 so has my (lying) Task Manager!
-
@anonymous234 They optimized the render loop so the FPS is really smooth.
-
Why does this laptop with Windows 10 have an application called "Windows 10 Upgrade Helper" installed? In case I decide to upgrade from Windows 10 to Windows 10?!
YES!
It's for upgrading from one version of Window 10 (e.g. Fail Craters) to another (e.g. April Current Years). Apparently they're different enough that standard Windows Update can't handle it.The only time I used that (and installed it) was to force windows to do an update (like when they treated Enterprise extra special and delayed the rollout). Nowadays, clicking 'Check for Updates' brings the release down even on Enterprise - so after I uninstalled that (over a year ago), it's never come back.
-
@scarlet_manuka said in WTF Bites:
My mother had a Win 7 laptop that she never really used, so I'm setting it up for my daughter to use (mainly for study). Currently in the "deleting crap" phase. (Do I want to uninstall Java 6 Update 22? Why, yes, I believe I do.)
Most WTF software title spotted so far: "HP Games". And yes, that is HP as in Hewlett-Packard. I really don't want to imagine...
HP... Delete crap - yeah, reimage that sucker.
-
@blakeyrat said in WTF Bites:
Just out of curiosity, how did it handle programs that claimed to handle the same file type?
That's what the creator code was for.
If you have 27 applications that all handle "TEXT" files (via the Macintosh file type system, which was 4 characters of meta-data, not a file extension), the creator code of the file would determine which application opened it by default. Although any application that claimed to support "TEXT" could open it if the creator code wasn't found on the system. (I don't know how it chose which application that was, maybe it was just first come, first serve. But it's not like it came up much.)
Going back to djls45's post point 3, Macintosh creator codes had a registry, and responsible application developers applied to take ownership of one before shipping their app. I actually have a certificate somewhere in my condo giving me ownership of the (IIRC) "BNMo" creator code.
Could that creator code be changed by the end user? Or did it make it impossible to set some other program as the default handler for that file type? Did the user even have a choice of choosing which of their 27 applications to use to open a "TEXT" file?
-
Could that creator code be changed by the end user? Or did it make it impossible to set some other program as the default handler for that file type? Did the user even have a choice of choosing which of their 27 applications to use to open a "TEXT" file?
IIRC, the user couldn't change the creator code, but they could ask when opening the file to use an alternative application. I can't remember how exactly; I never used classic MacOS very much (and didn't care for it at the time when I did, which was mostly to use a scanner at college). I think that saving with the new application would update the creator, but I could be wrong there.
Having seen the code to work with them at the low level, creator codes and file types were dead weird. They were little-endian packed 32-bit words, not strings in any sort of a conventional sense, even though they were often written as something that looked like a string. Mac (Objective-)C compilers allowed you to write them like
'TEXT'. With single quotes…
-
Could that creator code be changed by the end user?
Yeah; open the file in the application you want to be the new "creator", and hit "Save".
Or did it make it impossible to set some other program as the default handler for that file type?
Did what? I don't know what you mean by "it" here.
Did the user even have a choice of choosing which of their 27 applications to use to open a "TEXT" file?
I think you misunderstand how it worked. Every "TEXT" file had its own creator code.
They were little-endian packed 32-bit words, not strings in any sort of a conventional sense, even though they were often written as something that looked like a string.
They were literally a string with a fixed length of 4 characters. That's how strings in 680x0 computers looked.
-
@blakeyrat said in WTF Bites:
Could that creator code be changed by the end user?
Yeah; open the file in the application you want to be the new "creator", and hit "Save".
You had to open the application first and then open the file from there? You couldn't just say, "Open this file with that (different) app"?
Or did it make it impossible to set some other program as the default handler for that file type?
Did what? I don't know what you mean by "it" here.
Sorry. The first "it" was the creator code. The second "it" was a dummy pronoun to facilitate the extraposition of the rest of the sentence.
Did the user even have a choice of choosing which of their 27 applications to use to open a "TEXT" file?
I think you misunderstand how it worked. Every "TEXT" file had its own creator code.
Ah. So if I had an application that saved ASCII documents with a "TEXT" creator code, but then opened a file created by it in another application that saved documents with a "TXT1" creator code, saving the file with the second program would change the creator code to "TXT1" and cause the file thereafter to be opened with the second program by default?
-
Ah. So if I had an application that saved ASCII documents with a "TEXT" creator code, but then opened a file created by it in another application that saved documents with a "TXT1" creator code, saving the file with the second program would change the creator code to "TXT1" and cause the file thereafter to be opened with the second program by default?
You seem to be slightly confused. There were two codes, one for the type of the file, and the other to uniquely identify the application that created the file. (Apple didn't think deeply about weird people who kept several versions of the same application about.)
-
You had to open the application first and then open the file from there?
Or drag & drop the file's icon on to the application's icon, or drag & drop the file into an application's open window. MacOS 8 or 9 might have had a contextual menu for it.
But yes, in a general sense, you have to explicitly tell the OS which application to use. Regardless of the specific method.
Sorry. The first "it" was the creator code. The second "it" was a dummy pronoun to facilitate the extraposition of the rest of the sentence.
Then no, creator codes could be changed my the user using the technique of just saving the file when open in a different application.
(There was also the developer's tool ResEdit that could do it, naturally.)
Ah. So if I had an application that saved ASCII documents with a "TEXT" creator code, but then opened a file created by it in another application that saved documents with a "TXT1" creator code, saving the file with the second program would change the creator code to "TXT1" and cause the file thereafter to be opened with the second program by default?
A creator code of "TEXT" would be very confusing and probably not allowed by Apple, because it'd be way too confusing when one of the most common file types was also "TEXT". (Apple's text editor creator code was, "ttxt" for SimpleText.)
But to answer your question literally: yes. The name creator code is kind of a misnomer, it was actually the "last application who saved this file" code. Again, though, this isn't anything that would really come up in normal usage.
-
My immediate reaction to most ideas Google comes up with is "how do I block this?"
-
git(GNU Interactive Tools had to make way to it) andnode(there was anodepackage that had something to do with hamm-radio; and not that it actually installed/usr/sbin/node, so the files did not actually conflict, but it was still regarded as conflict and thenodefrom node.js was for long callednodejs)
ISTR
dockerwas another.You know how some cars have "parking assist" to make parallel parking easier? Somebody should make that for boats. They could call it Docker.
-
@topspin
is it called “picture-in-picture” when it is out of the browser.
-
My immediate reaction to most ideas Google comes up with is "how do I block this?"
Didn't Edge have a feature like this?
-
@bulb Because it has a very minor resemblance to the TV feature of the same name, I guess.
-
-
There can be no sane reason why the department-level final assignment for English should be distributed as a DOCX instead of a PDF.
-
-
var requestIP = GetClientIpAddress(HttpContext.Current.Request.RequestContext.HttpContext.Request); // Srsly .NET? That's the shortest way to get a HttpRequestBase from a HttpRequest?
-
@blakeyrat I'm going to assume that
HttpContext.Requestis not exposed like that right at the top?
-
Discovery: A new way to ensure a string'd boolean exists?
-
My immediate reaction to most ideas Google comes up with is "how do I block this?"
https://wicg.github.io/picture-in-picture/ :
If the algorithm is not triggered by user activation, throw a NotAllowedError and abort these steps.
At least there's that.
Also:
TL;DR: allows sending video playback to an external device.
-
Having seen the code to work with them at the low level, creator codes and file types were dead weird. They were little-endian packed 32-bit words, not strings in any sort of a conventional sense, even though they were often written as something that looked like a string.
Little endian, SRSLY?! Even though MacOS came from the M68k? That's just
Those four-letter-word-but-actually-longint are common in some container formats; the first was probably EA's IFF format, the latest Google's WebP.
All of those are big endian though, AFAIK.
-
@tsaukpaetra said in WTF Bites:
@blakeyrat I'm going to assume that
HttpContext.Requestis not exposed like that right at the top?The first
HttpContextis a class, not a property.
-
@ben_lubar said in WTF Bites:
@tsaukpaetra said in WTF Bites:
@blakeyrat I'm going to assume that
HttpContext.Requestis not exposed like that right at the top?The first
HttpContextis a class, not a property.I wasn't given that context, my snippet works in a webapi class.
-
@pie_flavor said in WTF Bites:
There can be no sane reason why the department-level final assignment for English should be distributed as a DOCX instead of a PDF.
Probably laziness/ineptitude/forgetfulness on behalf of the person who generated it.
I've done similar in the past, by mistake.
Corrected when people started contacting me asking "wtf is .ods?"
-
If the algorithm is not triggered by user activation
For which it's probably good enough if the user clicks anywhere on the site on a transparent overlay.
