vvanders

> Some of these conversations, Ben, I just find them delightful. We have these five whale customers that we’ve talked about, these are active conversations. Active, daily things and in that, the teams are now saying, well, what about the ultra low voltage threshold for the thin pitch library that we’re going to use in this particular cell? “TSMC is giving us these characteristics, you don’t characterize that corner.” Okay, guess what? Go characterize the corner! “Your PDK isn’t as robust as the Samsung or TSMC PDK is to describe the process technology for my team to simulate.”

I get where he's going with this but if you're ever on the other side interacting with a vendor you should be very careful about what, if at all you disclose that their competitors are doing. Vendors notice what they learn from your teams and if they know it is leaky they will not disclose things that make the technical side easier.

At a past gig we used the be the central point of contact for our vendors because we kept a strict firewall on the technical side between different product lines and SoCs.

The first instinct of most engineers when you're trying to evaluate something or get the best performance is to say "X does Y, why don't you do Y" or "X does Y, how can we get similar results" and you've just disclosed something and that vendor will notice. On the flip side if you build up that trust and are known to not disclose you can be read in on things that normally wouldn't be shared. This can be incredibly valuable when you're trying to close on a key technical issue under schedule/time constraints.

Reading the article and I didn't see writing fast Rust programs as easier listed(only Go). The callout was for sharing data between threads which I think is an area where Rust has the edge over other languages.

I would argue the opposite, there's a really strong skill transfer between gamedev(esp on the engine side of things) <-> embedded development. Both deal with hard constraints(performance, memory, storage) and you use similar approaches to deal with them.

At a more high-level HMI/game design has a pretty large overlap. No one knows what "fun" or "easy to use" are, so the approaches to converge there are similar(rapid prototyping, etc).

That doesn't sound far off from a PTO generator, assuming you've got the right interconnects exposed seems reasonable. From my limited understanding most diesel electrics go Diesel -> AC -> DC -> AC -> Wheels. If your taking power from the first AC part the engine RPM determines frequency(as with a PTO generator). Most diesels used in these applications with similarly buffered powertrains(some tractors/heavy machinery with HSTs/etc) have good governors to keep the engine from running away.

From the article it sounded like it wasn't ideal(there was damage to the gearbox from driving the engines down the road).

(as an aside this is why I think a diesel-electric tractor or pure electric would be pretty nifty thing)

While you can't use the motors 1:1 from what I understand a lot of the development of VFD AC motors happened in the locomotive space[1].

The traction of a DC drive vs AC drive is significantly different(the below article cites at least 2x better for AC) in part due to the fact that a DC motor will "run away" once it breaks the static friction limit where a VFD(holding a fixed frequency) will self-correct as the wheel overspeeds and is slowed down by the other side of the magnetic field. Since most EVs use AC VFD a lot of that same development can be applied in traction applications.

[1] http://www.republiclocomotive.com/ac-traction-vs-dc-traction...

The upper bound is interesting but my limited intuition is it's a very upper bound. LTO/LTCG will drive that down a lot. Last time I was looking at Rust binary sizes things like building the stdlib with heavy LTO/opt size had some pretty big influences on final binary size.

> The current variants are weakened versions of the virus that they are essentially the vaccine.

If that were true we would not be seeing 2,500+ deaths/day in the US which was higher than the initial first wave(2.2k/day) and is approaching the previous peak(~3k/day).

That doesn't track with either the CDC data above, other studies[1] or what we know about other variants.

[1] https://mobile.twitter.com/EricTopol/status/1476212140956553...

Gonna need to cite some sources there.

The current recommendation is to get a booster because it both reduces the severity of the disease and the chance of either catching a breakthrough infection or another variant[1]/[2].

[1] https://www.cdc.gov/coronavirus/2019-ncov/vaccines/effective...

[2] https://covid.cdc.gov/covid-data-tracker/#rates-by-vaccine-s...

> Given my low risk from the actual virus ...

It's not about your risk, it's about transmission to other people that have a much higher risk profile.

[edit] Thanks for the downvotes, confirms that people care less about others than experiencing any inconvenience themselves.

Having owned both CUT without any emissions control(1981) and a Kubota w/ DPF, I'll take the DPF every day. It's quieter, cleaner and the emissions controls are even more straightforward than other modern diesels. If you have a full DPF, you just regen it for 10-15(usually while you're working) and you're good to go.

Same for SoCal, I have fuzzy memories of flipping through boxes of shareware 3.5"/5" floppies and all sorts of with various hardware pieces.

Depending on what you want to do you can get away with a RPi and RTL-SDR which are pretty widely available.

Most wireless weather stations use ISM bands, I used RTL_433[1] to pull the raw data and quite a few popular stations already have the format documented.

Combine with InfluxDB+Grafana+simple polling script/program and you can do a bunch of fun stuff with it. Have the whole thing wrapped with docker compose and just runs in the backgound.

[1] https://github.com/merbanan/rtl_433

These are all fantastic but Yooper Scooper is really inspired.

I would agree, if we're talking CUT/SCUT you're in the realm of something that is easily serviceable(and the market doesn't really do DRM/lock-out currently) however these are different scale machines that are much pricier(just a quick glance looks like higher end 8Rs can start at 600k).

While I get where you're going with this however if you use small binaries that are built for efficiency then your process start time isn't 100s of ms, it's a least an order of magnitude faster.

Using a single process also guarantees a higher degree of isolation and resistance to memory leaks which can be important on certain systems.

Only thing that comes to mind immediately is VLA/alloca but I'd have to check. Most of the gnarly pointer things are fair game and work just as well as their C counterparts.

West WA doesn't have the infrastructure to clear the roads(which makes sense given how infrequently it snows) combine that with some steep areas and it's fairly predictable what happens.

From my experience there's a bit more dynamics in there. In particular the publishing agreements(I've been privy to a few) are structured in ways that the developer takes a substantial amount of risk and very rarely gains the reward of a breakout hit. Things like the first royalty doesn't come in until all development + marketing costs(which can be as much as dev) are paid back. Caps on payouts for companies or individual employees, etc.

The structure is much closer to what you see in the recording industry contracts , there's even been cases in the past of publishers denying milestone payments during peak burn to put the company into bankruptcy to gain the IP + source and then re-hire the dev-team back at 70% salary. Combine that with an robust supply of fresh faces trying to "break-in" it's not really a surprise the industry is the way it is.

If you're on the dev side of the industry you've got quite a few options to exit, if you're in art there's less options since a lot of adjacent industries have similar conditions(I've heard from past co-workers that the animation industry is even more brutal).

It's really a shame since there's some really fun technical problems to be solved and a lot of creativity but that ultimately gets exploited into the state it is today. It could be a better industry but it isn't. For those that want to build games I usually recommend doing it as a side project, there's a high probability that you can work on a genre you like(I never did during my time in industry) and you aren't subject to the state of the industry.

One of the advantages of fixed hardware is you can tune for that hardware directly. We used to bake content and design code with specific cache line sizes in mind. If you know you have a fixed memory budget for graphics/sound/etc you can make specific tradeoffs on where you spend that budget. PCs until recently did not have UMA and so you were bound by bus speeds(although this applied to some consoles too but you could exploit it if you knew how, ex: stream audio data from graphics memory and long as you stayed under the total bus bandwidth you got extra memory for the system if you needed it).

They generally go pretty well, I have them setup to happen nightly. This one was already deployed on my network.

The part of 5G that gets thrown around a lot with high speed and capacity is mostly based on mmWave bands(think 10's of Ghz) which attenuate incredibly quick. Most of them are nearly direct line of sight. You already see some issue with 5Ghz wifi not going well through walls, there's a high chance you'd be falling back to one of the lower speed bands inside.

The other thing is there's a non-zero amount overlap in the way spectrum is used in wifi and 3/4/5G, MIMO, spread spectrum and other approaches are all trying to get as close to the theoretical limit of the channel bandwidth. When you start looking at large scale wifi deployments it starts getting split into cells of channels not to dissimilar to cellular deployments. There are some differences and certain bands benefit from discrete allocation/cell management but at the end of the day it's all radio waves over the air.

If you have problems with wifi resiliency I've got bad news for you about the wavelengths 5G uses.

Fair, but feels like that significantly reduces the utility of pinned types then if for certain values you lose the ability to mutate values when the compiler overwise knows that there is a single mutable reference.

I would largely agree, in the cases where I've needed something pinned I just drop to Box'ing to, keeping the box internal and managing the pinning directly. It's annoying because you lose some classes of things that you may want to pin(values on stack for short durations) but I found similar complexities in the API.

For instance if you take a pinned Arc(ex: Pin<Arc<T>>) there wasn't a way I could determine to get out the mutable interior pointer(ex: via Arc::get_mut) since those APIs require a specific signature and you would need to un-pin the value to make those calls despite them being by reference(safe from a pinning perspective).

Most of Rust is incredibly well designed but so it's pretty jarring that Pinning is so much harder to use. I've found work-arounds for the cases where I've needed either via boxing or dropping to unsafe but would have been nice if it had worked for my use cases.

VSCode is still pretty sparse on the debugging side of things. I've tried to chase down heap corruption with it and the lack of data views, complex watch/breakpoints really limit it in that scenario.

CLion is getting there, it's not quite as good yet but was still much better than VSCode.

This is pretty good overview. One fun tricks we would regularly do was move all the background audio off the disk and into GPU ram. We'd stream just enough that we wouldn't saturate the bus but could get back 20-30mb of system memory.

There was also that time we ran out of open file handles ahead of key demo at one of the tradeshows. I remember rewriting the whole audio streaming subsystem to piggyback on the seekfree texture loading system so that we could use the that single big file as a source for both streaming texture and audio data. Did that in 24 hours less than 2 days ahead of the show, fun times.

[Edit]

Another fun thing from that era was that almost no one other than the in-house Sony Studios used the SPUs well. X360 came out just ahead and had tooling that was miles ahead(PIX!) so everyone started from the X360. None of the workloads we're vectorized so it was absolutely brutal to get them to fit into the SPUs. For a long time a good chunk of that silicon was just idle. If you did start from the PS3 though because of the vectorized workloads you had insane cache coeheranch and usually ran better on the X360/PC as well.

"Most" ends up being surprising(ex: ARM has a fairly weak memory model). I've seen a lot of code with aligned access and extensive use of "volatile" in MSVC/x86 explode once it was ported to other architectures.

I have one and can confirm it has a great battery and is snappy. They're a little hard to find in certain configurations but for a "gaming" laptop it's a pretty decent daily driver.

Subspace was another impressive one from around that era. 50-100 concurrent players on 28.8/56k.

They used a totally different technique(dead reckoning + game design that was about prediction) but it was pretty smooth given what average pings where back then.