If anyone is interested:
https://github.com/mieko/greenbar
I should probably chart out the changes throughout the years, but this was more of a curiosity hack.
686 karma · joined February 14, 2011
If anyone is interested:
https://github.com/mieko/greenbar
I should probably chart out the changes throughout the years, but this was more of a curiosity hack.
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.
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.
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.
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.
It's funny how profit flows up, but legal responsibility trickles down.
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.
I truly hope that this outlook on the world does you better than it did me when I was younger.
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.
Unless you're cool with the thefts that are going on, or think any government regulation is "overstepping."
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?
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.
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
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.
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)
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.
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.
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.
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 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.
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.