 |
|
|
|
|
|
|
|
|
|
1998 Jeep Cherokee - "She's dead, Jim" -- Star Trek
December was the month the Jeep's registration was due. For 2018 the registration required a smog check.
Took the Jeep to the local "test only " smog check station, as needed.
They put the Jeep on the dynomometer. Even at twenty years old, the Jeep passed tailpipe emissions quite well.
| test | %CO2 | %O2 | HC (PPM) MEAS | CO% MEAS | NO (PPM) MEAS | RESULTS |
| 15mph | 15.9 | 0.0 | 16 | 0.01 | 130 | pass |
| 25mph | 15.2 | 0.0 | 11 | 0.02 | 123 | pass |
BUT this year, then the smog technician did the OBD check (I do not remember they _ever_ being required to do an OBD check before this time, if it had passed the dyno), and it gave them two "pre" trouble codes. Mind you, car had just passed the dyno tailpipe emissions test. No "check engine" light ever turned on in the Jeep.
SO, because of the two "pre" trouble-codes, they failed the Jeep for the smog check, and I could not get it registered for 2019.
So, yes: I feel frustrated. The car does not pollute. I feel like it could not get registered due to a technicality. So what if a sensor might be bad on a twenty year old car. If it does not pollute, per emissions tailpipe, it should be allowed to be driven. Period.
But, since it failed, technicality or not, it cannot be driven. I am not going to put half a thousand dollars of repairs into a car that might just die anyway and get replaced. So, for all practicable purposes, my Jeep is dead.
Now will clean it out of tools and personal belongings, then research salvage yards that might give me a few dollars for it, and then have it towed away.
It served myself and my little family well, for twenty years. I am grateful to those that built it. I knew it had a finite lifetime. Cannot begrudge twenty years of service.
Tags: 1998, 2018, cherokee, jeep
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C++ multi-threading programming, debian, g++, gnumake, design patterns
I haven't played with multi-threaded programming since college. Having fun reading online tutorials about using std::thread, mostly. Next, want to try to find/discover best-practices in designing C++ multi-threaded programs, multi-threaded design-patterns, multi-threaded OOSE, and such.
Tags: 2018, cplusplus, debian, programming, std::thread, thread
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C++ multi-threading programming, g++, gnumake
For the compiler in Debian Stable that I use, the Programmer needs to add two flags to enable support for
functionality to the CXXFLAGS variable.
So in my makefile(s) that I use for using C++ multi-threading, I added the below two CXXFLAGS.
- "-std=c++11" and
- "-pthread"
#
# CXXFLAGS
# used by gnu make's implicit rules
#
# I choose to show all warnings (-Wall), and include debugging information (-g)
# I choose to include support for C++11 (-std=c++11);
# the g++ version in my Debian Stable, g++ version 4.9.2,
# requires it to use std::thread
# I choose to include support for pthreads (-pthread)
# the g++ version in my Debian Stable, g++ version 4.9.2,
# requires it to use std::thread
#
CXXFLAGS := -Wall -g -std=c++11 -pthread
Tags: 2018, cplusplus, debian, gnumake, make, programming, std::thread, thread
|
|
|
|
|
|
|
|
|
|
|
Previous
