141–150 of 151 posts
I sympathize with some of what the author has to say. That said, Google's choice to do business with Israel does not represent "support for genocide." It is also within their prerogative to dismiss employees who protest company policy. Naive / biased statements such of these cause me to lend less credence to author's other points.
Israel is actively committing a genocide right now. How is doing business with them not support for that?
Earlier quoted context omitted.
Does owning a business in the US mean you support the bad things the US has done?
No, but if that business does work for the US then you’re potentially supporting the bad things that they’re currently doing (like aiding and abetting a genocide in Palestine )
The officially stated goal of Hamas is the destruction of Israel.
War is never pleasant or desirable. That said, Israel has every right to defend itself and to fight for the return of its people.
Your position is that Israel should lay down and die. Any attempt to do otherwise is then disingenuously labeled as “genocide.”
The argument you are making is ridiculous. Fortunately, most people recognize that.
I sympathize with some of what the author has to say. That said, Google's choice to do business with Israel does not represent "support for genocide." It is also within their prerogative to dismiss employees who protest company policy. Naive / biased statements such of these cause me to lend less credence to author's other points.
> It is also within their prerogative to dismiss employees who protest company policy. If they are performing their duties adequately, then that's absolutely wrong. It's also utterly stupid. Employees who think about what they are doing are far, far more valuable than mindless drones.
Earlier quoted context omitted.
No, but if that business does work for the US then you’re potentially supporting the bad things that they’re currently doing (like aiding and abetting a genocide in Palestine )
On October 7, 2023, terrorists invaded Israel and killed 1,143 people. Among them - 767 civilians (36 children). Some of them were brutally raped. They then took 251 hostages. The officially stated goal of Hamas is the destruction of Israel. War is never pleasant or desirable. That said, Israel has every right to defend itself and to fight for the return of its people. Your position is that Israel should lay down and…
They’ve killed innocent civilians[2], health workers[3], and journalists[4] all in record numbers. They have not shied away from war crimes and humanitarian abuses [5].
Israel has every right to defend itself, but this has gone so far beyond that. There is no action that justifies this brutal of a reaction.
[1] https://www.reuters.com/world/middle-east/israeli-troops-kil...
[2] https://www.hrw.org/news/2024/04/04/gaza-israeli-strike-kill...
[3] https://www.doctorswithoutborders.org/latest/seven-months-re...
[4] https://cpj.org/2024/07/journalist-casualties-in-the-israel-...
[5] https://www.amnesty.org/en/location/middle-east-and-north-af...
Earlier quoted context omitted.
Except the problem is (which I didn't state but pointed out) is that this isn't really a "problem." It's just math. That's it. If you want to know if I know how to multiply two numbers together, you might as well just ask me if I know what 2*2 is and move on to the next question.
Are you insinuating that the article writer doesn't know what 2*2 is? As their original answer was, "I don't know".
Another example is from my own "worst interview ever" where the guy asked me to implement a BFS and a DFS on a tree. I mentioned that I'd literally been debugging an issue with a DFS algorithm all day at $dayjob, so should be a piece of cake. I wrote out the DFS example in 10s, but then when I got to the BFS, I spaced out on how to write a for-loop. The interview literally just laughed at me, saying, "that sucks for you" so instead I simply showed him how a BFS works and his answer was, "I don't care, I want to see code."
As an interviewer, I get it. I expect you to know concepts, not be able to perform rote actions and put on a show.
If he remembers that max signed int is ~2 billion, than easier to divide 4 billion by 2. 2b/1b/500m/250m/127m/64m - got 6 divisions, 32-6=26.
If you think that max int is irrelevant to the position - it is so relevant, I can't even describe, this number is everywhere, from database design to js-wasm (limited by 32-bit), from deep-learning (where some libraries still limited to 32-bit buffers) to networking (hello ipv4)
if you need a job or financial aid kindly contact us now via email : shalomagency247@outlook.com
Thanks.
Earlier quoted context omitted.
I love these threads. They always show what an absolute dice roll the interview process is. OP rates people taking a best guess at a problem they don't know as a positive character trait, this one rates it as a character flaw. Google didn't reject the candidate, the interview loop he got rejected him for any of the myriad of knee-jerk split-second decisions made on the candidate's character in an unnatural and stress…
Well the goal is to create companies or teams with a consistent sense of what is positive vs a flaw
> It’s you who chooses what sites we crawl Yeah, but you still reserve the right to not crawl sites (or to remove them from your index), yes? So there's still the opportunity to do evil. I'm still waiting for a "raw" search spidering provider. One that: 1. runs a web-spidering cluster — one that's only smart enough to know what robots.txt is, to know how to follow links in HTML pages, and to obey response caching-pol…
Yes, we veto sites to prevent spam. I'm not sure you would like the results of what you suggest - if you are really going to crawl everything indiscriminately, you will end up with a lot of rubbish. Just check out Common Crawl if you want to get an idea of what it would look like.
It has a lot of rubbish, sure, but the reason that that matters with Common Crawl, is that Common Crawl isn't a continuous stream; it's rather a big monthly 100TB incremental deliverable, that makes up part of an even larger multi-petabyte whole dataset; where "using the Common Crawl dataset" mostly means relying on one of a few IaaS providers who've grabbed the whole thing and unpacked it into their serverless-data-warehouse cluster that you can run map-reduce jobs against.
A given consumer of this hypothetical web-scraping-results "firehose via a data lake" API, meanwhile, wouldn't need to drink from the entire firehose in order to "follow" live data. For many purposes, they could instead just drink from the much-lower-pressure URLs queue, to discover what has been scraped; and then schedule fetching just those things [or rather, the domain-and-time-bucketed archive-chunks that contain just those things].
Which, for many consumers, might end up a low-bandwidth-enough affair that the data could be delivered to them over the regular public Internet, without needing them to "move compute to data."
Consumers might still need a copy of the entire dataset to backfill their indexing system initially — and this might still require doing the "colocate to the IaaS cluster where the dataset is, and run a map-reduce job" thing — but that'd be a one-time bootstrapping process, not a periodic job that needs to be reliable.
(In fact, since it's so rare, the scraping-service provider could even take responsibility for running these jobs themselves, as a sort of single-shot PaaS. "Subscribe to the firehose and we'll help you to do a one-time map-reduce over our dataset to backfill your index, all costs on us. Just define a job using this here SDK and upload it to our dashboard; it'll be queued to run on our infra; and when it's done, you'll get emailed a link to an object-store snapshot of the ephemeral data warehouse the job populated.")
---
Also, to be clear, I wasn't intending to describe an infrastructure whose output is directly able to be used as the index of a search engine. It'd be quite useless for that, just as Common Crawl would be. Such a dataset still needs curation.
It's just that, as with Common Crawl, the curation step should rightfully be the (direct, B2B) consumer's responsibility — because there are many different use-cases such data can be put to, that require different curation strategies:
• general whole-web search engines (obviously)
• site-specific search engines
• vertical-specific search engines (think: Google Scholar; FrogFind)
• format-specific global aggregators (e.g. a PubSubHubbub gateway that pre-discovers RSS feeds; a Matrix server that discovers and suggests other Matrix servers; or that old idea of an "Internet Yellow Pages" built out of people's VCard-RDF-microformat contact data embedded in XHTML — but now extended to the proprietary pseudo-microformats of various "about me" landing-page services)
• "see previous versions" services like the Wayback Machine (taking advantage of the immutability of the historical HARs in the data stream)
• a Shodan-like deep-web "discover what doesn't want to be discovered" service, surfacing websites with Disallow * robots.txt rules
• web analytics (like you can do with Common Crawl, but live, using scalable OLTP methods)
• continuous updating of ML models with "up to date" knowledge of the world (at least, once we figure out how to continuously train ML models)
There's really a lot you can do with what's essentially a periodic high-level packet dump of the result of poking every URL you can find, as often as it is willing to let you.