The Daily WTF: Curious Perversions in Information Technology

2013-01-04 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."

Check your reading skills, it's $14 million, not $148 million

2013-01-04 Reply Admin

noOne:
dude, if you are going to act like a pedantic ass and point put someone being wrong, you should at least be right yourself.
The reason you came up with (approximately) 10x his number is that you added an extra number and started with 148,177,804.04 instead of the correct 14,817,804.04...

625 lbs is much closer to the true number

And yet my calculations are correct as shown.

2013-01-04 Reply Admin

Nik:

Check your reading skills, it's $14 million, not $148 million

damn, i didn't see noOne's comment because he didn't quote you. ugh.

2013-01-04 Reply Admin

Ted:
(At the risk of being mocked for a sincere question...) and why not? Why don't packages install under a single directory? It would make it a lot easier to copy them, share them on a network drive, or delete them when you're done. (Why should you need an "uninstalller" to do what should be just a delete?)

Not always. There are sometimes system stuff that has to go elsewhere, for instance (for some stupid reason or other).

But even more to the point: that would give an inaccurate count. Installers don't just say "I installed to c:\blah, time to deltree c:\blah"; they maintain an actual list of files which are installed, and only remove those files. If you or the program put other files into the installation directory, they will be left.

How big of a problem this would be in practice is probably up for debate, but it'd certainly be annoying if you are trying to free up, say, 2 GB, see that there's a 2 GB entry in the programs list, uninstall it, and then see that only 1 GB has been freed.

I'm not that familiar with NTFS, but there have been operating systems that maintain a per-directory count of space used in real time, plus you can set quotas so the print queue doesn't take down the production database. In such a system, reporting the acutal space used would be a single file system query, as in, nanoseconds.

Even single queries take far more than "nanoseconds" if they have to go to disk; usually more like "milliseconds" (6 orders of magnitude more than "nanoseconds"). Maybe many microseconds if you're on an SSD.

But remember, that has a tradeoff: you're increasing the amount that you have to write when you change the size of a file. (Effectively, I think this will usually be true for every file write, as I think most programs don't do in-place changes.) My guess is it's not worth it.

2013-01-04 Reply Admin

Ted:
(At the risk of being mocked for a sincere question...) and why not? Why don't packages install under a single directory? It would make it a lot easier to copy them, share them on a network drive, or delete them when you're done. (Why should you need an "uninstalller" to do what should be just a delete?)
I'm not that familiar with NTFS, but there have been operating systems that maintain a per-directory count of space used in real time, plus you can set quotas so the print queue doesn't take down the production database. In such a system, reporting the acutal space used would be a single file system query, as in, nanoseconds.

Yes, remember the bad old MSDOS days when "installing an application" meant creating a directory for it and then copying the files from the floppy to a directory? And "uninstalling" meant deleting the directory?

But applications today have to spread their files across twenty directories, make entries all over the registry, check if supporting libraries are already installed, and who knows what else. Frequently the authors of the app don't know how to uninstall it completely.

And this whole idea of DLLs ... Just as disk space was becoming cheap, Microsoft came up with this brilliant idea that we could save disk space by sharing common libraries. Of course that creates a ton of problems (or at least 625 pounds of problems), like, How do you deal with multiple versions of a DLL? Can you assume that the DLL is always upward compatible? If an app that uses a DLL is uninstalled, can you delete the DLL? What if there are other apps installed that use it? How do you keep track of what DLLs an app uses? Etc etc. So in order to carefully conserve on a plentiful resource -- disk space -- we consume large amounts of a scarce resource -- programmer and user time. It's like someone who lives in a desert carefully safeguarding his supply of sand while thoughtlessly wasting hundreds of gallons of water.

2013-01-04 Reply Admin

On the serious side: Does NTFS support sparse files? I don't have a Linux or Unix box handy to check on this, but back in my Unix days you could create "sparse files", i.e. if you did a seek to byte 1,000,000 and wrote 1 byte, the file would actually occupy only 1 block on the hard drive, but there would be dummy pointers for all the previous blocks so it would look like it was 1,000,001 bytes long and if you read it you would get back 1,000,0001 bytes. But 1,000,000 of those bytes were phantoms.

2013-01-04 Reply Admin

The tax probably includes the Obamacare surcharge. http://www.dailymail.co.uk/news/article-2233221/Dennys-charge-5-Obamacare-surcharge-cut-employee-hours-deal-cost-legislation.html

2013-01-04 Reply Admin

jay:
On the serious side: Does NTFS support sparse files?

Yes.

(Lovely spam, wonderful spam!)

2013-01-04 Reply Admin

I like your math, but you caught an extra 7 compared to the receipt.

Should be starting with 14,817,804.04 rather than 148,177,804.04

Following your math, comes to 572.3 pounds.

2013-01-04 Reply Admin

jay:
And this whole idea of DLLs ... Just as disk space was becoming cheap, Microsoft came up with this brilliant idea that we could save disk space by sharing common libraries.

Shared libraries also save memory by sharing which today is much more important than saving disk space.

Of course that creates a ton of problems (or at least 625 pounds of problems), like, How do you deal with multiple versions of a DLL?

Perhaps like every Unix system out there?

Can you assume that the DLL is always upward compatible?

If the major version number matches, it should be (otherwise bug). So you can overwrite a library on minor upgrades, but install major upgrades side by side the old version.

If an app that uses a DLL is uninstalled, can you delete the DLL? What if there are other apps installed that use it? How do you keep track of what DLLs an app uses? Etc etc.

Package dependencies, autoremove, etc etc.

I know it's below you, but sometimes by looking elsewhere to find that all those "hard problems" have long been solved you may actually learn something.

2013-01-04 Reply Admin

15M$ tax for a starter. I'm not surprized. I told you so!

CAPTCHA: populus. Dead on, that's our populist communist government at work!

2013-01-04 Reply Admin

Jeff:
I like your math, but you caught an extra 7 compared to the receipt.
Should be starting with 14,817,804.04 rather than 148,177,804.04

He just anticipated the tax increase of the next 4 years!

2013-01-04 Reply Admin

fjf:
jay:
Of course that creates a ton of problems (or at least 625 pounds of problems), like, How do you deal with multiple versions of a DLL?
Perhaps like every Unix system out there?

Now I'll be the first to bash MS when appropriate, but yes, most every OS has this jumble-of-files-everywhere concept. It is as though "executables need to go here, and libraries here" in other words the file type information is stored in the file's unique identifier rather than in a separate attribute as anyone who's studied data design knows to do.

At least most modern Unixen have a comprehensive package-and-update management system that you use to install most everything, unlike Windows, where every application vendor botches up their own, and your system while they're at it.

Unix just makes an admin's life soooo much easier!

2013-01-04 Reply Admin

Ted:
Now I'll be the first to bash MS when appropriate, but yes, most every OS has this jumble-of-files-everywhere concept. It is as though "executables need to go here, and libraries here" in other words the file type information is stored in the file's unique identifier rather than in a separate attribute as anyone who's studied data design knows to do.

Haven't we had this discussion some weeks ago? AFAIR, the issues mentioned back then (like multiple file with the same (base) name) haven't been solved (rather than waved away) by the proponents of your way.

Here's two more issues:

Searching speed. This in particular affects the (main) executables. When the user types "foo", the traditional Unix (and, as I gather, also Windows) approach only has to search in a few directories (/usr/bin etc. on Unix). When each packages installs their binaries in their own place, it has to search all of them.
Heterogeneous networks: Though surely not as important anymore today, this is one of the classic reasons for the Unix file system design: Architecture-independent stuff (documentation, data) goes under /usr/share, so they can be shared on a network, whereas /usr/bin, /usr/lib etc. can only be shared across machines of the same architecture.

2013-01-04 Reply Admin

Ted:
Why don't packages install under a single directory? It would make it a lot easier to copy them, share them on a network drive, or delete them when you're done. (Why should you need an "uninstalller" to do what should be just a delete?)

You know, OS X has that capability - most application "bundles" (which are really directories) contain the entire application - just drag and drop. Or use the Mac App Store where everything must be self-contained. (This results in some difficulty for certain types of programs, which is why the MAS is not the be-all-end-all solution to software distribution. Like device drivers cannot be installed this way).

D E:
The 1.45 TB number is Altium's fault, not MS. The number is supposed to be generated by the installer and written to the registry. That's how they got that list to be so much faster versus the XP days since XP calculated it on the fly.

Yep, it's Altium's fault. It's what you get when you shift your software production from Australia to the US, back to Australia, and then lay off practically the entire staff and move it all to Shanghai (and a bankruptcy or two? Altium's a sordid mess - it's a wonder how it even still works given the complete loss of institutional knowledge several times). And China's got a not-quite-metric system of measurement, so perhaps the installer reported 1.4 Chinese TB.

2013-01-04 Reply Admin

campino:
I wonder how the check for a minimum of 0 characters is triggered. I mean, how do you type less than zero characters? Pressing delete very often?

Oracle Varchar Null?

2013-01-04 Reply Admin

PseudoBovine:
MiffTheFox:
That's probably the most meta placeholder text I've ever seen.

I'd imagine there's a story behind it:

"Bob, I know we're still waiting for legal, but you can't just make stuff up. While you might think things like 'If you're smoking riotous bud, you must give the delivery boy a toke' are funny, it's not something that should be part of the website, even during development.

There's a standard placeholder text for these situations called "Lorem Ipsum". ... No, I don't have a copy of it lying around - just Google it and copy and paste what you find."

Actually, I think the story is more like.

Boss: Just put some placeholder text in there until we get the real text. Minion: Lorum Ipsum FTW! Boss: WTF is this?! I can't even read it! Put something real in there. Minion: ...

2013-01-04 Reply Admin

noOne:
dude, if you are going to act like a pedantic ass and point put someone being wrong, you should at least be right yourself.
The reason you came up with (approximately) 10x his number is that you added an extra number and started with 148,177,804.04 instead of the correct 14,817,804.04...

625 lbs is much closer to the true number

Upvoooooooote!

2013-01-04 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."

It would be if we were talking about $148 million instead of $15 million.... you added an extra digit in there somewhere.

2013-01-04 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."

Oh, and if you think gold is $1775.50 per ounce, I'll sell you all you want to buy considering the market price is currently $1657.07 as I type this. And I converted directly from Troy ounces to "A" pounds with a conversion factor of 14.58 Toz/lb, which is close enough for WTF work.

2013-01-04 Reply Admin

Anonymous Bob:
Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."
Oh, and if you think gold is $1775.50 per ounce, I'll sell you all you want to buy considering the market price is currently $1657.07 as I type this. And I converted directly from Troy ounces to "A" pounds with a conversion factor of 14.58 Toz/lb, which is close enough for WTF work.

Oh, you went back and looked at the historical gold price on that day. That's nice.

2013-01-04 Reply Admin

Capitalist:
Jeff:
I like your math, but you caught an extra 7 compared to the receipt.
Should be starting with 14,817,804.04 rather than 148,177,804.04
He just anticipated the tax increase of the next 4 years!

Not to mention the inflation!

2013-01-04 Reply Admin

Anonymous Bob:
Oh, and if you think gold is $1775.50 per ounce, I'll sell you all you want to buy considering the market price is currently $1657.07 as I type this. And I converted directly from Troy ounces to "A" pounds with a conversion factor of 14.58 Toz/lb, which is close enough for WTF work.

Damn boy, a little quick on the reply button and slow on the preview button are we? • Congratulations on learning how to click a link to verify the citation for the gold price.

Apparently some people missed the first image?

2013-01-04 Reply Admin

Anonymous Bob:
Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."
It would be if we were talking about $148 million instead of $15 million.... you added an extra digit in there somewhere.

Are you sure? Because nobody else has pointed this out.

2013-01-04 Reply Admin

It just compresses very efficiently.

2013-01-04 Reply Admin

Paul Neumann:
Apparently some people missed the second image?

Strike on me.

2013-01-04 Reply Admin

On TDWTF, an order of magnitude is not significant.

2013-01-04 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."

I meant to quote...

On TDWTF, an order of magnitude is not significant.

2013-01-04 Reply Admin

Your computer can't handle a 625 pixel wide image?

It definitily can. My screen is 1024 pixels wide. That should be enough for that image, shouldn't it ? (don't answer that, that was ment sarcastically)

Alas, most sites, like this one, behave like my total screen estate is theirs, and have a nice wide (most often unused by visitors like me) column on the left which pushes their actual contents way to the right, and no way to suppress it.

And yes, I also have a bookmark column on the left. That one I use way more than this site, so it stays.

P.s. Not everyone has eyes of a 16-year old.

2013-01-04 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:
Gold spot value for 2012-09-14PM was 1775.50. There are 12 troy ounces in a troy pound.
  148177804.04 $
/      1775.5    $/T oz.
=     83456.9440 T oz.
/        12      T oz. / T lb.
=      6954.7453 T lb.
*         0.8229 A lb. / T lb.
=      5723.0599 A lbs.
I would consider nearly 3 tons more than "a little over 625 POUNDS of gold."

I don't believe there's any such thing as a troy ton. Gold is traded in grams in some countries, so a metric ton is possible (1 megagram, where mega does not mean 1048576.) I don't know any country where avoirdupois pounds or short tons or long tons are appropriate. In one country a thousand pounds are worth an ounce.

2013-01-04 Reply Admin

42 is the answer, and 1.4 million is the amount of tax, but both of those are piddly little irrelevant stuff. Did you notice the receipt doesn't show the tip? The haven't finished uploading the amount of the tip. That singer was out of this world.

da Doctah · 2013-01-04 Reply Admin

Guest:
Not everyone has eyes of a 16-year old.

I have.

They're in that jar that's holding the door open.

2013-01-05 Reply Admin

If someone is willing to pay $15 for a salad, they deserve to be taxed like that.

2013-01-05 Reply Admin

Paul Neumann:
Anonymous Bob:
At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
Check your math:

The Real WTF is that idiot comments like this one get "featured". (I had to say it and you know it…)

But i can see how the tax calculation was performed.

"Deep Thought, we have finally come to hear your answer. What is the tax for that meal, the meal of one crab roll, one house salad and all the rest?" "It's fourteen million, eight hundred and seventeen thousand, eight hundred and four dollars and four cents." "Uh, okay, and what kind of tax is that actually?" "I don't know. I wasn't built to calculate that. But I can help you build a much more powerful computer for that purpose."

dkf · 2013-01-05 Reply Admin

Gunslinger:
If someone is willing to pay $15 for a salad, they deserve to be taxed like that.

Don't worry; it's California Dollars, not real ones.

2013-01-05 Reply Admin

dkf:
Gunslinger:
If someone is willing to pay $15 for a salad, they deserve to be taxed like that.
Don't worry; it's California Dollars, not real ones.

There are no real ones any more.

2013-01-05 Reply Admin

Anonymous Bob:
Capitalist:
Jeff:
I like your math, but you caught an extra 7 compared to the receipt.
Should be starting with 14,817,804.04 rather than 148,177,804.04
He just anticipated the tax increase of the next 4 years!

Not to mention the inflation!

Inflation = tax increase = government printing money = communism!

dkf · 2013-01-05 Reply Admin

Dave:
dkf:
Gunslinger:
If someone is willing to pay $15 for a salad, they deserve to be taxed like that.
Don't worry; it's California Dollars, not real ones.
There are no real ones any more.

Not even in Australia and Hong Kong?

2013-01-05 Reply Admin

"This is the first time that I have every left the USA, seeing this did not leave me with any comfort," writes Jared.

It's all this foreign equipment that the British police rely on nowadays.;-)

Kwpolska · 2013-01-06 Reply Admin

"I was going to uninstall some old programs and found this calculation error," wrote Daniel Dugger, "I don't know who to blame here - Altium or Microsoft?"

Probably Microsoft.

2013-01-06 Reply Admin

russ0519:
Check number is 42, so the rest of the check makes sense.

Of course it does - he clearly ate at the Restaurant at the End of the Universe - that's what you get after five hundred and seventy-six thousand million years of raising taxes.

2013-01-06 Reply Admin

Guest:
Borf. That 1.45 TB thingy was outside my window, and I never saw it until just now.
There I was, trying to find something odd about those numbers on the left and couldn't ... rofl.

I have sine birdies singing outside my window

Captcha: Lorakeet - how appropriate

2013-01-07 Reply Admin

noOne:
dude, if you are going to act like a pedantic ass and point put someone being wrong, you should at least be right yourself.
The reason you came up with (approximately) 10x his number is that you added an extra number and started with 148,177,804.04 instead of the correct 14,817,804.04...

625 lbs is much closer to the true number

Yeah, I found a site that quoted gold prices in kg, and that was 53201.77 USD, so 278.52 kg, or about 614 pounds. I like the fact that the editors highlighted the comment from idiot who was pedantic and completely wrong.

2013-01-07 Reply Admin

Ted:
Unix just makes an admin's life soooo much easier!

I do hope you were being ironic.

I've only ever found Linux package systems to make life (relatively) easy if you are using something a 'standard' package.

Eg, try to install a later (released) version of a program than the one for which a package is available and you'll be spending 5 days trying to find all the right versions of the dependency source files

2013-01-07 Reply Admin

Steve The Cynic:
You don't think it odd that an application installed on that 232 GB disk is taking up 1.45 TB, i.e. 1450 GB?

While that's PROBABLY strange - it is possible that the app was installed on the D: drive (or E: etc) or that it was installed on what looked likes the C: drive, but there was a hard directory link meaning that it was actually on another physical disk

2013-01-07 Reply Admin

fjf:
jay:
And this whole idea of DLLs ... Just as disk space was becoming cheap, Microsoft came up with this brilliant idea that we could save disk space by sharing common libraries.
Shared libraries also save memory by sharing which today is much more important than saving disk space.

If you have two apps running at the same time that use the same version of the same DLL. In any case, RAM is getting cheaper, too.

Can you assume that the DLL is always upward compatible?
If the major version number matches, it should be (otherwise bug). So you can overwrite a library on minor upgrades, but install major upgrades side by side the old version.

Does it say somewhere in the DLL spec that minor versions must be upward compatible? Maybe so, I don't know. Do all software developers follow this rule? You casually say "otherwise bug". Umm, yeah. Can you guarantee me 100% that no program that uses a given DLL relies on behavior that is changed, intentionally or not, with a new version? Because if not, then I could install app A, it appears to work fine for years and years, then I install app B which has no obvious relation to app A (as far as the user is concerned), and suddenly A quits working. That has happenned to me, and in at least one case I tracked it down to an incompatible DLL. Maybe the developer screwed up, but that's my point. Installing app B can make app A fail. That is VERY mysterious to the user and difficult to track down.

In any case, it appears your answer is: Generally no, you can't assume upward compatibility, and so you have to maintain multiple versions. At which point, what have you gained over just letting each app keep its own copy of a library and forget this DLL stuff?

If an app that uses a DLL is uninstalled, can you delete the DLL? What if there are other apps installed that use it? How do you keep track of what DLLs an app uses? Etc etc.
Package dependencies, autoremove, etc etc.

Which sound great but are not simple nor entirely reliable. Have you never had a case where an app that used to work suddenly failed because of a missing DLL, or where DLLs have been left behind after you deleted an app?

I know it's below you, but sometimes by looking elsewhere to find that all those "hard problems" have long been solved you may actually learn something.

Oh brother. I know it's below you, but if you come down from the ivory tower and visit the real world now and then you may actually learn something. Ever hear the slogan, "That's great in theory, but it doesn't work in practice"? To say that a solution will work as long as no one writes code that has bugs in practice means that the solution does not work.

2013-01-07 Reply Admin

Ted:
fjf:
jay:
Of course that creates a ton of problems (or at least 625 pounds of problems), like, How do you deal with multiple versions of a DLL?
Perhaps like every Unix system out there?
Now I'll be the first to bash MS when appropriate, but yes, most every OS has this jumble-of-files-everywhere concept. It is as though "executables need to go here, and libraries here" in other words the file type information is stored in the file's unique identifier rather than in a separate attribute as anyone who's studied data design knows to do.

Sure. It's not just Windows that throws files everywhere, Unix/Linux do too. I wasn't bashing Windows per se. I'm an equal opportunity basher.

2013-01-07 Reply Admin

fjf:
Haven't we had this discussion some weeks ago? AFAIR, the issues mentioned back then (like multiple file with the same (base) name) haven't been solved (rather than waved away) by the proponents of your way.
Here's two more issues:

Searching speed. This in particular affects the (main) executables. When the user types "foo", the traditional Unix (and, as I gather, also Windows) approach only has to search in a few directories (/usr/bin etc. on Unix). When each packages installs their binaries in their own place, it has to search all of them.

Heterogeneous networks: Though surely not as important anymore today, this is one of the classic reasons for the Unix file system design: Architecture-independent stuff (documentation, data) goes under /usr/share, so they can be shared on a network, whereas /usr/bin, /usr/lib etc. can only be shared across machines of the same architecture.

Search speed: That depends on how you search for executables. In Windows and Linux GUIs, you don't type in an app name and the OS searches a couple of directories for it. You have icons or shortcuts for all your apps that include the full path to the executable. There is no search so it's a non-issue.

IMHO, each app should have its own directory. Then have one central, shared place where we list all the apps, that would basically have just an app name, the path to the executable, and a path to an icon. I think that would be it. Maybe some security-related info or some such. So yes, an install would have to update that central list. But that would be far simpler than the many places that an install updates today.

For GUIs, we'd then read that list and display the list of installed apps, just like Windows does now using the registry. For command-line, there'd be one place to search.

RE networks: Sure, some files should be accessible to anyone and others only to certain users. But it's hard to see why some pieces of a single app need to be available to different users than other pieces. Why would someone need to access the documentation for an app if they can't run the app? Okay, we might have a single copy of an app on a server but users each have their own data and can't see each other's. In those cases, the executables would have to be separate from the data. Actually I think that would often be the case. For almost any app, I might well want to have multiple sets of data. Like for an accounting program, we might have separate databases for different divisions. And certainly for a word processing program, we wouldn't say that you can only have one document, or that all users must keep all their documents in a single directory. So yes, I'd separate code from end-user data. But I wouldn't separate main executable from libraries from help screens from configuration data from preferences etc etc.

2013-01-07 Reply Admin

Kwpolska:
"I was going to uninstall some old programs and found this calculation error," wrote Daniel Dugger, "I don't know who to blame here - Altium or Microsoft?"
Probably Microsoft.

You apparently didn't read that article well enough: Windows doing the searching only occurs if the application didn't provide the EstimatedSize hint. There's even a note at the end that says "For some reason, a lot of people who link to this page fail to notice that little detail"!

In 2004, when that blog entry was written, you might have had a point. But assuming that the software has been updated in the last, I dunno, decade, it cleans MS's hands.

(Even ignoring that objection, I think it's more likely that the installer screwed up the EstimatedSize hint [Altium's fault] than it is that Windows is calculating the directory size incorrectly.)

2013-01-07 Reply Admin

jay:
fjf:
jay:
And this whole idea of DLLs ... Just as disk space was becoming cheap, Microsoft came up with this brilliant idea that we could save disk space by sharing common libraries.
Shared libraries also save memory by sharing which today is much more important than saving disk space.

If you have two apps running at the same time that use the same version of the same DLL.

Which is the case for the vast majority of libraries in my system.

Can you assume that the DLL is always upward compatible?
If the major version number matches, it should be (otherwise bug). So you can overwrite a library on minor upgrades, but install major upgrades side by side the old version.

Does it say somewhere in the DLL spec that minor versions must be upward compatible? Maybe so, I don't know.

Note I was talking about Unix (in particular Linux) where this is indeed the rule for shared libraries. For Windows DLLs it might not be so which is part of the problem.

Do all software developers follow this rule? You casually say "otherwise bug". Umm, yeah. Can you guarantee me 100% that no program that uses a given DLL relies on behavior that is changed, intentionally or not, with a new version? Because if not, then I could install app A, it appears to work fine for years and years, then I install app B which has no obvious relation to app A (as far as the user is concerned), and suddenly A quits working. That has happenned to me, and in at least one case I tracked it down to an incompatible DLL. Maybe the developer screwed up, but that's my point. Installing app B can make app A fail. That is VERY mysterious to the user and difficult to track down.

Can you guarantee me 100% that programmers do not make other kinds of mistakes? Of course not. And programs can (and do) fail for many apparently strange reasons all the time. The lesson to be learnt is to fix the bugs. Of course, this may be a strange idea under Windows where people keep scanning for viruses that exploit long known vulnerabilities again and again instead of MS fixing those vulnerabilities once ...

In any case, it appears your answer is: Generally no, you can't assume upward compatibility, and so you have to maintain multiple versions. At which point, what have you gained over just letting each app keep its own copy of a library and forget this DLL stuff?

As I said, only major versions need to be kept. On my system, there's perhaps two major versions of <5% of all libraries and one for all others. Compared to having dozens of versions of each library, what have I gained? Well ...

If an app that uses a DLL is uninstalled, can you delete the DLL? What if there are other apps installed that use it? How do you keep track of what DLLs an app uses? Etc etc.
Package dependencies, autoremove, etc etc.

Which sound great but are not simple nor entirely reliable. Have you never had a case where an app that used to work suddenly failed because of a missing DLL, or where DLLs have been left behind after you deleted an app?

Not that I remember (again, with Unix shared libraries rather than Windows DLLs). And if I ever did, in the first case I'd just reinstall the missing library (since the error message tells me which library it's missing, this is not too hard), in the second case I probably wouldn't notice, but if I did, I could always uninstall it by hand. (And a left behind library just occupies a litte disk space, which is cheap indeed, doesn't use any RAM, so is much more harmless than many redundant copies. I.e., the hypothetical problem in my case is still better than your "solution".)

I know it's below you, but sometimes by looking elsewhere to find that all those "hard problems" have long been solved you may actually learn something.

Oh brother. I know it's below you, but if you come down from the ivory tower and visit the real world now and then you may actually learn something. Ever hear the slogan, "That's great in theory, but it doesn't work in practice"?

Newsflash, I am in the real world, and it works for me.

To say that a solution will work as long as no one writes code that has bugs in practice means that the solution does not work.

OK, anything can fail if you assume there can be arbitrary bugs. So in your world, nothing ever works. Thanks, but I prefer to stay in my world where things do work.

Not the Sharpest Blade in the Data Center

Leave a comment on “Not the Sharpest Blade in the Data Center”