Android SDK install path cannot contain spaces...
-
How did 1, 2, 3 in the original message become previewed etc. as 1, 1, and 0 ?
Check the raw in my message, and then ask why it didn't render it the same when quoted…
-
If only there was a standard way of getting the correct folder 100% of the time...
<tonguestuckoutwinkyface>
-
FFS dude, use the GDMF APIs that allow you to find out the correct names on the machine you're running the install on!
"Hey {insert coworker(s) here}, we've got a beta of the new drivers ready for testing. We don't have an MSI installer ready yet, just drop these files in your System32 folder and do a 'Scan for Devices' in device manager and it should work. No, not that System32 folder, the other one...Yes, I know it's confusing. Here's the difference. No, this is the exact same thing I explained last week, and the week before, and the week before...No, they were not reversed last time, Syswo64 is always 32-bit and System32 is always 64-bit...yes I know it's confusing, here's why it works that way...no that's a Microsoft thing, I can't fix it...yes I know customers hate it too...they shouldn't be doing that, we have installers that take care of all of it for them...yes I know your customer is a special snowflake and needs to manually poke around in System32 because he's an idiot..."
-
"Hey {insert coworker(s) here}, we've got a beta of the new drivers ready for testing. We don't have an MSI installer ready yet, just drop these files in your System32 folder and do a 'Scan for Devices' in device manager and it should work. No, not that System32 folder, the other one..."
A beta, and no installer? Shoot whoever says that. If it's you, shoot yourself.
-
@mott555 said:
"Hey {insert coworker(s) here}, we've got a beta of the new drivers ready for testing. We don't have an MSI installer ready yet, just drop these files in your System32 folder and do a 'Scan for Devices' in device manager and it should work. No, not that System32 folder, the other one..."
A beta, and no installer? Shoot whoever says that. If it's you, shoot yourself.Sorry, that was meant to be for @mott555. Seriously, dude, if you're calling it a beta, you release it in an installer, or you wait until you can. Otherwise it's just people fucking about with files.
-
Internal beta you doofus. I'm not going to spend hours running through the full build process just to install a driver package and find out it BSOD's the system in 16 seconds flat...I'm going to compile the drivers which takes thirty seconds and give him the .sys/.dll files...
-
yes I know customers hate it too...they shouldn't be doing that, we have installers that take care of all of it for them...yes I know your customer is a special snowflake and needs to manually poke around in System32 because he's an idiot..."
No support for morons who fuck around with the software. Seriously. Microsoft KB entries that say "here's how you can fuck about in the registry to resolve this" also tell you that if you fuck it up, they might not be able to help you fix it, and by implication, "too bad, so sad." Installing driver files by hand is the same thing.
-
Internal beta you doofus. I'm not going to spend hours running through the full build process just to install a driver package and find out it BSOD's the system in 16 seconds flat...I'm going to compile the drivers which takes thirty seconds and give him the .sys/.dll files...
Ah, so pre-alpha that you call beta, gotcha. You're in the same boat that lots of other places are, including many I've worked at, but that doesn't make it right.
-
I would agree, but sales guys are an interesting breed and are willing to take in any idiot with cash. "Yes I know this guy's a complete moron but it was a $500k order so do what you need to to walk him through this system32 nonsense without hosing his system."
-
Hardware vendor here. We stuff things in those folders all the time due to authoring device drivers and user-mode hardware access APIs. Even our engineers get System32 and Syswow64 mixed up al the time. It's cnofusing as hell and I hav eto explain the difference about six times a month.
You are undoubtedly doing something wrong. I don't know what, exactly.
Curiously, the "Program Files" thing is even more broken, historically, than you think.
Ok...
On Win7 and after (possibly on Vista - I never had that particular pain), Explorer aliases lots of system-like folder names to localised equivalents. So it's "C:\Program Files" always (except when you're running Win64, when it's "C:\Program Files (x86)" and "C:\Program Files"), b
Blah blah blah. So when you say "broken" what you mean is "not at all broken". It's in the OS contract that those folders can change path and name; there's no break there. Correctly-written software would have had absolutely no issues. It would have no issues if Microsoft changed the name of those folders every week.
I like to think, but I'm probably wrong, that Microsoft changes them periodically just to suss-out shitty software and made it break, but alas they don't do it often enough for that to be the case.
"Hey {insert coworker(s) here}, we've got a beta of the new drivers ready for testing. We don't have an MSI installer ready yet, just drop these files in your System32 folder and do a 'Scan for Devices' in device manager and it should work.
Why not hit "Scan For Devices" then "Have Disk"? Then you can put it in any folder.
Either way, if you're not testing the installer, you're not testing the product. The installer's one of the most important parts.
they shouldn't be doing that, we have installers that take care of all of it for them...
Installers that you don't test! Really building my confidence as a customer up, there! Sure the driver can give you a bluescreen, boo hoo, meanwhile the component of the product that could DELETE ALL YOUR FUCKING FILES isn't tested at all.
Is that another part of your speech? "Yes, we hate our customers. Yes, we give them broken shit all the time that we didn't bother testing. No, it's not a Microsoft thing. Yes, we're dickwads."
-
Either way, if you're not testing the installer, you're not testing the product. The installer's one of the most important parts.
Installers that you don't test! Really building my confidence as a customer up, there!
Where did I say I don't test installers?
I think we need a shoulder alien emoji.
-
If you're not testing it during the beta, when the fuck ARE you? 4 months after release?
-
Why not hit "Scan For Devices" then "Have Disk"? Then you can put it in any folder.
Because Windows is retarded and somehow caches that path reference, so with the more disorganized engineers who have eleventy billion old driver folders floating around Windows will lie and tell you it's running one version of the driver but actually load a totally different version from a totally different place.
-
Why not hit "Scan For Devices" then "Have Disk"? Then you can put it in any folder
Or even provide it with a batch script that copies it into the correct folder?
-
Beta is the wrong word, it's just the term we use because "alpha" causes blank stares. Everyone knows what beta means, even if their definition is wrong.
-
@Steve_The_Cynic said:
Curiously, the "Program Files" thing is even more broken, historically, than you think.
Ok...
On Win7 and after (possibly on Vista - I never had that particular pain), Explorer aliases lots of system-like folder names to localised equivalents. So it's "C:\Program Files" always (except when you're running Win64, when it's "C:\Program Files (x86)" and "C:\Program Files"), b
Blah blah blah. So when you say "broken" what you mean is "not at all broken". It's in the OS contract that those folders can change path and name; there's no break there. Correctly-written software would have had absolutely no issues. It would have no issues if Microsoft changed the name of those folders every week.
I like to think, but I'm probably wrong, that Microsoft changes them periodically just to suss-out shitty software and made it break, but alas they don't do it often enough for that to be the case.
I'm having a clarity failure day, obviously. I meant that the crappy software and/or installers are broken, not that Windows itself is broken in any way(1). You might have noticed my exhortation to use the "GDMF API" for this...(1) In any way related to these folder names, that is.
-
Windows does not use the LSB, so it is broken by default.
-
Windows does not use the LSB, so it is broken by default.
I would suggest that not using lysergic acid 2-butyl amide when creating operating systems is probably a good thing.
-
People are going on and on about how Windows uses a compatibility layer to resolve which folder things go into as if it was a good thing. Linux doesn't need one. It has the Linux standard base.
The compatibility layer just shifts the maintenance burden (i.e., none, if you follow the standard on each platform).
-
And of course since it's Linux, the awful name is there to stay forever. Because nobody can ever change anything, ever. There's no APIs to look up the correct path, like in better OSes, so it's just wrong for all time.
There has to be a well known something. The choice is between well known directory name and well known identifier in some API. The former, which unix chose, is simpler. The later, which windows chose, solves absolutely nothing except
Unfortunately, the same is true in Windows, given how many applications hardcode "C:\Program Files".
provided opportunity for applications to use it wrong.
In Un*x the directories are well known, so relying on them is correct and applications can't get it wrong and there is no need for additional API and Average Joe User does not really care anyway, because he does not need full paths to programs often and when he does, they are just magic incantations to him whether they start with
/usr/,c:\Program Files (x86)orc:\PROGRA~2.So it's "C:\Program Files" always (except when you're running Win64, when it's "C:\Program Files (x86)" and "C:\Program Files"), but when you look at it in Explorer on a localised version (I'll use the French version, 'coz that's what I have), you see something like "C:\Programmes".
Mobile systems do that kind of thing as well. Symbian S60 for sure did (e.g. the SD card had
Pictures, but the built-in file browser showedObrázky). And I think Android does too, but I can't check, because I've set my new phone to English, because I prefer dealing with English¹ over dealing localization-challenged apps and localized messages that Google knows nothing about.On versions up to and including XP, it wasn't like that. If you had the localised versions, it localised the true names of the directories, so it really was "C:\Programmes". This, obviously, caused some amusement when localisation-challenged outfits tried to start distributing their software outside the English-speaking world.
Which is exactly the reason Microsoft changed it.
/usrmeans nothing, so nobody wants to localize it and everybody's life is simpler.
¹ The only think that irks me a bit is that I can't change the date separator from the ambiguous
/to.we normally use here. And the thousands separator to space as nobody uses that for decimal point. On Windows, both things can be set and on GNU/Linux² too as I can set the locale categories independently there.² Because Android is also Linux. …which leads me to:
Yeah; and go out of your way to do so by naming the folder after an OS you're not even running. "lsr" at least would sound like "loser", a good description of the average Linux user.
Well, that would make no sense at all anyway, because there are no Linux resources there. All the Linux resources live in
/boot. In old times they sometimes lived directly in/and now they may also live in/efi. But definitely not/usr-or-whatever-you-want-to-call-it.And it totally is an OS you are running, because Unix is now a generic name for everything POSIXish.
-
In Un*x the directories are well known, so relying on them is correct and applications can't get it wrong and there is no need for additional API and Average Joe User does not really care anyway
I wish this were true. Depending on distro/customer/planetary alignment, stuff often goes in one or all of the following, and no one anywhere can tell us what the difference is:
- /usr
- /bin
- /usr/bin
- /usr/sbin
- /usr/local/bin
- /usr/local/sbin
- /usr/bin64
I'm sure there are about 19 others I'm forgetting. We might be weird though, because we support so many versions of Linux and Linux-like operating systems. Despite there being a standard it's often ignored, especially when it comes to $500k orders to idiots who think rolling their own version of a distro from 1999 but with kernel version 4 while cross-compiling everything from another system with a totally different kernel and distro is a good idea.
-
People are going on and on about how Windows uses a compatibility layer to resolve which folder things go into as if it was a good thing. Linux doesn't need one. It has the Linux standard base.
The compatibility layer just shifts the maintenance burden (i.e., none, if you follow the standard on each platform).
Reading comprehension isn't your strong point, is it?Windows has a non-fixed layout, sure (historically, even the name of the base directory that's now "C:\Windows" wasn't necessarily fixed - on Windows NT it was C:\WINNT, while it was normally C:\WINDOWS on the 16-bit line that eventually became Windows 9x), but it has well-defined APIs so that programs (including installers) can find out what the names of those folders are on the current machine.
So you don't need to have a fixed (including directory names) layout on the disk - you just ask the system where things should go, and use the information that it gives you. The "logical" layout is the same - these things go in this location - but you don't have to keep the location's physical name fixed forever. It is accessed using a sort of "logical name", that is, what the API told you when you asked it.
The compatibility layer discussion centres around the stuff that allows 64-bit builds of Windows to effortlessly run code written for 32-bit builds, and the slightly peculiar name of the directory where its components live.
-
- /usr -- root of a hierarchy, binaries should not go in there
- /bin -- basic system binaries. things the system needs in order to load itself.
- /usr/bin -- installed binaries
- /usr/sbin -- installed binaries that require administrator/root to run
- /usr/local/bin -- locally installed binaries (i.e., installed from source instead of by your package manager)
- /usr/local/sbin -- locally installed administrator-requiring binaries
- /usr/bin64 -- 64bit installed binaries (this really only exists in 32 bit systems with a 64 bit run-time)
-
Are you a bit retarded?
People are going on and on about how Windows uses a compatibility layer to resolve which folder things go into as if it was a good thing. Linux doesn't need one. It has the Linux standard base.
Reading comprehension isn't your strong point, is it?
Windows has a non-fixed layout, sure (historically, even the name of the base directory that's now "C:\Windows" wasn't necessarily fixed - on Windows NT it was C:\WINNT, while it was normally C:\WINDOWS on the 16-bit line that eventually became Windows 9x), but it has well-defined APIs so that programs (including installers) can find out what the names of those folders are on the current machine.
So you don't need to have a fixed (including directory names) layout on the disk - you just ask the system where things should go, and use the information that it gives you. The "logical" layout is the same - these things go in this location - but you don't have to keep the location's physical name fixed forever. It is accessed using a sort of "logical name", that is, what the API told you when you asked it.
The API solves nothing that a sensible standard wouldn't solve.
To wit: the Windows developer really has to ask the Windows API manual which method to call to get the right directory for, say, log files. As opposed to the Linux developer who has to look at a standard to find the right directory. There is no difference in the complexity exposed to the developer -- log files go somewhere, and he has to look at a dictionary-like data structure to figure out where.
-
Because Windows is retarded and somehow caches that path reference
Why are you doing alpha testing on machines you can't roll back to a known, pre-installed state?
-
The API solves nothing that a sensible standard wouldn't solve.
To wit: the Windows developer really has to ask the Windows API manual which method to call to get the right directory for, say, log files. As opposed to the Linux developer who has to look at a standard to find the right directory. There is no difference in the complexity exposed to the developer -- log files go somewhere, and he has to look at a dictionary-like data structure to figure out where.
That's fine, so long as not one of those fixed locations ever changes. EVER. (The dreaded words "breaks backwards compatibility" appear in a description of the LSB version 5.0. That, in and of itself, is probably more retarded than this entire discussion. (I suppose that's evidence that, according to your definition, the LSB 5.0 isn't a "sensible standard".)With one exception, the ability to ask the system where a particular sort of file should be makes you immune to that sort of change. The one exception is if someone decides that it is necessary to subdivide a particular type of file into two areas.
-
As opposed to the Linux developer who has to look at a standard to find the right directory.
And then puts logs wherever he damn well pleases anyway because it looks better to him to put logs in
/home/bamboothan/var/log/sc
-
I would agree, but sales guys are an interesting breed and are willing to take in any idiot with cash. "Yes I know this guy's a complete moron but it was a $500k order so do what you need to to walk him through this system32 nonsense without hosing his system."
"OK, Mr Customer, to install the software, launch the .MSI."That's what you need to do to walk him through the system32 nonsense without hosing his system.
I mean, really, if he's prepared to do it by hand, he's too stupid to be allowed to touch any sort of technology, all the way down to not letting him bang the rocks together. It's actually amazing that there is enough squishy stuff between his ears to make him breathe without mechanical aid.
-
These are typically just developer machine
Why are you doing alpha testing on machines you can't roll back to a known, pre-installed state?
s in the office. I havve a few dedicated test machines bhat doesn't beat having engineers actually sit down and write/test software against the latest low-level bits.Hoyl Disocurse how do yoourew up text entry this bad??
-
Look, if your developers can't uninstall correctly, I can't help you there.
-
Disocurse
I LOVE how Discourse's composer stopped processing keystrokes in the right order and changed the word into this. It's becoming self-aware!
-
When I was working on testing ATM software, we had machines with emulated hardware (either software emulation or hardware emulator boards) that we had snapshotted to a known state. We could then install the new driver, test with it, roll back, and install the next build. You would hope devs could uninstall correctly on their own machines.
-
You would hope devs could uninstall correctly on their own machines.
We have very few here who understand anything about drivers. Somehow I am now the driver expert and I know next to nothing about them...I'm guessing there was a lot of turnover before I was here.
-
Beta is the wrong word,
Then why did you type it here?
it's just the term we use because "alpha" causes blank stares.
Ok; your co-workers are too stupid to get alpha, beta. Got it. But we're not, and you're talking to US now, not your moron co-workers.
Everyone knows what beta means, even if their definition is wrong.
Based on what you just said, I have no idea what "beta" means when you type it.
-
Am I now supposed to have some kind of translation/localization dictionary in my mind that automatically replaces office words with TDWTF/Blakeyrat words and vice versa? Maintaining that would be a full-time job due to
-
People are going on and on about how Windows uses a compatibility layer to resolve which folder things go into
It's not a compatibility layer; it's part of the Win32 and WinNT OS contract. Using the API to locate standard folders has been part of the OS since day one.
as if it was a good thing.
It is a good thing. There's an example right up-thread. Where Americans can see "Program Files" and the French can see "programmes" or whatever. Sure it's a small win, but a win's a win.
It's a hell of a lot more useful when it comes to locating USER files, there it enables a ton of features that allowed Windows to dominate the corporate market in the first place.
Linux doesn't need one. It has the Linux standard base.
Right; which every Linux distro follows to the letter, right?
Oh.
-
There has to be a well known something.
Well ok.
The choice is between well known directory name and well known identifier in some API.
Ok.
The former, which unix chose, is simpler.
And less flexible/powerful.
But I guess when you name your folders gibberish it matters less that you can't localize them.
The later, which windows chose, solves absolutely nothing except
provided opportunity for applications to use it wrong.
If the applications are doing it wrong, they're doing it wrong. That has nothing to do with the design of the OS. Unless you think every OS should be a pile of broken shit because application developers are lazy fuckers. If so, we're just going to have to agree to disagree.
Windows also allow application developers to set the volume to maximum and play overlapping howler monkey sounds. How do you propose the OS be changed to prevent that from happening and still allowing, say, Audacity to run?
In Un*x the directories are well known, so relying on them is correct and applications can't get it wrong
Hahahaha. Citation fucking needed.
/usr means nothing,
Oh so now it no longer means "unix system resources"? It's just gibberish?
You gotta get together with your fellow Linux lovers here and get your story straight, buddy, because just a few posts ago we were told it stood for "unix system resources".
-
It is a good thing. There's an example right up-thread. Where Americans can see "Program Files" and the French can see "programmes" or whatever. Sure it's a small win, but a win's a win.
It's a shim that does almost literally nothing. It solves no problem. Why should the user even be looking at the "Programmes" directory? Windows has a fancy graphical UI, with menus and start bars and installers and uninstallers. It ought to be called "XYZZY" for all the user should care. And then it could be standardized, instead of internationalized. And then a useless API could be gutted and eventually deprecated.
-
/usr -- root of a hierarchy, binaries should not go in there
Every folder's the root of a hierarchy, how is that relevant?
/bin -- basic system binaries. things the system needs in order to load itself.
... but which aren't "system resources", somehow.
/usr/bin -- installed binaries
Installed by whom? The user? In that case, why are they in system resources?
/usr/sbin -- installed binaries that require administrator/root to run
What does the S stand for? Lemme guess: sudo?
/usr/local/bin -- locally installed binaries (i.e., installed from source instead of by your package manager)
... huh? Wouldn't a locally installed binary be in a user's folder? Why would it be in here?
-
To wit: the Windows developer really has to ask the Windows API manual which method to call to get the right directory for, say, log files. As opposed to the Linux developer who has to look at a standard to find the right directory. There is no difference in the complexity exposed to the developer -- log files go somewhere, and he has to look at a dictionary-like data structure to figure out where.
Windows has Roaming Profiles; Windows sold millions of copies because it had Roaming Profiles.
I don't think Microsoft agrees with you that the level of indirection is pointless. It made them shitloads of money.
-
So does Linux. To wit -- mount your home folder on any machine in the world.
-
Am I now supposed to have some kind of translation/localization dictionary in my mind that automatically replaces office words with TDWTF/Blakeyrat words and vice versa?
It would help you avoid the criticism you got this morning.
-
I've had this conversation with Linux fans before and we can to the mutually-agreed-upon resolution that Linux did not have an equivalent to Roaming Profiles. I'm not going to have the same conversation again.
-
It would help you avoid the criticism you got this morning.
Yeah, but to be fair, he came here and the criticism was free.
-
Great, let's pretend you've had all the conversations about Linux and Windows and UIs for that matter. We'd love it if you would STFU.
-
Speak for yourself.
-
And less flexible/powerful.
But I guess when you name your folders gibberish it matters less that you can't localize them.
Localization is poor excuse as it makes little sense for the system directories (it makes some sense for the Pictures and Videos and such, but they should be user-configurable anyway). And I don't see any other use for the flexibility.
If the applications are doing it wrong, they're doing it wrong. That has nothing to do with the design of the OS.
If the applications are doing it wrong, they are doing it wrong. But if the OS is making them jump through two hoops where a straightforward solution would work, it the OS is doing it wrong.
Oh so now it no longer means "unix system resources"? It's just gibberish?
Yes, it no longer means that. It is just name that exists for histerical raisins. And it was never a good name anyway (because system resources were always the ones outside
/usr;/usrcontains the applications).You gotta get together with your fellow Linux lovers here and get your story straight, buddy, because just a few posts ago we were told it stood for "unix system resources".
No, we were told that's how the name was created. And not by me anyway.
So does Linux. To wit -- mount your home folder on any machine in the world.
That's not a roaming profile. Roaming profile makes some things shared across all machines you work on and others local (like caches and such). That does not work with network-mounted
~.I have never seen them really implemented and most applications probably get the split wrong anyway.
-
But if the OS is making them jump through two hoops where a straightforward solution would work, it the OS is doing it wrong.
A single API call is two hoops?
-
Yes. One is calling the API and one is assembling the final path in a dynamic string instead of just using a static one.
-
Oh, you're so right! How much a fool have I been? How could I have not realised that string concatenation is the Devil's work?
Seriously, if you're going to defend the choice of
/usrinstead of an API call, at least construct a defense based on the state of computing in the 70s; you'll find it a much firmer base to build on.
