npm
-
Don't twist mine then.
-
@lucas1 I twisted nothing; I quoted your exact words back to you. Do you deny that you typed those very words?
-
@lucas1 said:
They don't have any obligation to you.
they don't have an obligation to you to support an operating system just because you want them to.
however, i would argue that they have an obligation to support an operating system that they explicitly state is supported.
NPM explicitly supports windows.
i therefore argue that they must support windows as well as they support OSX and Linux, because otherwise their documentation lied to us.
If they lack the resources to properly support NPM on windows that's all well and good, but if that is the case then they should remove windows from the supported operating systems, or mark that support on windows is a "community driven" or "best effort" affair.
If you claim to support a setup, you support it fully and stand by that support.
NPM is not doing that, therefore they should not claim that they support windows.
-
@accalia said:
NPM is not doing that, therefore they should not claim that they support windows.
Is there more evidence than whatever this roaming profile thing is? Because honestly it sounds like their caching is pretty awful everywhere from what I've read.
-
@boomzilla
npmis an integral part of Node, and Joyent fully support Node on Windows, ergo they supportnpmon Windows too. Also, thenpmdocumentation includes a number of Windows-specific items, and when packages are installed,npmcreates.cmdfiles that serve the same purpose as the symlinks it creates on Linux.I think it's a pretty safe bet to say
npmis supported Windows ;)
-
@boomzilla said:
Is there more evidence than whatever this roaming profile thing is?
there's the tissues tagged windows in their bug tracker.
https://github.com/npm/npm/issues?q=is%3Aissue+is%3Aopen+label%3Awindows
these issues go clear back to 2012 which shows that they are not doing a good job of keeping the ticketsclear and aging off the ones that have becoem irrelvant due to being reported against no longer supported versions of npm
-
NPM works fine, there are issues with it picking up the VS C++ compiler if you are running certain versions of Windows and have certain versions of Visual Studio installed e.g. If you are running Windows 7 it used to assume that VS 2010 was installed, but if you were running Windows 8 it would assume that VS2012 was installed unless you specifically told it what version of the tooling to use.
There was problems with long filenames in the past, but this is now fixed.
Now there are a lot of npm modules that will assume that you are using *nix and won't work. But that isn't the fault of npm or node.
-
@RaceProUK said:
@lucas1 I twisted nothing; I quoted your exact words back to you. Do you deny that you typed those very words?
Yes and you and others are pretending for some reason that the mean something other than I meant, which I have no explained at length so there cannot be any ambiguity.
-
@lucas1 So, to confirm, you're denying the very words people are quoting from your own posts.
I think it's clear that anything you say from now on can be ignored.
-
Oh fuck off. It is quite clear to anyone with half a brain, that there are different expectations of support depending on whether you are paying or not. Nothing I said at all says anything to the contrary including what you quoted. And apparently clarifying repeatedly what I said so there is no ambiguity isn't good enough for you or anyone else.
Stop being unreasonable.
-
@RaceProUK said:
I think it's a pretty safe bet to say npm is supported Windows
I'm not arguing that they don't say that Windows is supported. I'm asking for evidence that they treat it like a second class citizen.@accalia said:
these issues go clear back to 2012 which shows that they are not doing a good job of keeping the ticketsclear and aging off the ones that have becoem irrelvant due to being reported against no longer supported versions of npm
Hard to say at a glance. I see 244 open (and 405 closed) of 2,047 open issues tagged with windows. I didn't notice any other OS specific tags / labels. Most of them also appear to have the
supportlabel. A quick browse through there doesn't really lend itself to a diagnosis of how serious they are about supporting Windows.
-
@lucas1 And it isn't my fault you keep
@boomzilla said:
I'm not arguing that they don't say that Windows is supported. I'm asking for evidence that they treat it like a second class citizen.
Ah, I misunderstood
-
I am not. You and everyone else as per usual were being unreasonable. It a discussion, it is fine that sometimes you say something potentially ambiguous and correct it later.
Being dicks about it isn't.
-
I would argue that a lot of developers that build modules that are in the npm gallery tend to write first for *nix.
-
Heh, roaming profiles. There's so much software that just doesn't care about this or tries to but gets it wrong anyway, I'm not sure why it's still surprising. In OSS at least there aren't that many people that even run Windows, let alone run Windows in a domain, so "nobody would notice the difference" is an extremely likely scenario.
-
Doesn't NodeBB have an "Edit other people's post titles" feature?
:moon:
Hmm... off to the bug report site.
-
@RaceProUK said:
@blakeyrat I just gave you the command line to make it work
RaceProck is telling blakey but blakey decided to stick your fingers in your ears and not listen!
-
@lucas1 said:
You and everyone else as per usual were being unreasonable.
Well, you know what they say when you're surrounded by dicks…
-
-
@RaceProUK said:
Well, you know what they say when you're surrounded by dicks…
Hope you like bukkake?
-
@boomzilla Ew.
Also
-
-
@dkf I wasn't the last time I looked
-
@CatPlusPlus I've always been a fan of software being engineered to break early and often if standards aren't followed.
For example, SQL queries have no ordering by default. But the contents usually get selected in some specific order, even if you don't specify any. I want SQL Server to, maybe one query in 25, shuffle the order around just to fuck with lazy programmers who assume it'll ALWAYS have that order.
Similarly, in this case, Windows could apply a per-folder quota in Roaming AppData so that, occasionally, attempts to write more than, say, 25 MB in a subfolder there would fail.
Of course the flaw in this is that they still wouldn't fucking fix NPM, they'd just call Windows broken. Even though it's NPM shitting all over the OS contract.
-
@blakeyrat That reminds me of when I deliberately changed the string hashing algorithm in some software I was working on. Now I did it to try to find a faster hashing algorithm (and that actually failed; the hash function I replaced was stunningly fast) but it exposed a whole bunch of code that was making huge unsafe assumptions about hash iteration order, making the exercise worth it.
My point? Your ideas about changing things around while strictly obeying the contract are very good. Doing it can help find all sorts of shitty code…
-
@dkf Windows has something called a "checked build" which actually logs shitloads of warnings whenever software does bad shit. The problem is, no developers use it. (Actually I'm not even sure they still bother making it. They did for ages.)
Whenever app developers griped about some compatibility hack changing behavior, Raymond Chen would always go, "if you use the checked build, it'll tell you when that hack applies to your app" but nobody ever did.
-
@blakeyrat said:
I've always been a fan of software being engineered to break early and often if standards aren't followed.
I'm fairly sure that this wouldn't make software any better. We'd just deal with even more problems.
@blakeyrat said:
Similarly, in this case, Windows could apply a per-folder quota in Roaming AppData so that, occasionally, attempts to write more than, say, 25 MB in a subfolder there would fail.
Arbitrary limits are bad too. And say you can request that your app is special and shouldn't get quota. If users were prompted about it, they'd get annoyed that they're prompted. If it were 100% programmatic then all misbehaving apps would just learn to use that. And if you don't give a way to lift the limit, everyone would be annoyed.
-
@CatPlusPlus said:
@blakeyrat said:
Similarly, in this case, Windows could apply a per-folder quota in Roaming AppData so that, occasionally, attempts to write more than, say, 25 MB in a subfolder there would fail.
Arbitrary limits are bad too. And say you can request that your app is special and shouldn't get quota. If users were prompted about it, they'd get annoyed that they're prompted. If it were 100% programmatic then all misbehaving apps would just learn to use that. And if you don't give a way to lift the limit, everyone would be annoyed.
I think he's suggesting that writes over your 25 MB limit would still work....most of the time. Violate the contract on what you do with /tmp and the OS will violate the contract that the filesystem will behave deterministically. It's only fair.
I think it's a great idea.
-
@blakeyrat said:
(Actually I'm not even sure they still bother making it. They did for ages.)
looks like they're still available on MSDN if your subscription includes operating systems
-
@accalia said:
they must support windows as well as they support OSX and Linux
Support isn't a "yes or no" binary affair. Sometimes some things are supported better than others. Some configurations of an operating system (say, roaming profiles) may be supported less well than the vanilla configuration.
@accalia said:
"community driven" or "best effort"
It's open source and you paid nothing, all support is best effort.
-
@another_sam said:
Some configurations of an operating system (say, roaming profiles) may be supported less well than the vanilla configuration.
Since Windows Vista, roaming profiles are the vanilla set-up
-
@blakeyrat THAT is what the checked build is? I'd heard the term but assumed it was mostly targeted at driver devs.
I shall poke this...
-
@Weng I believe it is targetted at driver developers, given the ability for drivers to screw system stability royally. Still, if you have access to it…
-
@RaceProUK said:
Since Windows Vista, roaming profiles are the vanilla set-up
I did not know that, but it was just an example, you rainbow-coloured horse clown.
-
@Weng I'd be lying if I said I'd used it myself.
My understanding is that it's for all Win32 apps, and also drivers. Specifically, that it answers the question, "how many compatibility shims is my app activating via its behavior, and what are they specifically?"
-
@blakeyrat Since my stuff is .net, but I depend on an unholy fuckload of ancient garbage, this may help me with my "we are truly, madly, deeply fucked with technical time bombs" arguments.
-
-
@boomzilla said:
@RaceProUK said:
Since Windows Vista, roaming profiles are the vanilla set-up
Waaaaaaaaaaaaat?
I think there's a little confusion there.
Vista introduced the new default home folder tree, rooted at
C:\Usersinstead ofC:\Documents and Settings. As part of that,C:\Documents and Settings\%username%\Application Datagot tidied toC:\Users\%username%\AppData\Roaming,C:\Documents and Settings\%username%\Local Settings\Application DatabecameC:\Users\%username%\AppData\Local, and a new thing calledC:\Users\%username%\AppData\LocalLowgot added.The fact that what used to be called Application Data is now a Roaming subfolder of something called AppData doesn't change what they're for. Both of them are where roaming profile stuff goes if you're attached to an Active Directory domain with roaming profiles enabled. If you're not, there's no roaming despite the new folder's name.
Putting cache stuff under
C:\Users\%username%\AppData\Roaminginstead ofC:\Users\%username%\AppData\Localis wrong and stupid, just like putting it underC:\Documents and Settings\%username%\Application Datainstead ofC:\Documents and Settings\%username%\Local Settings\Application Dataalways was.There are predefined environment variables that point to these things.
%APPDATA%has the pathname of the root folder for per-user roamable application data, and%LOCALAPPDATA%has the pathname of the root folder for per-user per-workstation local application data. Using the first where you should have used the second is just sloppy.
-
@flabdablet said:
There are predefined environment variables that point to these things.
Those are just values pulled out of the system configuration API, at least as I understand it.
-
@dkf I believe that's true. I look on them as a kind of weak-sauce GetSpecialFolders API for cmd scripts.
-
@boomzilla said:
Waaaaaaaaaaaaat?
She just means that Vista separated the AppData folders into a Local and a Roaming portion.
That doesn't mean the Roaming feature is turned-on. It does mean that (assuming application developers aren't shitty idiots who suck at their jobs) once you turn Roaming on, a hell of a lot less data will actually roam.
-
@flabdablet said:
@dkf I believe that's true. I look on them as a kind of weak-sauce GetSpecialFolders API for cmd scripts.
reply
cmd scripts are like doubly obsolete now. They were replaced by JScript/VBScript running in Windows Scripting Host, now those have been replaced by PowerShell.
Both WSH and PowerShell have direct access to the API used to get those paths properly. Please stop using doubly-obsolete software.
-
-
@Jaloopa said:
Has anyone ever used these?
Hundreds of thousands of people. Probably millions. Possibly billions.
Yes, that's been the correct way to script Windows since, what, Windows 98? 95 OSR2? I don't remember but: Ages. Fucking ages.
-
@blakeyrat said:
Vista separated the AppData folders into a Local and a Roaming portion
The earlier layout had that separation of function too. Vista just tidied up the folder names.
@blakeyrat said:
[jscript/vbscript in WSH has] been the correct way to script Windows since, what, Windows 98? 95 OSR2? I don't remember but: Ages. Fucking ages.
And cmd still got used well after those were released, mainly because cmd scripts are way, way easier to debug and usually considerably more concise.
There is still a place for cmd in modern Windows. I wouldn't use it for anything that actually needs the firepower of a more capable scripting language, but if what you need to get done involves invoking a bunch of Windows console executables it's still the easiest tool in many cases.
-
@blakeyrat said:
The problem is none of this shit works, and when it fails (which is inevitably does), there's no fucking error messages.
The "solution" is a series of magical incantations involving deleting various folders of cached shit.
It's night-and-day with, say, MSBuild which is reliable like few other pieces of software.
Did you seriously just say that? I don't know what you've been building with MSBuild, but when any little thing goes wrong with the build configuration, you end up with nothing useful for tracking it down.
Not to mention it's all in XML, so you're already deep in "now you have two problems" territory before you even start...
-
@flabdablet said:
If you're not, there's no roaming despite the new folder's name.
Not quite. Store apps use this folder to sync data between any devices the app is installed on.
-
@blakeyrat said:
This tool is awful.
JavaScript is awful. Node.js is fucking awful. But npm? It's just "embarrassing" and "pitiful".
The code itself is pre-obfuscated (those smarmy fucks don't believe in semicolons unless they're absolutely needed), and it's as if each "module" (or whatever-the-fuck the "let's pretend JavaScript is a grown-up programming language" term they use to describe their shit functions) is an entry for a front-page TDWTF CodeSOD.
This is the result of throwing $10M at a bunch of San Francisco, JavaScript hack
ers with no experience writing any software, ever.
-
@flabdablet said:
mainly because cmd scripts are way, way easier to debug
That is a fucking lie. WSH had a full integrated development environment, including a graphical debugger. It's not Microsoft's fault if morons weren't using it.
-
@apapadimoulis Yeah. For $10 million, they can't write a standardized string functions library.
Have I mentioned lately how glad I am to live in Seattle, where the tech industry (even the startups) are sane? Because I am. Fuck the Bay Area.
