0x0aff374668's comments

0x0aff374668 | 6 years ago | on: For the first time on record, the 400 wealthiest Americans paid a lower tax rate

> And that only increases as you get richer.

Correct. Which is why income is such a miniscule fraction of the 1% (and above's) earnings. It's all out there in the open. Pick any CEO in the top-100 corporations. Look at their income. Then look at their overall earnings. The bulk falls under capital gains due to stock. Then there is deferred compensation, where taxes are lowered even MORE if you agree to postpone being paid. There are so many clever ways for the very very rich to avoid taxes it boggles the mind.

So go ahead and keep talking about the income tax, they've got you distracted.

0x0aff374668 | 6 years ago | on: Making My Own Glasses

Funny, I've been struggling with exactly this issue. Over the past few years my eyes have worsened to the point where doctors cannot find a contact scrip that works in both eyes: we have to compromise with one eye fixing far-away and the other fixing near. I had TWO optemtrists generate an Rx and they differed in all domains, with the astigmatic axis off by 90-degrees in both eyes! I've wanted to buy a lens kit and do it myself for years, but after reading how complex a process it is to find a compromise due to all the daily fluctuations, I'm ready to accept that my eyesight is just a mess and nothing can fix it for ALL scenarios.

0x0aff374668 | 6 years ago | on: Why I Write Games in C (yes, C)

Which SDKs do you use that are C++?

I use Keil, IAR, Renesas's compiler, XM8/16/32 from Microchip, and GCC.

Which do you use?

One of the main features of C++, its object-oriented stuff, is built on top of constructors and destructors -- aka dynamic memory allocation. This sort of thing is not desirable on deeply embedded systems due to resource constraints and the very real spectre of heap fragmentation -- embedded stuff tends to rely on static memory allocation done at compile time or system startup.

C++ isn't quite as portable as C -- Not just the compilers which never quite supported the same combinations of features -- even if you just stuck with the ISO-ratified features -- but the language runtime, standard [template] library, and headers are far larger with various implementations including plenty of mis-features and quirks. All of this meant that it was quite common for C++ code to not even compile with a different toolchain -- especially when templates were used -- and even if it did compile, it might not actually function correctly.

If you restricted yourself to avoid the problematic areas of C++ (eg not using templates or dynamic allocations) you'll end up with a language that is basically C. So why not just use C? :)

0x0aff374668 | 6 years ago | on: Why I Write Games in C (yes, C)

Arduino is a sandbox for people with little experience in embedded programming to dip a toe. They aren't interested in writing optimized constrained code, which is what 99% of embedded programming for products is about. Two totally different spheres.

0x0aff374668 | 6 years ago | on: Why I Write Games in C (yes, C)

Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real product.

0x0aff374668 | 6 years ago | on: Pure Bash Bible

"maintenance headache."

Then stop maintaining code from languages you don't understand. This is frustrating. I've seen solutions on the comments that call PYTHON! Are you effing kidding me? PYTHON ??

Granted, BASH docs aren't particularly succinct, but shell scripts are an absolute necessity in the OS world.

It's pretty simple: If you don't understand shellcode, don't maintain an OS, or rather, don't expect to be accommodated for lack of knowledge for something that's been standard for 30+ years.

0x0aff374668 | 6 years ago | on: Pure Bash Bible

Very useful. I hate having to pull in external processes to do something simple in BASH that the manpage doesn't cover. Expecting PERL to be on every machine (or the right version of SED.. posix? gnu?) is not reliable in my line of work.

0x0aff374668 | 6 years ago | on: Oh shit, my weekend project turned into an App Store Best New App (2018)

I don't know what troubles me more:

1. a clearly-expert developer bragging about 1 hour to write hit app then telling everyone to basically live the dream chicken soup for the soul bs

2. people who experience increased anxiety from said wampeter/foma/granfalloon* because they haven't wildly succeeded

My brain to me: Welcome to 2019.

* See: Kurt Vonnegut

0x0aff374668 | 6 years ago | on: Michael Crichton: Why Speculate? (2005)

This raises my hackles every time I see it (enough to create an account and post): Y2K was ABSOLUTELY a real problem.

There was an enormous amount of money spent prepping for it years before 2000. In 1995, a few years after I graduated from college I got a moonlighting job cleaning databases for a UK phone company, manually editing 2 digit dates to 4 digit dates (I didn't know PERL existed at the time). Yeah, nothing major happened Jan 31 1999, but that's because there was a real, concerted effort to address it that wasn't trumpeted across the news media.

Not directed at you, I just needed to yell at a cloud.

page 2