We need to kill indefinite (or even long) copyright and the music industry has been one of the worst offenders.
1,373 karma · joined November 30, 2018
We need to kill indefinite (or even long) copyright and the music industry has been one of the worst offenders.
I think this isn't helped by the fact that HR in alot of companies in the past decade or so has been going with this narrative. We are all a family together in this, stay late when needed, work extra/after-hours, etc.. Lots of places even have the expectation in this regard.
Of course this all goes away instantly when you get cold-emailed a layoff for example. I think its a systemic problem that originated some decade ago in an attempt to exploit people's judgment by creating self-doubt (ie: work more/harder under the premise that if you dont you are letting your "family" down), got perpetuated around alot, all job postings are worded like that nowadays too ("join our family") and it gives the newcomers to the job market the wrong expectation.
The worst offenders are all under IT companies as far as I can see, but because it's been going for so long it wouldn't surprise me if this is industry wide at this point for non-manual-labor job offers.
My datamining project for a game for example, that noone besides me and 2 friends use, gets thousands of requests per second, because all the AI bots found it and try to index every single page (thousands of ssr pages) and they repeat the requests when my cache-control headers expire (ie: when i consider the old page stale), so it's an endless stream (I dont mind the challenge of serving all of these at high performance xD).
My main website, in the same domain (not a subdomain), barely gets any requests, it only has the one main index page with a single link to the datamining subdomain, that's about it.
Extremely legacy software wasn't affected either (log4j v1 or apache commons-logging!). Lots of automated scanners flagging the idle jar as well (when the app used Logback for example as the SLF4J implementer, but the scanner saw a transitive for the log4j jar and would scream at you - that's when I stopped caring about github vuln scans btw, it was a shitshow).
Like dont get me wrong, it was a bad vuln, but to me it seems like it was more hype machine and internet screaming than actual vulnerable applications. I do recall Minecraft was vulnerable though, that one was indeed a big target given publicly exposed servers and such.
I'm sorry but as an outsider to me this straight up just sounds like kicking the can down the road! Let's get it fixed, build more solar, get more power in the grid, deregulate personal solar so its an attractive incentive to get more people generating power, etc.. Rather than "you need to use less" mentality, especially while people literally die to the heatwaves the UK has been getting recently..
It's been pretty clear that globally the grid operators are all very much lazy and would rather increase prices and reap benefits short term than adding more capacity to the grid, even where i live (in Brazil) its very much clear that grid operators too would rather raise your bill and collude to add more taxes if you want to generate your own solar than to get more supply in the grid and make the bills cheaper (we have a minimum bill you have to pay even if you have full self-generated solar AND a thing called a "solar tax" because of course, the sun is the govt's property, gotta pay a tax for using it..).
Still makes me mad that some of the games in Orkut are just lost media now too. Still looking for Cafe Mania... maybe one day someone will find a copy of the flash files.. Ugh.
I'm not surprised they are confident in promoting it to the default, it alongside the many other safety features in the tooling are honestly probably better than my exhausted review of every action.
Auto mode denies are also interesting, sometimes Claude wants to go off script to double check something (ie: waste time checking something slightly related that I know is not necessary/truth holds) and auto mode plainly stops it since it's off scope, nice bonus.
Now that I think about it, maybe I can have a tool hook that detects those cut/tail exessive piping and just strips them and dumps the full output to a temp file..
I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.
StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.
Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.
It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.
Not too sure if you are looking for non Chinese manufactured though, down here anything else is just way too expensive and lower quality anyway!
Dont quote me on the specifics though, and honestly why it can't _just_ be a python file I couldn't tell you, claude code can very much run a python <filename> but maybe thats what the author tried to avoid (or the llm).
Also honest take this looks less like a "backdoor" (implies malicious - this is a link to a CVE after all) and more like a developer access credential/default credential that was burned into the firmware (i'd imagine the code remains but on a production run they randomize the key so its non-guessable but then you get lazy and dont run that extra step and this slips in/you burn the bare firmware with no production configs).