Not the Sharpest Blade in the Data Center

« Return to Article
  • Sehe 2013-01-04 06:07
    The 1.5TB make perfect sense. You know, BTFS supports sparse files since... forever.

    Also, compression can make a difference :)
  • russ0519 2013-01-04 06:22
    Check number is 42, so the rest of the check makes sense.
  • Rodnas 2013-01-04 06:28
    Of course if you have check #42, a freak wormhole opens and you are transported to the restaurant at the end of the universe. So, the tax rate seems normal to me.
  • Not sharp 2013-01-04 06:48
    Can someone explain no. 1?
  • GettinSadda 2013-01-04 06:51
    Of course if you have check #42, a freak wormhole opens and you are transported to the restaurant at the end of the universe. So, the tax rate seems normal to me.

    http://www.urbandictionary.com/define.php?term=Bistromathematics
  • dkf 2013-01-04 06:51
    Not sharp:
    Can someone explain no. 1?
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  • 50% Opacity 2013-01-04 06:51
    Lorem ipsum dolor sit amet.

    Hope that helps.
  • MiffTheFox 2013-01-04 06:54
    That's probably the most meta placeholder text I've ever seen.
  • campino 2013-01-04 06:57
    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?
  • Roby McAndrew 2013-01-04 07:09
    Not sharp:
    Can someone explain no. 1?


    I believe no.4 is an adequate explanation.
  • Herwig 2013-01-04 07:16
    N°1 stole the content of my personal web page
    Soso aber auch...
  • JamMule 2013-01-04 07:18
    Please note: do not use the browser back button to navigate


    Now that is a larger WTF than all the years...
  • faoileag 2013-01-04 07:20
    Back in the olden days when OS/3 Warp came out, I upgraded my pc with a 2x CDROM drive, because otherwise you would get the software in the form of a leporello with 22 3.5" floppy discs. I shudder trying to imagine on how many DVDs Altium Designer Release 10 ships, if the installation ends up consuming 1.5 TB... or do you just simply let a network install run while spending a week on Hawai?
  • Bill 2013-01-04 07:29
    JamMule:
    Please note: do not use the browser back button to navigate

    Now that is a larger WTF than all the years...
    So true. Browser back button breakers should be brutally brow beaten before being buried alive.
  • Guest 2013-01-04 07:43
    I don't get the 232 GB problem. At most its a rounding error, though it could have been simply rounded-down or having used a bankers-rounding.

    Oh yeah, the value is a result of dividing by a computer GB (1024^3 , GiB), not a manufacturers GB (10^9).
  • EvilSpudBoy 2013-01-04 07:49
    The real WTF is that the crab roll is 3.95 and the salad is 14.95
  • ggeens 2013-01-04 07:58
    Rodnas:
    Of course if you have check #42, a freak wormhole opens and you are transported to the restaurant at the end of the universe. So, the tax rate seems normal to me.


    Bistromathics in action!
  • wood 2013-01-04 09:03
    That's what I came here to say ... 14.95 for a house salad!!! That's TRWTF.
  • Steve The Cynic 2013-01-04 09:09
    Guest:
    I don't get the 232 GB problem. At most its a rounding error, though it could have been simply rounded-down or having used a bankers-rounding.

    Oh yeah, the value is a result of dividing by a computer GB (1024^3 , GiB), not a manufacturers GB (10^9).

    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?
  • urza9814 2013-01-04 09:11
    Guest:
    I don't get the 232 GB problem. At most its a rounding error, though it could have been simply rounded-down or having used a bankers-rounding.

    Oh yeah, the value is a result of dividing by a computer GB (1024^3 , GiB), not a manufacturers GB (10^9).


    You missed the WTF. The WTF is that there's apparently a 1.4TB software package installed on that 232GB drive.
  • ¯\(°_o)/¯ I DUNNO LOL 2013-01-04 09:15
    Gene Hoont would have none of this poofter Windows bollocks! He'd be sure to smash the heads of whatever pansy is responsible for this, and maybe plant some droogs on 'em too!
  • Andrew 2013-01-04 09:15
    I'm sure that Josip's error message violates several error message writing conventios.
  • dude 2013-01-04 09:21
    I think it is impressive that he carries nearly 15 million in cash. Would that even fit in a briefcase?
  • Zagyg 2013-01-04 09:28
    "This is the first time that I have every left the USA, seeing this did not leave me with any comfort," writes Jared.


    First time out the US and you end up in Manchester? You poor bastard ;)
  • anon 2013-01-04 09:29
    In AD 2101... WAR WAS BEGINNING
  • anon 2013-01-04 09:39
    Lorizzle ipsizzle dolor crackalackin amizzle, shut the shizzle up adipiscing elit. Nullizzle mammasay mammasa mamma oo sa velit, rizzle volutpizzle, suscipit quis, gravida vizzle, arcu. Pellentesque eget crazy. Uhuh ... yih! erizzle. Fusce at ma nizzle dapibus brizzle tempizzle sure. Maurizzle mofo nibh shiz crackalackin. Black in tortizzle. Pellentesque eleifend rhoncizzle my shizz. In hac habitasse platea dictumst. Ma nizzle dapibizzle. Yo bling bling pimpin', pretizzle boofron, ac, eleifend dizzle, nunc. Dang boofron. Things sempizzle velizzle sizzle daahng dawg.
  • Ben Jammin 2013-01-04 09:47
    dude:
    I think it is impressive that he carries nearly 15 million in cash. Would that even fit in a briefcase?

    He has a backpack full of gold bars
  • campkev 2013-01-04 09:47
    If you pay fifteen bucks for a house salad, you deserve to pay that much in "stupid tax".
  • pencilcase 2013-01-04 10:07
    "This is the first time that I have every left the USA, seeing this did not leave me with any comfort," writes Jared.


    Greater Manchester Police have a computer??!!! When did that happen?
  • Anonymous Bob 2013-01-04 10:31
    Ben Jammin:
    dude:
    I think it is impressive that he carries nearly 15 million in cash. Would that even fit in a briefcase?

    He has a backpack full of gold bars


    At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
  • dkf 2013-01-04 10:41
    Anonymous Bob:
    Ben Jammin:
    dude:
    I think it is impressive that he carries nearly 15 million in cash. Would that even fit in a briefcase?
    He has a backpack full of gold bars
    At today's price ($1645.45 / troy ounce) that's a little over 625 POUNDS of gold.
    Which is just a bit under 15 liters of gold if I've got my conversions right, so yes, a fairly small backpack full.

    Bearer bonds are much more convenient after all…
  • Svensson 2013-01-04 10:59
    aptent:

    Lorem ipsum dolor sit amet consectetuer dis Pellentesque Nunc eget eleifend. Lorem dui mauris auctor convallis ligula quis vitae lacinia ut Nunc. Habitasse non iaculis Pellentesque In Suspendisse tincidunt accumsan Cum pede auctor. Elit penatibus ac turpis eros Nunc nibh lacinia tincidunt Phasellus In. ...


    Makes sense up to the last paragraph:


    Justo urna urna In tellus nunc Aliquam netus pede laoreet id. Felis augue Vivamus Pellentesque arcu velit Nulla consequat est Fusce augue.


    but then you lost me. Could you clarify?
  • aptent 2013-01-04 11:16
    Svensson:
    aptent:

    Lorem ipsum dolor sit amet consectetuer dis Pellentesque Nunc eget eleifend. Lorem dui mauris auctor convallis ligula quis vitae lacinia ut Nunc. Habitasse non iaculis Pellentesque In Suspendisse tincidunt accumsan Cum pede auctor. Elit penatibus ac turpis eros Nunc nibh lacinia tincidunt Phasellus In. ...


    Makes sense up to the last paragraph:


    Justo urna urna In tellus nunc Aliquam netus pede laoreet id. Felis augue Vivamus Pellentesque arcu velit Nulla consequat est Fusce augue.


    but then you lost me. Could you clarify?


    If you can solve the riddle, you will know where the gold is hided.
  • Spewin Coffee 2013-01-04 11:25
    If the answer to the meaning of life is 42, then the answer to the meaning of death must be 14817804.04
  • HowItWorks 2013-01-04 11:36
    Ben Jammin:
    dude:
    I think it is impressive that he carries nearly 15 million in cash. Would that even fit in a briefcase?

    He has a backpack full of gold bars

    Or a $100Trillion note (https://en.wikipedia.org/wiki/Zimbabwean_dollar#Second_Redenomination:_Introduction_of_the_third_dollar_.28ZWR.29) and he will get change back, hopefully in gold.

    (apologies about not getting linked url)
  • emurphy 2013-01-04 11:50
    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?


    Ask the folks at table #0, they may have some useful suggestions.
  • PseudoBovine 2013-01-04 11:52
    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."

  • Paul Neumann 2013-01-04 11:54
    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."
  • Guest 2013-01-04 11:56
    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.
  • Grzechooo 2013-01-04 12:11
    TRWTF is writing the application size to the registry, and that's one of the "side effects".

    Captcha - tation - a s-less station.
  • Jeff 2013-01-04 12:13
    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.
    Dude! Your computer can't handle a 625 pixel wide image? It can't even zoom?? Such technical weakness boggles the mind... (checking calendar... nope, not 1993.)

    Oh, maybe you're one of those people who got a "phone" that does everything but make calls. In that case, a pox on you and all your house.
  • bye 2013-01-04 12:14
    Grzechooo:
    TRWTF is the registry
    FTFY.
  • Priest 2013-01-04 12:17
    Grzechooo:
    Bless you.
  • Paul Neumann 2013-01-04 12:21
    dkf:
    Which is just a bit under 15 liters of gold if I've got my conversions right, so yes, a fairly small backpack full.
    Using my previous calculations would indicate 134.6 liters, so a bit of a larger of a backpack.
    Bearer bonds are much more convenient after all…
    Agreed :)
  • Evan 2013-01-04 12:27
    Grzechooo:
    TRWTF is writing the application size to the registry, and that's one of the "side effects".
    It's really not...

    How would you do it? You "can't" just have Windows go out and calculate it, because where would it look? The installer would have to write a list of every file that it installs (just the directory is insufficient), then Windows would have to go and stat that file. I addition to being more work and more fragile, it'd be incredibly slow.
  • noOne 2013-01-04 12:27
    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
  • Steve 2013-01-04 12:28
    'Allo allo allo, what's all this then? Start Windows normally? You're nicked, mate.
  • Spewin Coffee 2013-01-04 12:38
    "Welcome to www.seeedy.com. We hope you enjoy your short, but pleasant stay."
  • D E 2013-01-04 12:43
    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.
  • Ted 2013-01-04 12:47
    Evan:
    Grzechooo:
    TRWTF is writing the application size to the registry, and that's one of the "side effects".
    It's really not...

    How would you do it? You "can't" just have Windows go out and calculate it, because where would it look? The installer would have to write a list of every file that it installs (just the directory is insufficient), then Windows would have to go and stat that file. I addition to being more work and more fragile, it'd be incredibly slow.
    (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.
  • Nik 2013-01-04 12:55
    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
  • Paul Neumann 2013-01-04 12:56
    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.
  • Nik 2013-01-04 12:58
    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.
  • Evan 2013-01-04 13:01
    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.
  • jay 2013-01-04 13:15
    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.

  • jay 2013-01-04 13:21
    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.
  • jay 2013-01-04 13:24
    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
  • Evan 2013-01-04 13:24
    jay:
    On the serious side: Does NTFS support sparse files?

    Yes.

    (Lovely spam, wonderful spam!)
  • Jeff 2013-01-04 13:34
    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.
  • fjf 2013-01-04 13:46
    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.
  • Capitalist 2013-01-04 13:49
    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!
  • Capitalist 2013-01-04 13:51
    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!
  • Ted 2013-01-04 14:01
    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!
  • fjf 2013-01-04 14:10
    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.
  • Worf 2013-01-04 14:42
    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.
  • Mr Minitel 2013-01-04 15:38
    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?

  • Micah 2013-01-04 15:46
    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: ...
  • Chuck 2013-01-04 15:54
    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!
  • Anonymous Bob 2013-01-04 16:33
    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.
  • Anonymous Bob 2013-01-04 16:42
    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.
  • Anonymous Bob 2013-01-04 16:45
    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.
  • Anonymous Bob 2013-01-04 16:48
    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!
  • Paul Neumann 2013-01-04 17:26
    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?
  • fjf 2013-01-04 17:45
    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.
  • instigator 2013-01-04 18:10
    It just compresses very efficiently.
  • Paul Neumann 2013-01-04 19:00
    Paul Neumann:
    Apparently some people missed the second image?
    Strike on me.
  • Me 2013-01-04 20:43
    On TDWTF, an order of magnitude is not significant.
  • Me 2013-01-04 20:44
    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.
  • Guest 2013-01-04 20:44
    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.
  • Norman Diamond 2013-01-04 21:09
    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.
  • Norman Diamond 2013-01-04 21:23
    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 22:20
    Guest:
    Not everyone has eyes of a 16-year old.
    I have.

    They're in that jar that's holding the door open.
  • Gunslinger 2013-01-05 03:28
    If someone is willing to pay $15 for a salad, they deserve to be taxed like that.
  • AdT 2013-01-05 05:11
    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 09:09
    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.
  • Dave 2013-01-05 09:38
    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.
  • Capitalist 2013-01-05 12:55
    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 13:10
    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?
  • chris 2013-01-05 17:27
    "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 09:27
    "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.
  • freibooter 2013-01-06 19:32
    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.
  • Billy G 2013-01-06 19:59
    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
  • Meep 2013-01-07 07:16
    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.
  • Paul 2013-01-07 08:43
    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
  • Paul 2013-01-07 08:46
    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

  • jay 2013-01-07 11:12
    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.
  • jay 2013-01-07 11:17
    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.
  • jay 2013-01-07 11:40
    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.
  • Evan 2013-01-07 12:27
    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.)
  • Capitalist 2013-01-07 14:36
    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.
  • Capitalist 2013-01-07 14:56
    jay:
    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.
    Oh yeah, and all scripts include the full path to all programs used (and the path may include version numbers, may be translates or arbitrarily renamed by the user). That would be fun.
    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.
    Even the latter bit is doubtful. For an (un)installer it's generally easier to place/remove a file in a unique location (/usr/bin/foo) than adding removing an entry in a central list which at least involved some amount of locking and synchronization. In fact, most Linux distributions have broken up many files in /etc which would have to be writable by different package installations into directories. E.g., instead of a single crontab that every package that needs a cronjob writes itself into (and removes itself from when uninstalled), there's now a directory where each package that need it creates/removes a file with a unique name (usually the package name).
    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?
    That's not really what I said, read it again. E.g., take an application, perhaps a flight simulator, with a relatively small executable but huge amounts of data that you want to use on a heterogeneous network, i.e. a network of different architectures, let's say they're diskless machines with a central file server. You'd want to share the data for all the machines, but need different executables for the different architectures. With the "classical" directory layout, that's easy: have /usr/share shared, and a different /usr/bin and /usr/lib for each architecture.
    But I wouldn't separate main executable from libraries from help screens from configuration data from preferences etc etc.
    This wasn't about separating executables from libraries (the reason to separate them is searching, you don't want to search all libraries when searching an executable), but separating help texts like other data, as I described. Configuration data and preferences are generally per-user and therefore separate anyway.
  • Norman Diamond 2013-01-07 18:33
    Meep:
    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.
    I like the fact that an idiot who complains about idiots who are pedantic and completely wrong is pedantic and completely wrong. In case you didn't previously know that gold ounces and pounds are troy, how many comments have already been posted to teach you? It's about 750 pounds.
  • Norman Diamond 2013-01-07 18:38
    jay:
    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.
    What? You can be an equal opportunity basher on Linux, but until it gets ported to Windows you have to be an equal opportunity PowerSheller.
  • jay 2013-01-08 15:22
    Capitalist:
    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. ... 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.


    My point is that there is a vast difference between these two scenarios:

    Scenario 1: I install app A. It works fine. Six months later I install app B. It fails.

    Scenario 2: I install app A. It works fine. Six months later I install app B. App B works fine, but now app A fails.

    If an app fails, the reasonable thing to do is to look for a bug IN THAT APP. To say that any time an app fails you have to look at all the apps on your system to see what damage one app might have done to an unrelated app creates a nightmare scenario. It's often tough enough to track down a bug in an app. Never mind trying to track down a bug when it could be caused by seemingly-unrelated apps anywhere on your computer.

    Suppose I install app A, which happens to be my year-end account reconciliation program. Then six months later I install app B. App B replaces a DLL used by App A. But I don't try to run app A again for another six months, until the next year-end cycle hits. And then it fails. How in the world can I figure out that the problem was that app B trashed one of his DLLs?

    I had a case once where an app trashed another app's DLL. And I was lucky that I happened to run the victim app the day before installing the new app and again the day after, so I at least could say, Hey, what changed yesterday? But if there had been a long gap in there? How would I know?

    I would think the goal should be to contain the damage that any error can cause.
  • jay 2013-01-08 15:42
    [quote user="Capitalist"][quote user="jay"]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.[/quote]Oh yeah, and all scripts include the full path to all programs used (and the path may include version numbers, may be translates or arbitrarily renamed by the user). That would be fun.[/quote]

    You do NOT specify a full path for every file you reference in a script, either at each reference, or by setting appropriate paths or shell variables? Wow, I always do. Otherwise you run the risk of other apps creating files that coincidentally have the same name as yours and suddenly your script stops working.

    [quote][quote]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.[/quote]

    Even the latter bit is doubtful. For an (un)installer it's generally easier to place/remove a file in a unique location (/usr/bin/foo) than adding removing an entry in a central list which at least involved some amount of locking and synchronization. In fact, most Linux distributions have broken up many files in /etc which would have to be writable by different package installations into directories. E.g., instead of a single crontab that every package that needs a cronjob writes itself into (and removes itself from when uninstalled), there's now a directory where each package that need it creates/removes a file with a unique name (usually the package name).
    [quote]

    That depends on how the central list is managed. Sure, if it's a flat file and each installer updates the flat file however it pleases you'd create the danger that two installs could collide or an install with a bug could trash the list. But I can think of numerous ways to handle it cleanly. It could be a directory into which each install drops a file with the metadata for that app. That would create no issues that do not exist now. If it's a single file there could be system calls to update it. Windows 3.1 did that with a flat file; current versions of Windows do that with the Registry. Either way, the OS is then responsible for handling locking, queuing, whatever, and there's one place to manage to make sure that is done right.

    [quote][quote]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?[/quote]

    That's not really what I said, read it again. E.g., take an application, perhaps a flight simulator, with a relatively small executable but huge amounts of data that you want to use on a heterogeneous network, i.e. a network of different architectures, let's say they're diskless machines with a central file server. You'd want to share the data for all the machines, but need different executables for the different architectures. With the "classical" directory layout, that's easy: have /usr/share shared, and a different /usr/bin and /usr/lib for each architecture.[/quote]

    Oh, sorry, yes, I missed your main point. But in any case, I agree that we routinely need to separate code from data for a variety of reasons: The same app will often run against different data files, and we might want to run the same data through different apps. Today I want to process my source code with a text editor, tomorrow I want to run it through the compiler, the next day I want to run a search program against it. We can't assume that there is a one-to-one relationship between code and data. So yes, apps from different architectures might want to access the same data.

    I guess I can imagine cases where you could have a Linux version of an app and a Windows version of the same app, and you want them to share help screens or configuration files or some such. But I think that would be a fairly rare case. I'd want to allow for it, but I don't see designing your structure around that odd case when it makes the normal case complicated. Let the odd case be complicated.
  • jay 2013-01-08 15:42
    Bummer, I apparently messed up matching the quote tags in my previous post. Sorry.
  • Norman Diamond 2013-01-08 18:32
    jay:
    Bummer, I apparently messed up matching the quote tags in my previous post. Sorry.
    Now you know why there's a Preview button next to the Submit button. However, I don't know why there's a Submit button next to the Preview button.
  • Bill C. 2013-01-08 18:35
    Hey, me too. I wouldn't dream of asking someone to submit without getting a preview.

    Captcha: inhibeo. Wrong, TDWTF, wrong. Not me.
  • bridget99 2013-01-08 19:44
    There's no surer sign of a feeble mind than that "Lorem Ipsum" crap.
  • bridget99 2013-01-08 20:24
    Evan:
    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).


    I'm not convinced. You admitted the stupidity of such a scheme in your post. I already knew that just randomly making registry keys / folders all over the place, maybe registering some COM objects, etc. was a stupid application install strategy. Don't tell me it makes sense. Yeah, some shit would have to change to do things correctly, i.e. within a single folder in the file system... these things _should_ change, then.

    There are general-purpose OSes that work this way. I think Apple uses this installation strategy for its desktop computers.

    Evan:
    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.


    You're assuming way too much. I wrote an uninstaller once. It was for a commercial product. It didn't do any of the crap you're describing. It did a deltree... maybe. I'm not sure my uninstaller did anything but just spin the progress bar in the user's face for a few minutes. Why would I have wasted my time writing what you describe? The only reason I would ever have wanted to facilitate uninstallation would have been to reinstall our product... some IT types seem to think that uninstall/reinstall is a good approach. So, I just made the uninstall process do nothing, and made the installation process repeatable ad infinitum. This way, if the tech forgets his precious uninstall, it's no issue. This was the best design from my employer's standpoint.

    Evan:

    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.


    I don't think there's a great answer to this design problem. So, the best design is to add shit up as needed.
  • Neil 2013-01-09 11:11
    Norman Diamond:
    jay:
    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.
    What? You can be an equal opportunity basher on Linux, but until it gets ported to Windows you have to be an equal opportunity PowerSheller.
    Just how many ports do you need? I only know of four: WinBash, MSYS, CygWin and Interix.
  • Nagesh 2013-01-09 15:05
    Norman Diamond:
    jay:
    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.
    What? You can be an equal opportunity basher on Linux, but until it gets ported to Windows you have to be an equal opportunity PowerSheller.


    Is this some puny example?
  • no laughing matter 2013-01-09 15:19
    Josip Medved:
    It's important to have minimum of zero characters for State field. We don't want our database to store negative character counts, do we?
    The requirement is not about the State field. The box states clearly:
    Seeed:
    Your state must contain a minimum of 0 characters.

    So it appears you are coming from a very deserted place!