altrus

Slackware was my first linux distribution, and one that I used continuously before moving to Arch.

As it happens, I think Arch embodies many of the original Slackware principles, but its focus on more modern hardware led to it growing a larger community - one that includes great documentation.

TLDR; If you're looking to reduce the risk of contamination, consider purchasing whole chickens or, at least, skin-on, bone-in, cuts.

This is because the risk is substantially higher if you purchase skinless or deboned chicken - most contamination is on the surface of the chicken, and is easily killed during cooking.

However, during processing, the tooling used to debone or deskin the chicken may get contaminated, and necessarily pierces the flesh of the meat. This tooling isn't usually disinfected between chickens (cost prohibitive). As a result, if one of the birds has surface contamination, this contamination will remain on the outside of the instrument, grow, and subsequently infect the inside of all the other birds.

This is important, because direct heat is actually pretty good at killing bacteria. However, if the bacteria are able to penetrate to the inside of the chicken, there's a substantially greater likelihood that the temperature (and duration) on the inside of the chicken are insufficient to kill disease causing bacteria.

Note: The overall idea is to recognize that surface bacterial contamination can be killed with sufficient temperature over a sufficient duration of time, recognizing that the lowest overall temperature will be in the thickest part of the meat, and ensuring that there isn't a mechanical mechanism that will introduce contamination in that area.

That is stack up dependant - we work the board house on that, depending on geometery and material. Once they give us a ballpark, we will adjust our widths and clearances to something reasonable, recognizing that fab will adjust the traces and arcs to whatever spec we subsequently need.

We use kicad for the design of a 28 layer PCB that includes a number of high speed (>10Gbps) impedance controlled lanes, including 25Gbps signal lines, and implementing three DDR4 banks, with a varying number of discrete chips, and breaking out from a large pin BGA, using a number of HDI features (blind/buried vias, etc).

We've been closely tracking the releases, and, at this point, our layout tech prefers using Kicad over another (proprietary) tool for the majority of layouts - so much so that's she's pushing for us to port all our designs to it.

I don't entirely understand this; could you provide a concrete example, or actual trades, that could be involved in such a position? (I'm just curious how it would actually look like in practice.)

I completely agree - the IKEA dill mustard is quite delicious: the flavour is remarkably well balanced, and the mustard itself is creamy but still has a bit of bite to it.

My overall favourite mustard is Löwensenf extra sharf (extra hot) mustard. It's the one in the red bottle, and it's a good hot mustard - I find it's really hard to get a good hot mustard in North America, so that's my go to.

Congratulations on the launch! It's a nice product, and seems to work (for me). What happens after the run of 250?

They aren't perfectly usable if they've been used. Semiconductors are kind of like toothpaste - if they've been used, you don't really want to buy them.

This is largely because the cost of any individual component is so much less than the cost of a finished assembly, or the cost of a defective assembly. Inserting used components into your manufacturing process (unless they're very high value or rare parts), is asking for trouble.

These components need to be stored properly to be effectively assembled, and you'd never be sure of why the used one were thrown out. Especially as many types of damage or degradation would either require very substantial and specific testing rigs, or else be challenging to identify in the first place.

Putting them inside a vehicle isn't a viable option from an safety or economic perspective.

From the Article:

What I actually learned is that if something is right, it’s right. Context makes a slight difference but fundamental principles hold true. There are laws of nature.

The article isn't suggesting militarizing start ups - it's providing some context on which elements of the military officer selection process are transferable to the start up co-founder selection process.

edit: clarity

> There are always going to be leaks.

As this seems to be something that's given quite a bit of thought, do you have an idea on what the maximum diameter hole through the fuselage to safely maintain sufficient cabin pressure during cruise flight at, say, PL390? More specifically, what's the maximum rate of pressurization that the cabin pressurization system is designed to support?

Additional commentary and background can be found in Science;

https://www.sciencemag.org/news/2020/10/could-certain-covid-...

The concerns raised in this article do not speak to the efficacy of candidate vaccines using Ad5 vectors. Rather, they discuss the potential impact Antibody-dependent enhancement might have on at risk groups, and, as a consequence, for the design of clinical trials using those vectors.

Writing robust cores is usually substantially harder than writing the equivalent software library. You usually have to design the logic to satisfy various different criteria (area, performance, or power), and, especially when implementing high speed design, take into account the targeted device.

Unfortunately, the number of people who are competent to design, test, and implement these cores is fairly small, and usually well funded. Oftentimes, these cores represent very non-trivial time savings, especially when it comes to characterizing performance and closing timing, so there is tremendous value in the marketing and selling of these cores.

On the other hand, sites like opencores are great for finding useful IP that people have contributed and may be adapted to your device.

FWIW: The latency gains that usually benefit HFT or algorithim design, aren't, for the most part, realized using off-the-shelf tool kits.

Unfortunately, the tooling and hardware isn't currently quite at the point where HLS languages, or openCL for that matter, have had substantial impact for real-world problems, especially if you're targeting a low tier FPGA. This is especially true when implementing interfaces to PHYs or other IP.

I think part of the problem is that successful HDL design requires a fundamentally different approach to program architecture - especially when it comes to closing timing - and there's a fairly steep learning curve to getting everything set up.

I appreciate the idea of skipping verilog or low level logic introductions, but it seems to me like that's asking for substantial problems later on when you actually want to do something practical.

Then again, I can't really think of any better (ie; easier) learning pathway than what you mentioned.