mieko

I wonder this too about X: when I sundowned my Twitter account when I started seeing 80% "no question literal nazi-posting" by bluechecks on my feed, I unfollowed everyone and kept the account just to prevent someone posting on what was my username for over a decade.

So now that I follow no one, when I click a link from Reddit or HN to X, my "For You" page is:

- Asian pornography; AI generated "vibes" videos of machines doing "oddly satisfying" things; Elon Musk; American right-wing politicians and pundits screaming about "woke" or jerking off ICE videos; AI or real public sex outdoors at festivals?

Of course, I don't use X, and don't seek this stuff out, and only see it there.

For 3D, the return of in-engine inverse kinematic nodes (SkeletonModifier3D descendants) has been a big deal for me.

The old 3.x system was a mess, so it was dropped in 4.0. The community filled a lot of the gaps in the meantime, but having the new system (in-engine) is great.

I've been working with it for a few weeks from git master, and everything just works as I expect. It definitely needs some more user-level documentation, though: if I hadn't been following development, I don't think I'd know what everything does, and if someone were new to IK generally, it'd be hard to get off of the ground.

For contrast: Chrome, a piece of software which has a huge amount of attackable surface area, and lives in a spot with insane stakes if a vulnerability is found, checks for updates every five hours, last I read.

For people finding this thread via web search in the future:

screen.studio is macOS screen recording software that checks for updates every five minutes. Somehow, that alone is NOT the bug described in this post. The /other/ bug described in this blog is: their software also downloaded a 250MB update file every five minutes.

The software developers there consider all of this normal except the actual download, which cost them $8000 in bandwidth fees.

To re-cap: Screen recording software. Checks for updates every five (5) minutes. That's 12 times an hour.

I choose software based on how much I trust the judgement of the developers. Please consider if this feels like reasonable judgement to you.

I don't know where you're from, but in the US, the average spot I'd be killing time in is surrounded by acres of parking lots and a busy stroad or two. A Tamagotchi or 1980s pocket calculator is more engaging.

Nothing to do with adrenaline, addiction, doom-scrolling, dopamine or chemical receptors. Millions of people are surrounded by a wasteland of asphalt and machines going 60mph with nothing interesting within sight.

If you're into this, here's my 2014 breakdown of the Silk Road CAPTCHA: https://github.com/mieko/sr-captcha

[flagged]

keen to find out who was responsible at the lowest level

It's funny how profit flows up, but legal responsibility trickles down.

MIT's Living Wage calculator is mentioned in the article. It's a great project.

A while back, I toyed with a project which needed to propose/estimate hourly labor prices for a service marketplace. Not wanting to contribute further to gig-economy exploitation, I used the data as a per-hour payment floor.

Although freely readable on their site, structured data is only available upon request. I think having the data more readily available would allow socially conscious businesses to actually fix part of the inequality problems we have, instead of just knowing how bad it is.

My request went un-answered, but I put together JSON and CSV serializations anyway. If this would be of use to anyone else, contact info is in my bio.

If you're being micromanaged to the point of "allowed" CSS selectors, perhaps you should branch out a bit?

I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.

I truly hope that this outlook on the world does you better than it did me when I was younger.

Use the facilities your host OS provides just as you'd do with Ruby, Python or Perl.

Well that's the thing: I don't know anyone who actively develops in Ruby, Python, Perl or Node that uses the OS-packaged runtimes. The system packages and the language-specific package managers live in different universes.

I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.

Yeah: Literally make it illegal for shops to possess the platinum or palladium without documentation of provenance.

Unless you're cool with the thefts that are going on, or think any government regulation is "overstepping."

Your local cat thief does not have connections overseas. This market only exists because domestic purchasers aren't regulated.

Yeah: No one thinks it's mechanically difficult to remove identifiers. The point is to make such altered parts illegal to buy. Similar to VIN restrictions or handgun signifiers in many states.

Because COBOL has been replaced with better languages for most purposes. SQL is entrenched. I'd also pick SQL for a greenfield project, because... what else?

This says nothing about the quality of SQL as a language.

What I think is more interesting is: if you were to greenfield a language for a relational database, how much would it look like SQL?

The SQL language design is more contemporary to COBOL than anything we'd choose to use today.

That's not implying that large, successful projects cannot be built upon SQL. We see them in the real world all the time.

We have awesome implementations of the language, but any productivity is in spite of a quirky language designed in the early 1970s, not because of it.

Thanks for this project. I found SingleFile a year or two ago, and used it to take "HTML Screenshots" of third party sites I could embed in guided walkthroughs with modified/example data changed, instead of just PNGs.

SingleFile was ultra-valuable for this.

If anyone has a similar use-case, I wrote some pretty rough (and slow) code to post-process SingleFile's output to remove any HTML that wasn't contributing to the presentational render by launching puppeteer and comparing pixels. It's available here: https://github.com/mieko/trailcap

As someone whose pay is processed by Gusto, thanks. That was straightforward.

As someone who has been responsible for large cloud budgets, I wonder if Google is aware that their "support strategy" toward both content creators/contractors and customers across the entire brand has completely ruled out GCP for me.

GCP might have great support. They may not have automated bots suspending accounts. They might actually follow the DMCA counterclaim process instead of some weird process on top of it.

I'll never know: I restrict Google products to casual, throw-away contexts. I've imagined myself trying to explain to my boss or a client "They won't respond" or "They say they can't provide any information." Just typing that freaks me out.

Anyway, if you want to be a huge corporation living under one brand umbrella, you've got to take the good with the bad. Google is for entertainment stuff and toys to me.

I've been running an east-coast-but-middle-of-nowhere startup, primarily implemented by myself, and self-funded, with the occasional with help of random one-off contractors in the hospitality/IoT space for two years now. Basically during off-hours from a (pretty successful) day job in a non-tech company I started years ago.

My choke point has always been finding another technical-minded parter that gets the industry. Every time I've seen the YC application season roll around, I've thought it'd be a perfect fit for applying to YC, with the connections and clout that come with it. What's stopped me, even at my half-assed pace, was the chance of the huge ego/momentum hit of getting rejected, considering it's still a labor of love (although profitable).

I have a handful of customers that are already paying monthly for "The Vision Lite" at discounted prices: just enough for me to continue development. But larger competitors are sure to move more aggressively into the area over the next year or so, before my current trajectory can deliver on the "this is Star Trek-level shit" experience I've got planned. I'm sure I can grow my customer base at a moderate rate, but I'm not sure I can keep up once the field gets serious against better-funded competitors.

Where do you think the tipping point is between the Basecamp-style "Just get profitable, stay profitable, and move forward" model vs. "Take VC money and turn a two-year schedule into a six months, and get entrenched while you can?" (Fred Brooks notwithstanding)

This is what I do, and just so others know:

Realize that if your personal account's shell is pointed into the homebrew installation in /usr/local, and you implode homebrew or wipe /usr/local, you won't be able to start a terminal until your shell is changed or the binary exists. Solving this without Terminal.app being able to launch is a minor annoyance.

asuswrt-merlin is awesome. I replaced my ISP's shitty combo router with a barebones TP-Link DSL modem and an Asus AC5300 (which physically looks ridiculous) running asuswrt-merlin. It turned one of the more annoying parts of my day into, eh, nothing. It just works flawlessly for months on end.

I'm not certain, but is it possible it went smooth because everyone working in C/C++ started paying attention to their data sizes?

We don't have to guess. A huge amount of the code that made this transition was strewn across the internet in CVS and SVN repos, and now in preserved git history. From compilers and libcs to kernels to linkers, loaders and interpreters. They make concessions where they had to (check out glibc), but stay with traditional K&R-style types when possible. The "i32 calculate_age()" thing is way newer than that.

I've heard Microsoft had a great story there, but I was drawing from experiences with the open source Unix-likes. Seems like it was across the board until you get too far into the weeds.

Yeah, I'm arguing that the situation you describe (accurately) is better than baked-in sizes all over the source code.

Use the platform-native types (whatever size they may be) unless you have a reason not to, then use <stdint.h> or an analogue. If CHAR_BIT is 13, let char be 13 bits: the platform probably chose that for a reason. When you have to pack it into a TCP header, do your strict fixed-width stuff there.

Looks like you haven't worked on embedded systems.

I've deleted a defensive technical response to point out that these dismissive assumptions (usually unjustified) are pretty prevalent on HN, and I don't think it promotes level-headed discussion. It reads like "Let me discredit a stranger's background that I don't know, and then argue my opposing view." It creates a defensive mindset off the bat.

Edit: I mean, your points are valid. We won't agree on them, but I don't like the assumption that we won't agree because I'm ignorant to them.

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types.

I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function."

"Just has to work" low level code was the norm during the 16-bit to 32-bit transition, so it was a fucking pain. Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit that to high-level languages that don't care about this stuff, and people using better practices like generic word-sized ints and size_t's in lower level code. Keep that stuff on the borders of the application.

I've noticed a decent-sized emphasis on type size in both Crystal and Swift, two not-entirely braindead newer languages. I don't get it, it's a big step backward.

This is a really good point, and I feel like the two issues are intertwined. I think HPKP being heavily adopted as it's spec'ed now makes it even harder for third parties trying to do the Right Thing, and their customers from taking advantage of it.

Most of the problems I've seen with pushing HTTPS and the vulnerable CA problem forward really do break down at the "third party provider" boundary, which is a little surprising, because it's an amazingly common situation now, and has been for a while.

There's still a decent size contingent of non-technical people that look at exampleapp.com the way I'd look at wellsfargo-online-banking.com. I don't blame them: subdomains imply authority.

While I'm sure there's more, github.io, herokuapp and GAE/Appspot are the only services I know of following this practice, and they cater to a developer-level technical audience with the assumption that they'll work out a better name.