HN user

BuckyBeaver

292 karma
Posts0
Comments183
View on HN
No posts found.

Leaded gas is on the (long overdue) way out, now that there's finally an unleaded option approved for the entire piston fleet.

A modern piston plane can get the equivalent of 30 MPG, and fly directly to its destination. So there's no need to rag on it.

Really? Electronic ignition and fuel injection alone are advantageous enough, not to mention the ability of at least one Rotax engine to use true automotive gas (gasohol).

As the article points out, the writing was on the wall for leaded fuel decades ago. The GA industry killed itself by dragging ass on eliminating the need for it, abetted by the burdensome FAA certification process for any aviation advancements.

It may be too late to save GA. BasicMed was a big help, and the increased pace of STC approval has been a boon. But with the FAA derelict in its duty to protect airports (see the sellout of Santa Monica as an example) and corrupt local governments eager to destroy our public airports and sell their land to developers... the future looks grim indeed. Just as electric training aircraft, unleaded fuel, and less-polluting and more-efficient engines render the anti-aviation cabal's excuses moot.

Transmission v4.0 3 years ago

Every time I try a new Transmission release, I remember why I deleted it last time:

NO PROXY SUPPORT.

Ridiculous.

Maybe I'm missing something about this one, then. How is detecting "me" Mastodon links on Web pages similar to discovering people who are online near you?

Or as that not what Nintendo's did? Anyway, thanks for any insight.

Spyware or malware or adware. The beyond-obnoxious badgering to log in, log in, LOG IN!!! with your "Microsoft account" to do ANYTHING renders the OS totally unacceptable in my house... and I regret replacing my parents' computers with new Windows machines plagued with that offensive behavior, along with crippling UI defects (some MS apps ignore the system-wide font-size setting, for example) and missing fundamental applications (like a competent E-mail program).

I was a software developer of large Windows-based systems for over a decade, before going to work for Apple. I regarded Windows as a sharp knife, and Mac OS as a child's safety scissors. Today, Windows is a depressing, hopeless mess and Mac OS is what I rely on daily to get stuff done. I hope rumors of Apple introducing touchscreen Macs are wrong. Doing so would require degrading the OS UI for a stupid, failed idea... leaving no good mainstream desktop OS.

The original pressing is a great example of how good pop music used to sound and how shitty it sounds today because of dynamic compression.

“3 a.m. Eternal” sounds huge, and doesn’t inflict pain when turned up LOUD.

I haven’t listened to it on streaming services, but most of their catalogs have been ruined by “remastering;” AKA crushing them into a wall of noise with dynamic compression to make them “louder.” It’s despicable.

This is exactly what I expected: a well-traveled path. I assumed I was doing something wrong or just not "getting it," and spent weeks digging through the scattered doc and poring over Java code and templates... and the generated code, which wouldn't even compile. In our case, we needed C++ for client and server... a hugely under-served scenario.

Using OpenAPI and Stoplight was very useful for thinking the API through and how the whole thing could work, but the code-generation aspect was a total bust. And talking to some new colleagues later who had some knowledge of it, I found that I wasn't alone in my opinion that the tooling is trash.

Even worse, the prevailing opinion on the ecosystem is so poor that it might even be a professional liability to propose (or admit to) using it. The implication was that it (or at least the code-generation facilities for it) is by and for people who don't know what they're doing. Oof.

It's hard to say. It may be that the Java ecosystem for it is in good shape. The generator tools are almost all Java, so you might have the best-case scenario.

The OpenAPI Generator uses Mustache templates and a plug-in-style design to handle all the different languages and outputs targeting different packages. I was never able to find a succinct document explaining exactly how the processing steps worked or even a catalog of data elements that the generator extracted from your OpenAPI spec document (YAML or JSON). So while there's a lot of talk about creating a custom template, or, if that's not enough, a custom generator... the documentation to do so is very incomplete. The only example I found all discussed making a generator for documentation and not code. Again, not to sound unappreciative, but... that's lame.

What are you trying to do in regard to your API? I just developed an extensive API definition using OpenAPI, which (as of version 3.1) is compliant with JSON Schema. I used Stoplight Studio on Mac OS, although it still doesn't fully support OAS 3.1 two years after it became the current OpenAPI standard. The support from tools and generators is terrible; there's still no apparent toolchain that supports version 3.1 from definition through code generation.

Ass-dragging on 3.1 support aside, the code-generation tools out there are, in my experience, trash anyway. It's a massive hodgepodge of Java-based tools with incomplete and redundant documentation repositories all over the place, and widely varying output quality... when the tools work at all. I appreciate people giving their time to open source, but on the other hand I wasted so much time trying to make the broken tools work that I could have written my own code generator from scratch (which is what I ended up deciding to do after weeks of dicking around with OpenAPI Generator).

Anyway, I was just wondering how you're using JSON Schema for API work (since you didn't mention OpenAPI).

"The flying cars that are in development currently are largely mega-sized drones."

Mmmm, I'm not aware of any that are. The Terrafugia wasn't, but it has been abandoned apparently. The Samson Switchblade is a three-wheeled car with a pusher-prop design: https://www.samsonsky.com/models/

The three-wheel strategy is pretty smart, because the vehicle can be licensed as a motorcycle and doesn't have to have all the heavy safety equipment of a car.

Cool! Thanks for the link. I checked out a few DIY projects years ago, and even bought a few broken Super-8 projectors to scrounge their film-advance mechanisms. But I haven't revisited the state of the DIY art for a long time.

Sure. I don't begrudge the cost of the devices. In this case I'm calling out the missed opportunity of having built most of such a device already and not following through to expand its appeal to more potential customers by offering a particular accessory.

Also the opposing viewpoint to remind yourself of is that hey, SOMEBODY was the first to make one of these things and started a company to do it! I've given up on ideas before starting because of the manufacturing technology required, only to see a company like GoPro come out of nowhere and own a market segment.

I understand (I work in the industry), but the point still stands that these companies could have added greatly to the appeal of their scanners by offering a motion-picture attachment, no matter how slow.

I was considering trying to build one out of an inspection microscope, but gave it up and just had my most-important reels scanned to TIFFs.

Another one is that nobody made a feeder for movie film, for ANY of the consumer or "prosumer" scanners at any price.

If you want film scanned today to individual files per frame, it's still a bunch of money if you can find someone to do it... and good luck getting it done right.

There's a happy medium, though. Overly-photorealistic controls are actually counter-productive, especially when incompetently chosen. For example, at the height of Apple's cheeseball skeuomorphism was Game Center, which featured such things as "velvet" card-table surfaces with "painted" labels on them... but those labels were actually controls in some cases. Now who sits at a blackjack table and tries to interact with the paint on the velvet in front of him?

Another example was the "LCD" display at the top of iTunes, depicted as having a transparent cover over it with a sheen and highlights. Unbeknownst to most users (I suspect), some of the labels in that display were actually clickable controls. WTF? I've owned numerous audio components with displays behind clear plastic windows, and I've never tried to poke at one with my finger.

I think mid-'90s GUIs hit the right combination of graphical (not photographical) with universal visual cues. Buttons had only three or four monochrome shades, but had beveled edges whose shadows inverted when the button was "depressed."

I'm glad to see some backlash against the lazy obscurity of "flat UI," and a return to some proper demarcation of controls.