Wednesday, August 30, 2017

Photobucket finally just bit me :)

2017.08.30

Came in here to add a pink flamingo marionette ad (from Amazon) to my sidebar over yonder ~~~~>

That's when I just tripped over this:


*heh!*

A while back, I read something about how half a bazillion images across the entire Internet were suddenly going to go blank. That's not quite true. Instead they look more like that "PLEASE UPDATE YOUR" image just above. If the original image had been larger, you could have read the whole message.

They advise that you need to sign in quick and take care of business. In other words, after all these years, everyone who ever hosted a Photobucket image on a third party site either pays up or takes some other proactive measure to send that "PLEASE UPDATE YOUR" image packing.

They allege you can still access your images even if you don't pay up. I guess I'm about to find out firsthand.

Was just looking at mine the other day. It was a Pegasus horse that I threw in as an afterthought icon a number of years ago. I was thinking Pegasus was part of a collection I have and thus more easily retrievable, but, nope, I'm now remembering that "collection" was 100% butterflies. *go figure!*

Guess I'll adapt one of those and take it from there. Now to find a place where I can host it without the fear of losing it again probably much sooner than later this time. It's not hard to imagine other image hosting websites following in step with Photobucket... which... you know... it's just about business... is all it is right there. :)

No hard feelings, Photobucket. You make a *_CHOICE_*, I make a *_CHOICE_*, you make a *_CHOICE_*, I make a yada-yada.... :)

Now where was I...............? Oh, right... Amazon ad... adorably adorable *PINK!* Flamingo Marionette! Sidebar..... right over there ~~~~>

Wednesday, August 23, 2017

New Linux Kernel: The Elves Made Me Do It...

Last night (2017.08.22) there was an announcement that there was a bouncing baby new update release for npm so I attempted to install it:

npm i npm -g
/home/candycane/.npm-g/bin/npm -> /home/candycane/.npm-g/lib/node_modules/npm/bin/npm-cli.js
/home/candycane/.npm-g/bin/npx -> /home/candycane/.npm-g/lib/node_modules/npm/bin/npx-cli.js
+ npm@5.3.0
updated 1 package in 14.971s


That... only took 15 seconds versus the now anticipated (and fairly normal) half hour. It's supposed to be... v.5.4.0, but that says 5.3.0 as does npm -v. *?*

So I just set it to the side and moved on to attempting to get hsfconfig to actually config my HSF modem. Yeah, I know ~~~~> *ewwwww*

A long time ago, I had that all working. Unfortunately there have been a number of hard drive crashes during times when I couldn't afford backup supplies. That meant I lost all my notes including some seriously tear stained ones about the whole HSF modem process. *sighhhh*

Things I can still remember to do include popping over to Linmodems, catching up on their methodology, and then attempting to apply it to my user specific setup. This also coincidentally came up on Debian-User. I need to finally read all the way through and see what they ended with as a final outcome there at Debian.

It feels like that was the thread where it was suggested to the OP (original poster) that their time would be better spent just buying a hardware based modem instead of fighting this many years' long issue. I am more like the OP in this case. I have learned a ton of shtuff while fighting... this very specific and very many years' long proprietary software issue.

Somewhere in the middle of all this, I got the bright idea to additionally... take this opportunity to self-teach on how to mangle install... the latest stable Linux kernel offering from kernel.org.

Yeah, I don't know, either. I guess the mischievous little elves twiddling their thumbs somewhere in the back of my mind decided I just hadn't flocked things up enough yet.

So where that's at this second is that last night I started following the destructions on the KernelBuild Guide to building the Linux kernel page k/t kernelnewbies. Even posted my first post on their listserv last night, mostly a quick recap of my own current path and a few related links if I'm remembering correctly.

Their KernelBuild notes seem to do the trick. I had spent over an hour the night before trying to find something, anything that was cognitively friendly. That search eventually and finally pointed back to kernelnewbies whom I had just found days before that. *here's your sign*

It takes many hours to attempt this, but most of that time is you giving your computer its head... while you go out to see a movie. #Life Lesson learned on the fly is that you probably better make that movie a double feature.

The preliminary steps include installing some additional software that occasionally involves a "dev", as in developer development type, identifier. For most people, that install step is pretty painless these days.

Years ago *for me*, that step was a show stopper because those packages had to be built from scratch. Invariably those show stoppers would fail more often than not and for nearly every reason known under the Sun. Except that, uh-uh, nuh-uhhh, they did not have to be built from scratch, even back then.

What I didn't understand back then was how many Linux distributions work. The installation process is semi-automatic these days. The user's only chore in most cases is to decide what they'd like to see installed on their computers. After that, their favorite package manager takes over and completes the process.

For me, that "package manager" is apt-get. A browser's CTRL+F or similar "find" feature used on the words "package manager" will land a few viable alternatives on Debian's admin packages subsection.

That admin packages subsection is specifically for Debian Buster Testing which is the release that I'm using right now. To switch to another release's similar page, it's as simple as replacing the word "buster" in the link, the URL, with others like stretch, jessie, wheezy, and sid. That's a very nice feature that saves wear and tear on their servers, for one thing, because web surfers don't have to mess around with in between links to get what we need.

Ok. Newly churned up Linux kernel. It's apparently done. It rumbled on for a long time throughout the night. That part comes from the mix of deciding on your .config file choice and then performing the make command. I went the cp /boot/config-`uname -r`* .config to snag my existing, working config file and then simply ran make.

That secondarily suggested make -jX deal felt like it did something funky. I canned it, ran make clean, and tried it again just as make. I'll read up on it one of these days if going that route suddenly becomes a tweak that I need to do to help chug things along a little faster than last night. #toDo. :)

The only thing I had to do when I got up this morning was:

sudo make modules_install install

The KernelNewbies author rambles a second there about install options, but that specific line worked perfectly fine on my end. I started out by verifying the potential existence of the author's "installkernel" reference. locate installkernel said, "Yup, it's there." Implementing the related sudo make modules_install install command took way less time than the initial compile, but it still took a while.

AND... it went ahead and ran update-grub while it was at it. That's a nice perk, Debian. #ThankYou :)

Now I need to reboot. What they're saying there at the end about reboot'ing is that you need to know how to seriously manipulate whatever controls your boot process.

After the "installkernel" process, I checked my /boot/grub/grub.cfg. There were references to both kernels now residing on that partition which reminds me there's still one more step left. All my manually created possibilities in /etc/grub.d/40_custom were in the house, too.

That means it's almost time to attempt a reboot. That thing that I was just reminded of, though, was that I need to go in as root... and point /vmlinuz and /initrd.img at the new configuration files. That's done with symlinking. As example, *I* manually perform that action via ln -s boot/initrd.img-4.12.8 initrd.img while sitting in the root directory followed immediately with similar for vmlinuz.

Next step is to verify that the size of the symlinks matches the file they each respectively point to in the /boot directory. If their sizes don't match, that's my sign that something went wrong with the symlinking.

Today's new symlinks do match up right, but, wow, what a difference in size. The old /initrd.img was 18.7MB, and the new one... is a whopping 249.9MB! OUCH!


#1 I wonder how that will affect boot up time. #2 is that I understand that it's because(y) I did the whole raw kernel deal. The smaller, previous one was basically pre-existing somehow with respect to being only AMD64 indicated. *that makes sense* :)

I really need to stop, reboot, and test it. That's scary... is what that is...... but here I go-o-o-o-o!!

!!!!****WOOHOO, IT WORKS****!!!!

There didn't seem to be a significant time lag in the bootup time, either. I did catch one heart stopping flash on the screen where it said......

RIP

NO JOKE. I actually gasped as that flipped by. I don't know what it had to do with, and I'm in too much forward motion right now to attempt to track it down via a grep in hopes of tripping over a log containing that very small word.

NOW... I am... what am I doing? Oh, installing the latest opera-beta browser. Again, yeah, I know. It seems like almost every browser has its detractors these days. That one is working more often than the rest do on dialup for *ME* so there you go.

In the process of installing that, I just realized what a message had been telling me before. The way I've been installing opera is to go to their website, manually download the latest update (via wget -c [Internet-path-to-file]) if one exists for Linux, and then dpkg -i [entire-package-name] from within the archive's new home directory.


While running dpkg -i, the first window says:

│ Opera can configure your system to include new versions of the Opera
│ package together with the regular system upgrades. Enabling this option
│ is highly recommended to make sure you receive critical security updates
│ in a timely manner.

│ If you agree, Opera will install a file into /etc/apt/sources.list.d, so
│ that the Opera package is upgraded to any available newer release as
│ part of your regular system upgrade.

│ Do you want to update Opera together with the rest of the system?


To which I each time emphatically have replied, "OMG, YOU WANT TO DO WHAT WHERE?!?!?!"

*heh*

As of my experience with installing npm and nodejs recently... *I'm over it*

What that wants to do is create a file that points to the repository that contains the files, the opera/opera-beta archives, exactly like the ones I've been manually downloading when I remember to do so. This was a #Life Lesson learned on the fly this past week when I stumbled over where nodejs had quietly installed /etc/apt/sources.list.d/nodesource.list in my file hierarchy. *ok, now I see*

So now I understand more. And I'm going to go the route of letting opera do what nodejs did. My poor Debian is no longer a pure anything, but it's working, and I'm talking about resources I trust because of how high profile they are right now. #doneDeal.

This is the end result of what it all has my permission to do (until further notice):


The image is depicting that my /etc/apt/sources.list.d directory now contains both nodesource.list and opera-beta.list. Let's hope I continue to remember that I played an active role in how they got there.... :)

After dpkg -i [full-package-name] came that gut wrenching moment where you open the browser up... and there was that brand new window... with not one single one of my old currently-in-use tabs to be found. *cr4p*

Took me a few seconds to decide to go to the /home/[user] directory (via file manager thunar) and nose around for anything that looked familiar. CTRL+H to display hidden files and directories unearthed .cache and .config. I hit up .cache first, but only for a few seconds after I remembered it's one directory I block during my rsync backups. That means it's not a player here.

Next I went into .config, and there they sat... side-by-side... opera and opera-beta with their own, separate directories. That means opera-beta created its own whole new thing and that I now need to figure out how to move my old history into that directory.

First way I thought to do so was to simply copy and paste as myself. That failed. Quick instant memory recall was that copy and paste found some special files that I couldn't copy over as a normal user. Had I tried to do so as root, that might have worked but would then ultimately fail. My experience is that root plants its hardcore (inaccessible) permissions on files it copies and pastes via right click yada-yada.

Enter rsync which handles special files most fabulously. And that's exactly what it did because opera-beta began to immediately display my previous tabs and bookmarks afterward. We are so talking *SCORE*!

On that high note, I do believe that I'm going to take a break. My brain's not sure where to go next after all this successfully successful success this morning. *kvell-kvell!*

* to be continued.......... *

Friday, August 18, 2017

One recent morning started out with the previous night's upgrade of nodejs still sitting there waiting:

Get:1 https://deb.nodesource.com/node_8.x buster/main amd64 nodejs amd64 8.3.0-1nodesource1~buster1 [13.2 MB]
Fetched 7,894 kB in 1h 10min 44s (1,859 B/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 143397 files and directories currently installed.)
Preparing to unpack .../nodejs_8.3.0-1nodesource1~buster1_amd64.deb ...
Detected old npm client, removing...
Unpacking nodejs (8.3.0-1nodesource1~buster1) over (6.11.2-1nodesource1~buster1) ...
Setting up nodejs (8.3.0-1nodesource1~buster1) ...
Installing new version of config file /etc/profile.d/nodejs.sh ...
Processing triggers for man-db (2.7.6.1-2) ...


Yeah, I knowwww... Check that out.... 7,894 kilobytes.... taking 70 minutes to install. Welcome to computing at the speed of abject poverty.

(Not so) funny is that wasn't even the whole download. That was only the last partial of it so the time invested was more than that for that 13.2 megabyte file at day's end. #TrueStory.

PS Last partial... Have I mentioned "abject poverty" yet? It's nothing to have to stop installs for to be able to accomplish something else online at a transfer rate higher than 963 BYTES per second. #EvenTruerStory.

So those last few lines there... I initially did not grasp that part where my packages will no longer only come from Debian secured repositories. That's kinda sorta a little scary and is something everyone must keep in mind 110% of the time during this adventure.

Killed me to do it, but I traveled over to my once former one-liner /etc/apt/sources.list file for to witness it no longer being only one line....

But it still is.

That's because the new repository's indicator was injected into a newly generated file at:

/etc/apt/sources.list.d/nodesource.list

That file in whole says:

deb https://deb.nodesource.com/node_8.x buster main
deb-src https://deb.nodesource.com/node_8.x buster main


I keep forgetting about that "deb-src" part. I need to remind myself what that's about. That wouldn't be thrown in there just because(y) they got a wild hair up their keyboard. There's a rationale behind that, but I've forgotten what that is.

That notation that it [d]etected old npm client, removing is not an advisement that I ever see left in place. It's not hard to imagine that this potentially is what goes on when software is upgraded. Then again, maybe package managers install a whole new instance instead of packing in a new one over top of an existing one.

Except that... no, I've seen the advisements that my apt-get was unpacking new editions actually over top of something already installed under their respective names.

Being so new at this whole node thingy, I don't know if we only ever need one instance of npm... or not. For most of the rest of the packages, it's imperative that we know and control what's there. This would include the fact that you can have many versions of the same named package all residing side by side.

During my initial peer dependencies installation attempts a couple days ago, that's where a major bug was encountered with eslint and webpack. Those two kept narcissistically deleting any of their respective "sibling" packages that they found during the installation process. Yes, that's a #FAIL which in my case caused me to repeatedly go in circles trying to install those two last necessary peer dependencies. *grin*

Then I found a newer npm Github bug that says.... it's not just me. *comforting to know*

Much later that same day.... and mostly just because I had not yet mangled things enough:

npm uninstall --save beaker
npm WARN deprecated isparta-loader@0.2.0: Package is deprecated, use https://github.com/deepsweet/istanbul-instrumenter-loader
npm WARN deprecated jade@1.11.0: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated bower@1.8.0: ..psst! While Bower is maintained, we recommend Yarn and Webpack for *new* front-end projects! Yarn's advantage is security and reliability, and Webpack's is support for both CommonJS and AMD projects. Currently there's no migration path, but please help to create it: https://github.com/bower/bower/issues/2467
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated transformers@2.1.0: Deprecated, use jstransformer
npm WARN deprecated css-list@0.1.3: Deprecated.
npm WARN deprecated graceful-fs@1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm ERR! Unexpected end of input at 1:17415
npm ERR! Shrinkwrap":false},"3.6.1":{"name":"eslint-plugin-react","version":"3
npm ERR!

npm ERR! A complete log of this run can be found in:
npm ERR! /home/[user]/.npm/_logs/2017-08-17T01_39_38_742Z-debug.log


No, actually I'm not sure that I originally installed beaker while using that --save flag. Another tip I gathered somewhere was that you have to or should use the same flag for uninstall that you did for npm install. I don't remember a "why", just that you should.

This is where it starts turning my stomach. I'm not versed at separating my dependencies and such into their respective lumps. Once you can, then it's not so hard to.....

Oh, wait.... maybe that file that's causing so many problems has a clue? *let's check that out*

Now more error looking error chatter:

npm ERR! errno EAI_AGAIN

Without actually going onto any webpages, I'm seeing things like that it's about being behind a proxy and suchly. Since I'm on dialup, maybe it's purely about access, period.

And now another one.... ENOTFOUND

Also not to be forgotten: rollbackFailedOptional.

At day's end, the speed of locally provided dialup started looking like a feasible culprit. Even higher on my list, though, was that I started wondering about a "slashdot effect" on npm. Last night I went ahead and pondered that out loud over at npm's Github. Even from a newbie's perspective, it just seems like a lot of sudden connectivity issues for it to suddenly all only be about the end user.

In the meantime, the glitch... the bug... appeared to be fixable by simply rinse and repeating install attempts until they actually installed successfully. Sometimes it takes more than a few times, but it does seem to work... if you keep plugging on.....

*to be continued...* :)

Wednesday, August 16, 2017

Ok, so a couple days ago I began installing the Beaker peer-to-peer browser k/t having seen a blurb about it on Slashdot. This latest experience in the geekette has been... challenging but not in a super negatory way.

If I had this to do all over again, I would start with one of the first pages I read but did not comprehend initially. That page is the Installing Node.js via package manager over at Node.js' home website. That's where I got this:

curl -sL https://deb.nodesource.com/setup_[choice-of-version].x | sudo -E bash -
sudo apt-get install nodejs


For me on Debian Linux, Buster edition, following the curl/apt-get install instructions worked. Until that point, I had been floundering around with things like nvm because(y) that's what hit my radar early on. *it's a cognitive thing*

[choice-of-version] means there are several running around out there. I initially did the "setup_6.x" as reflected on Node.js' package manager tips page. I spent the rest of the day, MANY hours, messing around with dependencies. That may or may not change, only Time will tell.

UPDATE 2017.08.18: I stumbled upon a What's the difference between curl | sh and sh -c “$(curl)”? (StackExchange; ~2017.01.22). I'll be trying that one the next chance I get to see if it makes a difference in effectiveness, i.e. do things still install properly.

If you wander around on the issues bug report board for Beaker, you'll find a comment that nodejs installs npm by natural default. Not quite... i.e... if you install solely via apt-get in my Debian Buster without the curl, it appears to not quite go. I know this because(y) that's the route I stumbled upon first.

One factor that will be time consuming to test is that I didn't know about closing a terminal window and then reopening it just after install. Sometimes you have to do that before npm becomes available. I didn't do that because I did not know it helps. It will take a fresh install, perhaps even of my old buddy Sid, to test that theory. That's at least 2 days all by itself aka... *it can wait*

So. #Life Lesson Learned on the fly: Skip straight to Node.js' Installing Node.js via package manager. Should you encounter something where it doesn't work, hit up the appropriate Github issues page for whichever package is failing.

My next step was then to npm install beaker. I messed up at first. I should have been writing up notes, but I didn't. There were two errors that aren't showing up now that it would have been nice to document.

Today... I'm seeing this:

UNMET PEER DEPENDENCY autoprefixer-core@^5.2.0
├── UNMET PEER DEPENDENCY babel-core@^5.0.0
├── UNMET PEER DEPENDENCY babel-loader@^5.3.2
├── UNMET PEER DEPENDENCY babel-plugin-object-assign@^1.2.1
├── UNMET PEER DEPENDENCY babel-plugin-rewire@^0.1.21
├─┬ beaker@6.1.0
│ ├─┬ change-case@2.3.1
│ │ ├── camel-case@1.2.2
│ │ ├── constant-case@1.1.2
│ │ ├── dot-case@1.1.2
│ │ ├── is-lower-case@1.1.3
│ │ ├── is-upper-case@1.1.2
│ │ ├── lower-case@1.1.4
│ │ ├── lower-case-first@1.0.2
│ │ ├── param-case@1.1.2
│ │ ├── pascal-case@1.1.2
│ │ ├── path-case@1.1.2
│ │ ├── sentence-case@1.1.3
│ │ ├── snake-case@1.1.2
│ │ ├── swap-case@1.1.2
│ │ ├── title-case@1.1.2
│ │ ├── upper-case@1.1.3
│ │ └── upper-case-first@1.1.2
│ ├── diff@2.2.3
│ ├── exit@0.1.2
│ ├── lodash@3.10.1
│ ├── minimist@1.2.0
│ ├─┬ nconf@0.7.2
│ │ ├── async@0.9.2
│ │ └─┬ yargs@3.15.0
│ │ ├── camelcase@1.2.1
│ │ ├─┬ cliui@2.1.0
│ │ │ └── wordwrap@0.0.2
│ │ └── window-size@0.1.4
│ ├─┬ q-io@1.13.4
│ │ ├─┬ collections@0.2.2
│ │ │ └── weak-map@1.0.0
│ │ ├── mimeparse@0.1.4
│ │ └── url2@0.0.0
│ ├─┬ sleep@3.0.1
│ │ └── nan@2.6.2
│ └── versiony@1.4.2
├── UNMET PEER DEPENDENCY coveralls@^2.11.2

< half a ton of UNMET PEER DEPENDENCY lines snipped >

└── UNMET PEER DEPENDENCY yaml-loader@^0.1.0

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: 7zip-bin-mac@^1.0.1 (node_modules/7zip-bin/node_modules/7zip-bin-mac):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for 7zip-bin-mac@1.0.1: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: 7zip-bin-win@^2.1.0 (node_modules/7zip-bin/node_modules/7zip-bin-win):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for 7zip-bin-win@2.1.0: wanted {"os":"win32","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN beaker@6.1.0 requires a peer of autoprefixer-core@^5.2.0 but none was installed.

< respective half ton of required PEER DEPENDENCY versions snipped (again) >

npm WARN beaker@6.1.0 requires a peer of yaml-loader@^0.1.0 but none was installed.
npm WARN beakerbrowser@ No repository field.
npm WARN beakerbrowser@ No license field.


Oy, have mercy. There MUST be like one single package that covers all of those... or something like that. :)

But there's not. And something I noticed while proofreading here is that the "tree" there, Beaker in this case, appears in line where its respective package is actually halfway installed properly. *got it*

Here's a funny. The number of websites returned for a search on the above... is my old employee number at Kmart MANY mango seasons ago..


*memories!*

One of those top website pages returned for my search... says it's a new thing that we have to manually install those peer dependency packages. Are we sure about that, though? Let's check out another website. Ok, that one is saying to try things like npm uninstall [package-name] and npm cache clean first. *that makes (total common) sense (when you know all the commands AND flags to use)*

Like npm install --save-dev. That sounds like an important one to use... especially on dialup. *maybe (?)*

Now I'm looking at this:

npm WARN beakerbrowser@ No repository field.
npm WARN beakerbrowser@ No license field.


That sounds minorly important.... too. *hm*

Only 3 results?


That's bringing back memories of the good ol' days when you were lucky to get that many answers back. *lol*

Possible best answers are at StackOverflow. Multiple comments hint that it's a developer thing to ignore those instead of making sure they don't occur. *grin*

This is already actually looking like it might could work. This right here:

beakerbrowser@ /home/candycane/Documents/git/beaker/beaker
└─┬ node-gyp@3.6.2
├─┬ fstream@1.0.11
│ └── graceful-fs@4.1.11


That's a sampling of the feedback that shows up on the terminal while doing this. That graceful-fs right there was highlighted as not installed yesterday. The impression I'm getting is that it is now installed. That's because I am following this process as a mix garnered from the Yeoman@Github and Angular@Github links above:

npm uninstall beaker
npm cache clean
npm install node-gyp
npm install node-pre-gyp
npm install beaker


Don't know if it's appropriate to use it here, but there is that --save-dev flag running around in the wild. That is NOT --save-dep which would seem and feel more logical.

--save-dev means:

Dev Dependencies. A module installed using the "--save-dev" flag is saved into the "devDependencies" list in the package.json file. If an npm module is listed as a "devDependency" it means that your npm plugin isn't dependent on it, however your development environments are dependent on it.

k/t Daniel Tonon @ LinkedIn

Those are things you need locally to do what you're doing... but maybe it's not a required demand at the project's end. *I think (?)*

There is another flag, "-g", e.g. npm install -g that means globally across one's system. That takes root privileges to accomplish that one if you leave it like that. For me right now, I'm fine with it being "just" as me because I don't want it messing up my currently functioning globals... *grin*

Addendum as I proofread: Globally sounds desirable now to the point that I went that route. It's what things like apt-get install already do by design.

Nope, there was still a massive laundry list of not-yet-installed packages (do they even call them packages?):

autoprefixer-core babel-core babel-loader babel-plugin-object-assign babel-plugin-rewire coveralls css-loader csso csswring eslint eslint-plugin-react file-loader grunt grunt-cli grunt-contrib-watch grunt-eslint grunt-filenames grunt-karma grunt-webpack imports-loader isparta-loader jade-loader jasmine jasmine-core json json-loader karma karma-chrome-launcher karma-cli karma-coverage karma-firefox-launcher karma-jasmine karma-jasmine-jquery karma-sourcemap-loader karma-spec-reporter karma-webpack less-loader lodash matchdep postcss-loader raw-loader react react-dom sass-loader style-loader webpack webpack-dev-server yaml-loader

48 packages if mousepad (text editor) line counts are to be believed.

Packages. Do they even call them that in this instance? :)

Alrighty, then....

More errors...

npm ERR! node v6.11.2
npm ERR! npm v3.10.10

npm ERR! shasum check failed for /tmp/npm-8755-700488db/registry.npmjs.org/eslint/-/eslint-4.4.1.tgz
npm ERR! Expected: 99cd7eafcffca2ff99a5c8f5f2a474d6364b4bd3
npm ERR! Actual: ba90d15ab3280166ff3d668f497996b23732fdec
npm ERR! From: https://registry.npmjs.org/eslint/-/eslint-4.4.1.tgz
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!

npm ERR! Please include the following file with any support request:
npm ERR! /home/candycane/Documents/git/beaker/beaker/npm-debug.log


But it's the one just above those that scares me.....

npm ERR! Linux 4.11.0-1-amd64

Um, yeahhhh.. That's what I'm using. WHYYY is that a problem? *oh, no*

So you know from "oh, cr4p!"? I just did again. I just successfully installed istanbul-instrumenter-loader because isapart-loader is "deprecated". *that's what they said*

It's not complaining about my Linux 4.11.0-1 kernel anymore... but it somehow added a few more necessary packages because the count is now UP to 54. That's after it installed a few things as other necessary dependencies. *hm*

Potentially getting smarter by the hour about all this. According to another StackOverflow thread, the above peer dependency install list should look like this:

autoprefixer-core@^5.2.0 babel-core@^5.0.0 babel-loader@^5.3.2 babel-plugin-object-assign@^1.2.1 babel-plugin-rewire@^0.1.21 coveralls@^2.11.2 css-loader@^0.15.6 csso@^1.3.11 csswring@^3.0.5 eslint@^1.1.0 eslint-plugin-react@^3.2.2 file-loader@^0.8.4 grunt@^0.4.5 grunt-cli@^0.1.13 grunt-contrib-watch@^0.6.1 grunt-eslint@^17.1.0 grunt-filenames@^0.4.0 grunt-karma@0.12.0 grunt-webpack@^1.0.11 imports-loader@^0.6.4 isparta-loader@^0.2.0 jade-loader@^0.7.1 karma@^0.13.8 karma-chrome-launcher@^0.2.0 karma-cli@^0.1.0 karma-coverage@^0.5.1 karma-firefox-launcher@^0.1.6 karma-jasmine@^0.3.6 karma-jasmine-jquery@^0.1.1 karma-sourcemap-loader@^0.3.5 karma-spec-reporter@^0.0.20 karma-webpack@~1.7.0 less-loader@^2.2.0 lodash@^3.10.0 matchdep@^0.3.0 postcss-loader@^0.4.3 react@0.14.2 react-dom@0.14.2 sass-loader@^2.0.1 style-loader@^0.12.3 webpack@^1.11.0 webpack-dev-server@^1.10.1 yaml-loader@^0.1.0

In other words, leave the version numbers in there. Those matter to npm. They're also noting the --save flag so I'll be trying that, too.

For the more whacky looking ones, I saw a tip where you additionally even tack on some parentheses before you're done, e.g.:

npm install -g funkyPackageName@">=0.0.1"

Better yet, you can show that you're a really importantly too busy to type developer by further shortcutting that to:

npm i -g funky-package-name@">=0.0.1"

I tried it. *it works!*

MANY HOURS LATER: Am still at it. Had a few packages, namely eslint and webpack, that kept running me in circles with their peer dependency demands. I would update one then another would yell that its peer dependencies are unmet... even though I'd already manually installed them minutes before. I'm definitely missing some minor detail here about the whole npm process. :)

A couple packages have gone off and gotten themselves deprecated by becoming other names. jade has something to do with pug, and I'm not sure which karma was triggering it but something wants to be yarn or some other name I've already forgotten.

UPDATE 2017.08.18: I think that other name was webpack. How'd I ever forget that?

Then I kept seeing this:

npm WARN deprecated bower@1.8.0: ..psst! While Bower is maintained, we recommend Yarn and Webpack for *new* front-end projects! Yarn's advantage is security and reliability, and Webpack's is support for both CommonJS and AMD projects. Currently there's no migration path, but please help to create it: https://github.com/bower/bower/issues/2467

If you see that message... and the related npm install just seems to be... lost in space there, leave it have its head. It's downloading something large. It's not frozen or something...... *#Life lesson learned on the fly* :)

Ohhh-kayyy. eslint and webpack are running me all the freak all over the place... in circles. I install what I think is one of them, and a bunch of other unmet peer dependencies pop up. Those peer dependencies are in their same name, just different versions. I install one or more of those... and the previous one... returns. *smacking head*

Then I remembered something I'd seen for a second:

$ npm ls webpack
beakerbrowser@ [file-path-location]
├── UNMET PEER DEPENDENCY eslint@4.4.1
├── UNMET PEER DEPENDENCY karma-jasmine-jquery@^0.1.1
└── UNMET PEER DEPENDENCY webpack@3.5.4


I installed the first one, eslint@4.4.1 then ran npm ls webpack again... nothin'. Freaking... nothin' changed.

I'm thinking... that I'm done running in circles for the day... is what I'm thinking...

*to be continued* :)