• (cs) in reply to Drak

    Drak:
    Normal form is fixing the database schema to be how you should have designed it in the first place.
    I must honestly say that I forgot totally everything about designing a database the moment I left school to go to work. I did like the classes though, but can't remember one single bit about what I learnt.

    I didn't take a database course which discussed NF until my Masters degree, after some time working in the field.  I learned that every database I'd ever designed have been in 3NF from the start.   I had a lot of trouble with the exercises in class, which would give you a badly designed database, and than ask you to put in into 1NF.  I would immediately put it into 3NF.  ("But why would you want me to fix it wrong?")

  • (cs) in reply to tufty

    tufty:
    Doesn't that somewhat defeat the object of having shared libraries?

    Shared libraries don't really exist in .NET, unless they're in the GAC.  Of course, multiple apps can use their own copies of the same dll.  For example, log4net and SandBar are components that live in dlls deployed with the application.  If another app also wants to use those dlls, they bring along their own copies.  Since it's just a copy of the same dll, this doesn't necessarily mean code duplication.

    The only disadvantage of this is to do with the size of the dll - if 100 apps use the same one, then you need to download and store that 100 times.  The GAC gives you a way out of that, however.

    _please_ tell me that the metadata lives within or is otherwise permanently linked to the 'assembly', and not separate, in the global cache. Please tell me that. Because as described it sounds rather like a "registry for dlls" :) Simon

    Yup, this is all stored within the dll.  You can access it by looking at the file properties, or by going to C:\Windows\Assembly. (replace "windows" with "winnt" if needed).

  • (cs) in reply to johnl

    Shared libraries don't really exist in .NET, unless they're in the GAC. Of course, multiple apps can use their own copies of the same dll. For example, log4net and SandBar are components that live in dlls deployed with the application. If another app also wants to use those dlls, they bring along their own copies. Since it's just a copy of the same dll, this doesn't necessarily mean code duplication.

    Ummm. BOGGLE

    I absolutely have to be missing something here.

    Surely the point of a dynamically linked library is that it can be shared. I mean, linking dynamically as opposed to statically hits performance, so carrying around a dll so that you and only you can link to it seems insane. Just fucking link statically, surely? Assuming .net allows this, but I guess it must.

    A similar WTF exists under MacOSX / OpenStep - an app can carry its own versions of a shared framework, (or .so, if it so desires), but who would fucking want to? OSX does, to its credit, allow those libraries to be shared with other apps, but even that is a WTF - what happens if the library is actually needed by another app and you delete the container?

    And multiple copies of the same library mean duplication. by definition, as that's what a copy is. It's code duplication whichever way you cut it.

    Yup, this is all stored within the dll. You can access it by looking at the file properties, or by going to C: \Windows\Assembly. (replace "windows" with "winnt" if needed).

    Right. So the file is presumably named something like 'myfunkylibrary_v123.dll'? Otherwise I couldn't have multiple versions living in the same place, right, cause NTFS is teh suxx0r[0]? Otherwise I have to install multiple versions all over the fucking place and have a central repository that links versions to files. Maybe that's what c:\Windows\Assembly does? And if that's the case, what happens when that gets all fucked up?

    I'm sorry if I'm asking stupid questions here, I know jack shit about .NET, come from 20+ years of serious unix and mainframe development and am slightly worried that .net is based around another "registry"[1][2]. I actually fail to see, as described, how this goes any way to actually solving what is, admittedly, a difficult problem[3].

    Simon

    [0] Well, not much more so than most other filesystems, but hey. [1] A concept that sort of worked 20 years ago when I first came across it in the mainframe world, and doesn't work now [2] I could, and arguably should, google this stuff up. but I prefer to get some feedback from peple who supposedly know it.[4] [3] Speshly if you're drunk, which I am. [4] Filtering out the fanboyisms, of course.

  • (cs) in reply to Chris F
    Chris F:
    In the meanwhile, I'll use an FS that doesn't suck.
    .


    That statement incorrectly assumes that such a thing currently exists.

    But what do I know? I still think Xanadu will eventually get finished...
  • (cs) in reply to tufty

    Surely the point of a dynamically linked library is that it can be shared. I mean, linking dynamically as opposed to statically hits performance, so carrying around a dll so that you _and only you_ can link to it seems insane. Just fucking link statically, surely? Assuming .net allows this, but I guess it must.

    It's a valid point.  I don't know enough about how .NET links assemblies.  There's a reference in the assembly to dependencies, and it cries if you don't have the required files, so I suspect that, despite having multiple files, it is actually linking statically.  You can use Assembly.LoadFrom() to dynamically load an assembly.

    Why not just have everything in the one file?  I can't really say.  It doesn't bother me that much, though.

    And multiple _copies_ of the same library mean duplication. by definition, as that's what a copy is. It's code duplication whichever way you cut it.

    But you didn't need to type it twice. That's what I meant.  Code duplication (to me, anyway) is when you have to figure out how to do it, then someone else has to figure it out again, or has to copy and paste the code.  With a duplicated file, an automated build can copy the file.

    Right. So the _file_ is presumably named something like 'myfunkylibrary_v123.dll'? Otherwise I couldn't have multiple versions living in the same place, right, cause NTFS is teh suxx0r[0]? Otherwise I have to install multiple versions all over the fucking place and have a central repository that links versions to files. Maybe that's what c:\Windows\Assembly does? And if that's the case, what happens when that gets all fucked up?

    No, not quite.  The dll is still called the same thing, it's just that the filenames don't have to be unique in the GAC.  The GAC is a special folder where the normal file identification rules don't apply.

    Ok, you have myfunkylibrary.dll.  It has a version number property of 1.2.3.  You install another version, called myfunkylibrary.dll, with a version number of 1.2.4.  Because the version number property is different, the file is different and does not overwrite v1.2.3.  When your app wants v1.2.3 of the library, it specifies v1.2.3 in the reference, and gets v1.2.3.

    Actually, it's a bit more complicated than that (isn't everything) because it also takes into account public key (which I belive must be regenerated with each new version), culture (language), and so on.  It's not a registry, it's just that when Windows references files in that folder, it takes into account more than just the filename.

    When/if that all gets fucked up...  Pretty much the same thing as you always get when your machine fucks up - you go to your backups or your System Restore repository.

  • (cs) in reply to tufty

    tufty:
    Surely the point of a dynamically linked library is that it can be shared.

     I mean, linking dynamically as opposed to statically hits performance, so carrying around a dll so that you _and only you_ can link to it seems insane. Just fucking link statically, surely?

    Actually, they are (fucking) statically linked.  Remember that .Net Assemblies are made up of bytecodes, which are natively compiled & statically linked at run-time.  

    An shared libraries should be shared, but the world is filled with some very bad programmers (you need me to tell you that here?), so that AppFoo, which was written to use SharedLibV1, can't be trusted to work with SharedLibV2 (It's it's usually impossible to tell which author of which app is to blame).   That is commonly known as "DLL-Hell".

     And multiple _copies_ of the same library mean duplication. by definition, as that's what a copy is. It's code duplication whichever way you cut it.

    Yeah, and hard drives are under to a dollar a GIGABYTE. (And most .Net assemblies are under 100KB)

    So the _file_ is presumably named something like 'myfunkylibrary_v123.dll'? Otherwise I couldn't have multiple versions living in the same place, right,

    Basically, you copy version 123 of myfunkylibrary.dll to that directory, and it's automatically renamed myfunkylibrary_v123.dll.  Copy it to another directory, and it gets it's old name back.

  • (cs) in reply to JamesCurran

    Remember that .Net Assemblies are made up of bytecodes, which are natively compiled & statically linked at run-time.  

    Darn, how did I forget that?

  • (cs) in reply to johnl

    This works with plain Win32 dlls as well (C, VB, Delphi, Python, etc), it's just harder because you have to create the manifests yourself, and presumably update them every version.

    If done correctly there is no reason to worry about DLL hell, you just link to the latest version of the file that matches your specs exactly. Just update the manifest to link to a newer one.

    If you'd like to see some of this in action in XP, check out windows\winsxs, you can find the manifests and various versions of some system files in there. I don't know too much about it, just that it's a prototype for introducing the whole shebang in .Net and Vista.

    I do know that if you delete the folder (lookit all them files wastin' space!) most programs will fail with a missing gdiplus.dll error. >.>

  • (cs) in reply to JamesCurran

    Yeah, and hard drives are under to a dollar a GIGABYTE. (And most .Net assemblies are under 100KB)

    The problem is not so much with disk space, although that can be a problem, but with disambiguating at runtime. Under most systems, shared libraries get loaded once, so 2 apps using the same shared library will be sharing a copy of the code segment. This can make an enormous amount of difference to load-time performance, as well as overall memory footprint.

    Under most OSs, it's not reasonably feasible to disambiguate between multiple copies of the same file at runtime, so if app a loads libfoo from location a, and app b loads libfoo from location b, both will be loaded into memory, even if, for example, both the location a and location b versions are symlinks to a version in location c

    Of course, if .NET statically links everything at runtime, all bets are off. It just becomes a deferred loading mechanism, at least for those assemblies carried around with the app. Of course, that's going to mean that if you have 20 apps running log4net, there will be 20 instances of the log4net code floating around in memory, and the compile-link step will be carried out 20 times too.

    Basically, you copy version 123 of myfunkylibrary.dll to that directory, and it's automatically renamed myfunkylibrary_v123.dll. Copy it to another directory, and it gets it's old name back.

    Ah, okay. OS voodoo. Yes, that scares me. It seems an over-complex solution to a problem that is largely solved elsewhere. Remember, DLL hell is generally speaking only a problem on windows...

    Thanks for the explanations, though

    Simon

  • (cs) in reply to tufty

    Well, if you open up a cmd prompt, cd into that directory (c:\windows\assembly) and do use a command like tree or dir /s/b, you'll get an idea of what's going on.

  • (cs) in reply to tufty
    tufty:


    > Yeah, and hard drives are under to a dollar a GIGABYTE.
    > (And most .Net assemblies are under 100KB)

    The problem is not so much with disk space, although that can be a problem, but with disambiguating at runtime. Under most systems, shared libraries get loaded once, so 2 apps using the same shared library will be sharing a copy of the code segment. This can make an enormous amount of difference to load-time performance, as well as overall memory footprint.



    The problem is not only with space on either disk or memory, but with maintainability: Let's have 100 apps use the same Library (as already assumed above), and each app brings with it a copy of this library.

    Now they find a major security risk with that library, but lucky you they fix it in one day.

    If there were only one library, that each app references, then you were really lucky, because replace one file and everything is fixed.

    But as I understand the situation,now you will have to wait for 100 vendors to update their app or provide a patch that will replace this broken library.

    And I doubt GAC will solve this, because an app that requests version 1.2.4 (which is broken) will never see the fixed 1.2.5, so the app remains broken until the vendor will provide a patch, even though you already installed the fixed version on system.

    cu
  • (cs) in reply to foxyshadis

    This works with plain Win32 dlls as well (C, VB, Delphi, Python, etc), it's just harder because you have to create the manifests yourself, and presumably update them every version.

    Well, that's one reason why I mentioned Windows Installer - it can create the manifests for you at install-time, you just have to putall the info for the manifests in yourself.

  • (cs) in reply to johnl
    johnl:


    Chris F:
    The single most important use of symbolic links to me is their ability to abstract and maintain the integrity the filesystem.  Systems have been using them for decades to protect against incompatibilities, provide organization, centralize configuration, and relieve the stress of structural changes.  All without touching application code.


    That's a nice feature, I'll admit, but it's far from essential.  Try again.

    Uh, and where did I claim they were essential?

    johnl:

    Chris F:
    It's not my job to stroke your dimunitive imagination.  Others have given more specific demonstrations.  But a word to the wise: If a programmer thinks fundamental concepts like abstraction aren't "vitally important", I would suggest they are either seriously inexperienced or in the wrong line of work.


    Ah, the claim of the wrong.

    Me: "explain your assertions"

    You:  "I don't have to explain them!"

    It's amazing how you can call my explanations "a nice feature" in the first paragraph, and in the next you completely misrepresent my assertions as unexplained.  If you're looking for specific, concrete applications then you have deliberately ignored my statement that "others have given more specific demonstrations".  Who do you think you're convincing?

    johnl:
    Oh, and a word to the wise:  abstraction in programming is a completely different issue.

    What I'm going to write should be completely obvious, but you've missed it entirely: The concept of abstraction transcends any specific area of computer science.  Fully-featured symbolic links allow the separation of physical and logical model.  It's amazing what lengths someone will go to rationalize inferiority.
  • (cs) in reply to Chris F

    Uh, and where did I claim they were essential?

    You what?  That was the whole basis for your argument!  That NTFS sucked because it didn't have them (except it does, just not quite as funky).  If they're not essential, then your argument falls apart, because NTFS can't suck just because of that.  (See below)

    It's amazing how you can call my explanations "a nice feature" in the first paragraph, and in the next you completely misrepresent my assertions as unexplained.  If you're looking for specific, concrete applications then you have deliberately ignored my statement that "others have given more specific demonstrations".  Who do you think you're convincing?

    Who do you think you're convincing?

    There's a difference between "essential" and "a nice feature".  For example, folders are essential.  File access security is essential.  If you don't have these, then the FS sucks.  With them (as well as all other essential features), you have a workable OS.  Maybe not the best, but it doesn't suck.  Symbolic links are a nice feature, but not essential.  You were claiming they were essential, but they're not.

    Are you still confused?

    What I'm going to write should be completely obvious, but you've missed it entirely: The concept of abstraction transcends any specific area of computer science.  Fully-featured symbolic links allow the separation of physical and logical model.  It's amazing what lengths someone will go to rationalize inferiority.

    Separation isn't always desired.  In some cases it is, but not always.  In some cases it just leads to confusion.  I wonder how many people have seen symbolic links and said "hey, cool", set up millions of links to all kinds of files, and then got conused when they think a link is a copy.  I'm not saying they're harmful, but they can be if not used correctly.

    When I browse my file system, I'm not programming.  In fact, my file system should act in a similar way to a file cabinet (hence the terms "file" and "folder").  It should be simple.  Symbolic links are really for specific cases.  Windows (and *nix running KDE or Gnome or X, most likely) has enough trouble keeping application shortcuts organised, so you want to add a load more unnessecary symlinks?  No thanks.

    It's also interesting how you claim that you never said symlinks were essential, then in the next breath say they're essential, isn't it?  How am I supposed to take notice of you, when you can't even keep track of your own posts?

  • (cs) in reply to johnl
    johnl:

    For example, folders are essential.  File access security is essential.  If you don't have these, then the FS sucks.  With them (as well as all other essential features), you have a workable OS.



    Well, CP/M 68k had neither folders nor file access security (though you could hide them and make them read-only), but still it was a VERY workable OS in its time.

    Now do you still think, folders and file security are _essential_ features by your definition?

    cu
  • (cs) in reply to johnl
    johnl:
    Chris F:
    Uh, and where did I claim they were essential?

    You what?  That was the whole basis for your argument!  That NTFS sucked because it didn't have them (except it does, just not quite as funky).

    You've committed the cardinal sin of misinterpreting a subjective term.  Suck is a term relative to each individual that uses it, and its application has nothing to do with essential features.  Fuck, computers aren't essential, they just make things nicer.  That's all this is about.

    johnl:
    There's a difference between "essential" and "a nice feature".  For example, folders are essential.  File access security is essential.

    Bullshit, neither of these are essential.  People have gotten by for years without either.

    johnl:
    If you don't have these, then the FS sucks.

    I agree!

    johnl:
    You were claiming they were essential, but they're not.

    Again, bullshit.  Find this claim and quote it.  This is a bald-faced lie.

    johnl:
    Chris F:
    What I'm going to write should be completely obvious, but you've missed it entirely: The concept of abstraction transcends any specific area of computer science.  Fully-featured symbolic links allow the separation of physical and logical model.  It's amazing what lengths someone will go to rationalize inferiority.

    Separation isn't always desired.

    I neither stated nor implied that separation was always desired.  The administrator can decide if this abstraction is necessary given the featureset available to him.  Just because an administrator can create directories doesn't mean that the administrator is going to go buck-wild making directories that confuse everyone.  Don't blame the tool for your shortcomings.

    johnl:
    It's also interesting how you claim that you never said symlinks were essential, then in the next breath say they're essential, isn't it?

    Hahahahahahaha.
  • (cs) in reply to Chris F

    So when you implied (I sure hope you are not denying that you implied this?) that NTFS sucks, you weren't actually trying to imply that? Make up your goddamned mind!  Or was your original post just you being an MS-bashing troll?

    Ok, we can simplify this greatly (since you seem )

    A) Does NTFS "suck"?  No, it does not.

    B) Does NTFS have symlinks?  Yes, they're just called junctions, and admittedly not quite as funky as symlinks are on *nix.

    C) Are symlinks essential?  Nope.  They're a nice feature, nothing more.

    D) Are file-based symlinks essential?  (That is, does NTFS suck because it only links directories?)  Er, read the above.  Symlinks aren't any more than a nice feature in the first place.  They're still a nice feature even if they can only be used on directories.

    E) Is separation essential.  Hell, no, in fact if not done correctly, it can really screw things up.  Separation is great in programming, but then a file system shouldn't require programming skills. 

    Anything you disagree with here?

  • (cs) in reply to johnl
    johnl:
    So when you implied (I sure hope you are not denying that you implied this?) that NTFS sucks, you weren't actually trying to imply that?

    Can you read?  I implied that NTFS sucks with about as much grace as an elephant can figure skate.

    johnl:
    Or was your original post just you being an MS-bashing troll?

    This statement is a fallacy of induction.  I clearly bashed NTFS, not MS.  Shame on you for mistaking a company with a filesystem.

    johnl:
    B) Does NTFS have symlinks?  Yes, they're just called junctions, and admittedly not quite as funky as symlinks are on *nix.

    Yeah, you call it "funky", I call it "not crippled".  I'm sure you're very happy with your non-funky, inferior filesystem.  Oh, and symbolic links are a function of the file system not the operating system, so it is completely wrong to say "on *nix".

    johnl:
    A) Does NTFS "suck"?  No, it does not.

    johnl:
    D) Are file-based symlinks essential?  (That is, does NTFS suck because it only links directories?)

    Read my post dumbass.
    Chris F:
    Suck is a term relative to each individual that uses it, and its application has nothing to do with essential features.  Fuck, computers aren't essential, they just make things nicer.  That's all this is about.


    You know the Amish?  I think their lifestyle sucks and I can give my reasoning.  But they sure as hell don't think it sucks.  This is your #1 error throughout the misconception-laden drivel you call a post.  Your willfull misrepresentation is staggering.  You have no intellectual integrity whatsoever.
  • (cs) in reply to Chris F

    Can you read?  I implied that NTFS sucks with about as much grace as an elephant can figure skate.

    Whether you did it gracelessly or not, you made the implication.

    This statement is a fallacy of induction.  I clearly bashed NTFS, not MS.  Shame on you for mistaking a company with a filesystem.

    So you were being an NTFS-bashing troll, then?  Also, by extension, you were bashing MS, since MS produce the system.

    Oh, and symbolic links are a function of the file system not the operating system, so it is completely wrong to say "on *nix".

    *nix is the only OS that uses etc, as far as I know (does Be use it?  I don't know).  My knowledge about that is probably incomplete.  Thanks for pointing the error.

    Read my post dumbass.

    Why should I read it again?  Are you somehow able to edit your posts to make them sensible.

    You know the Amish?  I think their lifestyle sucks and I can give my reasoning

    So say "IMHO", dumbass

  • (cs) in reply to johnl

    One more thing: Chris, you seem like an otherwise intelligent person, but your posts read like something from /.

  • (cs) in reply to johnl
    johnl:
    One more thing: Chris, you seem like an otherwise intelligent person, but your posts read like something from /.


    Reading this thread, the exact same could be said of you.  People in glass houses, and all that.
  • (cs) in reply to JThelen

    I'm not pushing hate of anything.  I'm not saying "Windows sucks because it's not Linux" or anything along those lines.  So I'm not sure what you're on about.

  • (cs) in reply to johnl
    johnl:
    I'm not pushing hate of anything.  I'm not saying "Windows sucks because it's not Linux" or anything along those lines.  So I'm not sure what you're on about.


    No, but you've called him out as an idiot for having an opinion of something which clashes with your own.  That's the historical bases of many a slashdot flamefest, and your reply here to make yourself seem innocent of all wrongs is quite keeping in that.
  • (cs) in reply to JThelen

    I've done no such thing.  I never said he was an idiot (in fact, I said I thought he wasn't an idiot), and it's got nothing to do with my opinions (ok, maybe just a little - if it had been anti-Linux, I might have laughed at it).

    I had a go at him because he presented his opinion (that NTFS sucks) as a fact, citing absence of symlinks as reasoning.  Other people informed him that symlinks do exist in NTFS.  From then, he said/implied that NTFS still sucked because NTFS symlinks aren't as feature-rich as the etc ones.  I maintain that this difference does not make NTFS suck.

    It's not his opinion that got me fired up, it's the way he put it forward.

  • (cs) in reply to tufty

    um.. Do you think you could lean how to use [ quote ] tags?  When I try to post a message quoting you, your message is reformat, removing line breaks, so trying to sort out your comments from the lines you quote is rather diffcult...

    tufty:
    . Ah, okay. OS voodoo. Yes, that scares me. It seems an over-complex solution to a problem that is largely solved elsewhere.
     So, how do those other OSes do it (without using a registry-like device)

     Remember, DLL hell is generally speaking only a problem on windows...
    Nonsense.  It happens anywhere there are shared libraries.  It the effects of scale again.  95% of the computers in the world run Windows, so 95% of the shared-library problems are with Windows, with some mitigating factors which shift the appearance.  (With Macs, due to the limited app market, it's very unlikely you'll be using AppA with SharedLibraryB from different vendors;  With Linux, if AppA stops working with SharedLibraryB, the general response is : "You have the source code-- fix it yourself".)

    tuffy:
    The problem is not only with space on either disk or memory, but with maintainability: Let's have 100 apps use the same Library (as already assumed above), and each app brings with it a copy of this library.

    Now they find a major security risk with that library, but lucky you they fix it in one day.

    If there were only one library, that each app references, then you were really lucky, because replace one file and everything is fixed.

    But as I understand the situation,now you will have to wait for 100 vendors to update their app or provide a patch that will replace this broken library.

    Not quite.  Trust level is controlled by the user.  Hence those 100 apps could each request "myfunkylibrary" sans version number, and they are given v123.  When v124 come out, they could use that (you may have to copy it to every directory).  If one crashes with v124, you can say "only use v123".   If it's a high security app, the app designed can say "only run with v123", to prevent someone from hacking it by slipping a bogus v124 in.

    In .Net assemblies can be "weakly-name" (just the filename), and "strongly-name" (which includes the filename, version number, contents CRC, locale info, and, I think, and encryption key).

  • (cs) in reply to johnl
    johnl:

    I've done no such thing.  I never said he was an idiot (in fact, I said I thought he wasn't an idiot), and it's got nothing to do with my opinions (ok, maybe just a little - if it had been anti-Linux, I might have laughed at it).

    I had a go at him because he presented his opinion (that NTFS sucks) as a fact, citing absence of symlinks as reasoning.  Other people informed him that symlinks do exist in NTFS.  From then, he said/implied that NTFS still sucked because NTFS symlinks aren't as feature-rich as the etc ones.  I maintain that this difference does not make NTFS suck.

    It's not his opinion that got me fired up, it's the way he put it forward.



    At which point, I called you out for the same thing as you did him;  presenting your opinions as fact.  It's your opinion that NTFS doesn't suck because it does have the same basic features as the etc FS.  You called him out as an 'anti-MS troll' for that opinion, which had nothing to do with the issue at hand. 

    I've said it once already and feel it bears repeating;  People in glass houses should not throw stones.
  • (cs) in reply to JThelen

    @James: Who were you talking to here? Me?  I wasn't aware of any formatting problem with my posts.  I use [ quote ] tags just by typing them, which is how I thought I was supposed to use them...

    At which point, I called you out for the same thing as you did him;  presenting your opinions as fact

    Grrrr....  I don't actually think I'm guilty of this - I've never expressed my opinions, except that NTFS doesn't suck.  I take that as a fact.  I think if you say that NTFS sucks and, for example, etc doesn't, then you need to come up with real reasons why that is.  Symlinks on files as opposed to directories just isn't good enough a reason.  I take that as a fact. Maybe I am guilty as putting my opinions forward as fact, but I don't think I am, though IIRC it all started with people challenging Chris for putting his opinions forward as fact.

    You called him out as an 'anti-MS troll' for that opinion, which had nothing to do with the issue at hand. 

    Now, I do admit to that - I did call him out as an "anti-MS troll". And I still do, because he is. And it has everything to do with the issue at hand, if the issue at hand is whether NTFS sucks or not.  Admittedly, that's not the original topic of this thread.

  • (cs) in reply to johnl
    johnl:
    Grrrr....  I don't actually think I'm guilty of this - I've never expressed my opinions, except that NTFS doesn't suck.  I take that as a fact.  I think if you say that NTFS sucks and, for example, etc doesn't, then you need to come up with real reasons why that is.  Symlinks on files as opposed to directories just isn't good enough a reason.  I take that as a fact. Maybe I am guilty as putting my opinions forward as fact, but I don't think I am, though IIRC it all started with people challenging Chris for putting his opinions forward as fact.

    I thought it was obvious I was expressing an opinion: There is no objective definition of suck.  No fact you can point at and prove.  It is meant to convey emotion not logic.  Emotions which are different for everyone.

    johnl:
    Now, I do admit to that - I did call him out as an "anti-MS troll". And I still do, because he is. And it has everything to do with the issue at hand, if the issue at hand is whether NTFS sucks or not.  Admittedly, that's not the original topic of this thread.

    Are people that think WinME sucks anti-MS as well?  Are people that use slurs like "XP's fischer price theme" anti-MS?  Are people anti-MS if they hate Clippy? Are people anti-MS if they think NTFS sucks?

    No, no, no, and no.  Shades of gray.  No black and white opinions here.

    I'm not an anti-MS troll.  I think they've done a lot of great things, and .Net is currently my favored development platform.  I also think they've done a lot of stupid things, and -- like everyone else -- they deserve to get called on it.

    johnl:
    One more thing: Chris,you seem like an otherwise intelligent person, but your posts read like something from /.

    Thanks.  Sorry, I do get carried away sometimes.
  • (cs) in reply to Chris F

    All right, sorry, I get carried away soemtimes as well.  Maybe I just read (past tense) /. too much but it seems like everyone just wants to have a pop at MS.  I'm not an MS fan, really, but if they have a good product (and IMHO NTFS is a good product) then why not recognise that?  But people don't want to do that - they just want to have a pop at MS, and it really does get tiresome.

    Admittedly they have done a lot of stupid things, but no-one seems to list the stupid things that, say Apple has done, or IBM, or the Linux community.  The most annoying thing is that a person new to computing would easily get the impression that the only thing you need to do to be better than MS is to not be MS, and that when choosing a software product,  they just have to go "if it's not MS, I'll take it", rather than do an actual comparison on what the software can actually do.

    I suppose I first got annoyed when people (way back in the mists of time) tried to claim that MS distributing IE with Windows was them trying to take control of everything, but when Linux does the same thing with Konqueror, it's just providing a feature-rich OS.

    NTFS isn't perfect, but then neither is etc.

  • zorro (unregistered) in reply to johnl
    johnl:

    people (way back in the mists of time) tried to claim that MS distributing IE with Windows was them trying to take control of everything, but when Linux does the same thing with Konqueror, it's just providing a feature-rich OS.



    Well, isn't Konqueror standards compliants (as much as possible in the browser space)? Then it is understandable
    If MS ship IE with their own little changes to the standards and everyone is basically using it by default it's somewhat of a problem. Overall, the fact that this issue was looked at seriously by courts is quite telling I think.

    Peace.

      zorro.

  • (cs) in reply to johnl

    Sorry that was meant to say ext.

  • (cs) in reply to zorro

    Well, isn't Konqueror standards compliants (as much as possible in the browser space)? Then it is understandable
    If MS ship IE with their own little changes to the standards and everyone is basically using it by default it's somewhat of a problem. Overall, the fact that this issue was looked at seriously by courts is quite telling I think.

    Not really - courts respond to public opinion as much as any other government institute.  If the public opinion (rightly or wrongly) is that MS is evil, then that's what the courts will decide.

    And Konqueror isn't actually compliant any more than IE is - the difference is in bits where the standards are unclear. For example, on the subject of :hover in CSS stylesheets being supported on elements other than links, this was never (AFAIK) set in stone, it just existed as more of a proposal.

  • (cs) in reply to johnl
    johnl:
    Admittedly they have done a lot of stupid things, but no-one seems to list the stupid things that, say Apple has done, or IBM, or the Linux community.

    Sure they do, all the time.  People are constantly railing about Linux is hard to install or has bad driver support, how its user interfaces haven't been up to snuff, how one-button mice suck, etc.  There was a thread here just a little while ago where some guy with a poor head for logic inducted that Open Source was bad because of a bad Ubuntu experience.  While it's easy to point out his inductive error, I agree with the specifics of his complaints.

    johnl:
    And Konqueror isn't actually compliant any more than IE is - the difference is in bits where the standards are unclear.

    Well, I wouldn't say that.  KHTML (Konq's engine) really is more compliant than Trident (IE's engine).  Take a look at this comparison chart: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28CSS%29.

    Still, a mere chart doesn't tell us what the impact of very specific bugs are.  Some pieces are used much moreso than others, and can thus lead to significant amounts of pain.  No bug that I'm aware of has had the impact of the Internet Explorer box model bug.  This is responsible for an unbelievable number of misrendered sites.

    johnl:
    For example, on the subject of :hover in CSS stylesheets being supported on elements other than links, this was never (AFAIK) set in stone, it just existed as more of a proposal.

    The recommendation  never defines the elements to which :hover applies, but it doesn't restrict them to links specifically.  The current implementation is an extremely lazy interpretation of the text.
  • (cs) in reply to Chris F

    Sure they do, all the time.  People are constantly railing about Linux is hard to install or has bad driver support, how its user interfaces haven't been up to snuff, how one-button mice suck, etc.  There was a thread here just a little while ago where some guy with a poor head for logic inducted that Open Source was bad because of a bad Ubuntu experience.  While it's easy to point out his inductive error, I agree with the specifics of his complaints.

    A poor example, since IIRC he was verbally ripped to pieces.  That's what usually happens to people who criticise Linux on forums - they get blasted into submission.

    No bug that I'm aware of has had the impact of the <FONT color=#246398>Internet Explorer box model bug</FONT>.

    Which has been fixed.  It's also a fairly insignificant bug, resulting in slightly narrower text.  In most cases, the user probably wasn't even aware that anything was amiss.

    The recommendation  never defines the elements to which :hover applies, but it doesn't restrict them to links specifically.  The current implementation is an extremely lazy interpretation of the text.

    Why?  They've followed the spec.  In a company such as MS, programmers are practically forbidden to do anything that's not in the spec, so they were just following their development practices.  What you call lazy they call safe (since a programmer adding :hover to all elements might have caused more problems).

  • (cs) in reply to emptyset
    emptyset:
    Anonymous:

    <font face="Arial">PLEASE refrain from using that Linux-lover's pen name on this glorious website.  /. is for geeks.  TDWTF is for everyone else.</font>

    <font face="Arial">Pwnt.  Please drive through.</font>

    <font face="Courier New" size="2">what are you talking about?  /. is limbo for script kiddies.  "geek" is a wonderful label.  treat it with reverence.</font>



    Think "/." is for script kiddies?
    Go and check out comments on "digg.com"
  • (cs) in reply to johnl
    johnl:
    No bug that I'm aware of has had the impact of the <font color="#246398">Internet Explorer box model bug</font>.

    Which has been fixed.  It's also a fairly insignificant bug, resulting in slightly narrower text.  In most cases, the user probably wasn't even aware that anything was amiss.


    If you're a causual browser, I can see where you might get that idea, but if you're a web developer who's attempted to create a site that's both easier to maintain than a mess of tables and displays cross-browser reasonably well.... it's driven a few of us to funny farms and premature baldness. If it looked insignificant, that was only the patience of the web designer to work around it, because it could cause overlapping this, one-word column that, and non-wrapping paragraphs here.

    At times I wondered if I was using IE6 or IE3, some elements came out so badly.

    I'm happy that it's been largely or entirely fixed in IE7, but the last five years (and the next 2 as people slowly upgrade) have been hell for designers who want something more complex than your average MT blog - while being CSS compliant without the pandemonium of tables. And I'm one of those people who get pissed off at the constant complaining about IE.

    (Gecko and KHTML have had their share of box-model bugs crop up, as well, but rarely have they made it into release versions.)
  • (cs) in reply to JamesCurran

    JamesCurran wrote:

    um.. Do you think you could lean how to use [ quote ] tags?

    I know how to use [ quote ] tags. On all other bloody forums apart from this one. Unfortunately, this particular one doesn't like safari and won't let me quote at all. Well, it might. sometimes. if I pray to exactly the right elder gods. Sorry. You'll have to live with it or kick Alex into installing something that works.

    then I wrote:

    OS Voodoo

    then James wrote:

    So, how do those other OSes do it (without using a registry-like device)

    Using symlinks and search paths, generally. It's not perfect, but it works and has worked for a very long time.

    I appreciate that, with .NET, MS are trying to solve a problem that has never been fully fixed (although BeOS might have done a pretty good job, I can't remember the specifics under Be though).

    The problems:

    Versioning : this is actually a metadata issue; how do you represent metadata when your filesystem does not support it? unix-like systems generally use file naming and symlinks to 'latest', this is a kludge. Trust: again, this is metadata. How do you know you can trust a library? unix-like systems tend to ignore this. Java deals with it by embedding the signature.

    It seems to me that MS have tried quite hard to solve the problem, but have had to resort to a central repository approach, which is horribly hacky. Of course, without symlinks or metadata support in the filesystem(s) they couldn't do much else, I guess.

    <snip DLL hell discussion>

    Well, I was being slightly fatuous when I made the comment, but your rebuttals are wrong.

    Under any unix-like system, different versions of shared libraries can and do coexist side-by-side. Even the most horrific shared library issue I've come across (the great linux libc migration) was solvable using the 'kludgy' symlink-and-versioned-filename solution to a large extent.

    Dependency hell, that exists - installing package x requires y which requires z which requires 'a' version 123. It's a pain, but that's what packaging systems are for. But DLL hell is very very rare under unix-a-likes, and it generally only happens when you have an old package that relies on the 'latest' version of a library, where the 'latest' version of that library has moved on so far that it's no longer compatible.

    As for the "With Macs, due to the limited app market..." comment, I'm afraid you crossed my troll boundary. My mac runs apple-specific software, pretty much anything compilable under a sane unix, and all your windows stuff as well. Yeah, I feel very limited as to what apps I can run...

    The final comment was not made by me, but you have neatly bypassed or ignored the point, which was that if you have 100 apps carrying assemblies around in their own package, and one of those assemblies is found to have a hole, you have 100 places to patch, not one.

    Regards

    Simon

  • (cs) in reply to foxyshadis

    foxyshadis:
    If you're a causual browser, I can see where you might get that idea, but if you're a web developer who's attempted to create a site that's both easier to maintain than a mess of tables and displays cross-browser reasonably well....

    I'm both.  And neither.  I'm not really a web developer, though I have worked on websites, but only in support of my main role as build engineer.  But when I browse around the web (which I do a lot) I'm not thinking about HTML tags, I just want to get to a particular piece of information.  ATM, IE does that better.  I find it strange that I should care about what HTML tags make up a page when all I want to do is read the information (which could be anything from a news article to bus timetables to game reviews to online manuals).  It'd be like watching news on the TV and complaining that the newscaster's suit is the wrong colour.  If the site didn't work, then I might care, but it usually does, and better in IE than in Firefox.

    I have also experienced situations in development where Firefox didn't work and IE did.  There was a case where a change control document in XML format had to have an XSL transform applied so that it was readable in a report-style format.  In IE, everything worked fine, but in FF, a horizontal line (I think it was actually a <p> tag with the background colour set to dark blue, but I can't quite remember) always appeared really thick, and none of the columns would actually line up.  It was like it was constantly resizing everything to fit the text, whereas IE just displayed it all nice and neat.  I tried changing the height of the horizontal line, but to no avail.

    My guess is that in FF the <p> tag has a minimum height.  AFAIK, that's not in the spec.

  • (cs) in reply to tufty

    tufty:
    I know how to use [ quote ] tags. On all other bloody forums apart from this one. Unfortunately, this particular one doesn't like safari and won't let me quote at all.
    Huh?  You are quoting text.  You prepend each quoted line with ">>".  I'm just saying stop typing ">>" on each line, and start typing "[ quote ]" & "[ /quote ]" around the paragraph.   WTF does your browser choice have to do with that?

    As for the "With Macs, due to the limited app market..." comment, I'm afraid you crossed my troll boundary. My mac runs apple-specific software, pretty much anything compilable under a sane unix, and all your windows stuff as well. Yeah, I feel _very_ limited as to what apps I can run...
      True, but total irrelevant.  We were talking about how various OSes deal with shared libraries, so the "app market" in question here are those written specifically for Macs, using the Apple-designed shared-library resolution procedure.  And while Mac-ist will proclaim that they have every app category covered with two or three native choices--generally from major firms, Windows users generally have 20-30 choices in each category--many from smaller companies. Hence "limited app market".  The entire shared-app question revolved around interaction of many divergent applications.

  • (cs) in reply to JamesCurran

    Chris F and johnl, u two are the biggest bunch of users I have seen in a long time. Get a life.

  • (cs) in reply to AndrewVos

    *losers

  • (cs) in reply to AndrewVos

    Just because we like having a discussion?  I'm glad I at least have something I give a rat's arse about.  I pity you, I really do.

  • (cs) in reply to AndrewVos
    AndrewVos:
    Chris F and johnl, u two are the biggest bunch of users I have seen in a long time. Get a life.

    [:'(] Waaaaaaaah people aren't spending their time the way I want them too waaaaaaah [:'(]
  • (cs) in reply to Chris F

    Chris F:
    AndrewVos:
    Chris F and johnl, u two are the biggest bunch of users I have seen in a long time. Get a life.

    [:'(] Waaaaaaaah people aren't spending their time the way I want them too waaaaaaah [:'(]

    Nice rewording...

Leave a comment on “tblCalendar”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article