reportt · HackerTrans

2 years agodiscuss

Also could be causing user informational dissonance. You are potentially reading the "FireFox Version" of the site, and your NotebookLM is chomping away on the "AI Version" of the site, and they can be wildly different. And you won't even know because you don't see the "source" of the "AI Version". What are we gonna do, upload everything ourselves, manually?

reportt

2 years agodiscuss

> This is no different than the decades-old technique of "cloaking", to fool crawlers from Google and other search engines. Isn't this more "Hey, why is this website giving my NotebookLM different info than my own browser?" You reading Page_1 and the machine is "reading" a different Page_2, what's the difference between that information?

I'm reading this less as

> "We serve different data to Google when they are crawling and users who actually visit the page"

and more

> "We serve the user different data if they access the page through AI (NotebookLM in this case) vs. when they visit the page in their browser".

The former just affects page rankings, which had primarily interfaced with the user through keywords and search terms -- you could hijack the search terms and related words that Google associated with your page and make it preferable on searched (i.e. SEO).

The latter though is providing different content on access method. That sort of situation isn't new (you could serve different content to Windows vs. Mac, FireFox vs. Chrome, etc.), but it's done in a way that feels a little more sinister -- I get 2 different sets of information, and I'm not even sure if I did because the AI information is obfuscated by the AI processes. I guess I could make a browser plugin to download the page as I see it and upload it to NotebookLM, subverting it's normal retrieval process of reaching out to the internet itself.

reportt

3 years agodiscuss

> and because it results in people asking to talk to me instead.

reportt

5 years agodiscuss

Yeah, that's understandable. Don't be afraid to have refactored changes on other repos locally, just be sure to do the package version updates first.

reportt

5 years agodiscuss

> Does anyone have any other practices they can recommend for managing these type of projects?

Honestly, the only way around these sorts of issues is to utilize automation in some form.

I've found that setting up repositories (like devpi[0], Artifactory[1], or Docker Registry[2]) on a shared network location (for your project, could be local if you work alone) and using CI/CD tools (like Jenkins[3]) are the key. The goal is that you end up working on one portion of the code base at a time, and those need to go through the standard validation processes so that you can pull in the updated package version when you work on something down-stream. You making sure that the CI/CD environment _doesn't_ have access to other packages's non-versioned code is key for making sure things actually work as expected.

For example, if you have FooLib, and you need an update in that for BarApp, then even if you branch FooLib 1.2.3 to 1.2.3-1-gabc1234d (the `git describe` of the commit) on `feat/new-thingy` , then even if BarApp v2.3.4-1-gaf901234 depends on that new branch, it shouldn't be in any way able to reference that branch on the CI/CD build process. How do you get around this? Good development -- finish the FooLib branch, get that working, merge it in with the updated version, and push the package (with the new version) to the CI/CD-accessible repository. At that point, when you push your BarApp change, it can actually build and not die. But until FooLib has got a versioned update, BarApp's branch _shouldn't_ be able to build.

The statement of "But I want to work on the changes locally, in parallel" is valid. That's what local development is for -- giving you space to work on related things that don't impact the upstream codebase. You should have the option to utilize FooLib's branch code in your BarApp code locally, and you can often do that via things like `pip install` or `maven install` or whatever the relevant local install command is. At this point, the package still probably has the same version number, so the local build doesn't trigger issues. You can work on the two and tweak and twist as you want, but refrain from actually trying to push BarApp referencing FooLib's branch until it's actually in the repo.

This all takes a great deal of restraint and patience. The goal here is make it just a tad harder to introduce problems somewhere since you can't depend on something that hasn't been given the go-ahead. While there might be a lot of "Updated FooLib requirement to v1.2.4" throughout your codebase, why are you doing that just off-hand? If you are doing it because of a security issue or bug, let that be known in the commit message. If you are doing it because you can utilize a new feature/whatever, your commit message won't be just "Updated FooLib", you likely are doing "Added Feature X2Y, updated FooLib to 1.2.4".

PHP I try not to touch much, simply because I've always had bad experiences. I know for a fact that there are decent ways to do it with build tools like Maven[4], setuptools[5], and Docker[6]. Hell, I have used Docker as a way to introduce versioned dependency packaging, only needing to use Docker Registry (each dependent project does a multi-stage build, pulling in the dependencies via the versioned package images).

---

[0]: https://devpi.net/docs/devpi/devpi/latest/%2Bd/index.html

[1]: https://jfrog.com/artifactory/

[2]: https://docs.docker.com/registry/

[3]: https://www.jenkins.io/

[4]: https://maven.apache.org/

[5]: https://setuptools.readthedocs.io/en/latest/

[6]: https://www.docker.com/

reportt

5 years agodiscuss

I know, right? I mean, I paid my rent on time for the entire pandemic due to having a job. All those people who have back rent and possibly lost their jobs and only now are getting them back should also have to meet the same financial burden!

Or, ya know, accept that people need a place to stay and recognize that the pandemic was a global disaster that many places were unable to handle, and kicking people out now might be a bigger second order problem.

reportt

5 years agodiscuss

The only time in which you would need blockchain over a centralized DB is when everyone needs access to the DB, but no one trusts each other. Like if you needed to store healthcare information for multiple people which theoretically could be accessed by multiple competing hospitals or something. It's a lot of overhead to legitimize not just using a centralized DB for most applications.

reportt

5 years agodiscuss

U.S. taxpayers who make $452k single/$509k married would have their top marginal tax rate increase from 37% to 39.6%. This will happen in 2025 anyways, assuming Congress does with regards to the Tax Cuts and Jobs Act.

The people who this applies to generally fall into the Top 5% of Earners tax bracket (Top 5% in 2018 was $309k+). [1]

[1]: https://www.investopedia.com/personal-finance/how-much-incom...

reportt

5 years agodiscuss

> If someone found an exploit in your web app container [...]

A good pattern here is to reverse proxy all requests to the application through something like nginx. My applications tend to have a back-end application that is not accessible to the internet, with an nginx instance that proxies all API requests itself. Only port 80 is public facing. If someone can get console access to an nginx container and then use that to springboard to another container and get root access there (again, where the only open ports are ports 80, maybe 8000?) to get envvars, they should get access to it all.

If you are worried about secrets, check out the Docker Compose 3.9 documentation: https://docs.docker.com/compose/compose-file/compose-file-v3...

reportt

5 years agodiscuss

Using the docker-compose.override.yml helps with that. In local you can just have those services/configurations added, and then the production environment doesn't even need to know they exist.

reportt

5 years agodiscuss

The idea is that you have a core structure that is used in both local/dev environment and the prod environment, with just the override applying changes. For example, your local override might have the "build" configuration, whereas the dev environment or production environment docker-compose should not have that configuration (assuming you are pulling from a private registry). That single core docker-compose.yml can be copied to any environment it needs and it should just run the app, but if you really, really need to override something for a specific reason, it's not hard to do it without modifying the core docker-compose.yml.

reportt

5 years agodiscuss

But underwriters don't necessarily need to insure every officer, and not every officer will be insured the same. If they are deemed too risky, it doesn't matter if the union is backing their premiums or not -- if they don't have insurance, they can't work (or can't do fieldwork or something).

comments