Hacker Newsnew | past | comments | ask | show | jobs | submit | rezonant's commentslogin

I guess their LLM doesn't have much training data on how to do video engineering. The result? A "video" stack that looks like a junior engineer wrote it.

Or Gstreamer, which the article says they were using.

> DASH isn't supported on Apple AFAIK. HLS would be an idea, yes...

They said they implemented a WebCodecs websocket custom implementation, surely they can use Dash.js here. Or rather, their LLM can since it's doubtful they are writing any actual code.

They would need to use LL-DASH or HLS low latency but it's quite achievable.


Interesting. Just tried this out on Pixel's gboard and it does seem to correct this sort of issue

Yes, much like admin.google.com (the GSuite admin interface), which goes ahead and tries to two-factor your personal GMail account every single time you load it instead of asking you which of the actual GSuite accounts you're signed into you'd like to use...


I love how the two factor screen has no obvious way to tell it that you want a different account.

Hint: you can often avoid some of this mess by adding the authuser=user@domain to the URL.


Yeah, with multiple chrome profiles, you have to be mindful of which one you last had focused before clicking a link from an external application (i.e. tailscale), so that it opens the new tab in the right instance so the account(s) you use in it are available

Def use multiple chrome profiles if you aren't. You can color code them to make visual identification a breeze


I'm aware of multiple Chrome profiles and I do not want to use them. Google should simply make their account switching consistent across their apps and work sensibly in these corner cases.

"simply" is doing a lot of work, profiles is the outcome of addressing the problems you are talking about. Many people enjoy them and find them useful. Why are you against using them?

Simply isn't doing much work, account switching works just fine on GMail, search, maps, calendar etc. The issue is that some Google apps do not follow the standard of the overall fleet. Google gives us the account switching feature, it's obviously an intended way to use their products. Otherwise they would not give you that and tell you to use browser profiles.

I don't want my history, bookmarks, open tabs and login sessions at every website divided among my 5 GSuite workspace accounts and my 1 personal Gmail. That adds a bunch of hassle for what? The removal of a minor annoyance when I use these specific Google apps? That is taking a sledge hammer to a slightly bent nail.

If it works for you, great, that's why it's there. But doing this for anything more than the basic happy path setup of "I have one personal account and 1 GSuite work account" is nuts in my opinion.


I always have a buggy ass hell experience with having multiple google accounts pretty much across all their services. I've been wondering if its just me or how the hell this is normal.

I long ago concluded that trying to mix multiple google (or MS) accounts in the same browser profile is a path to madness.


seriously, just use different chrome profiles, but part of the issue is that they are so interwoven you pretty much have to do this

Nice! Didn't know you could make a Datadog dashboard public like that!


For the first case, it doesn't work because Object.assign() does not copy the prototype or non-enumerable properties, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

  > let config = {};
  > Object.assign(config, JSON.parse('{"__proto__": {"isAdmin": true}}'));
  console.log({}.isAdmin); // undefined
That being said, it _will_ happen if you use your own merge() function like the TC-39 proposal demonstrates, but its because you are using the [] syntax to implement it which can affect __proto__

Side note, JSON.parse() also doesn't let you set the actual prototype:

  > JSON.parse('{"__proto__": {"isAdmin": true}}')
  { ['__proto__']: { isAdmin: true } }
  > JSON.parse('{"__proto__": {"isAdmin": true}}').isAdmin
  undefined
A normal JS object can do it, but of course that isn't attacker controlled unless you are using `eval()`, in which case the battle is lost anyway.

  > {"__proto__": {"isAdmin": true}}.isAdmin
  true
But even if JSON itself doesn't set the actual prototype, combining it with a user-written merge() function that copies __proto__ will indeed pollute.

  > Object.entries(JSON.parse('{"__proto__": {"isAdmin": true}}')).reduce((o, [k, v]) => o[k] = v, {}).isAdmin
  true


That was a typo, yeah. It should be

  console.log(config.isAdmin); // true!


That's very clever!


We have this nifty util in our codebase:

```ts

/*

* A function that asserts that a value is never.

* Useful for exhaustiveness checks in switch statements.

*/

export function assertNever(x: never): never {

  // eslint-disable-next-line @typescript-eslint/restrict-template-expressions

  throw new Error(`Unexpected object: ${x}`)
}

```


Sigh, I'm so over homebrew's hipster rubyist brewery analogy


And then while checking your email you mindlessly click it and realize its the one you have "snoozed" by marking it unread, so you need to mark it unread again.

Rinse, repeat


Yes - that was Hell.

Now I have a keystroke that will automatically create a TODO with a link to the message. I hit the keystroke and then archive so it no longer shows up in my inbox.

There are lots of poor productivity books/hacks, but the "Do not treat your inbox as a TODO list" has stood the test of time.


I was inbox-only since GMail was in beta, and received tons of email notifications and extraneous mail over that 20 year period that didn't get read.

My inbox was at about 100k _unread_ emails with about 280k total.

I am happy to say I am now at inbox-zero (ish).


Impressive. I've also been using gmail since beta. I'm only at 27,980 unread.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: