I'd have preferred XML to this. Even with XSLT.



  • We sell a medium to largish software product written in C++ with Qt. Or to be more honest we sell computers with our software product manually configured by the software developers on it. The computers run a fairly old version of Debian Linux.

    One of the reasons why developers need to manually configure it is that our software does not have an installer and finding out what libraries need to be installed is currently a process of trial and error. I've been pushing for a sane solution for over a year now, but this always gets pushed behind the next deadline because so much else is also wrong with the software.

    The other reason is our configuration files. While running our product, depending on configuration, consists of 10-25 processes that communicate via DBUS. For each of those processes there is an executable and a configuration file. So if you for example need to set an IP address for something you get to search the configuration files to find the right one. I'll now list some of the things about this that made me go WTF:

    • Some of the values are duplicated in multiple files.
    • The configuration files live in their own folder and for legacy reasons their filenames start with a dot, which means that linux treats them as hidden files.
    • They use a home-grown format implemented in extremely ugly code and with some odd features (see below)
    • We have a "configuration tool" that just shows the contents of each file in a tab with a text input field for each possible value.
    • Some executables read from other executables' configuration files instead of just their own.
    • Naming of the configuration files is inconsistent with the naming of the executables.
    • One of the executables has recently been renamed. It's configuration was half-renamed for a while. That is, some keys were in the old config file, some in the new one.

    Now some details about the implementation of the home-grown format:

    Config files are parsed by a class called Ccontrolfile (capitalization like in our code, name anonymized). The constructor for Ccontrolfile takes a filename string but also does something else: If that string starts with the user's home directory that part of the path is replaced by the contents of the environment variable CONTROLFILE_PATH. It does not use the environment variable when the user's home directory is not in the filename string.

    An example for the control file format:

    KEY1 = foo
    # This line is a comment
    KEY2 = bar # this is not a comment even though it looks like one
    
    # There is one level of nesting permitted. Not more than that.
    A.FOO = true
    A.BAR = false
    
    # Repeating keys means you are creating a list.
    A.baz = 1
    A.baz = 2
    A.baz = 3
    

    The control file library prints an error message to standard error whenever code tries to access a key that does not exist. This is especially unfortunate because the interface contains no method to query if a key is in the file.

    That's about what I remember while not staring at the code in horror. To clarify the title, I would have preferred XML configuration files that for some inexplicable reason needed to be passed through XSLT before being used.



  • @witchdoctor said:

    The configuration files live in their own folder and for legacy reasons their filenames start with a dot, which means that linux treats them as hidden files.

    Two questions:

    1. having config files in their own folder: how is that a bad thing?
    2. What exactly might the difference between a hidden and a non-hidden file be?


    1. There is nothing wrong with them being in their own folder. It's the hidden thing that's the problem.
    2. Hidden files do not show up in file management tools or when listing files on the console by default. That means one more step whenever you want to do something with the files and more training required before users have a chance of finding them. It's also a big hint that things aren't properly adjusted when new functionality comes in. Making config files hidden is how you make a single configuration file in a user's home directory in Linux.

  • Discourse touched me in a no-no place

    What is “ls -A”? Why should you know this?



  • @witchdoctor said:

    1. There is nothing wrong with them being in their own folder. It's the hidden thing that's the problem.
    2. Hidden files do not show up in file management tools or when listing files on the console by default. That means one more step whenever you want to do something with the files and more training required before users have a chance of finding them. It's also a big hint that things aren't properly adjusted when new functionality comes in. Making config files hidden is how you make a single configuration file in a user's home directory in Linux.
    1. Well, then why did you mention it like it's a big WTF?
    2. Look, I'll be honest, my shenanigans detector is going haywire. First of all: you said that the developers configure the computers you sell, not the users. This is an important point because if the developers are the ones configuring you product, they should know what the files are called, so again, what difference does a dot make? Now, all of a sudden it's the other way around, and I'm not sure I'm buying that. Second, I fail to see how the fact that configuration files start with a dot on your product, is a big hint that things aren't properly adjusted when new functionality comes in. As a matter of fact, I'm pretty sure you didn't say anything with that point. Being unsure about your previous point makes that suspicious.Third, being a desktop Linux user for a number of years now, I'll have you know that if there's one thing I've learned in all these years, it's that I don't know the difference between a hidden and a non-hidden file in Linux. Having read your answer I still don't. Maybe I'm not very smart or something? There is AFAIK nothing inherently WTFy about "hidden" files whatsoever, and in all decent file management tools they either do show up by default, or you can easily see them if you know how (for example) how to hit Ctrl-H. Especially if you're a developer being paid to know where they are.

  • Winner of the 2016 Presidential Election

    .files are usually a hint that "don't modify this file if you don't know what you're doing." They tip off a non-technical user that here there be dragons, not because they know that specifically, but because they just don't see the file unless they jump through a hoop.

    I still think TRWTF is using a naming convention for hidden files instead of a metadata flag.



  • @toon said:

    @witchdoctor said:

    1. There is nothing wrong with them being in their own folder. It's the hidden thing that's the problem.
    2. Hidden files do not show up in file management tools or when listing files on the console by default. That means one more step whenever you want to do something with the files and more training required before users have a chance of finding them. It's also a big hint that things aren't properly adjusted when new functionality comes in. Making config files hidden is how you make a single configuration file in a user's home directory in Linux.
    1. Well, then why did you mention it like it's a big WTF?
    2. Look, I'll be honest, my shenanigans detector is going haywire. First of all: you said that the developers configure the computers you sell, not the users. This is an important point because if the developers are the ones configuring you product, they should know what the files are called, so again, what difference does a dot make? Now, all of a sudden it's the other way around, and I'm not sure I'm buying that. Second, I fail to see how the fact that configuration files start with a dot on your product, is a big hint that things aren't properly adjusted when new functionality comes in. As a matter of fact, I'm pretty sure you didn't say anything with that point. Being unsure about your previous point makes that suspicious.Third, being a desktop Linux user for a number of years now, I'll have you know that if there's one thing I've learned in all these years, it's that I don't know the difference between a hidden and a non-hidden file in Linux. Having read your answer I still don't. Maybe I'm not very smart or something? There is AFAIK nothing inherently WTFy about "hidden" files whatsoever, and in all decent file management tools they either do show up by default, or you can easily see them if you know how (for example) how to hit Ctrl-H. Especially if you're a developer being paid to know where they are.

    I admit that this is a nitpicky point. The convention is: a config file living in the root of the user's home directory gets a dot. Config files in their own directory do not. At most the directory gets one.

    About the developers configuring things: This is only necessary because the config files are such a confusing mess, not because what needs to be configured is especially complex.



  • @witchdoctor said:

    About the developers configuring things: This is only necessary because the config files are such a confusing mess, not because what needs to be configured is especially complex.

    It's Linux... just have the users do their own installation, and when it doesn't work tell them to go to IRC, and when they ask questions they can be laughed at.


  • Discourse touched me in a no-no place

    @toon said:

    What exactly might the difference between a hidden and a non-hidden file be?
    Nothing. It's merely convention that, by default, most tools will not display any directory entries starting with a period. Linux itself doesn't have a concept of 'hidden files.'



  • @joe.edwards said:

    I still think TRWTF is using a naming convention for hidden files instead of a metadata flag.
     

     You think Windows convention to treat files diffetently basing on extension is bettwer in any way? 



  • @spamcourt said:

    @joe.edwards said:
    I still think TRWTF is using a naming convention for hidden files instead of a metadata flag.
    You think Windows convention to treat files diffetently basing on extension is bettwer in any way?

    Look in order of non-shittiness:

    1) Linux: determine the contents of a file by ??? Guess and check? I guess? Whatever, our OS sucks, nobody uses it.

    2) Windows: determine the contents of a file by file extension, even though that sucks.

    3) OS X: determine the contents of the file by file extension most of the time, but do the funky shitty Linux thing some of the time just to make sure we have maximum shitty code factor.

    4) Mac Classic: store meta-data in the file saying not only what type it is in detail, but what application should open it by default if multiple applications to handle that type are available on the computer. This is obviously the best way of doing this, but of course Apple threw it out because Apple is fucking terrible. (And because the Internet uses the shitty Linux convention, which couldn't read the meta-data.)



  • @blakeyrat said:

    Guess and check?

    Nope, just check, but you got close. You may not know, but nearly all file types identify themselves if you know where to look.

    @blakeyrat said:

    2) Windows: determine the contents of a file by file extension, even though that sucks.
     

    And then hides the data from the user as best as it can, so he'll run a trojan with an image icon.

    @blakeyrat said:

    And because the Internet uses the shitty Linux convention, which couldn't read the meta-data.

    Wait... what? The Internet uses MIME metadata.


  • Discourse touched me in a no-no place

    @Mcoder said:

    nearly all file types identify themselves if you know where to look
    That's a non-trivial problem. I've seen quality metrics collected over time for various tools that do the “look to see the type” operation, and the tools we checked were not at all consistent. Yes, those tools include pretty much any you might think of using; we were thorough (as we're wanting to use it on many petabytes of data, it pays to be careful up front).

    Can't find a reference to the analysis work we did; it's likely somewhere readable, but I can't figure out where…



  • @blakeyrat said:

    1) Linux: determine the contents of a file by ??? Guess and check? I guess? Whatever, our OS sucks, nobody uses it.

    Well it's a little more involved than that: http://linux.die.net/man/1/file It checks the beginning of the file for tell-tale elements, and if it looks like a text file it will try to look for a hashbang to see if it's a script and if so, what kind.



  • @witchdoctor said:

    The convention is: a config file living in the root of the user's home directory gets a dot.

    If any of you write software that puts config files as hidden files in the home directory, then I hate you and I wish you would die a horrible death in a ditch on the side of a road. I hate software that puts all its crap in my home directory assuming that I have it hidden. It's amazing how Lunitards write software that does this and at the same time mock Windows for hiding hidden files by default because they take it as an insult to their intelligence and leetness.

    $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.



  • @Arnavion said:

    If any of you write software that puts config files as hidden files in the home directory, then I hate you and I wish you would die a horrible death in a ditch on the side of a road. I hate software that puts all its crap in my home directory assuming that I have it hidden. It's amazing how Lunitards write software that does this and at the same time mock Windows for hiding hidden files by default because they take it as an insult to their intelligence and leetness.

    Just to recap:

    • Hidden files are awful
    • I like hidden files
    • I hate hidden files
    • Hidden files are wonderful
    • Hidden files are not hidden

  • Discourse touched me in a no-no place

    @Mcoder said:

    @blakeyrat said:

    Guess and check?

    Nope, just check, but you got close. You may not know, but nearly all file types identify themselves if you know where to look.

    Stop polluting the forum with facts when Blakeyrant is making shit up. Like he normally does when it comes to anything Linux/non-Windows.



  • @Mcoder said:

    @blakeyrat said:

    2) Windows: determine the contents of a file by file extension, even though that sucks.
     

    And then hides the data from the user as best as it can, so he'll run a trojan with an image icon.

     Because you can't do this in any other OS?  Make an executable in MAC and give it an image icon...@Mcoder said:

    @blakeyrat said:

    And because the Internet uses the shitty Linux convention, which couldn't read the meta-data.

    Wait... what? The Internet uses MIME metadata.

    Well, some of it does, which is why this is needed.


  • Discourse touched me in a no-no place

    @Sutherlands said:

    Because you can't do this in any other OS?  Make an executable in MAC and give it an image icon...
    You can do this, but smuggling it onto the system without alerting the user is a little more awkward; OSX applications are directories, and will attract a big scary dialog from the system the first time you try to run them (unless they come from a verified source, I think). By the time you've got around all that, you've actually got other easier things you could do instead.


  • Discourse touched me in a no-no place

    @Sutherlands said:

    Because you can't do this in any other OS?  Make an executable in MAC and give it an image icon...
    You can do this, but smuggling it onto the system without alerting the user is a little more awkward; OSX applications are directories, and will attract a big scary dialog from the system the first time you try to run them (unless they come from a verified source, I think). By the time you've got around all that, you've actually got other easier things you could do instead.



  • @toon said:

    Two questions:

    1. having config files in their own folder: how is that a bad thing?
    2. What exactly might the difference between a hidden and a non-hidden file be?

     

    Unix/Linux convention for per-user apps is either hidden files in the home dir, or unhidden files in a hidden dir.

    Latter makes more sense.

     



  • @joe.edwards said:

    I still think TRWTF is using a naming convention for hidden files instead of a metadata flag.
     

    That.

    Windows uses a file extension to indicate the file type (and associated application) but uses metadata to signify hidden/system. Unix does it the other way around (name to signify hidden, metadata to indicate executable, etc).

    Both are as bad as each other.



  • @blakeyrat said:

    1) Linux: determine the contents of a file by
     

    .. command/utility[1] or two that identifies what it thinks the file is, irrespective of its filename and permissions.

    @blakeyrat said:

    2) Windows: determine the contents of a file by file extension, even though that sucks.

    Nowadays they hide the extension and you determine it by icon.

    @blakeyrat said:

    4) Mac Classic: store meta-data in the file saying not only what type it is in detail, but what application should open it by default if multiple applications to handle that type are available on the computer. This is obviously the best way of doing this, but of course Apple threw it out because Apple is fucking terrible.

    I can never understand why the most sane approach never got copied by the runner-ups and those that championed this approach had to gerfuck it themselves.

    @blakeyrat said:

    (And because the Internet uses the shitty Linux convention, which couldn't read the meta-data.)

    Wha?

    [1] the "file" command, or various graphical file management tools.



  • @Ben L. said:

    @Arnavion said:

    If any of you write software that puts config files as hidden files in the home directory, then I hate you and I wish you would die a horrible death in a ditch on the side of a road. I hate software that puts all its crap in my home directory assuming that I have it hidden. It's amazing how Lunitards write software that does this and at the same time mock Windows for hiding hidden files by default because they take it as an insult to their intelligence and leetness.

    Just to recap:

    • Hidden files are awful
    • I like hidden files
    • I hate hidden files
    • Hidden files are wonderful
    • Hidden files are not hidden

     

    Don't forget:

    • I hate you if you put stuff in my home directory
    • putting it in ${HOME}/.config is okay. But because it's in my home directory, I'll hate you.
    • $XDG_CONFIG_HOME contains the path that should be used (which may be my home directory, so I'll hate you for doing it correctly)

    </pedant>

    However, I agree with the point of developers not sticking to standards. 

     



  • @Cassidy said:

    However, I agree with the point of developers not sticking to standards. 

    The problem is that some of this software was written a decade (or two) ago, when those standards didn't exist, and nobody wants to touch it because "what about compatibility".



  • @Mcoder said:

    You may not know, but nearly all file types identify themselves if you know where to look.

    Except for those ones that are just zipped XML, such as OpenDocument or OfficeOpenXML, and similar cases. So now Linux works by a combination of checking contents and reading the extension. Try taking a random zip file and renaming it to end in ".odt" and it should show up in the file browser as an OpenOffice file.



  • @anonymous234 said:

    @Cassidy said:
    However, I agree with the point of developers not sticking to standards.

    The problem is that some of this software was written a decade (or two) ago, when those standards didn't exist, and nobody wants to touch it because "what about compatibility".

    Even when Linux was started in 1991, standards on where to put various types of files existed on other OSes-- the Preferences folder on Mac OS, the basics of the NT system, etc. Moreover, even by 1991, those OSes had a OS API call to retrieve the location used-- Gestalt() in Mac OS for example. They were a little primitive, but there were plenty of examples for Linux to copy. If they had given a shit.



  • @anonymous234 said:

    The problem is that some of this software was written a decade (or two) ago, when those standards didn't exist, and nobody wants to touch it because "what about compatibility".
     

    If standards didn't exist... compatibility to what?

    It sounds more like people don't want to touch it because they want it to remain incompatible.



  • @blakeyrat said:

    Even when Linux was started in 1991, standards on where to put various types of files existed on other OSes--
     

    Linux standards are a combination of Unix standards (where they exist) and vendor-specific standards (where Unix didn't exist) so it's not surprising there's standards forking if the community aren't really under central control.

    Either way, no matter what the standards are (if they even exist), there are still a lot of developers - Linux or otherwise - that would choose to ignore them or willingly violate them because the non-standard easier route is preferable to the standard more-maintainable route. 



  • @Cassidy said:

    Don't forget:

    • I hate you if you put stuff in my home directory
    • putting it in ${HOME}/.config is okay. But because it's in my home directory, I'll hate you.
    • $XDG_CONFIG_HOME contains the path that should be used (which may be my home directory, so I'll hate you for doing it correctly)

    I can forgive Ben L. for being retarded, but not you. I don't want three programs to put .program1, .program2, .program3 in $HOME because it clutters up $HOME. If they put everything in $HOME/.config then the clutter isn't in $HOME.



  • @Arnavion said:

    I can forgive Ben L. for being retarded, but not you.
     

    Eh, I was harmlesly dickweeding.

    @Arnavion said:

    I don't want three programs to put .program1, .program2, .program3 in $HOME because it clutters up $HOME. If they put everything in $HOME/.config then the clutter isn't in $HOME.

    I think the point was that if they were hidden - files or directories - then you wouldn't spot the clutter.



  • @dkf said:

    You can do this, but smuggling it onto the system without alerting the user is a little more awkward; OSX applications are directories, and will attract a big scary dialog from the system the first time you try to run them (unless they come from a verified source, I think).
    Windows introduced this around XP SP1.

    @blakeyrat said:

    Even when Linux was started in 1991, standards on where to put various types of files existed on other OSes-- the Preferences folder on Mac OS, the basics of the NT system, etc. Moreover, even by 1991, those OSes had a OS API call to retrieve the location used-- Gestalt() in Mac OS for example. They were a little primitive, but there were plenty of examples for Linux to copy. If they had given a shit.
    NT wasn't public until 1993, and the user profile directory structure only appeared in NT 4, which was released in late 1996 (and since the default user account had administrative privileges up to including XP, it wasn't until Vista before most programs actually started using per-user settings properly; before XP was released, Windows programs that worked with per-user settings were few and far between).



  • @Cassidy said:

    I think the point was that if they were hidden - files or directories - then you wouldn't spot the clutter.

    True, but I always enable hidden files and folders in whatever file manager I use, just like I do in Windows. I'd think every non-beginner user would do it. And like I said, elitist Linux users make fun of Windows users because Windows hides hidden files and folders by default, yet also use/write software that treats their home directory like a dumping ground, so I can only assume they like seeing shit in their home directory.



  • Goddamned you pedantic dickweeds, when are you going to just fuck off and die?



  • In less than 100 years if thing go correctly.



  • @Arnavion said:

    elitist Linux users make fun of Windows users because Windows hides hidden files and folders by default,
    If Windows didn't hide them then they wouldn't be . . . you know . . . hidden.  (Sorry, just being silly, I know what you meant). TRWTF is hidden files/directories. Sure, you don't want people mucking aorund and deleting stuff they shouldn't, but it eventually leads to a situation where someone needs to fix a problem but the problem is hidden.

    For example, you can find hundreds of posts on forums all over the Internet from people asking how to move their Firefox profile to a new computer, which is really simple and easy, except that it's in a hidden directory.  (On Windows, not sure of other OS).  So first you have to walk them through the steps of unhidng the directory.  What moron thought that putting program configuration files in a hidden directory is a good idea?



  • @El_Heffe said:

    So first you have to walk them through the steps of unhidng the directory.

    I just tell them to type %APPDATA% or %LOCALAPPDATA% in explorer's location bar. Although just yesterday a person interpreted this to mean "Create a directory named AppData under C:" so I suppose it's not infallible.



  • @Arnavion said:

    Although just yesterday a person interpreted this to mean "Create a directory named AppData under C:" so I suppose it's not infallible.
     

    When training, I have refined my directions to remove as much ambiguity as possible and reduced the possibility of misinterpretation down to negligible levels[1].

    And yet I occasionally encounter those cloth-eared gits with instruction-mangling XSLT embedded between ears and brain.

    [1] apart from situations where misinterpretation and variance are part of the learning objectives.



  • @El_Heffe said:

    @Arnavion said:

    elitist Linux users make fun of Windows users because Windows hides hidden files and folders by default,
    If Windows didn't hide them then they wouldn't be . . . you know . . . hidden.  (Sorry, just being silly, I know what you meant). TRWTF is hidden files/directories. Sure, you don't want people mucking aorund and deleting stuff they shouldn't, but it eventually leads to a situation where someone needs to fix a problem but the problem is hidden.

    For example, you can find hundreds of posts on forums all over the Internet from people asking how to move their Firefox profile to a new computer, which is really simple and easy, except that it's in a hidden directory.  (On Windows, not sure of other OS).  So first you have to walk them through the steps of unhidng the directory.  What moron thought that putting program configuration files in a hidden directory is a good idea?

    Firefox doesn't have an "export profile" option?  That WOULD be super-easy. 

    The problems that people want to fix by going into a hidden directory are 1) few and far between, 2) typically resolved by an installer and 3) for super-advanced users only.  If you actually need to use those directories, then you either know how to get to them or know how to figure it out.  (Except with that firefox problem, but that's open source for you.)



  • @El_Heffe said:

    So first you have to walk them through the steps of unhidng the directory.

    The real problem is that showing hidden directories was a PITA in versions of Windows prior to 8. The idea of hidden directories is fine, as long as there is a simple way to un-hide them when you need them. Thankfully in Windows 8 it's just a checkbox in the ribbon (same as with showing file extensions).


  • Winner of the 2016 Presidential Election

    @anonymous234 said:

    @El_Heffe said:
    So first you have to walk them through the steps of unhidng the directory.

    The real problem is that showing hidden directories was a PITA in versions of Windows prior to 8. The idea of hidden directories is fine, as long as there is a simple way to un-hide them when you need them. Thankfully in Windows 8 it's just a checkbox in the ribbon (same as with showing file extensions).

    This is the first feature I've read about that actually sounds improved over 7. I'm normally an early-adopter of new versions of software, but what I've read about W8 has been primarily bad (well, workflow-disrupting without being objectively better).



  • @joe.edwards said:

    This is the first feature I've read about that actually sounds improved over 7. I'm normally an early-adopter of new versions of software, but what I've read about W8 has been primarily bad (well, workflow-disrupting without being objectively better).

    For me there's pluses and minuses with Win8, but more pluses. Things like the start screen can be a pain, but I rarely use it. When I do, any program I want is just a search away. Generally, that's the only valid complaint about Win8 over 7.

    Mind you, I'm looking forward to storage spaces becoming saner.



  • @anonymous234 said:

    The real problem is that showing hidden directories was a PITA in versions of Windows prior to 8.
    Uh... no it's not.



  • @Sutherlands said:

    @anonymous234 said:
    The real problem is that showing hidden directories was a PITA in versions of Windows prior to 8.
    Uh... no it's not.
     

    Can anyone show a comparison? I only know the way in Win7 (Tools > Folder Options) which has largely remained similar through Win95 upwards.



  • @Scribbler said:

    Things like the start screen can be a pain, but I rarely use it. When I do, any program I want is just a search away.
     

    Yeah, but the search is really far away.


  • Discourse touched me in a no-no place

    @ender said:

    @dkf said:
    You can do this, but smuggling it onto the system without alerting the user is a little more awkward; OSX applications are directories, and will attract a big scary dialog from the system the first time you try to run them (unless they come from a verified source, I think).
    Windows introduced this around XP SP1.
    Curious; I do not remember seeing that in practice despite using XP SP1 (and later) for years. I was definitely downloading some executables directly off the internet (by people I really trusted) during this time, and I don't ever recall any kind of warning box turning up. Maybe it was a capability that had to be explicitly switched on but which was off by default? If so, it's not likely to protect many people in practice. On OSX, that warning turns up by default for applications; you can't turn it off (but it does only ask you once per downloaded app; more than that would be retarded).@ender said:
    @blakeyrat said:
    Even when Linux was started in 1991, standards on where to put various types of files existed on other OSes-- the Preferences folder on Mac OS, the basics of the NT system, etc. Moreover, even by 1991, those OSes had a OS API call to retrieve the location used-- Gestalt() in Mac OS for example. They were a little primitive, but there were plenty of examples for Linux to copy. If they had given a shit.
    NT wasn't public until 1993, and the user profile directory structure only appeared in NT 4, which was released in late 1996 (and since the default user account had administrative privileges up to including XP, it wasn't until Vista before most programs actually started using per-user settings properly; before XP was released, Windows programs that worked with per-user settings were few and far between).
    FWIW, Linux was just following general POSIX multi-user practice, which had many years of maturity at that point (I think that was following principles developed in the 1970s, so we're talking around 20 years when Linux was started and around 40 years nowadays). I'm not claiming that old automatically is good (or bad); just that that's how it's been from the beginning.

    The problem with Windows (and also MacOS for a long time) was that it was a platform with an assumption that there would only be one user, and this assumption was an integral part of how applications were written. Such assumptions, especially when part of third-party software, are very hard to shift without causing lots of breakage, and when it came to do so, Apple did it their way — they just broke old apps and told the vendors of the apps to suck it up — and Microsoft did it their way — bending over backwards to keep crufty old code working long past the point where anyone else would've bothered. (Linux, because it started out multiuser, didn't have to do this adaptation in the first place.)



  • @dhromed said:

    Yeah, but the search is really far away.

    Windows key -> type -> Enter

    Same muscle-memory as Vista or Windows 7.



  • @dkf said:

    don't ever recall any kind of warning box turning up. Maybe it was a capability that had to be explicitly switched on but which was off by default?
     

    No, but I could never quite reproduce it.

    Downloads seemed to be just fine,  but "executables" copied off a network drive to local while in VPN, or .asp files opened right off that drive would pop up a warning.



  • @blakeyrat said:

    @dhromed said:
    Yeah, but the search is really far away.

    Windows key -> type -> Enter

    Same muscle-memory as Vista or Windows 7.

     

    Oh.

    I guess the absence of a focused text field in the start screen told me that I couldn't do that. But thanks for the tip.

     



  • @dkf said:

    The problem with Windows (and also MacOS for a long time)

    Only Win32-based Windows.

    And Win32 had the concept of multiple users; what it didn't have was security to prevent one user from touching another user's stuff. (MacOS also had this around release 7.5 or 8.0 IIRC.)

    @dkf said:

    was that it was a platform with an assumption that there would only be one user, and this assumption was an integral part of how applications were written.

    Only shitty applications. Applications correctly written for Win32 run correctly in NT. Because the API has had fuctions that mocked multiple-user support even when the OS didn't have user security.

    This is exactly WHY you code to the API documentation instead of guess-and-check, people. If you had, you'd get all these lovely features for free with no effort on your part. If you didn't, you were in hotfix hell the instant NT became popular.

    @dkf said:

    (Linux, because it started out multiuser, didn't have to do this adaptation in the first place.)

    True; but on the other hand Win32 and MacOS could be used to print nice-looking graduation party invitations. And that's the kind of feature people who aren't geeks actually give a shit about.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.