Law Mandating C++, OpenGL, and Linux Only

Hell I remember playing space invaders on ,y brother in laws commodore sixty four. and taking three hours to download a picture for my daughter 1st grade science report on 14/4 dial up. But then I'm old enough to remember tracing paper.

 

This is the kind of computing environment where you want 'mandated' technology standards without question. Failure is not an option in this kind of environment. You don't want to look down and see Blue Screens of Death here. An application that hangs all the time is just not cool here, or an OS that reboots itself for no apparent reason. Fault Tolerance, Failover, Redundancy, Reliability and Persistence. These are mission critical foundations that are not always found in pure C++ environments. Sometimes, you need code that is far more streamline, direct and to the point. One that is designed to interface with hardware in a more intimate and direct way.

Primus Epic EFIS by Honeywell:


On the other hand, you probably would not like Retail Computing that much, if you had such restrictive mandates. If you think I'm verbose, just try writing a C++ application to drive this EFIS and you'll come away with a completely different definition for the word "verbose."

Programming languages are Tools. You pick the right one for the job and you get that specific job done as efficiently/optimally as possible. Not every job has the same encoding requirements - which can be myriad in their diversity.

 

Fixed it. I say C/C++ because it's a parent child relationship. If your coding in C++ you can easily just code using C only. C is better used in embedded/firmware coding, more direct and efficient. Also, you are leaving out web code languages like java-script and PHP. Or do you want those languages to somehow merge with C?

 

Of course I know that C++ isn't the only modern programming language. I have programmed extensively in Ada, C, C++, and Java. Damn! Typed a semi colon for a period just thinking about that sh*t! LOL

Actually C is a subset of C++ and was actually the first language that I learned to program really well in. And to this day, I still use many of the string manipulation utilities that C provides because they were what I first learned and are what I know how to use well. However modern software development seeks to encourage the object oriented approach, which places emphasis on viewing software modules as OPAQUE objects where the details of the implementation are hidden, thus freeing the developer to only worry about the interface. Thus the concepts of encapsulation, abstraction, and inheritance become critical. While C does provide some support for encapsulation with its structures, it does not have INTRINSIC support for abstraction and inheritance. C++ with its private and protected access classes provide INTRINSIC means to achieve abstraction. Furthermore in C there is no INTRINSIC support of the concept of inheritance which makes polymorphism possible. So for example, let's suppose I create a dinosaur class that has a method which returns the number of legs of the dinosaur. In C++ I can create a single base dinosaur class which contains all of the common attributes for all dinosaurs and then create derived classes for the different types of dinosaurs that may have different attributes. So in the base dinosaur class I could declare a virtual method that returns the number of legs of a particular type of dinosaur, which would then allow the derived classes to implement the method in such a way that the correct number of legs is returned for a particular dinosaur. The derived class thus has all the functionality of the base class, without having to re-implement the details over again, along with the functionality that is unique to the derived. This is what the concepts of inheritance and polymorphism are essentially about. It is a powerful concept and something that cannot be done in C, at least not with great difficulty. It makes software reuse and maintenance easier.

Yeah bash, C, and korn shells make it useful to do many administrative tasks as well as routine software tasks that users engage in. However, that's not what I am talking about here. You can't use bash to create a complicated application that has a modern user interface which may have to input and store internally store hundreds of gigabytes of data, perform serialization such that the state of the interface can be saved and retrieved later and capture mouse actions such as button press, drag, and button release.

I understand your point however I think the analogy is a bit exaggerated. I would say its more like whether you prefer to drive a Toyota or a Honda. Both will get the same thing done, but one may have some features that you may like better than the other.

Any rate, I'm gonna go spend some time with my sweetie. This is a long drawn out subject. Maybe I will get to the remaining parts of your post later.

 

I recall "lusting" after the leading edge high speed 14.4 acoustic coupler. My 300 baud set up was just too slow. (Don't even get me started on uucp.)

Ya know every once in a while (like this thread) I am reminded of just how much I've seen along the way, how far we have come and how damn old that makes me.

 

Hmmm. That's interesting. My first time hearing about this language. I think the concept is interesting, but I am suspicious for the following reason. One of the big things that was touted about Java when it first came out was that it would eliminate a lot of problems that centered around dangling pointers with its automatic garbage collection. However, having worked with Java extensively, especially when you are writing an application that has to input and handle hundreds of gigabytes of data at a time, this mechanism simply falls far short. For this type of thing you really need to be able to MANUALLY allocate and free memory because the automatic feature simply degrades performance to the point that the application becomes unusable. I found this out the hard way. I suppose what I am saying is that although what you have put forward here as a language that automates many tasks is a nice idea, it is likely to come at the cost of performance degradation. But honestly I have never used it and really don't know that much about it. I am just making that observation off the top of my head.

NetBSD. The BSD signifies that it is based on the Berkeley System Distribution of the UNIX operating system. Although UNIX was initially developed at AT&T, a variant of it was developed at Berkeley by people like the famous Bill Joy. As such NetBSD is an operating system that is a variant of UNIX, like Linux. Therefore, I see no reason why the authentication scheme that you favor could not be integrated into the Linux kernel as a feature.

No, but what you do is that you train software developers on the modern principles of software design like object oriented development, AND you give them a tool like C++ which provides support for those principles so that they can create software that is easier to develop and maintain.

Did not say you could not do that in Vulkan and Metal. What I am saying is that your point about OpenGL being old is misleading because it has features that have been added that make it suitable for the 3D programming needs of developers today. If it was so useless, as you appear to want to led us to believe, then there would not be so many developers threatening to stop making Mac games because of the OpenGL move. Hell, C is as old as the hills now, but you still feel that it is useful.

Well I suppose the point is that it would be nice if there were some standards that made cross platform software development and maintenance easier and more cost effective. What I proposed would be a step in that direction.

 

It's surprisingly unintrusive. It's a lot easier in a functional language, because everything is defined as a function and has zero side effects.

I mean, it could, and the Hardened Linux Kernel is pretty much exactly that, it's just that NetBSD has a userspace already designed with all of this in mind and generally takes less work than setting up Hardened Linux.

I'm really not that crazy about OOP, honestly. Objects and inheritance are really useful in a lot of cases, but I detest languages that force you into the paradigm, given how it often results in things being unnecessarily clunky when you're doing something that doesn't require much use of OOP features.

I was trying to put a bit finer of a point on it than that. The thing about graphics **** is that it's a lot easier to start anew with new hardware in mind than to reverse-engineer old software to take advantage of new hardware advances. C, meanwhile, is particularly universal because it's got an excellent compiler on nearly every platform and it's concise enough that there really isn't much to overturn.

 

How exactly does C/C++ force you into the paradigm? You are certainly free to not use OOB. C++ adds OOP features to C. It's there, not required.

 

It's been a few years, but the last time I did it, it was not that difficult to install CentOS on a box. The only problem was trying to install the Linux driver for the graphics card so that 3D hardware acceleration would be enabled. As I recall, that was a problem then because not all graphics card vendors were supplying Linux drivers for a particular flavor of Linux. However, I think that is not such a problem now because most of the major vendors are writing Linux drivers for their cards.

Well I used to be like that because really I did not study computer science in school. Its just that I was so broke after four years of school that a software job fell in my lap so I took it. However, after having seen the types of things that people do when you don't do it that way, especially with large complicated applications, you see the advantage of it. Not only that when I think about XWindows/Motif programming in C, that stuff could have been a lot cleaner and powerful using the principles of OOP. For example let's suppose that I want to create a custom button for a user interface that is round and uses a pixmap for its display. Doing that in XWindows/Motif and C, while possible, is a major headache. However, in modern user interface libraries that make use of OOP, all I have to do is create a derived class from a base button class. Then I can simply write my own draw method, without having to re-write all the stuff to handle all the various events like button push, button release, etc. That's the power of it. And I suppose until you have to start getting into that type of thing, you may not appreciate the power of OOP.

I don't know if that is necessarily true with regards to OpenGL because it is pretty much a state machine that allows you to render commonly used primitives that are used in 3D graphics. At the end of the day, all that you can do is draw lines, curves, and surfaces along with some lighting while taking into consideration some sort of assumed conceptualized perspective. That's all anything is going to do with regards to 3D graphics on a computer screen. OpenGL is pretty low level, and what people usually do is to wrap OpenGL into scene graph APIs like OpenSceneGraph, OpenInventor and Java3D. So really its not so much about reverse engineering because at the end of the day you will have to figure out how to do those things anyway on any type of graphics hardware, its just a matter of the implementation for that hardware.

 

There should never be limits on what technologies to expand.

 

syntax errors
run debug

 

I've had by far the best results with AMD and Intel graphics on Linux today. Nvidia remains a bit of a sore point in many cases, as they are far more closed with their driver software. I get the amdgpu driver installed standard with Fedora, for instance, and the same seems to go for Intel, but Nvidia needs to be added separately after the fact and there can be a conflict between their driver and the open source nouveau driver, which obviously is developed without Nvidia's help.

By the way, why CentOS? I've tried it a bit, but found it to be pretty far behind current development. It's like using Debian stable or Linux Mint Debian Edition, but it manages to be even harder to set up properly.

 

Ditto my man ditto. The plane that took me to basic training doesn't even put in an with antique fly in shows these days. I remember typing out punch cards for my intro to programing class most people here wouldn't know what one those was if you handed them one.

 

Interesting that you should say that because if I recall correctly, that was a Nvidia card on that box. It was a bit of trouble to install.

There was no reason other than it was free, not to say that there are not other free distributions, but CentOS was the one.

 

Fedora is a close cousin of CentOS, in a way, both coming from the same code base and being under IBM's direction more or less. I guess CentOS is built from the open portions of Red Hat Enterprise Linux, hence its being older (thoroughly tested and stable on supported platforms), while Fedora (equally free, of course) is kind of the development branch of Red Hat. It's where all the latest and greatest software gets implemented, and the distro gets regular new releases every six months. Right now I'm on kernel 4.16.13, and that gets updated pretty often, as in once a week if not more. Lots of bleeding edge stuff here. It even has Wayland and an experimental version of Firefox that is supposed to use that natively, and I guess Gnome (the standard desktop for Fedora) is supposed to be on Wayland now as well, as opposed to X.org. I have had Firefox Wayland running on my little Intel Pentium-based media PC, but it won't start on my main machine here with the AMD GPU, for some reason. But then, I think that version of Firefox only came out within the last few weeks or so. I only noticed it the other day, anyway, and not when I last reinstalled Fedora.

The upshot is that Fedora gets all the latest drivers and other software, e.g. for supporting games. Everything in its repos is very fresh, and I like that a lot. VirtualBox is barely behind the official site release, Wine is likewise, QEMU, etc. Yet it all manages to be very stable! I did have to disable C-states in the BIOS to avoid some kind of odd freeze/crash that would occur, though. Seems to be a Ryzen or chipset-specific issue, and only comes up with the latest kernel series. CentOS would not even install on here due to how old it is. I was trying different distros after encountering that crash and before finding out that I could 'fix' it in the BIOS as described. Linux Mint Debian Edition was stable, as was Mint 18.3, but I ran into other application-related issues with those that ultimately drove me back to Fedora. That's why I'd recommend Mint for newbies doing basic things and Fedora possibly for the more technically orientated, and CentOS if you want to be very, very conservative in terms of both hardware and software

 

No.

 

Machine code is where it's at.

 

Those damn punch cards! Send of a stack to be run, wait till next weeks class, examine the t an error code or two (or not) that it spit out, making corrections, sending it out again, waiting, more minor issues, and before you know it a simple N! program took 8 weeks to "write and debug". today, a novice programing student could do it half an hour. NO shoes and uphill in both directions!

 

I used to work for a guy that could read machine code like you or I read prose. An amazing skill.

 

Closest I ever got to real programming was ANSI, a code, if memory serves. peculiar to early CNC lathes and mills.

 

dupe p[ost

 

My first programming language was Motorola 6808 machine code which I learned after building the Heathkit Educational Robot (HERO 1) back in 1983. After, that I took my first BASIC programming class and soon to follow were all the other programming languages that I eventually learned.

https://en.wikipedia.org/wiki/HERO_(robot)

 

One concept that is interesting is software like VMWare that will let you run several versions of Linux say on a machine that is running Windows. All you need is an image of the Linux version that you want such as a version of Fedora or CentOS, then you can set it up in VMWare running on a Windows machine and you can run Linux while at the same time running Windows. I suppose that what is actually happening is that you are actually running Windows, but VMWare is using the Linux image that you supply to emulate Linux. Its an interesting concept, an operating system within an operating system. I only used the demo free version, but it appeared to work well. Its just that when you get to very complicated applications that make use of big data, like in the hundreds of gigabyte range, then you see noticeable performance degradation. But an interesting concept nonetheless.

 

Damn!! Probably had black rimmed glasses with lenses one inch thick!

 

VirtualBox does the same thing as VMWare and is free. No demo, no nothing. www.virtualbox.org

I use it to run Windows and sometimes play with other Linux systems on my Linux host. Naturally you can use it on Windows to run Linux or other Windows systems in virtualization as well, and it is even available for the Mac. However, no Mac guests are supported on non-Mac hosts, because Apple's gonna Apple.

You also don't need to get an image to use, but can use any installation media you like, whether physical or an ISO file. Once you have set up your virtual machine, it can boot from the installation media and install just like on a real computer. The VM appears as a computer to the guest operating system. Thus it's another computer you are emulating, not just the OS.

But yeah, I/O is likely to be a bit slower that way than natively. I think there are fast options out there, like Xen, which I guess is much more bare-metal than something like VMWare or VirtualBox, but I have not tried it. Qemu and KVM do the same things as VMWare and VirtualBox, though Qemu can also emulate other architectures, which can be really fun. It can emulate various PowerPC platforms, for instance, and Macintosh emulation seems to be coming along fairly well. It can also do Intel Mac OS more reliably than VirtualBox (VMWare apparently also supports this), though I think you need to get a custom EFI and compile it to use with that Qemu/KVM virtual machine, and you have to set it up just right.