tracker1

This is just more than a little fucked up... I think we've "limited" liability way too much in terms of corporations... it's the investors that are meant to be protected, executives and board members are not meant to be immune. And I do think in the worst cases, the death penalty should be on the table.

edit: to be clear, IMO, corporate power is an expression of govt power, which should be minimized.

To me, the graphics abilities have been there for a decade... what we need are better games and gameplay. More fun games without gotcha, pay to win, loot box efforts. Too much effort is going for dazzling graphics at the expense of overall gameplay. How many people are still playing CoD, WoW and so many other games from over a decade ago? How many refreshes of Final Fantasy have we seen?

The graphics can only carry you so far. There's indy adventure games with SNES level graphics that have millions of daily users.

On the margins, that's crazy thin for the size of the org... One bad quarter could turn from a few million in profits to hundreds of millions in losses. It's too close, and there's no way to build/store funds for any kind of storm at that level.

Now, I think the vast majority of the pain is more than self-inflicted... I think actual business, marketing and focus need to start taking priority over idealistic political PoV. Let the games target their natural audiences and have the broadest appeal... at a certain point, trying to gain 1% of audience means alienating 25% or more.

For smaller projects and locally, I'm running background services via a compose file... it's a few lines of configuration, and just works. Redis is crazy low hanging fruit.. even job queues that run over Redis make a bit more sense than with Postgres more often than not.

I'm far more hesitant to throw a more formal MQ in the mix though... mostly from experience in that a lot of mid level ("senior") developers don't really understand queues very well at all. Even if conceptually, using tables for queues is more complex.

That said, I will use PG for workflows similar to K/V, Document (JSONB) and other structures over reaching for say MongoDB, etc.

Both Dell and Lenovo have tended to favor Intel first... even more recently on business laptops.

For that matter, just getting Chinese DRAM into the market could cool pricing down a lot to oppose the cartel.

When this hardware was announced, it was expected to be in the $1200-1400 range new... so, maybe. The real question is will the powers that be let this bubble burst, and how painful will the fallout be... I have a feeling it will be worse than 2001-2002.

That's the rub... this platform was supposed to be around $1200-1400 maxed out, but now it's $4k, which is insane.

I'd say an event should have the date/time in local offset AND the location details rough or fine grained. OR the date/time should be stored/transmitted in UTC if it doesn't have a localized date+time+location.

DateTime logic in general is just difficult in general.. Most systems can translate to/from UTC with ease, it's just when the localized offset of the futre changed like in this case.

I've seen commercial sites hard-code gzip content in all their responses regardless of the Accept headings. Probably just as fair to use Brotli these days.

Similarly, I've been using zopfli (gzip/unzip compatible) for png compression after quantization for db storage from 2-color (B/W) scans as it's directly compatible to the browser but winds up about 1/6 the original sized tiff. Not the best compression, had a discussion for a better compression, but required a wasm renderer to decompress as it isn't in the browser box.

We have 4 smaller dogs (mix of chihuahua and terriers), and they all absolutely love the greenies over anything else. One of them now has a prescribed treat and he definitely isn't happy about it, and the others won't touch it.

Hardest part is now feeding them all separate dishes at regular times every day.

I worked for a while at a service company that helped for a few of those issues specifically. It basically served as a back-search against an email address and known connections (social media), and online connections to give it an effective score if it should be manually verified or sidelines into a separate bucket than the general pool.

And even that isn't as icky as a short project I worked on for a major CC company. Still get the icks thinking about it, and I didn't continue beyond the 6mo contract.

I played the NewEgg shuffle game for months to get the couple GPUs I needed during that time... not fun at all. I had to limit myself to bundles where the other component wasn't complete garbage. I still have a 600W EVGA PSU from one of the bundles (RTX-3080) that I've only used once to test if my issue was the PSU, MB or something else... turned out to be the RAM.

Redis can also cache sets with correlated sub-data as part of the model/eviction pattern.. this can give you trends beyond simple k/v

I tend to write an abstraction interface, if there isn't already one, where you request a key and pass an async function/lambda that will return the value from source in case of a cache miss.

    var value = cache.lookup<T>(
      keyname, 
      () => db.query<T>(...), 
      TimeSpan.FromMinutes(5) // or CacheOptions
    );

This way it can fallback/insert on a cache miss directly...

I remember one "fun" feature in Memcached, is that each client did it's own hashing/sharding system... and when trying to share cached values across platforms/languages in order to further reduce resources, that was fun... writing a custom .Net/C# client to match the Java implementation. This was in the .Net 1/2 timeframe around 2002-2003 before NuGet.

That said, it's interesting when you learn in practice that sometimes an N+1 problem is actually faster as N+1 than trying to query across separate DBMS systems.

I'm not disagreeing with the search aspect.. I will say that GSuite still doesn't do as well for calendar/scheduling integrations, or messaging beyond email for that matter... it used to, IMO, be as good for interactive messages before they nuked Hangouts in favor of whatever of the half dozen incompatible corp/public chat apps they've had along the way.

When Hangouts had integrated Google Voice and SMS in the app, imo, that was peak poweruser useful.

I don't know about that... unless a good open-source option comes out for corporate email that matches what Outlook/Exchange/M365 offers for calendars and scheduling.

That last part is the real point of integration... then real time chat and messaging status baked in... it's hard to beat. You have services and applications that offer pieces, but none integrate as well.

In the early 2010's I think that both Blackberry and Mozilla had an opportunity to create their own competition in the space and neither did. Google is pretty close, but IMO still a much lesser experience, reinventing a new chat app every other year didn't help their cause at all.

Beyond just email, the group scheduling and calendar experience is pretty much the best you're going to find. Google does pretty good, but it's still not nearly as good as the integrated corp experience with Outlook for scheduling... that said, I hate that I now get teams messages for meetings more than a business day in the future... I have outlook for that, I don't need it in teams... having a calendar and notifications in teams is fine, but limit notifications to things in the near future.

Hell, VS Code + Remote SSH is pretty freaking awesome.. edit locally run remote. The integrated terminal pretty much makes this as smooth an experience as working locally.

I'm not really using anything too exotic... my hardware all works, and my printer has generally been without issue (HP Color Laser on ethernet) regardless of what I use to print from.

For me, I switched when the start menu started showing internet ads as part of the results... I ran insiders for years, often joking that WSL was my favorite Linux distro... I love the new MS Terminal, and pretty happy with a lot of things. That said, there's far more that annoys me... it's too in your face trying to sell you additional software/services/features that frankly I find offensive from an OS. It's like built in malware ads. They might as well try to sell me an X10 camera in those popups, I'd feel just as irritated about it.

I went from dual booting, to just Linux for my personal use a few years ago and been pretty happy. I'm not a gamer, and was already using Linux as my dev target for server software. It wasn't a big deal for me. Even the growing pains for Cosmic have been less annoying than some of the "features" of Windows.

While I don't like the new Outlook much, half the time I use it is through a browser on my Linux box anyway, when I check work email from my own hardware...

I'm also don't agree with the assertions that you cannot address performance issues in a web based application. The actual email rendering in Outlook classic is still an embedded browser engine. Now it's just doing more of the application. If anything VS Code and the underlying editor system should show that you really can create pretty responsive applications on a browser surface... no, it's not the fastest, but if you're comparing to a lot of "full" IDE applications, it's a massive improvement... Visual Studio around 2010 was absolutely horrible for building web based applicatons, with common freezes and input lags.

There's plenty of room for improvement in these applications... I think the web shift is more to support cross platform better than it is to avoid optimization. At this point, they really want to be able to support Android, iOS, Windows, Mac and maybe unofficially Linux. The browser is the best bet to make that happen. I think that wasm can bridge a lot of the performance issues where service interactions go beyond the immediate state. With the rust ecosystem as good as it is for wasm target usage, I'm frankly surprised more of the logic isn't already there instead of JS. That said, I don't know how much is effectively asm.js or electronic translations to JS, or relying on server functionality. I haven't dug that deep.

That said, there's plenty of room to optimize web based applications. Even if it comes down to single-channel RDP application shells to a server-running application remotely. I think the point is to share as much as possible and support as broad an audience as they can. I think this is still happening in a context where three are still those that are trying to keep Windows on top and ignore Linux, while others in the org want to fully embrace it.

see: aud/target

Exactly... especially if the expiration is a tolerance window you can handle without revocation at all. I'm a pretty big fan for using it inter-service, APIs and SPA systems.

I disagree with you and the article on this... I thought that was pretty clear.

You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let alone every 1s or every request... you're effectively then inflating every single API request into 2 requests... one for a new token, then another to the API being called. This is irresponsible for not much gain in a user-facing context.

If you work at a company with well over a hundred employees, you're likely to see at least half of them on windows and devs may get an option of Windows or Mac... and IMO, Windows + WSL + Docker is actually slightly better than the Docker experience on Mac. There's plenty that I really do hate with Windows though. I'd rather run Linux but most corp environments just don't have the tooling for it.

Security vulnerability guardrails are kind of stupid to begin with... I would want the AI agent to be able to fix my security issues... having it obscured is just begging for more unsafe code in the world.

Oh, I'll just leave this SQL injection path in place.... etc.

Yeah... some early implementations just allowed for any authority to be set in the header and trusted it... that's of course wrong from the start... if you only allow for trusted or "known" authorities a lot of the contextual concerns become non-concerns.

Beyond this, you can make shorter lived JWTs just fine in the browser and have the agents self-update. If you use Azure Entra or a number of other providers it works this way in practice... you keep your JWTs relatively short lived (5-15m) and can even check for jti revokation.

JWTs are incredibly useful for separating/reusing an access authority from your applications/api systems. You shift the attack surface and do it in a way that can be trusted. We use PPK for lots of things, including SSH all over the world. No, I wouldn't use shared secrets and I wouldn't use long lived tokens... but short lived, ppk signed tokens from verified/known sources are generally fine.

For that matter, it's often API keys that are really problematic. Just had to implement them... for me, the API key presents as a Bearer token as well, but there's a short "sak." prefix then an identity part (base64url uuid bytes) followed by a secret as base64url bytes... in the database is the uuid and a passphrase level salt+hash from the secret.. so the api key generated should be treated as a secret and is one-way to the database, so a db breach doesn't breach auth.

Even then, an API key leak is far mroe likely than a problem with a well implemented JWT solution.

JWTs are insecure... even when using trusted, rsa/ppk based signing methods? not shared secrets.

JWTs are too long lived... Nothing is stopping you from limiting the JWT lifetime and having a refresh model against an authentication authority... I mean, even if you use cookie based sessions, you're storing somewhere... you can have a jwt valid for 5-15min. 15minutes is roughly the cache timing for many authorization systems including Entra... and even a 5min token with a refresh system can be used fine from a browser.

Lastly, I prefer to have identity/auth separated from the application/api services... it externalizes context and JWT per request is easier to deal with than some shared cache/state system that may intermittently fail as opposed to a signed token that you can verify the signature against known authorities.