placatedmayhem

> But it's difficult to have much sympathy for companies that invested large sums of money into SVB without doing their due-diligence

What due diligence would a bank customer do that would uncover the sort of escalating risk profile you've outlined? I ask as someone very far from finance and banking.

This feels like an achievement:

  Unbelievable, the crater is visible from Earth
  
  Score: 190.2 point crash
  Speed: 1612.3mph
  Angle: 98.6°
  Time: 220 seconds
  Flips: 0
  Max speed: 1612.3mph
  Max height: 4534ft
  Engine used: 15 times
  Boosters used: 129 times
  https://ehmorris.com/lander/

This feels much too light to me. I'm not sure I can think of a worse thing to do to someone while interviewing them than discriminate against them based on a protected status, outside of proper criminal things.

Discrimination (including "unemployment discrimination") during interviewing should be an automatic, hefty fine, with a significant portion going to the target of the discrimination (assuming the claim is found to be valid). Just riffing, maybe set the fine to something like the equivalent of total yearly compensation package for the average employee in the position being sought. That would be penalty enough to encourage putting it right in the front of any training for anyone making offers, particularly HR.

I see plenty of discussion about CFAA being used against scrapers, particularly automated "bot" scrapers, but I don't see anything about alternative clients, where a human consumer of the service is barred from using the API. But I also only did cursory searching, so some sources for CFAA applied to API would be helpful.

I'm not sure how this would be any different than other software projects that use an API they don't own. Things like Cider for Apple Music, Ripcord for Slack, and the many Spotify clients all come to mind. Perhaps those are less aggressive in pursing 3rd party clients?

I don't know the specifics about Twitter's API saga over the years but... why isn't this the case? Why does Twitter need to be involved on the client side with consumption of the API?

> I have no idea what kind of metrics lead Google towards fixating on the most generic terms of a search

Total shot in the dark, but I'm guessing that interpreting a query string more generically allows Google to serve up a broader collection of ads.

There used to be an operator in search engines of yore (including Google, iirc) that specified, basically, "expand beyond exact matches" to include synonyms and such, maybe "~". Google has basically inverted that, so exact matching requires explicit input. I also find it frustrating.

gron https://github.com/tomnomnom/gron

It takes JSON input and produces flat, key-value output based on the path to the value. Usage with grep was obviously the original intention, but I've used it to help me better understand a given JSON's structure, too, which I then usually reflect back into a program that's consuming that JSON.

It also supports "ungron" too, so, for example, `gron some.json | grep -v "thing I don't want" | gron -u > filtered.json" makes for quick filtering of a JSON. I find it more user friendly than jq's language.

YouTube's copyright controls have been a constant sore spot for creators for years at this point. YouTube/Google seems uninterested in addressing the problems. It seems that improvement is either imperceptibly small or just outright doesn't exist.

What will it actually take for this to improve? Copyright legislation (e.g., DMCA) roll back or alteration? Content creators and/or viewers leaving the platform over it? Something else?

Mildly off-topic, but I'm somewhat tired of the reuse of names for different software. Originally, I was confused by this post and why Substack would be using Norton Ghost. There's also the Android post-explotation framework and ImmersionRC's Ghost radio control protocol.

There are significant questions about the efficacy of AMBER Alerts, which is concerning given the massive disruption and potential for negative conditioning for other government-originated alerts (severe weather, terrorism, etc.). Here's one paper from 2014 that analyzes AMBER Alert cases compared to those without an alert:

https://www.tandfonline.com/doi/abs/10.1080/0735648X.2014.10...

Yes. When we got a shipment of 1000+ servers that are all supposed to be cabled the same way, both internally and externally, the device naming made it easy to see when something got messed up. This allowed us to hold the system builder accountable, simplify our configuration management, and reduce the amount of configuration discovery a engineer needed to do during an incident.

I and multiple of my coworkers love systemd. We work in a "hyperscale" environment and we moved from sysvinit through Upstart to systemd at scale, predominantly on RHEL and a little Debian. We were all skeptical at first. But sysvinit and Upstart both sucked for various reasons, and we had tried to work around the warts. systemd has mostly solved all of those problems for us. Some of the things that systemd improved:

Init scripts suck to test and debug. When manually-called, the caller's environment would get used, rather than a clean env, which would cause problems with the poorer-quality scripts. These showed up multiple times in production where an engineer would bounce a process manually and it got some configuration from their environment. We took some steps to alleviate this, like encouraging use of `service`, but using the scripts directly was reflexive for most because of years of indoctrination and it's portability to some other operating systems. systemd eliminated this entire class of issues, because unit files are just config files, not scripts.

Dependencies actually work. Usually, this came up when needing to wait on the network. With systemd, this is just a single dependency in the unit file. It also meant we stopped having to manage S## and K## which became something of a time-consuming art on machines with lots of services.

Not exactly init system, but systemd's triggered units absolutely destroy cron. Manually running a job (e.g. when testing or when a run failed) guarantees the same environment, whereas cron has no similar capabilities. It also actually keeping status means we can more easily see if the last run succeeded. This may ease our monitoring burden, too, but we haven't gotten to give it attention yet.

There is still a lot of demand for the not-latest-generation, "long tail" fab processes. Much of the long tail manufacturing was (is?) what the chip shortage was about, rather than the current generation.

A good example is the automotive industry. It doesn't typically move quickly or frequently onto newer generation processes as that requires R&D time and other expenses. However, these have been some of the worst shortages, with auto manufacturers still impacted by lead times (although, this is starting to clearing up fwiu).

Targeting the current-best process, rather than the next generation, alleviates some compounding of risk that would be incurred by logistics concerns of turning up a new site and putting that new site on a process that they don't yet have full confidence in because it's not seen production yet.

It's not just a web browser, though. It's the sole method to install software, most similar to a package manager on a desktop operating system. On your point, many package managers do have the ability to browse the remote index of the software they can install (e.g. `brew search [X]`, dnf search [X]`). However, the primary purpose of a package manager, including the App Store, is to install and manage software. This is a critical operating system function, made more critical on iOS by the fact that the App Store is the only way to get software.

Same. I have moderately large hands (XL motorcycle gloves), and I prefer the iPhone Mini form factor for the exact same reason. Sadly, it looks like it's gone to the graveyard. I haven't seen a flagship Android phone in a similar size recently either.

To get the battery life, I'd rather have a thicker phone without increasing the screen size.

I agree. I find canary or blue/green deployments paired with good rollback plans to be more valuable than a staging environment, yet I see them utilized less. I'm not sure why, though.

This is why I mention Chrome's web apps. I see these as a reasonable middle ground. They are a relatively low barrier to entry and could be used as a way to allow the user to opt into app-like behavior. Sites that the user hasn't opted into wouldn't have these abilities.

As another commenter mentions, I'm more likely to disable Javascript by default rather than continue to allow it's abuse. I suspect I'm in the minority though.

Double-redirect attacks not withstanding...

Thanks for posting this. I am increasingly frustrated with browsers' weak stance on user control. Hijacking back buttons, right clicks, copy functions, and other items has become quite commonplace and even expected. For example, YouTube puts some functions only in the right-click menu and TinkerCad's viewport rotation is primarily right-click and drag.

Presumably, this is in pursuit of making web pages behave more like apps, but it is truly frustrating. If I wanted app behavior, I'd install an app (even something like Chrome's apps). While I'm in a web browser on a web page, I expect to interact with the web browser primarily and the web page through the browser intermediary.

The Line of Death discussion is highly relevant: https://news.ycombinator.com/item?id=13400291

I've grown increasingly frustrated with media outlets not citing sources, particularly about scientific, medical, and technological topics. I frequently have to go find source papers myself to discover things like the sample size for a medical study is actually single-digits and statistically irrelevant.

Specifically, more atomic commits make rollbacks easier when issues with a change are discovered after merge (e.g., in integration and user acceptance testing). In the very active code bases I've worked on, generating a rollback commit for a single commit is far more straightforward than having to deal with a merge commit that potentially includes other merges (e.g., with `git pull`'s default behavior). In fact, GitHub's pull request UI has it as a single button.

I can only guess about the distinction our legal department sees.

Yeah, other shell flavors are fine.

I moved over to shellharden a while ago. It can actually apply the suggestions it makes. Aside from that, my employer is somewhat disapproving for GPLv3 tools, but MPL that shellharden uses is essentially auto-approved.

https://github.com/anordal/shellharden

Rebase has become so integral to my workflow, it's hard to imagine living without it. I intentionally avoid merge commits, including configuring git pull to rebase rather than merge. I find it so much easier to commit a bunch of tiny iterations while doing local testing, rebase and squash them, then post them for review. As a bonus, I frequently push after each of those small commits to a feature branch so I don't have to worry about losing work if my drive dies.

Looks like it's back, at least for me. Wayback Machine has a copy, just in case: https://web.archive.org/web/20220920152158/https://www.nvidi...

The CentOS project itself called Greg a founding member in a blog post interviewing him in 2019, well before the Red Hat/CentOS events in December 2020.

https://blog.centos.org/2019/03/greg-kurtzer-centos-founder/

For what it's worth, The Register refers to Greg as a CentOS founder in their first Rocky article:

https://www.theregister.com/2020/12/10/rocky_linux

If you have some references to back your assertions, I would very much like to see them. You're not the first person I've seen assert that Greg shouldn't be called a founder of CentOS, but I've yet to see that backed up.

Also, you seem to minimize the non-technical, especially legal, work around setting up and maintaining a distribution, but I don't understand why. In terms of legal work, trademarks need to be registered, non-profits need to be set up to fund critical items like build infrastructure, and more. Each of these seems like exceptionally valuable, if not critical, to the success of a distribution.

There was an article here a couple months ago about the browser's "danger zone", i.e. the area that can be controlled by the website, and how it's changed over time. The context was around the encryption padlock to indicate valid certificates. What I took away is that nothing in a browser can be trusted now.

Indeed, in my experience, hijacking elements like right click, copy, and back/forward buttons is somewhat commonplace. Some browsers are better at avoiding this, but none I've used are immune to hijacking tricks, especially the back button.

Having read the full context on the original article on pocketgamer.biz, he is, in fact, making the assertion in this post title -- that game creatives that aren't working with sales and publicity teams from the beginning to build in monetization are idiots.

Original article: https://www.pocketgamer.biz/interview/79190/unity-ironsource...

Edit: I say this because I don't understand how it's not clear that he's driving for monetization in every game.

I presume that local vault support has been removed, as AgileBits planned. This is now a problem for the workflow we use to manage passwords in my team, so we'll be changing password managers, which will likely influence my personal usage as well.