A decade in the industry; a ten year retrospective

[sharonyue]

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.

[gotwf]

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!

[phenomlab]

@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

[gotwf]

@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!

[julian]

@phenomlab Ooh, you were active during y2k, eh? I think I was still a teen with no responsibilities at that time

[phenomlab]

@julian Certainly was !!

[gotwf]

@phenomlab Meh... more like Much ado about nothing.....

Unless you were being purposefully clueless....

[phenomlab]

@gotwf exactly that. Huge hype over absolutely nothing. The true definition of FUD.

[julian]

@phenomlab @gotwf Are we going to say the same in 2033 and 2034?

[gotwf]

@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?