A decade in the industry; a ten year retrospective
-
I would never have imagined that I would've made the jump to entrepreneurship, the antithesis of a steady paycheque!
Congrats.
The best of life is living by interests and you make it. Previously I was an assistance prof in an university. Then I quit since I dont like it and I am trying to live by my interest.
-
Somehow missed this. But now found it. Cool.
"Here's to a decade in the industry, and here's to 10 more."
Naw, I think I'd rather retire before all that long...
Cool retrospective. And yeah, life IS a trip!
-
@gotwf @julian I have a similar line in the industry, but in fact, over a longer period - 30 years+ to be precise. It's documented here - https://sudonix.com/journey
-
@phenomlab yeah, mon! I realize ye' be old n' gray but ten decades is one hundred years. Hence I imagine even the old farts among us have a ways to go yet fer' that one, eh?
Rock on!
-
@phenomlab Meh... more like Much ado about nothing.....
Unless you were being purposefully clueless....
-
@julian One may hope not. Leastwise.... what is special about those dates? I know not. Mayhaps were you referencing the 2038 Unix Epochalypse? I think this has potential to be far more problematic. I have been aware of this since the great Y2K "crisis" but kind of forgot about it until this thread since 2038 was a "long ways off yet". I also thought this would be no big deal in future modern times due to the prevalence of 64 bit processors and os platforms. Alas, I seem to be in error:
There is no universal solution for the Year 2038 problem. For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to 2106 (specifically, 06:28:15 UTC on Sunday, 7 February 2106), would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64 bits in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions. [emphasis added]
Could be in for some interesting times, eh?
-