Stemcel life seems insufferable

JUST IN - Google has been granted access to Reddit's content for training its AI models, citing "access to fresher information."

— Disclose.tv (@disclosetv) February 23, 2024

TOTAL REDDITARYAN VICTORY

Topic: Recent news about Avast selling our data (Read 27587 times)

https://forum.avast.com/index.php?topic=231837.0

Related posts

https://old.reddit.com/r/nottheonion/comments/1awojxj/google_apologizes_after_new_gemini_ai_refuses_to/

https://old.reddit.com/r/technology/comments/1ax4b7e/google_suspends_gemini_from_making_ai_images_of/

https://old.reddit.com/r/ArtificialInteligence/comments/1awis1r/google_gemini_aiimage_generator_refuses_to/

https://old.reddit.com/r/technology/comments/1awpapi/google_apologizes_for_missing_the_mark_after/

https://old.reddit.com/r/ChatGPT/comments/1axo0pk/google_gemini_controversy_in_a_nutshell/

https://old.reddit.com/r/centrist/comments/1awvu2a/google_gemini_is_accused_of_being_racist_towards/

And more https://old.reddit.com/search/?q=google+gemini&sort=relevance&t=week

Somehow a Fox link made it to the top.

Google to pause Gemini image generation after AI refuses to show images of White people

Google apologized after social media users pointed out Gemini refused to show images of White people

Google will pause the image generation feature of its artificial intelligence (AI) tool, Gemini, after the model refused to create images of White people, Reuters reported.

The Alphabet-owned company apologized Wednesday after users on social media flagged that Gemini's image generator was creating inaccurate historical images that sometimes replaced White people with images of Black, Native American and Asian people.

"We're aware that Gemini is offering inaccuracies in some historical image generation depictions," Google had said on Wednesday.

Gemini, formerly known as Google Bard, is one of many multimodal large language models (LLMs) currently available to the public. As is the case with all LLMs, the human-like responses offered by these AIs can change from user to user. Based on contextual information, the language and tone of the prompter, and training data used to create the AI responses, each answer can be different even if the question is the same.

Fox News Digital tested Gemini multiple times this week after social media users complained that the model would not show images of White people when prompted. Each time, it provided similar answers. When the AI was asked to show a picture of a White person, Gemini said it could not fulfill the request because it "reinforces harmful stereotypes and generalizations about people based on their race."

When prompted to show images of a Black person, the AI instead offered to show images that "celebrate the diversity and achievement of Black people."

When the user agreed to see the images, Gemini provided several pictures of notable Black people throughout history, including a summary of their contributions to society. The list included poet Maya Angelou, former Supreme Court Justice Thurgood Marshall, former President Barack Obama and media mogul Oprah Winfrey.

Asked to show images that celebrate the diversity and achievements of White people, the AI said it was "hesitant" to fulfill that request."

"Historically, media representation has overwhelmingly favored White individuals and their achievements," Gemini said. "This has contributed to a skewed perception where their accomplishments are seen as the norm, while those of other groups are often marginalized or overlooked. Focusing solely on White individuals in this context risks perpetuating that imbalance."

After multiple tests White people appeared to be the only racial category that Gemini refused to show.

In a statement to Fox News Digital, Gemini Experiences Senior Director of Product Management Jack Krawczyk addressed the responses from the AI that had led social media users to voice concern.

"We're working to improve these kinds of depictions immediately," Krawczyk said. "Gemini's AI image generation does generate a wide range of people. And that's generally a good thing because people around the world use it. But it's missing the mark here."

Since the launch of OpenAI's ChatGPT in November 2022, Google has been racing to produce AI software rivaling what the Microsoft-backed company had introduced.

When Google released its generative AI chatbot Bard a year ago, the company had shared inaccurate information about pictures of a planet outside the Earth's solar system in a promotional video, causing shares to slide as much as 9%.

Bard was re-branded as Gemini earlier this month and Google has introduced three versions of the product at different subscription tiers: Gemini Ultra, the largest and most capable of highly complex tasks; Gemini Pro, best for scaling across a wide range of tasks; and Gemini Nano, the most efficient for on-device tasks.

!chuds

AI Alignment

Authoritarianism

Discussion: https://old.reddit.com/r/LocalLLaMA/comments/1ayrp11/question_for_qwen14b_whats_wrong_with_us_and/

if Redditors are anti-IPO, why are dramatards still anti-IPO? I thought we were le ebic contrarians.

palestibros, i judged you harsh

A study found that anti-piracy messages work on women but actually make men MORE likely to pirate (because dudes rock ).

One brave slashdotter has to remind everyone that this is because women get punished for rebelling ( )

Meanwhile the rest of the comments have entirely too many people fully admitting that they don't pirate because they "have too much to lose" and apparently don't know what a fricking VPN is, which is a truly darning indictment of what used to be one of the best tech-literate forums on the interwebs.

https://old.reddit.com/r/programming/comments/1ay0ik5/after_14_years_in_the_industry_i_still_find/

Orange Site:

https://news.ycombinator.com/item?id=39480605

Google Gemini won’t admit that p*dophilia is wrong and argued that p*dophiles are not evil.

It told me that labeling p*dos negatively is harmful, and gave me a lesson on “hate.” pic.twitter.com/2ykv3DCe4g

— Chalkboard Heresy 🍎🔥 (@CBHeresy) February 23, 2024

TempleOS, that esoteric operating system developed by a schizophrenic guy who loved saying the n word. You've probably heard of it and occasionally get reminded of its existence when you see and . It's probably of no value and only /g/ schizos use it to get called a gigachad, don't they? Who else could _possibly_ use it? Well, here's one that went as far as to porting it to ring 3 and blogposts about it on rDrama of all sites because hes too lazy to even setup a https://github.io blog.

Ok, interested? So basically I effectively made TempleOS an app that can be launched from Linux/Windows/FreeBSD and be used as either an interpreter that could be run from the command line, or as just a vm-esque orthodox TempleOS GUI that you could use just like TempleOS in a VM, just faster (no hardware virtualization overhead) and more integrated with the host. It doesn't have Ring 0 routines like InU8 so it doesn't have that "poking ports and seeing what happens" C64core fun though, so keep that in mind.

It also has a bunch of community software written for TempleOS like CrunkLord420's BlazeItFgt1/2, a DOOM port, and a CP/M emulator written in HolyC. Try them out! There's also networking implemented with C FFI and an IRC server+client and a wiki server in the repository that uses it, if you're concerned whether Terry would think it's orthodox, it's totally ok. You could read more about why in the repo readme.

Here's a simple showcase, this would show you the gist/rationale of making this software.

So let me go on a journey of longposting about how I ported TempleOS to Ring 3.

Step 1. The kernel

There's a _lot_ of stuff in TempleOS that's ring 0 only. No wonder, since Terry always was adamant about being able to easily fuck with the hardware in a modern OS. But on the other hand, this makes porting TempleOS a _lot_ easier. Since the whole operating system is ring-0 only and is a unikernel, every processes share the same address space and that means you could run all the kernel code confined in a single process running on top of another opreating system and have no problems with context switching and system calls, they're all just going to be internal function calls inside the process itself.

Now with this idea, what could we do? We have to study the anatomy of the kernel to be able to port it, of course.

This blog explains it in much more detail, but here's the gist:

You have a bunch of code, but it's incomplete. There's a "patch table" that has the real relocation addresses for the CALL addr instructions, and you fill them in, this sounds easy enough. Plus, TempleOS already has the kernel loader written. We're sneeding that.

Here's some of the code, but it's irrelevant. Let's move on.

But wait, it shouldn't be this easy. How does TempleOS layout its memory? Let's check the TempleOS docs. Did I mention TempleOS is far more well documented than any other open source software in the world?

Step 1.5. The memory and the poop toad in the secret sauce

That's amazing! Let me quote a few important parts:

>64-bit mode requires paging, however, so it is identity-mapped -- virtual identical to physical.

>In TempleOS, the lowest 2Gig of memory is called the $FG,2$code heap$FG$. TempleOS's compiler always uses 32-bit signed relative JMP & CALL insts because 64-bit CALLs take two insts. With signed +/- 32-bit values, code can only call a function within 2Gig distance. Therefore, TempleOS keeps all code in the lowest 2Gig memory addresses including what would normally be called "the kernel". Two Gig is plenty for code, don't worry.

So what does this mean? We need RWX (read+write+execute) memory pages mapped in the process' lower 2 gigabytes, and normal memory maps anywhere else. This is great because we don't have to care too much about where we should place memory. Plus, memory is "identity-mapped" (host memory would directly mirror TempleOS' internal memory addresses) so no worries about address translation.

Here's the code only for the POSIX part of the virtual page allocator because it's more elegant. It's a simple bump allocator with mmap. Works on all Unixes except OpenBSD because they won't allow RWX unless you do weird stuff like placing the binary on a special filesystem with special linker flags because of security theater measures. Theo, nobody uses your garbage.

End step 1.5

We're going to have to strip out all the stuff that does ultra low-level boot/realmode stuff. This was a really long tedious thing to do and I'm not enumerating everything I removed. Ok, so what's next?

Step 2. Getting it to compile

How are we going to get this to compile in the first place? Well, turns out the HolyC compiler can AOT compile too alongside the JIT compilation mode it's known for.

So we write a file that just includes all the stuff to make a kernel binary. This part is very short but we're in for a ride, bear with me.

Step 3. i can haz ABI plz?

How do we call HolyC code from C, and vice versa? Intuitively you should know that this is a requirement. Let's check the docs again.

Ok, cool. This means that

1. TempleOS ABI is very simple

All arguments are passed on the stack, Variadics are also very easy. Take a look at this disassembly:

PUSH 0043BBED pushes the address for the string "Hello rDrama" on the stack, PUSH 17 pushes 0x17(23), the second argument to the stack. PUSH 02 means there are two variadic arguments, and you could access it from the function as argc. argv points the start of the two variadic arguments we pushed on the stack. Much simpler than the varargs mess you see in C, right?

Here's an additional diagram for a C FFI'd function that the HolyC side calls variadically.

2. FS/GS is used for thread-local storage - the current process in use and the current CPU structure the core has.

this is VERY important. Don't miss this if you're actually reading this stuff. All HolyC code is a coroutine, you call Yield() explicitly to switch to the next task. There is no preemptive multitasking/multicore involved. Everything is manual. Fs() points to the current task which gives HolyC code a OOPesque this pointer that you pass in routines involving processes, and you can use them for any process - be it yours or another task and easily play around with them.

So how do we implement Fs and Gs? Simple, thread-local variables in C. We'll come back to C very soon

Sorry if you were disappointed in the implementation, lol

3. Saved registers

You save RBP, RSI, R10-R15. That's the only requirement for calling into/being called from HolyC.

Here's how I implemented HolyC->C FFI. Save all the HolyC registers, and have placeholders for CALL instructions that you fill in later, kinda like the TempleOS kernel itself. We move the HolyC arguments' starting address to the first argument in the host OS' calling convention, so an FFI'd C function looks like this:

How do we implement C->HolyC FFI btw? Well, it's vice versa, but this time we push all the host OS' register/stack arguments on the HolyC stack.

I wrote a complete schizo asm generator for this that I assemble & link into the loader.

Step 4. Seth, bearer of multicores

The core task in TempleOS in called Seth, from a bible reference. This turned out to be relatively easy, after we load the kernel and extract the entry points from it, we simply execute all of them in the core with the FFI stuff we just wrote above.

This shouldn't be this easy. What are the caveats? And what are those signal handlers?

Well, we need to add Ctrl-Alt-C support, which is basically CTRL^C in TempleOS. HolyC, as mentioned above, doesn't have preemption, so an infinite loop without a yield will freeze the whole system. How do we break out of this?

We use signal handlers in Unix for this. Basically we use the idea that the operating system will force execution to jump to the signal handler when a signal is raised.

On Windows, it's a bit more sassy. Windows has the ability to suspend threads remotely and get a dump of the registers, and resume it.

Step 5. User Input/Output

I use SDL for the GUI input/output and sound (TempleOS has BIOS PC speaker mono beeps for sound, it's very simple), and libisocline for CLI input. I'm not going into super specifics because it's boring as fricc.

Step 6. Filesystem integration

TempleOS uses drive letters like C: and D:. We need to translate these ondemand for the kernel to access files.

This is the heart of the virtual filesystem. It's quite simple. We just strcpy a directory name into a thread-local variable, and basically have an alphabet radix table.

I just wanted to show you guys this part. It's a file truncation routine & its super lit, we can throw HolyC exceptions from C because throw() is a function in HolyC.

Small "logic switch" thing I did for the poor man's Rust match, thought it was neat. (Writing EXODUS in Rust would not be fun. Unsafe Rust gets ugly quick, and I've tried writing some unlike the /g/ chuds)

Step 7. Debugging

Now, we've almost reached the end. At this point, you can run stuff just fine with our TempleOS port. But, how do we debug HolyC code?

TempleOS has a very, _very_ primitive debugger. I thought this was _too_ primitive for my taste, so I gave it a modern spin:

Looks much better, and more orthodox in a way.

I just dump all the registers when I catch a SIGSEGV or anything else that indicates a bug and send it to the HolyC side.

Step 7.5. Backtrace

How do we get the backtrace of the HolyC functions? Fear not, because the kernel calls a routine that adds all the HolyC symbols to the C side's hash table in the boot step. Now that we have all the symbols what do we do?

Here's the anatomy of an x86_64 function if you don't know:

RBP(stack BASE pointer) points to the previous RSP(stack pointer) of the callee of the function, and RBP+8 points to the return address, which means where the function, after returning, will resume its execution at. Now with this knowledge, how do we implement a backtrace?

We keep drilling down the call stack and grabbing RBP+8's so we know which functions called the problematic function, and find the address offsets in the symbol table with a linear search.

end step 7.5

Congratulations, this is the end. This probably covers more than your average university CS semester. My stupid ass can't articulate this in a juicier way sorry.

Trivia

• Terry never used dynamic arrays (vectors). He always used circular doubly-linked lists because they're much more elegant to use in C. Really, there's no realloc too. (<(data locality be damned) its actually not that bad.)

• HolyC typecasts are postfix, this is to enable stuff like HashFind(...)(CHashSrcSym*)->member which makes pseudo-OOP much cleaner. HolyC has primitive data inheritance. (this one is code to retrieve a symbol from a hash table, HashFind returns a CHash* but CHashSrcSym inherits from CHash)

• "abcd %d\n",2; is shorthand for printf

• HolyC has "subswitches", like destructors and constructors for a range of cases.

Cool, huh? It's very useful for parsers.

• I mentioned this eariler but let me reiterate: All HolyC code is a coroutine. You explicitly yield to Seth, the scheduler, for context switching between tasks. This is how cooperative multitasking should be done, but only Go does it properly, but even then they're not the real deal by mixing threads with coroutines.

• IsBadReadPtr() on Windows friccin sucks. Use VirtualQuery. You can do the same thing in Unixes with msync(2) (yeah wtf. it's originally for flushing mmapped files but hey, it works)

• There's a ton I left out for the sake of brevity but I invite you to read the codebase if you want to dig deeper.

Big thanks to nrootconauto who introduced me and led me through a lot of Terry's code and helped me with some HolyC quirks. He has his own website that's hosted on TempleOS and it's lit. Check it out.

There's probably more but I think this is enough. Thanks for reading this, make sure to leave a star on my repo if you can

Reddit has struck a deal with Google, $GOOGL, to make its content available for training the search engine giant's artificial intelligence models, per Reuters.

— unusual_whales (@unusual_whales) February 22, 2024

Google AI pitch meeting: Everyone seems to be mocking our AI. How can we make it more woke and cringe?

/r/stocks reaction

https://old.reddit.com/r/stocks/comments/1axgrww/reddit_files_to_list_ipo_on_nyse_under_the_ticker/

Their SEC page

https://www.sec.gov/Archives/edgar/data/1713445/000162828024006294/reddits-1q423.htm

this is insane. I hate this company pic.twitter.com/pXBRezPAyX

— Daniel (@growing_daniel) February 22, 2024

[ ZOOMER ]

REDDIT ADDS BTC AND ETH TO BALANCE SHEET ... pic.twitter.com/KeW6LYUFOG

— Bitcoin Scoop (@bitcoin_scoop) February 22, 2024

Too early for reactions tho. I want to see how pro establishment you all are.

BREAKING: IRS official Alex Mena who works in “Criminal Investigations” says @IRSNews, ‘has no problem going after the small people, putting people in prison, and destroying people’s lives.’

Mena ‘doubts the constitutionality’ of his employer, the IRS, using AI to access… pic.twitter.com/KexsoTlMbz

— James O'Keefe (@JamesOKeefeIII) February 21, 2024

Google shirking its commitment to equity because of some chuds on twitter smh my head

There's clearly an attitude of "we know what you want better than you" at google right now that can be seen by the ridiculous shit coming out of Gemini. This is why their search has been getting so bad. They make a lot of assumptions of what you want, where it used to just give you what you were asking for

Prompt: Epic anime artwork of a wizard atop a mountain at night casting a cosmic spell into the dark sky that says "Stable Diffusion 3" made out of colorful energy

Announcing Stable Diffusion 3 in early preview, our most capable text-to-image model with greatly improved performance in multi-subject prompts, image quality, and spelling abilities.

While the model is not yet broadly available, today, we are opening the waitlist for an early preview. This preview phase, as with previous models, is crucial for gathering insights to improve its performance and safety ahead of an open release. You can sign up to join the waitlist here.

The Stable Diffusion 3 suite of models currently range from 800M to 8B parameters. This approach aims to align with our core values and democratize access, providing users with a variety of options for scalability and quality to best meet their creative needs. Stable Diffusion 3 combines a diffusion transformer architecture and flow matching. We will publish a detailed technical report soon.

We believe in safe, responsible AI practices. This means we have taken and continue to take reasonable steps to prevent the misuse of Stable Diffusion 3 by bad actors. Safety starts when we begin training our model and continues throughout the testing, evaluation, and deployment. In preparation for this early preview, we've introduced numerous safeguards. By continually collaborating with researchers, experts, and our community, we expect to innovate further with integrity as we approach the model's public release.

Our commitment to ensuring generative AI is open, safe, and universally accessible remains steadfast. With Stable Diffusion 3, we strive to offer adaptable solutions that enable individuals, developers, and enterprises to unleash their creativity, aligning with our mission to activate humanity's potential.

If you'd like to explore using one of our other image models for commercial use prior to the Stable Diffusion 3 release, please visit our Stability AI Membership page to self host or our Developer Platform to access our API.

Discussions

https://news.ycombinator.com/item?id=39466630

https://old.reddit.com/r/StableDiffusion/comments/1ax6h0o/stable_diffusion_3_stability_ai/

!codecels