StillBored

I get not a lot of people here have been growing their own peppers. I say that because if one goes to their local garden center right now and buys a jalapeño seedling, puts it in a fairly large pot and gives it a regular dose of N and a daily dose of water and puts outside in the 65-80F weather for the next few months it will produce peppers that are very large and taste pretty similar to the ones in the grocery store. Pick, them just as they reach an couple inches in length before they start to ripen and taste them.

Then if one lives in the south, brings it inside next year over the winter, and stop fertilizing it, and reduces watering it to once a week or so, it will again produce peppers next year that will be a lot hotter, but during the summer if you live in somewhere its getting over 100F daily, stop watering it until it starts to drop its leaves and pull it back from the brink of death ever couple weeks over the summer. The last peppers to set in the late spring early summer will only grow to be an inch or so long and the plant will stubbornly refuse to drop them even when they start to shrivel a bit and its lost most of its full size leaves only sprouting 1/4" long leaves during the short periods of recovery when the soil isn't bone dry. Then after a couple months when those peppers get really dark before they start to turn red, pick one and taste it.

The second year that plan will produce peppers hotter than probably anything most people have ever tasted. But, the plant will get strong and gnarly, continue to mistreat it for another year or two and what you will have is a pepper that no one can actually eat.

In my 20's I found pleasure in sampling top ten lists of hottest hot sauces and peppers, but nothing prepared me for the pepper I pulled off a ~5 year old jalapeño plant I had largely been ignoring all summer long and hadn't been fertilized since it was a seedling. A single bite, and about two chews, and I went into an upper body "hickup" that might be better described as a repeating upper body spasm, and a mouth burn unlike anything I've ever experience before or since. Those are peppers one should pick with gloves.

Pepper genetics or even variety aren't the largest dictator of how hot a pepper is. A bigger factor is how they are grown. Give a young plant a 70-80F pleasant environment, plenty of water and nutrient rich soil and they produce lots and lots of peppers that vary only slightly in heat based on their variety. Exactly what a commercial grower will do to maximize yield. Keep a plant on life support for multiple years and it will be an ugly thing, producing only a few peppers that grow slowly and ripen slowly over months, stress it to the point where its largely dropped all its leaves and only has a few small leaves baked daily in full 100F+ sun and it will produce peppers that are by themselves in-edible.

I had a 20 year old APC start misbehaving on me a few months back, and new batteries didn't fix it. After messing up the repair on the first one, a second one started doing the exact same thing, and I immediately took it apart and, now an expert on how not to fix them and what the root cause was, I swapped every cap on the board that my ESR meter claimed was bad. It's now back in operation, and while I was testing it, I realized it's so inefficient that about 10% of its max rating is just going up in heat. The replacement for the first one, I assumed, would be much more efficient, and it is, but it's still dumping about 7% of its energy into heating the transformer.

OTOH, the older UPS behaves much better with apcupsd, going so far as giving me the firmware versions, battery replacement times, better power monitoring/etc. While the new one works its missing most of what the older UPS could do (although its not a APC).

So, i'm sorta on the fence about just using "backup generators" from Amazon/etc because one of the ones I have has about 5x the capacity of the new UPS and seems to be able to switch without the computer plugging into it having an issue. Plus, its power waste is less than 1%.

Its worse than the article mentions. Because bandwidth isn't the problem its IOPS that are the problem.

Last time (about a year ago) I ran a couple random IO benchmarks against a storage optimized instances and the random IOPs behavior is closer to a large spinning RAID array than SSDs if the disk size is over some threshold.

IIRC, What it looks like is that there is a fast local SSD cache with a couple hundred GB of storage and then the rest is backed by remote spinning media.

Its one of the many reasons I have a hard time taking cloud optimization seriously, the lack of direct tiering controls means that database/etc style workloads are not going to optimize well and that will end up costing a lot of $$$$$.

So, maybe it was the instance types/configuration I was using, but <shrug> it was just something I was testing in passing.

Well, in the USA, for the past at least 50 years, "family values" means "fundamentalist Christian" rather than supporting families/childrearing/parenting/etc. This is why "family values" politicians are usually against family leave, prenatal programs, early childhood programs, or well any social programs designed to support poor families

Depends on your market. If you want a high end server/workstation class processor then openPOWER absolutely has an advantage because they have a shipping product that is (somewhat) competitive in that arena and despite the risc-v promises the products look like early 2010 era arm server machines. OpenPOWER have 30+ years of instruction set and architectural tuning to fall back on, and that is nothing to sneeze at if you actually want good vector perf, a stable toolchain, or a roadmap that doesn't depend on VC's staying in the game.

On the other hand if you looking for a small embedded one off solution then sure, risc-v. But unless your already sold on risc-v, there are a lot of other competitors in that space which have such a huge breadth of product offerings that it might be hard to justify a risc-v solution solely based on the processor architecture.

The Russians apparently have 600 tanks queued up right now for an advance. And while apparently they don't use the tanks as mobile guns for their infantry there is probably a good number in support of those tanks, and it seems unlikely one would fire missiles at infantry. Which is why we were dumping 50 year old stockpiles of dumb bombs in Afganistan. Which leads to the question of how one maintains air superiority for flying bombers in the face of more advanced MANPADS...

Right the arm stuff is probably in the "it runs" camp. Largely because its SVE, which is barely available, and the code written to utilize it has largely probably been tuned for the a64fx, or maybe the gravaton v1's.

Both of which have considerably different memory and vector size/issue characteristics. So three different SVE variations now, and the previous two show significant uplift when given custom tuning (ex: see gcc -mtune=neoverse-512tvb, vs the custom a64fx compiler benchmarks). Arm put a bunch of effort into creating an instruction set that is microarch agnostic, but then its not exactly worked the first couple tries. Maybe that will be fixed with V2 and all SVE cores going forward.

Oh, right lets replace cheap simple and dumb artillery we can't produce with super complex guided missiles with 1/10000th the production capability.

They never actually diagnosed it, I did. They just kept replacing things until they decided they couldn't actually fix it and sent a check. At no point did LG or the authorized center actually find a leak, or suggest that it might be leaking from the yoder loop. They would come out with their leak detection equipment (both sniffers and after the dryer replacement, a UV light to detect the dye) fail to find a leak, and just replace the next thing on the list. Which usually was a three trip process for each item they replaced with a few days/week or so while they ordered the part, and queued the work detail.

I had the yoder loop conversation with the tech on the last call when they came out to verify it was still broken/unfixable, and he basically said bypassing it wasn't possible, which is odd since other companies can.

My experience went on for ~6 months of soap opera, similar to what you're describing, where an authorized service provider would "fix" it, and then it would stop cooling within a week or two. Then LG, or the authorized center, would diagnose some other thing that hadn't been replaced. No actual leaks were ever found, which was the problem after they replaced the compressor (the first thing they replaced, but it was on the 2nd trip), and now they had access points to check the pressure.

With the bonus that in our particular case, we were paying for the "labor" and getting the parts under warranty, which means that in the end I paid ~$1000 for repairs and LG claimed to have provided ~$1200 worth of parts (which is bullshit because an aluminum evaporator coil doesn't cost $400 unless it has a 20x retail markup). So, when they sent a check, it covered our sunk costs. But I had a fridge with a brand new compressor, evaporator, and condenser, as well as an upgraded control board/etc. This is part of the reason I took a crack and just ran it without the Yoder loop.

So, a couple of points: some other companies fix yoder loop leaks by bypassing them and feeding factory-provided heating coils through the now vacant line.

Also, the LG parts all had copper brazing points, so the tech never had to work with aluminum/steel directly.

Finally, I wonder, after your initial comment, if there was just a problem with the refrigerant charge, which was causing your fan to ice over as a byproduct because it was slightly under/overcharged from the factory.

Its not just their linear compressors, its the fact that they use very thin aluminum tubing on the high side, and apparently have had assembly issues where weld material has splattered on the tubes, which after a bit of thermal cycling (or maybe its just galvanic corrosion) they start leaking.

I to had a LG refrigerator declared "unfixable" and bought back by LG, but I actually decided they were idiots and fixed it myself after having not only their local repair people fail to fix it, but the "expert" from LG's regional center come out and diagnose it. (It should be noted that he diagnosed the condenser, the only part not already replaced at that point, and that failed to fix it so, they declared it unfixable).

Turns out in my case, the leak was in the yoder loop, a modern trick for increasing the efficiency of a refrigerator by running a high pressure refrigerant line around the doors to avoid needing electric defrost loops (what pretty much every fridge made pre ~2005 or so has).

And since the yoder loop is embedded in the spray foam insulation between the exterior and interior of the fridge is is largely unrepairable because the insulation would have to be destroyed and somehow partially refilled, which wouldn't be possible without adding a bunch of access holes/etc to the exterior.

So, I bypassed it, as a "research project" before buying another fridge, something the LG folks told me wouldn't work, and the tech refused to do. Which funny enough i'm an EPA certified small appliance repair tech (don't ask! lol) so, it apparently is just up my alley. And guess what 5 years later is still going. I've had to manually defrost the ice maker fan once in that timeframe and it does tend to get some condensation build up on the bottom of the french doors, but nothing that wipeing it away every few days doens't solve.

As an additional bit of fun, this refrigerator has a steel condenser and both aluminum as well as copper tubing/fittings.

There isn't anything that fundamentally makes a top loader clean better than a front loader per se.

And while I don't doubt your SQ top loader with a full agitator does an absolutely fantastic job when compared to a modern front loader you have a big apples/oranges comparison problem.

And if you live in Austin, I would be willing to have a cloths cleaning video made against my 25 year old kenmore/frigidare front loader. :) And that is simply because (as of a couple years ago when I checked) my front loader uses closer to as much water as a modern top loader. It puts a good 6" of water in the tub and has a much smaller capacity that most of the modern front loaders because it has a very small opening and a fairly deep tub but is also narrower front to back. Given the agitators are about the same as the water depth, the cloths can be fully submerged/agitated out.

I to do a lot of outdoor work/repair (including that stupid washer's bearing), and things get dirty/greasy/etc and that washer has consistently amazed me just how good a job it does, and as a bonus when I got it I was also amazed at how much longer it seemed many of my cloths were lasting. I have 25 year old shirts that still look fairly new. So IMHO that washer has been a bit of a miracle worker, which is why despite being used at much greater duty cycle than your average home washer for the past 15 years (think ~15-20 loads a week, don't ask), every time it starts to need another bearing set, I upset my wife by fixing it. The parts cost like $30, and now that I've done it a few times its a ~2 hour job. Although, last time I sorta re-engineered the bearing set after discovering some new bearing technology better suited to being in a wet/soapy environment like a washer, so its possible I may have significantly extended how long it goes between bearing replacements (aka hopefully I never have to do it again). It also seems to spin significantly faster than many of the modern front loaders, which is seemingly at least part of the problem with the bearing loads.

Yes, but ATT advertises 1G fiber connections, and it's only available at a small fraction of their service addresses. Or for that matter spectrum with Internet Gig (or whatever they call the 850/30 Mbit service).

I would be in favor of a bit more truth in advertising such that they have to provide a service (not "up to") at, say, 80%+ of their service addresses before being allowed to advertise it. Or, for that matter, they can only advertise the slower of up/down or maybe the average of both if they wish to site a single number rather than both up/down.

I take that to mean you haven't tried any recent (zen3/4 U series) AMD laptops then, or for that matter the M1/2/3's. I've heard this from a number of people who are comparing the x13s or new mac's with their 14nm intel that has a discrete nvidia gpu (which is eating another 10W+) from 2017/8 or so.

I have a pile of laptops including the x13s, and that part burns a good ~30W for a couple minutes, while running ~30% (or worse) slower, then thermally throttles and drops another ~30% in performance.

For light browsing it manages to stay under 5W and gets 10h from its 50Wh battery. This is also doable on just about any AMD or Mac laptop. The AMD machine I'm typing this on tells me I have more than 12 hours remaining and i'm sitting at 81% battery (67Wh). And this machine is a good 3x faster compiling code, or running simple benchmarks like speedometer when its plugged in or allowed to burn 35W. Except it also has a fan that turns on when its under heavy load to keep it from thermally throttling.

Yes the x13s is cute, it is a thin/light laptop and is probably the first windows on arm machine that isn't completely unusable. But, its going to take another leap or two to catch-up with current top of the line machines.

Everyone loves geekbench so, here is an obviously unthrottled x13s vs a similarly rated 28W AMD 7840U.

https://browser.geekbench.com/v5/cpu/21596449 https://browser.geekbench.com/processors/amd-ryzen-7-7840u

That Amd is 2x the single threaded perf, and 50% faster multithreaded, and anything graphics related is going to look even worse.

Linux is a nightmare in the embedded/appliance space because one ends up just having platform engineers who spend their day fixing problems with the latest kernels, drivers, core libraries, etc, that the actual application depends on.

Or one goes the route of 99% of the IoT/etc vendors, and never update the base OS and pray that there aren't any active exploits targeting it.

This is why a lot of medium-sized companies cried about Centos, which allowed them to largely stick to a fairly stable platform that was getting security updates without having to actually pay/run a full blown RHEL/etc install. Every ten years or so they had to revisit all the dependencies, but that is a far easier problem than dealing with a year or two update cycle, which is too short when the qualification timeframe for some of these systems is 6+ months long.

So, this is almost exclusively a Linux problem; any of the *BSD/etc. alternatives give you almost all of what Linux provides without this constant breakage.

The box fan's CFM is probably a good order of magnitude higher than most commercial purifiers, meaning in theory it should move more air through the filter, thereby cleaning the room faster.

That said, it probably doesn't provide much vacuum/head, so the air that gets drawn through it probably doesn't change much with tape, although I'm guessing the energy draw goes down...

So two comments for DIY air filters, put fiberglass or similar prefilter over the hepa filters, and/or add more filters instead of tape around the fan. Even if they aren't hepa they will catch stuff.

Did I read the same article as everyone else here talking about price controls?

Cause that isn't what I got from it; term negotiated and contracted prices aren't "price controls." The suggested fix here is industry standard practice in many other business-to-business markets where the buyer selects a seller based on not just on how much they are selling it for today, but how long or for how many units they will guarantee the price for. Which is what is being talked about. AKA food supplier negotiates a price and guarantees it for a year.

So, its not a bad plan. Forcing the supplier to manage their costs vs. just passing them on at will gives the supplier an economic interest in suppressing their own suppliers and increasing their delivery efficiency. It pushes some of the price risks away from the individual consumers, who don't have much individual purchasing power.

Notably missing in the article was the mention of the floppy/IDE interface QIC tape drives, which were usually somewhere between $100-200 for the drive, with tapes usually just a few dollars each. By '97, I think I had been using a QIC 3080 drive for a couple of years, which was 1.6GB. This was a natural progression from the QIC-80s I had been using in ~1991 to swap warez because it was a lot easier to give people a tape than the dozen+ floppy most applications were being distributed on at that time.

So, I do vaguely remember seeing VHS-based backup systems, but the price/capacity wasn't something that, at least in the US, was competitive against existing consumer tape systems. I do remember though having a couple big DAT drives at work, which were the data grade versions of VHS, but the drives were a lot more expensive.

I put an antenna in my attic a couple of years back to get local ATSC broadcasts because it's a good source for PBS and local news/etc. It works marginally better than the built-in one and just as good as the monstrosity the neighbor has way up a pole.

So, is this just a case of digital TV killing the marginal signal stations that were available 30+ years ago if one didn't mind watching 50% static/snow? These days its an all-or-nothing proposition, one either gets crystal clear picture, or its unwatchable. And it turns out that massive complicated antenna configurations don't do much for bringing in otherwise unavailable stations.

This isn't really an "operating system" problem. Particularly in the open-source world, there are a number of fairly core libraries that refuse to provide any kind of API compatibility.

Then, when there are a couple dozen applications/etc that depend on that library, it's almost an impossible problem because each of those applications then needs to be updated in lockstep with the library version. There is nothing "clean" about how to handle this situation short of having loads of distro maintainers showing up in the upstream packages to fix them to support newer versions of the library. Of course, then all the distro's need to agree on what those versions are going to be...

Hence containers, which don't fix the problem at all. Instead they just move the responsibility away from the distro, which should never really have been packaging applications to begin with.

  understanding that they are different tools for different jobs

Right, but this goes against the dogma on both sides and the fact that much of Linux userspace is the wild west. Ideally, there should be a set of core system libraries (ex glibc, openssl, xlib, etc) that have extremely stable API/ABI somatics and are rarely updated.

Then one dynamically links the core libraries and statically links everything else. This solves the problem that a bug/exploit found in something like OpenSSL doesn't require the entire system to be recompiled and updated while allowing libraries that are not stable, used by few packages, etc, to be statically linked to their users. Then, when lib_coolnew_pos has a bug, it only requires rebuilding the two apps linked to it, and not necessarily even then if those applications don't expose the bug.

Uh, truncation is a huge no-no for security. But, that isn't what I was talking about. For deduplication/hash key/etc kinds of functions where a checksum works (or some other algorithm with a high chance of collisions is implemented for unit testing to assure collision paths are handled correctly).

This is part of the entire discussion, it's possible to use algorithms originally intended for cryptographically secure purposes in places where the reversibility/collision properties aren't considered problems. And likely this will only happen more frequently as algorithms are picked because they have hardware acceleration and are fast rather for the underlying security properties.

BTW: There is a fun game that I've played; see how much you can truncate a modern cryptographic hash before it becomes trivial to find collisions.

The theming/window manager/basic UI groups at MS seem like they are either incompetent or just Aholes. Largely because they seem to remove features during rewrites and then discover they need them back, a few years later. Ex: windows 3.x could do "dark mode", as well as any number of other things that got ripped out. Yes, having a theming manager as complete as the one in say KDE that can create themes to match most current and historic OSs is "hard" but looking at the code doesn't seem like something professionals paid to maintain the largest desktop OS by market share should be incapable of it.

So, it seems to me that no one should have been allowed to ship a windows theme/WM that couldn't at least support a win95 style theme. AKA you don't get to merge it until it can do these half dozen simple things. Similarly the task bar, ok nice you created a new one, but can it be positioned on the left side of the screen, or have the start menu moved? Then no, it doesn't get merged.

Often, its less about picking it for a new project vs having the discussion about how to update an existing one, often with data at rest that needs converting. In the latter case often the hash needs to fit into the existing 128b field size, so one is throwing a good number of the SHA bits away anyway.

RIP, and thanks for helping indirectly to put me on my career path.

I learned pascal fairly late in the grand scheme of things (basic->6502 assembly->C and then eventually pascal) but it was used for the vast majority of my formal CS education first by instruction, then by choice, and eventually in my first real programming job. The later pascal dialects remain IMHO far better than any other languages I write/maintain/guide others in using. Like many others of his stature it was just one of his many hits. Niklaus Wirth is one of the giants I feel the industry stands on, and I thank him for that.

"All those moments will be lost in time, like tears in rain..."

Sigh, been having this conversation in a related codebase. Md5 is just as fine as any other generic hash function if its being used as a non-unique key, which for many cases replacing it with one of the more "secure" alternatives does nothing except for the fact that the resulting hashes are frequently longer, thereby further reducing the statistical chance of an accidental collision. For something like a document store, duplication system, etc, simply taking the extra step of doing a binary comparison against the text associated with the hash assures that accidental (or intentional) collisions are handled. With the bonus that you probably get to either publish a paper or detect someone trying to attack the system should the text comparison fail.

And given the history of cryptographic hashes, i'm even more convinced that anyone depending on sha3/whatever being better than md5/etc over the next 10-20 years is fooling themselves.

Now would I use it in a secure boot chain/etc as a stamp of uniqueness? Probably not.

   Govenments need to start subsidizing charging stations just like they subsidized filling stations along interstates and turnpikes.

100% no, this is one of the problems I have with the recent climate legislation in the USA. This is the equivalent of taking more money out of the pockets of the middle class and giving it to the top 10%, same as the subsidies on electric vehicles which cost > $75K. It does close to nothing to actually encourage people to buy electric vehicles. The charger situation will solve itself once enough people have electric cars, because there will be demand for the service. Right now at least in the US, the model is just throwing money at gas stations and other commercial interests to go against their economic interests. Either the chargers have sufficient demand or it is a giant waste of money.

So, if you want to encourage people to actually buy electric vehicles a better plan is to make it so inexpensive to charge them with actual carbon free energy that they cost less to own and operate.

AKA spend the money on making the power grid provide cheaper power, and the charger problem will solve itself as people compare the price of a new electric vehicle vs a gas one.

I still believe in the dream from the 1960's that started with the catch phrase "electric too cheap to meter". And given the state of the US economy (and may other energy driven markets) it would actually have even farther reaching positive economic impacts beyond convincing people to buy electric cars. Ex: many fundamental industries run away from expensive energy. Its also why the global economy tanks when oil prices spike, or countries go into recession when their energy rates go above their neighbors.

That is still basically the process. You need to ensure that the arch options are being selected properly in your dhcp file, ex:

if option arch = 00:07 { filename "uefi/shimx64.efi"; next-server X.X.X.X; } else ...

Otherwise, your going to get the wrong arch/filename.

It is similar to HTTPS, but the arch = 00:10 for x64 and it needs:

option vendor-class-identifier "HTTPClient";

Then put the URL in the filename field.

Finally just put the usual bios/pxe stub in the last "else"

Of course, your distro should provide a PXE capable grub/kernel/initrd, which you then toss on the TFTP/HTTPS (or HTTP then you don't have to deal with certs) server in the path provided.

DTs are part of the problem.

It is one of those "devil in the details" kinds. In theory, DT would be okay, but it's not. The issue starts with HW vendors failing to create 100% (backwards) compatible hardware. For example, if they need a uart, they fail to hook up the standard baud rate divisor and instead use a clock controller somewhere else in the machine because its already there. So now DT describes this relationship, and someone needs to go hack up the uart driver to understand it needs to twiddle a clock controller rather than use the standard registers. Then, of course, it needs to be powered up/down, but DT doesn't have a standard way to provide an ACPI-like method for that functionality. So now it either ends up describing part of the voltage regulation/distribution network, or it needs a custom mailbox driver to talk to the firmware to power the device on/off. Again, this requires kernel changes. And that is just an example of a uart, it gets worse the more complex the device is.

On x86, step one is hardware compatibility, so nothing usually needs to be changed in the kernel for the machine to understand how to setup an interrupt controller/uart/whatever. The PC also went through the plug and play (PnP) revolution in the 1990's and generally continues to utilize self-describing busses (pci, usb) or at least make things that aren't inherently self-describing look that way. Ex: intel making the memory controller look like a pci root complex integrated endpoint, which is crazy but solves many software detection/configuration issues.

Second, the UEFI specification effectively mandates that all the hardware is released to the OS in a configured/working manner. This avoids problems where Linux needs to install device-specific firmware for things like USB controllers/whatever because there is already working firmware, and unless Linux wants to replace it, all the HW will generally work as is. Arm UEFIs frequently fail at this, particularly uboot ones, which only configure enough hardware to load grub/etc, then the kernel shows up and has to reset/load firmware/etc as though the device were just cold powered on.

Thirdly, ACPI provides a standard power management abstraction that scales from old pentium from the 1990s where it is just traping to SMM, to the latest servers and laptops with dedicated power management microcontrollers, removing all the clock/regulator/phy/GPIO/I2C/SPI/etc logic from the kernel, which are the kinds of things that change not only from SoC to Soc but board to board or board revision to board revision. So, it cuts out loads and loads of cruft that need kernel drivers just to boot. Nothing stops amd/intel from adding drivers for this stuff, but it is simply unnecessary to boot and utilize the platform. While on arm, its pretty much mandated with DT because the firmware->OS layers are all over the place and are different with every single arm machine that isn't a server.

So, the fact that someone can hack a DT and some drivers allows the hardware vendors to shrug and continue as usual. If they were told, "Sorry, your HW isn't Linux compatible," they would quickly clean up their act. And why put in any effort, random people will fund ashai like efforts to reverse engineer it and make it work. Zero effort on apples part, and they get Linux support.

Are you an EE with a specialty in power electronics? Cause that seems insane to me, inductive loads will cause a voltage spike (flyback) when disconnected, which will exceed that easily. That is why there is generally a reverse diode across the contacts, which I didn't see in the diagram.

Granted the article notes it appears to be largely a resistive load, but I would want data sheets on the car/charging requirements, not measurements, to ensure this is true 100% of the time. Maybe the car has an AC compressor or a pump to cool the battery during charging, which draws directly from the charger when plugged in. You might not see that doing a few random measurements because it turns on only after some time or if someone is sitting in the car.