Daz is promoting Hexagon/Bug fixes

Atanacius

DzFire said:

karmaspice2000_2c77e33c86 said:

Folks, I was joking about the Y2K thing but Hex is still a product of a bygone age that needs an update.

It does need an update but I wouldn't call it from a by-gone age. Infact, the modeling and UV features are still top of the line. This model took me a day to model and map with the current Hex program:

When I first started modeling for game mods such as Need for Speed and Delta Force, I had to do it with hex editing and would take months to do this same model (seriously, that computer would crash with something this big).

This is a great model, Bravo !

ShawnDriscoll

Subtropic Pixel said:

I see it now.  Your use of the words "BIOS" and "buy a new computer and update their software" makes it obvious that your perspective is entirely PC/end-user based, and you have no experience with the other types of systems more widely in use back then; namely the midrange and mainframe computers of the time and how their applications fit into the architecture, as well as the fact that companies running the application software were often also the application developers.

Today, software vendors are what most people think of as "devs", and very little is written in-house.  But back then with those types of systems, "buy a new computer" was not the answer.  And "update the software" meant that the company's own in-house devs would be tasked to go through the code, sometimes line by line.  Millions of lines of code, within thousands (or tens of thousands) of application programs, written in cobol, assembler, fortran, pl/1, or other languages.  This required skill and expertise specific to the language used for a given application.  A good cobol programmer might not make a good assembler programmer. 

IT has come a long way in 17 years, but there are still many of those old systems around, even now.  If you book a flight somewhere, it's very possible that your app is accessing a mainframe computer.  You just don't know it because your PC's web browser or your tablet's app is serving you as the front-end, hiding the true technology from you.  There really is a lot more to the story than you are aware.

You're funny.

namffuak

shawndriscoll_34affb248a said:

Subtropic Pixel said:

I don't know what your history was, but I suspect that Y2K may have happened before your career, or your career never dealt with the technologies and application code that was most susceptible to errors.  I assure you, Y2K was not a joke, and it was not fake news.  It was a legitimate and real risk.  As I said in my prior post, there was some fallout and some of it was very serious.  It could have been worse but was not.  From personal experience, I know this was due to the high priority it was given.

I guess having doubters means that those of us who put our hearts and souls into the work just kind of made it look easy.

I was there. I wrote a lot of code that would fail in 2000. Some of it would fail even sooner depending on BIOS/computer, etc. The idea was that no one would still be using the code/computers that late in the game. When people are told that their dates won't work after 1999, they buy a new computer and update their software if they need to. It's not rocket science. And no one of any importance was still using junker computers when 2000 happened. So it was just hype.

The problem was quite real. My department spent most of the summer and fall of 1999 double-checking all in-house code and installing vendor-supplied updates. And we still had a couple of questionable areas - our phone/cbx accounting package was no longer supported (vendor had gone toes-up in 1998) and there wasn't anything else available for our phone system. We 'fixed' most of the potential problem areas by converting from our in-house mix of code to SAP/R3 at the end of 1997, but that still left payroll and cost accounting to double check. And finding a slot that we could take a 24-hour outage on the R3 system to do the required y2k update on it.

And then our 3 Windows admins, both Oracle DBAs, both SAP/Basis support people, our two SAP security admins, our network admin, our boss, and I came in at 10:00 PM on the 31st and watched all the systems through 4:00 AM January 1, 2000. I was the OS support for the non-Windows systems - aka the production systems - and the one thing I could not get a viable test on was whether ntp (network time protocol) would glitch on us, as the production environment was a dual system high-availablity setup with dynamic takeover and required time sync at +/- a tenth of a second.

Very much a not-fun six months overall.

ShawnDriscoll

namffuak said:

shawndriscoll_34affb248a said:

Subtropic Pixel said:

I don't know what your history was, but I suspect that Y2K may have happened before your career, or your career never dealt with the technologies and application code that was most susceptible to errors.  I assure you, Y2K was not a joke, and it was not fake news.  It was a legitimate and real risk.  As I said in my prior post, there was some fallout and some of it was very serious.  It could have been worse but was not.  From personal experience, I know this was due to the high priority it was given.

I guess having doubters means that those of us who put our hearts and souls into the work just kind of made it look easy.

I was there. I wrote a lot of code that would fail in 2000. Some of it would fail even sooner depending on BIOS/computer, etc. The idea was that no one would still be using the code/computers that late in the game. When people are told that their dates won't work after 1999, they buy a new computer and update their software if they need to. It's not rocket science. And no one of any importance was still using junker computers when 2000 happened. So it was just hype.

The problem was quite real. My department spent most of the summer and fall of 1999 double-checking all in-house code and installing vendor-supplied updates. And we still had a couple of questionable areas - our phone/cbx accounting package was no longer supported (vendor had gone toes-up in 1998) and there wasn't anything else available for our phone system. We 'fixed' most of the potential problem areas by converting from our in-house mix of code to SAP/R3 at the end of 1997, but that still left payroll and cost accounting to double check. And finding a slot that we could take a 24-hour outage on the R3 system to do the required y2k update on it.

And then our 3 Windows admins, both Oracle DBAs, both SAP/Basis support people, our two SAP security admins, our network admin, our boss, and I came in at 10:00 PM on the 31st and watched all the systems through 4:00 AM January 1, 2000. I was the OS support for the non-Windows systems - aka the production systems - and the one thing I could not get a viable test on was whether ntp (network time protocol) would glitch on us, as the production environment was a dual system high-availablity setup with dynamic takeover and required time sync at +/- a tenth of a second.

Very much a not-fun six months overall.

The US DoD had us going through all that as well. Lots of travel. I was on base all that night. No issues though because systems were updated long before. But admirals, needing to look important, still thought the sky would fall. In the end, there was no Black January.

Ryuu@AMcCF

shawndriscoll_34affb248a said:

namffuak said:

shawndriscoll_34affb248a said:

Subtropic Pixel said:

I don't know what your history was, but I suspect that Y2K may have happened before your career, or your career never dealt with the technologies and application code that was most susceptible to errors.  I assure you, Y2K was not a joke, and it was not fake news.  It was a legitimate and real risk.  As I said in my prior post, there was some fallout and some of it was very serious.  It could have been worse but was not.  From personal experience, I know this was due to the high priority it was given.

I guess having doubters means that those of us who put our hearts and souls into the work just kind of made it look easy.

I was there. I wrote a lot of code that would fail in 2000. Some of it would fail even sooner depending on BIOS/computer, etc. The idea was that no one would still be using the code/computers that late in the game. When people are told that their dates won't work after 1999, they buy a new computer and update their software if they need to. It's not rocket science. And no one of any importance was still using junker computers when 2000 happened. So it was just hype.

The problem was quite real. My department spent most of the summer and fall of 1999 double-checking all in-house code and installing vendor-supplied updates. And we still had a couple of questionable areas - our phone/cbx accounting package was no longer supported (vendor had gone toes-up in 1998) and there wasn't anything else available for our phone system. We 'fixed' most of the potential problem areas by converting from our in-house mix of code to SAP/R3 at the end of 1997, but that still left payroll and cost accounting to double check. And finding a slot that we could take a 24-hour outage on the R3 system to do the required y2k update on it.

And then our 3 Windows admins, both Oracle DBAs, both SAP/Basis support people, our two SAP security admins, our network admin, our boss, and I came in at 10:00 PM on the 31st and watched all the systems through 4:00 AM January 1, 2000. I was the OS support for the non-Windows systems - aka the production systems - and the one thing I could not get a viable test on was whether ntp (network time protocol) would glitch on us, as the production environment was a dual system high-availablity setup with dynamic takeover and required time sync at +/- a tenth of a second.

Very much a not-fun six months overall.

The US DoD had us going through all that as well. Lots of travel. I was on base all that night. No issues though because systems were updated long before. But admirals, needing to look important, still thought the sky would fall. In the end, there was no Black January.

Indeed. I dealt with such in both the Navy and State Department.

The panic (of the higher ups) was very real. The issues, where they did appear, not so much.

Once the matter made the news in the mid 90's, they had us test just about EVERYTHING. It turned out that the vast majority of the equipment BIOS's couldn't care less what the date versus the day was supposed to be, as it was the OS that controlled what the applications would see. This left only a few machines that actually ever needed replacement, and their replacements cost FAR LESS than the original boat anchors. It actually resulted in substantial savings of weight, space and the cost of power to run them for our commands--and once our Exec saw that, he ordered replacements of several systems which had no problems by using that justification alone.

The OS's we were using were already Y2K compliant: Microsoft DOS & Windows, Unix, Linix, Banyan Vines, etc, so no issues there. That only left very few applications that had any issues, which there were commercial upgrades/replacements that were cost effective to install.

So, a big scary lit fuse, but a fizzle pop.

But just wait for Y3K!! 

Cherubit

Thank you Daz for making updates for a new Hexagon program!

I still use Hexagon and Blender - about Blender UI yes it is very complicated at first, but once you learn it you see it's actually pretty logical, I had to buy a course to learn it though, it's hard to understand it from free youtube tutorials.

takezo_3001

shawndriscoll_34affb248a said:

Blender's UI sucks.

Not if you're an automaton it's not...

Subtropic Pixel

namffuak said:

shawndriscoll_34affb248a said:

Subtropic Pixel said:

I don't know what your history was, but I suspect that Y2K may have happened before your career, or your career never dealt with the technologies and application code that was most susceptible to errors.  I assure you, Y2K was not a joke, and it was not fake news.  It was a legitimate and real risk.  As I said in my prior post, there was some fallout and some of it was very serious.  It could have been worse but was not.  From personal experience, I know this was due to the high priority it was given.

I guess having doubters means that those of us who put our hearts and souls into the work just kind of made it look easy.

I was there. I wrote a lot of code that would fail in 2000. Some of it would fail even sooner depending on BIOS/computer, etc. The idea was that no one would still be using the code/computers that late in the game. When people are told that their dates won't work after 1999, they buy a new computer and update their software if they need to. It's not rocket science. And no one of any importance was still using junker computers when 2000 happened. So it was just hype.

The problem was quite real. My department spent most of the summer and fall of 1999 double-checking all in-house code and installing vendor-supplied updates. And we still had a couple of questionable areas - our phone/cbx accounting package was no longer supported (vendor had gone toes-up in 1998) and there wasn't anything else available for our phone system. We 'fixed' most of the potential problem areas by converting from our in-house mix of code to SAP/R3 at the end of 1997, but that still left payroll and cost accounting to double check. And finding a slot that we could take a 24-hour outage on the R3 system to do the required y2k update on it.

And then our 3 Windows admins, both Oracle DBAs, both SAP/Basis support people, our two SAP security admins, our network admin, our boss, and I came in at 10:00 PM on the 31st and watched all the systems through 4:00 AM January 1, 2000. I was the OS support for the non-Windows systems - aka the production systems - and the one thing I could not get a viable test on was whether ntp (network time protocol) would glitch on us, as the production environment was a dual system high-availablity setup with dynamic takeover and required time sync at +/- a tenth of a second.

Very much a not-fun six months overall.

For us, it was a couple-year process to get ready.  Again, Congress had passed the act, so every CEO of every large company thought they could go to jail if they screwed up badly enough to get sued by their stakeholders; so it was "all hands on deck" for most.  Just like the generals and admirals.  Nobody at those levels wanted anything to do with hoisting, petards, or dressings down.  I think that was a good thing.

We also ran at least 2 shifts of people working on the 1st.  I worked the graveyard shift New Year's Eve into about 6 am, I think; then when the day shift took over, I went to breakfast at a Denny's, and caught some z's at home before going to a bowl game.  I have no idea who played or who won, but it sure was nice to spend a portion of that day watching the pagentry of a bowl game, including the half-time show, which consisted of hundreds of cheerleading teams. 

But yeah, none of us partied the night away that year.  It did go very well and it was a good thing we had so many talented people working it, both before and after the transition.  As professionals, most of us handled it all very, um, "professionally".  I think overtime was approved, and the day shift got pizza out of the deal.

We did have some applications render some wacky results in the first week or two of January that year, but if memory serves, it all got fixed in due course.  And nothing crashed and burned; no systems, no planes, trucks, or trains, and no spacecraft... 

eternityblue_8d52ac7c3c

I’m new to Daz as a regular user, I am a happy Blender user but was wondering about Hexagon, if there are any compelling reasons to try it in relation to using Daz. Is it stable on Win 10 64 bit now? And regarding Blender, I think the single biggest things that confuse people are that it by default has reversed mouse buttons to what is normal and logical to most users, and the way you manage windows is confusing as hell when you start out. You can find some really good tutorials on that, but 2.8 with a par real-time engine is soon to be in beta and released next year, and it has considerable ui changes, so I would recommend anyone turned off in the past to give it another try, considering the cost of other programs, a small amount of time with focused study and even adapting s9me behavior to your own workflow will make you fall in love with it. It really is a lovely program now, once you really get to know it, and it will be a lot more powerful very soon. I’m hoping Hexigon has some cool nifty features though that kind of add to Daz, and I just like software in general so maybe it would be a new to, just it would be great to know if it is still worthwhile.

ShawnDriscoll

Blender is a chore to model stuff in. Hexagon has easier/cleaner tools to use.

DzFire

ShawnDriscoll said:

Blender is a chore to model stuff in. Hexagon has easier/cleaner tools to use.

Agree