The end-users probably aren't (officially) selling their used drives; they're probably selling their three year old machines by the kilo to an authorised disposal agent, who in turn wipes the drives (or is contractually supposed to do so) then either sells the machines as used, or breaks them into components for sale as used.
My home desktop motherboard does AGP, and none of the AGP graphics cards I can find support 1920x1200; I don't think most of them support 1600x1xxx. So if I go get a decent LCD monitor, I'm going to need to replace the motherboard to support the graphics card...
I've run a 21" CRT at 1600x1200 with an nVidia GeForce4 440MX, a Radeon 7500 and a Radeon 9250, all AGP. None were the greatest - even when I bought them - for games, but if all you want is a regular desktop (and an occasional bit of 3D), they'll suffice.
I don't remember having to manually enable the network initscript on my FC10 install. And I'm pretty sure DHCP worked fine, but the reason I disabled NetworkManager was that Firefox defaults to offline mode otherwise.
Well, AFAICS, NetworkManager is useful on desktops too - if you have 802.1x enabled on your network.
But yeah, it's not quite as polished as it could be. But that's Fedora (as opposed to RHEL/CentOS) for you...
It's not gratuitous; it's because MD5 and SHA-1 are no longer safe to use. See this FC11 feature note for more info. Note that FC11+ RPMs can still be converted to cpio format using rpm2cpio and unpacked using cpio.
In theory. In practice, doing an upgrade install from the install media only seems to do a reasonable job if you don't have packages from third-party repositories. I tried FC8->FC9->FC10 recently; it took ages, and the mess it left looked harder to fix than backing up/etc and doing a clean FC10 install. And I've been using RH since the 2.1 days.
Next time, I'll try using the unsupported yum method, whilst leaving my third-party repos enabled, I think.
Anyone know, why PC133 memory would have an issue on a bus overclocked from 100MHz to 133? It should be able to handle it just fine, so I'd like to think:-/
It's probably not the RAM as such; the 440BX on the P2B is only officially rated for 100MHz. Overclocking the chipset can have any number of side-effects.
Once it leaves the investigating officers hands, it reaches the courts. The prosecutors don't give two shits about the defendant, the victims, or the truth. They only care about ONE THING, AND ONE THING ONLY. That is, "Can I get a conviction?". I highly doubt any prosecutor has ever thought long and hard about the veracity of any of the evidence in front of them that they are using. As far as the other side, "discredit, discredit, discredit".
That tallies with my experience of jury service in the UK; the evidence I heard didn't convince me at all (though it did convince a large majority of my fellow jurers, sadly). I can understand why the police work this way; government targets, limited resources, and most saliently, the fact that one can never actually know when one has established the truth (kinda like the halting problem in CompSci). It's the jury's job to take a fairly skeptical stance towards all evidence presented, and only reach a guilty verdict if they're pretty sure it's 'good enough'.
That was just as stupid semester project on a 3-computer ethernet LAN, but I imagine the big boys have figured out how to make it work
Checkpoint's Firewall-1 product has been able to transfer the current firewall state to a backup firewall for quite some time (at least 1998 or so), but it originally required the use of RIP to implement failover which introduced delays. In about 1999, Stonesoft produced an add-on product, Stonebeat, which added ARP spoofing, so the failover was virtually instantaneous. These days, the failover is done using VSRP.
To hell with CAD, let me know when a mobile phone can act as a functional word processor.
I've envisaged, for a few years now, a PDA/mobile phone that has a docking station allowing full-size HID/display peripherals to be connected. Netbooks are kinda there already, or to a lesser extent, the Nokia tablets with a Bluetooth keyboard.
No, Lite-On - probably an LTD-163 or similar. If I remember correctly, it malfunctioned after trying the Arachne DOS web browser (specifically probing for an NE2000 NIC) from the UBCD. I reported it to the UBCD maintainers, but they said they'd had no similar reports.
I'm trying to remember why I didn't; I think it might have been the combination of a) the vendor being dabs (essentially only contactable via email) b) the drive being just out of its one year warranty (but barely used during that time, hence 'nearly new') and c) new drives falling in price to under £10. Sometimes the principle just isn't worth it...;-)
It makes me more wonder why doesn't a motherboard have a jumper that disables BIOS updates? That would be quite a strong safety measure. Anyone capable of knowing why to, and how to execute a BIOS update is certainly capable of opening/closing that jumper for the procedure.
I've been thinking that this is necessary ever since I lost a nearly-new DVD Rom drive to a rogue piece of software that managed to wipe out one bit in sixteen of the drive's firmware.
I agree with you regarding optimization, but it's been my experience that many applications *can* benefit from these sorts of simple multithreading techniques- the programmers just don't do them, either from lack of ability or lack of resources.
There can also be usability issues; if a user plans to do thing A (a slow process), followed by thing B, they may be somewhat perturbed when initiating thing A apparently returns control immediately, and some aspect of thing A that they are monitoring hasn't been done. That looks a lot like the application failing to carry out an operation for some unknown reason. So they'll probably queue up another request of thing A. Eventually, the queue will complete, and they'll get a flurry of duplicate thing A operations which need to be undone before thing B can be done.
I for one am certainly not going to be reading chip data sheets unless there's some real performance benefit to be found. If there's enough benefit, I may even write parts in assembly, I can handle any ugliness. But only if there's a benefit from doing so.
I agree; reading processor data sheets should only really be necessary for compiler and kernel programmers; for everyone else, pick the right algorithm, implement it efficiently and the compiler should turn it into efficient machine code that runs efficiently under the target OS kernel.
Using the same character for different usage scenarios takes the obviousness out of its usage. On Windows you can do "cd X11" or "cd X11\" and get to the same spot.
UNIX's use of / is identical to Windows' use of \. Both are path separators. Both, in their leading form, ALSO indicate the root of the hierarchy (try 'CD SYSTEM32' and 'CD \SYSTEM32' from the WINDOWS directory; one will take you to WINDOWS\SYSTEM32, the other will fail for the same reason 'cd/X11' fails).
In you original post, you assigned blame to Microsoft for "DLL hell". My response was intended to redirect the blame to application vendors who aren't doing what they have been told to do a million times.
If I did, that wasn't really my intention, other than so far as "DLL hell" could have been prevented if the earliest versions of Windows shipped with either a better-structured package management mechanism, or something like SxS. It never was fair to make the users/admins resolve the problem themselves. Also, once application developers have gotten into bad habits, it's hard to convince them to do it another way, so you end up being forced to support their crappy ways in the least harmful way possible. (cf. applications not using fsync() when writing config files in the recent ext4 situation on Linux).
Finally, I note that Microsoft as application developers don't follow their own rules; I note that AoE 1 and 2 don't share a bunch of their DLLs that presumably could be shared. In issues like this, it's important for top tier developers for the platform to set an example, surely?
It seems as if you didn't even read my post. Side by Side assemblies solve all of those problems.
I did, but I was put off from researching it further as, in your own words, "it's not being used properly". Indeed, looking at an XP system with over 100 third-party applications installed, I see only a dozen or so entries in windows\sxs, and most of those appear to be core Microsoft DLLs. Apparently, there are over 11,000 DLLs on this system in total, with many from a small set of developers/publishers. Better than nothing, but...
As far as I'm concerned, this was a discussion about the practicalities of running a Windows system today, rather than a Linux vs. Windows architecture contest. I'm primarily a Linux user/admin/hacker, but I keep my hand in on Windows, and I even acknowledge that in some areas, Windows has the edge architecturally (e.g. some aspects of Transactional NTFS aka TxF). I find it interesting that a DLL publisher can effect say "This DLL should work with any app that was good with the old version" or "This version definitely changes the API" but also that application developers and/or power users can override that if experience demonstrates otherwise. It's an interesting approach to solving the problem of "DLL hell" without forcibly exposing "dependency hell" to the end-user/sysadmin. The closest Linux comes is with major version numbers, and that sometimes isn't a great measure (e.g. glibc changes its major version number quite conservatively as doing so with every significant API change could result in many versions being in memory simultaneously, but it does mean that sometimes an application won't successfully link and/or run, even if the major version number indicates it should).
The downside of each application keeping its own DLLs in the application installation directory is that they won't be available to other applications. On the other hand, given it's not always possible that an application will work with all newer versions of a given DLL than that it shipped with, and that it would appear that Windows packages can't specify dependencies in the same way RPMs or dpkgs can, that would force the administrative overhead of resolving DLL incompatibility onto the end-user, which isn't generally seen as acceptable in Windows-space (it's not acceptable in Linux-space either, which is why our package tools try to ameliorate the problem).
Linux doesn't work with which iPods? My girlfriend and I have two different iPod models and they both work fine in Amarok (the KDE3 one, haven't tried in Amarok 2).
iPhones and current iPod Touch models require hacking for the iTunesDB to be usable with non-iTunes managers. Doing so rules out using the AppStore. More details.
I've been using Ubuntu for about a month now. There's a few things that just don't make sense, but most do. Now that I'm thinking about them, I may as well list them.
1) Apps are labelled by task rather than name. I had to use google to find out that the "File Browser" was called "nautilus". Gee - could you label it using the app's name, or make it launchable by entering something like "file-browser" in the run box?
File that as a bug with Ubuntu. RH/Fedora are starting to do what you describe, at least for typical desktop user apps, like the file browser, web browser, email, text editor and so on.
2) No easy way to sudo GUI stuff. Often I have to open a terminal and use sudo to complete a task, which is annoying. Why can't there just be a button to kick me up to root for a minute or two?
It's not safe to run GUI applications as root. If you insist, and your distro vendor agrees, then they may configure it (using PAM) to use consolehelper (part of the usermode package) to ask for the root password when you run it.
3) Navigating folders is a PITA in the terminal.
These fail:
cd etc/X11/
cd etc/X11
To be expected, unless your Current Working Directory (CWD) is the root of the filesystem, known as/, or you have a duplication etc/X11 hierarchy under your CWD. The trailing / on the first example is redundant, BTW.
cd/etc/X11/
cd/etc/X11
Both those should be fine. Did you test before posting?
cd etc
cd/X11
cd etc
cd X11
First pair will try to change to etc in the CWD (and fail), then try to go to X11 in the root (and fail). Second will try to go to etc in the CWD (and fail), then go to X11 in the CWD (and fail).
This doesn't:
cd/etc
cd X11
Would it hurt to be a little intuitive about where I wanted to go? Apparently so...
It's impossible to be intuitive when they mean entirely different things. Would you expect 'CD D:\SYSTEM32' to Do The Right Thing on Windows when Windows is installed on C: and SYSTEM32 is inside the WINDOWS directory? Same deal. If it helps, think of C:\ being roughly equivalent the root of the filesystem (i.e./). It kinda breaks down because UNIX doesn't have drive letters, and actually Windows uses the backslash in the same way as UNIX uses the slash; note how you can use 'CD \' to go to the root of the current drive.
4) More #2. It would be much easier to have a way to kick gedit up to root so I can save xorg.conf. That'd save me having to navigate to that folder, which took 10 minutes the first time.
In addition to the earlier explanations, it's really not safe to let just any old user have write access to system config files by default. At best, they might mess them up, at worst, they may make them do bad things (install spyware, delete their home directory) to other users. If you wish, if you're the owner of the file (i.e. root in the case of xorg.conf), you can loosen the permissions on specific files using chmod.
5) Argh. More #3. My Windows partitions often have folders about 8-20 deep. Navigating with the terminal is... horrible. I may have to resize my linux partition and just stick everything on it, because accessing stuff on a shared partition with good organization is such a huge PITA.
You know about tab completion in the shell, right? Hit tab on a partial file or directory name, and it'll complete as best it can. If there are multiple matches, it'll beep. Hit tab again, and it'll show them.
6) Oh dear god. I made a shortcut to a file on an NTFS partition and put it on the desktop. The thing is, when I open it, I can't go "up" to the folder's parent folders - it takes me "up" (back) to the desktop. Great. I guess I'll get into the habbit of opening the terminal, typing "gksudo nautilus" in, then navigating manually to the folder I need on my NTFS partition, so that I can go "up" properly and cop
Ideally, installing DLLs so that they could be shared between applications (even from different vendors) would be perfect.
However, Windows has no dependency management scheme for packages, and it's unusual for DLLs to be packaged separately from applications anyway.
I see it as Microsoft shying away from 'dependency hell' in favour of 'DLL hell' (and a set of rules that, if followed by application developers, make it unlikely to be a problem in practice, albeit at the cost of reducing the usefulness of DLLs).
Quite; about 1.5 years into my post-Bachelors career I interviewed, and got a offer for a job that required frequent international travel; Amsterdam; Vienna, Virginia; Reston, Virginia; Ashburn, Virginia; New York, New York; Miami, Florida; San Jose, California and Los Angeles, California. Yes, various machine rooms around the world that happened to host Internet exchange points. I figured one machine room and hotel room looks very much like another and passed, in spite of the superficial glamour that came with the role!
Slashdot Mirror
The end-users probably aren't (officially) selling their used drives; they're probably selling their three year old machines by the kilo to an authorised disposal agent, who in turn wipes the drives (or is contractually supposed to do so) then either sells the machines as used, or breaks them into components for sale as used.
My home desktop motherboard does AGP, and none of the AGP graphics cards I can find support 1920x1200; I don't think most of them support 1600x1xxx. So if I go get a decent LCD monitor, I'm going to need to replace the motherboard to support the graphics card... I've run a 21" CRT at 1600x1200 with an nVidia GeForce4 440MX, a Radeon 7500 and a Radeon 9250, all AGP. None were the greatest - even when I bought them - for games, but if all you want is a regular desktop (and an occasional bit of 3D), they'll suffice.
I don't remember having to manually enable the network initscript on my FC10 install. And I'm pretty sure DHCP worked fine, but the reason I disabled NetworkManager was that Firefox defaults to offline mode otherwise.
Well, AFAICS, NetworkManager is useful on desktops too - if you have 802.1x enabled on your network.
But yeah, it's not quite as polished as it could be. But that's Fedora (as opposed to RHEL/CentOS) for you...
chkconfig --disable NetworkManager && service NetworkManager stop
It's not gratuitous; it's because MD5 and SHA-1 are no longer safe to use. See this FC11 feature note for more info. Note that FC11+ RPMs can still be converted to cpio format using rpm2cpio and unpacked using cpio.
In theory. In practice, doing an upgrade install from the install media only seems to do a reasonable job if you don't have packages from third-party repositories. I tried FC8->FC9->FC10 recently; it took ages, and the mess it left looked harder to fix than backing up /etc and doing a clean FC10 install. And I've been using RH since the 2.1 days.
Next time, I'll try using the unsupported yum method, whilst leaving my third-party repos enabled, I think.
Anyone know, why PC133 memory would have an issue on a bus overclocked from 100MHz to 133? It should be able to handle it just fine, so I'd like to think :-/
It's probably not the RAM as such; the 440BX on the P2B is only officially rated for 100MHz. Overclocking the chipset can have any number of side-effects.
Once it leaves the investigating officers hands, it reaches the courts. The prosecutors don't give two shits about the defendant, the victims, or the truth. They only care about ONE THING, AND ONE THING ONLY. That is, "Can I get a conviction?". I highly doubt any prosecutor has ever thought long and hard about the veracity of any of the evidence in front of them that they are using. As far as the other side, "discredit, discredit, discredit".
That tallies with my experience of jury service in the UK; the evidence I heard didn't convince me at all (though it did convince a large majority of my fellow jurers, sadly). I can understand why the police work this way; government targets, limited resources, and most saliently, the fact that one can never actually know when one has established the truth (kinda like the halting problem in CompSci). It's the jury's job to take a fairly skeptical stance towards all evidence presented, and only reach a guilty verdict if they're pretty sure it's 'good enough'.
That was just as stupid semester project on a 3-computer ethernet LAN, but I imagine the big boys have figured out how to make it work
Checkpoint's Firewall-1 product has been able to transfer the current firewall state to a backup firewall for quite some time (at least 1998 or so), but it originally required the use of RIP to implement failover which introduced delays. In about 1999, Stonesoft produced an add-on product, Stonebeat, which added ARP spoofing, so the failover was virtually instantaneous. These days, the failover is done using VSRP.
To hell with CAD, let me know when a mobile phone can act as a functional word processor.
I've envisaged, for a few years now, a PDA/mobile phone that has a docking station allowing full-size HID/display peripherals to be connected. Netbooks are kinda there already, or to a lesser extent, the Nokia tablets with a Bluetooth keyboard.
Was it an ASUS DVD-RAM Drv. by any chance ?
No, Lite-On - probably an LTD-163 or similar. If I remember correctly, it malfunctioned after trying the Arachne DOS web browser (specifically probing for an NE2000 NIC) from the UBCD. I reported it to the UBCD maintainers, but they said they'd had no similar reports.
I'm trying to remember why I didn't; I think it might have been the combination of a) the vendor being dabs (essentially only contactable via email) b) the drive being just out of its one year warranty (but barely used during that time, hence 'nearly new') and c) new drives falling in price to under £10. Sometimes the principle just isn't worth it... ;-)
It makes me more wonder why doesn't a motherboard have a jumper that disables BIOS updates? That would be quite a strong safety measure. Anyone capable of knowing why to, and how to execute a BIOS update is certainly capable of opening/closing that jumper for the procedure.
I've been thinking that this is necessary ever since I lost a nearly-new DVD Rom drive to a rogue piece of software that managed to wipe out one bit in sixteen of the drive's firmware.
I agree with you regarding optimization, but it's been my experience that many applications *can* benefit from these sorts of simple multithreading techniques- the programmers just don't do them, either from lack of ability or lack of resources.
There can also be usability issues; if a user plans to do thing A (a slow process), followed by thing B, they may be somewhat perturbed when initiating thing A apparently returns control immediately, and some aspect of thing A that they are monitoring hasn't been done. That looks a lot like the application failing to carry out an operation for some unknown reason. So they'll probably queue up another request of thing A. Eventually, the queue will complete, and they'll get a flurry of duplicate thing A operations which need to be undone before thing B can be done.
I for one am certainly not going to be reading chip data sheets unless there's some real performance benefit to be found. If there's enough benefit, I may even write parts in assembly, I can handle any ugliness. But only if there's a benefit from doing so.
I agree; reading processor data sheets should only really be necessary for compiler and kernel programmers; for everyone else, pick the right algorithm, implement it efficiently and the compiler should turn it into efficient machine code that runs efficiently under the target OS kernel.
Using the same character for different usage scenarios takes the obviousness out of its usage. On Windows you can do "cd X11" or "cd X11\" and get to the same spot.
UNIX's use of / is identical to Windows' use of \. Both are path separators. Both, in their leading form, ALSO indicate the root of the hierarchy (try 'CD SYSTEM32' and 'CD \SYSTEM32' from the WINDOWS directory; one will take you to WINDOWS\SYSTEM32, the other will fail for the same reason 'cd /X11' fails).
In you original post, you assigned blame to Microsoft for "DLL hell". My response was intended to redirect the blame to application vendors who aren't doing what they have been told to do a million times.
If I did, that wasn't really my intention, other than so far as "DLL hell" could have been prevented if the earliest versions of Windows shipped with either a better-structured package management mechanism, or something like SxS. It never was fair to make the users/admins resolve the problem themselves. Also, once application developers have gotten into bad habits, it's hard to convince them to do it another way, so you end up being forced to support their crappy ways in the least harmful way possible. (cf. applications not using fsync() when writing config files in the recent ext4 situation on Linux).
Finally, I note that Microsoft as application developers don't follow their own rules; I note that AoE 1 and 2 don't share a bunch of their DLLs that presumably could be shared. In issues like this, it's important for top tier developers for the platform to set an example, surely?
It seems as if you didn't even read my post. Side by Side assemblies solve all of those problems.
I did, but I was put off from researching it further as, in your own words, "it's not being used properly". Indeed, looking at an XP system with over 100 third-party applications installed, I see only a dozen or so entries in windows\sxs, and most of those appear to be core Microsoft DLLs. Apparently, there are over 11,000 DLLs on this system in total, with many from a small set of developers/publishers. Better than nothing, but...
As far as I'm concerned, this was a discussion about the practicalities of running a Windows system today, rather than a Linux vs. Windows architecture contest. I'm primarily a Linux user/admin/hacker, but I keep my hand in on Windows, and I even acknowledge that in some areas, Windows has the edge architecturally (e.g. some aspects of Transactional NTFS aka TxF). I find it interesting that a DLL publisher can effect say "This DLL should work with any app that was good with the old version" or "This version definitely changes the API" but also that application developers and/or power users can override that if experience demonstrates otherwise. It's an interesting approach to solving the problem of "DLL hell" without forcibly exposing "dependency hell" to the end-user/sysadmin. The closest Linux comes is with major version numbers, and that sometimes isn't a great measure (e.g. glibc changes its major version number quite conservatively as doing so with every significant API change could result in many versions being in memory simultaneously, but it does mean that sometimes an application won't successfully link and/or run, even if the major version number indicates it should).
I dunno, I'm not feeling particularly fearful or doubtful after reading the article.
The articles has, apparently, sown Uncertainty in you, however, so it was 33.3% successful.
The downside of each application keeping its own DLLs in the application installation directory is that they won't be available to other applications. On the other hand, given it's not always possible that an application will work with all newer versions of a given DLL than that it shipped with, and that it would appear that Windows packages can't specify dependencies in the same way RPMs or dpkgs can, that would force the administrative overhead of resolving DLL incompatibility onto the end-user, which isn't generally seen as acceptable in Windows-space (it's not acceptable in Linux-space either, which is why our package tools try to ameliorate the problem).
Linux doesn't work with which iPods? My girlfriend and I have two different iPod models and they both work fine in Amarok (the KDE3 one, haven't tried in Amarok 2).
iPhones and current iPod Touch models require hacking for the iTunesDB to be usable with non-iTunes managers. Doing so rules out using the AppStore. More details.
I've been using Ubuntu for about a month now. There's a few things that just don't make sense, but most do. Now that I'm thinking about them, I may as well list them.
1) Apps are labelled by task rather than name. I had to use google to find out that the "File Browser" was called "nautilus". Gee - could you label it using the app's name, or make it launchable by entering something like "file-browser" in the run box?
File that as a bug with Ubuntu. RH/Fedora are starting to do what you describe, at least for typical desktop user apps, like the file browser, web browser, email, text editor and so on.
2) No easy way to sudo GUI stuff. Often I have to open a terminal and use sudo to complete a task, which is annoying. Why can't there just be a button to kick me up to root for a minute or two?
It's not safe to run GUI applications as root. If you insist, and your distro vendor agrees, then they may configure it (using PAM) to use consolehelper (part of the usermode package) to ask for the root password when you run it.
3) Navigating folders is a PITA in the terminal. These fail: cd etc/X11/ cd etc/X11
To be expected, unless your Current Working Directory (CWD) is the root of the filesystem, known as /, or you have a duplication etc/X11 hierarchy under your CWD. The trailing / on the first example is redundant, BTW.
cd /etc/X11/
cd /etc/X11
Both those should be fine. Did you test before posting?
cd etc cd /X11
cd etc
cd X11
First pair will try to change to etc in the CWD (and fail), then try to go to X11 in the root (and fail). Second will try to go to etc in the CWD (and fail), then go to X11 in the CWD (and fail).
This doesn't: cd /etc
cd X11
Would it hurt to be a little intuitive about where I wanted to go? Apparently so...
It's impossible to be intuitive when they mean entirely different things. Would you expect 'CD D:\SYSTEM32' to Do The Right Thing on Windows when Windows is installed on C: and SYSTEM32 is inside the WINDOWS directory? Same deal. If it helps, think of C:\ being roughly equivalent the root of the filesystem (i.e. /). It kinda breaks down because UNIX doesn't have drive letters, and actually Windows uses the backslash in the same way as UNIX uses the slash; note how you can use 'CD \' to go to the root of the current drive.
4) More #2. It would be much easier to have a way to kick gedit up to root so I can save xorg.conf. That'd save me having to navigate to that folder, which took 10 minutes the first time.
In addition to the earlier explanations, it's really not safe to let just any old user have write access to system config files by default. At best, they might mess them up, at worst, they may make them do bad things (install spyware, delete their home directory) to other users. If you wish, if you're the owner of the file (i.e. root in the case of xorg.conf), you can loosen the permissions on specific files using chmod.
5) Argh. More #3. My Windows partitions often have folders about 8-20 deep. Navigating with the terminal is... horrible. I may have to resize my linux partition and just stick everything on it, because accessing stuff on a shared partition with good organization is such a huge PITA.
You know about tab completion in the shell, right? Hit tab on a partial file or directory name, and it'll complete as best it can. If there are multiple matches, it'll beep. Hit tab again, and it'll show them.
6) Oh dear god. I made a shortcut to a file on an NTFS partition and put it on the desktop. The thing is, when I open it, I can't go "up" to the folder's parent folders - it takes me "up" (back) to the desktop. Great. I guess I'll get into the habbit of opening the terminal, typing "gksudo nautilus" in, then navigating manually to the folder I need on my NTFS partition, so that I can go "up" properly and cop
Ideally, installing DLLs so that they could be shared between applications (even from different vendors) would be perfect.
However, Windows has no dependency management scheme for packages, and it's unusual for DLLs to be packaged separately from applications anyway.
I see it as Microsoft shying away from 'dependency hell' in favour of 'DLL hell' (and a set of rules that, if followed by application developers, make it unlikely to be a problem in practice, albeit at the cost of reducing the usefulness of DLLs).
Interesting hypothesis and it has a certain logic and plausibility to it. If I had mod points, I'd give 'em. I'd love to know if it is accurate...
Ur doin it wrong!
Well, if international travel is a goal anyway.
Quite; about 1.5 years into my post-Bachelors career I interviewed, and got a offer for a job that required frequent international travel; Amsterdam; Vienna, Virginia; Reston, Virginia; Ashburn, Virginia; New York, New York; Miami, Florida; San Jose, California and Los Angeles, California. Yes, various machine rooms around the world that happened to host Internet exchange points. I figured one machine room and hotel room looks very much like another and passed, in spite of the superficial glamour that came with the role!