Same here, updated my framework laptop, rebooted to blinky screen, turned it off, did some research, loaded up a livecd to revert the kernel and then updated when 5.19.13 made it into arch. Thankfully just a pain in my butt not a dead lcd for me.
I had the same experience. Updated the computer, rebooted into the blinky screen. Powered off the machine & went to the BTRFS snapshot created immediately before my update. No damage to the screen that I'm aware of.
You have to load a livecd to use an older kernel? That is pretty sad. I keep as many kernels as I like. And I can easily run a command to purge all but the running and next kernels.
As another commenter mentioned, fancy pants filesystems that support snapshots simplify this situation.
well, It's my laptop and Iw as playing with endeavouros on it so it didn't have any fallback kernels. choosing grub options isn't really a brains operation for most of us, we stick with defaults.
> fancy pants filesystems that support snapshots simplify this situation.
This is what I used. zfsbootmenu is an EFI executable with support for doing zfs rollbacks (and any other arbitrary zfs command) so as long as my EFI partition is left untouched, I don't need a livecd or another partition or anything.
> After looking at some logs we do end up with potentially bogus
panel power sequencing delays, which may harm the LCD panel.
So sounds like it can cause some out of spec stuff at the analog level, which could plausibly result in damage, but also probably dependant on exactly what bogus values are sent in a particular case and how resilient a particular LCD is.
Well, I've got a Lenovo with an integrated Intel GPU and a discrete AMD one. I'm on 5.19.12 and I didn't notice anything, but still I can't conclude that maybe there isn't something wrong going on during boot that could cause damage. I'll look now for updates.
I booted both of my Framework laptops on 5.19.12 and it didn’t break anything. I could type my LUKS password and still get into gdm fine.
I still reverted back to 5.19.11 though.
That it can damage the display is currently a hypothetical scenario. I don't think anyone has reported a broken panel. One of the i915 devs on the stable mailing list said:
> After looking at some logs we do end up with potentially bogus
panel power sequencing delays, which may harm the LCD panel.
My framework laptop was affected by this. When I booted 5.19.12 my display was flickering like crazy. Rebooting with 5.19.11 corrected it. 6.0 is also fine.
No luck, I'm running 5.19.12, noticed flicker that looked like a bad LVDS cable. but it was wired because it happened while the laptop was not being moved. I would have not thought of a software issue as it was affecting the whole display. But most of the time the flicker would disappear, the display doesn't look to be damaged, as I ca use it normally when it's not flickering. Hopefully the revert will make the flicker disappear.
Ha, reminds me of a myth from 20+ years ago, that there was a virus that could damage your CRT display by requesting the monitor to refresh at 1000Hz or something stupid, which would damage at least some monitors without the proper safeguards. No idea if that was real though.
Chose one :) You can't state it was a myth and then later say you don't know!
I've heard the same thing about older CRT monitors and remember reading about people damaging their CRT monitors by careless programming in regards to refresh rates. But I haven't actually seen in real life, and I must have read about this in the early 90s or something like that I think, so long time ago.
I heard this in regarding to Linux and X, back in the 90ies. That scared me away from Linux for quite some time. I felt confident, that I could fix any "software damage" to the family PC running Windows, but I did not want to risk hardware damage.
Well I mean it was in the category of "you can catch mew in Pokemon Yellow if you get to the truck behind the ship"-myth. People have said it, I read about it online in the "early days" but I've never seen it happen to anyone.
Yes, "back in the day" you could only get it through official distribution, or hack it in with a gameshark code. There was a truck behind the SS Anne that you could get to(you had to get the HM move from the boss, then faint - that would put you in the nearest pokecentre, so you could continue until you found HM Swim, then you could go back to the ship since it never departed, and swim behind it - and yep, there was a truck) - but that truck did nothing, it was just set decoration.
The RNG method to encounter Mew in the wild was only discovered years and years later and most definitely wasn't known 20 years ago.
> You can't state it was a myth and then later say you don't know!
The word myth generally has two meanings. One is that it's a false belief. The other is that it's a legendary story of which the truth is not known. GP obviously intended the latter definition.
I recall, back in the day, we had video cards on the Amiga with a passthrough port.
The Amiga could output stock NTSC/Pal and some close variants, and many monitors existed which could handle that lower scan frequency (15khz), as well as higher res output with Picasso cards.
You could overdrive the CRT on the Commodore PET with a poke to a particular register.
On some models it would cause damage, on other models it would cause faster screen draws.
Those of us who've calculated our own modelines are familiar with that caution. It was part of the documentation of standard tools at the time, though I've never personally encountered a damaged display or knew of anyone else who had. Though one turns up in this thread: <https://news.ycombinator.com/item?id=33093385>
A typical modeline calculator warning:
It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk.
Before "multiscan"/"multisync" CRTs, there were fixed mode CRTs which would break in one way or the other if the incoming signal had the wrong timings.
> My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
One of my recent projects was to get my PC to output 480i signals to my recently acquired Trinitron TV for running modern and historical games on a CRT TV (I'd definitely be better served by a monitor, but I didn't have one and still don't :( ). I learned many interesting but otherwise-irrelevant bits of trivia from this experience:
- A modeline used to output 480i SDTV-compatible signals (525 scanlines) from a PC, differs from the same resolution's modeline under Coordinated Video Timings (arachnoid.com generates a 516-line modeline for 480i, and Linux's cvt tool doesn't document its interlacing flag because interlacing is not part of VGA or something).
- DVI and HDMI signals are effectively continuous signals with CRT-like timings, translated into digital signals (discrete-time at your GPU's configured dot clock, and quantized) and encoded using TMDS with special pixel values on the blue channel (outside of the 0-255 range) for hblank and vblank. Whereas DP signals are packetized in some manner I haven't researched.
- One common way to output 480i is through HDMI-to-component converters. But 480i has a too low pixel clock below the HDMI spec's minimum timing, and many GPUs cannot put out such a slow signal or converters cannot understand it. (I wonder how DP-to-component would fare, given it's packet-based and might not suffer from a minimum dot clock readable by the receiver chip.) A common workaround recommended by the developers "CRT Emudriver" (AMD GPU drivers modded by in-place binary patching) is to set a 2560x240p or 480i "super resolution", then configure emulators and games to output stretched signals. Unfortunately, neither non-RetroArch games nor Windows's CRT Emudriver cannot rescale their image to non-square pixels and their 1440x480 images were squashed to a 4:3 aspect ratio, so I had to switch to Linux and xrandr for square images.
- I had to pick 1440x480i because otherwise the vblank pulses generated by my AliExpress HDMI-to-component converter were insufficiently staggered between interlaced and non-interlaced scanlines. Since I don't have an oscilloscope, I diagnosed this by piping the sync-on-green composite signal into my motherboard's 192khz line-in capture, then recording in Audacity and comparing to correct NTSC timings (the vertical serrations should be evenly spaced and they weren't).
- The Linux amdgpu driver is well capable of outputting a 1440x240p resolution (there are many NTSC modelines, with varying undesirable horizontal offsets and stretching, and vertical offsets), and xrandr is an excellent way to scale a 1280x960 framebuffer to 1440x240 or such (which is scaled back to square aspect ratio on-screen). Unfortunately Linux amdgpu's dc driver for its display controller (compatible with atomic modesetting) has missing support for interlacing, the easiest workaround being to pass `amdgpu.dc=0` to the Linux kernel command line (this disables atomic modesetting, switches to the legacy display controller driver, breaks HDMI audio, and makes the mouse cursor unaffected by Redshift so Plasma's text cursor becomes practically invisible on white text fields).
- - I debugged this extensively at https://gitlab.freedesktop.org/drm/amd/-/issues/1636, but failed to solve the problem. If I hack the driver to force interlacing on (not realizing I needed interleaving as well), the resulting analog signal repeats the first scanline hundreds of times followed by a birth-defect serration pulse, which I would be unsurprised if it would physically destroy some CRTs. I recorded a video (epilepsy warning) at https://www.youtube.com/watch?v=GoQ9q1lwKHI.
- - Antonio Giner claims to have a fix for interlacing in amdgpu.dc=1 mode, for his Gr...
In a poorly constructed CRT you can definitely damage the drive circuits by an excessively high line rate. That's basically the reason why CRTs tend to include "out of range" warnings and shutdowns. You could, I think at least theoretically, also cause damage by incorrect blanking, because line rate + blanking determines the drive waveform for the LOPT.
I heard about a million times that, and that you could also destroy the hard drive by reading the first and last track many times in secession.
If at all truth, it was in very specific HW (I was in touch with really, really, really big amounts of people in the industry and HW, and have never first hand heard of that happening).
One I remember from way back was that the XT-era Hercules monochrome adapter allowed the refresh rate to be set to zero, causing the monitor to emit its magic smoke. I'm not sure it was weaponized, though.
I remember seeing somewhere that in the beginning of Linux on the Nintendo Switch that people destroyed their displays by raising the brightness bar too high.
How come these things are not secured against at the LCD controller side? Why would a general purpose controller be designed to accept e.g. too high voltage levels?
Well because like you said - it's a general purpose controller. Maybe it can drive any display accepting voltage input between 5 and 12V, which means that you can use it with a display that only supports 5-8V range - you just limit the range in software and make sure the user can't select anything about 8V. But if a device is hacked and the controller sent direct commands, then of course it could lead to issues.
LEDs are current driven, not voltage driven. It's still weird as most controllers have the current set via resistor (either the value of inline resistor used for current measurement, or separate one), why wouldn't you set that to the max one for the panel ?
because the whole industry [and by extension the whole world] is built on a throne of lies, shit, pain, and weapons-grade idiocy.
there's absolutely no safety mindset for anything behind the cover.
if it's industrial, just put a big sticker on it, write something about it in the mandatory occupational hazards training kit, maaaaaaaybe consider adding a fence, but it's fine anyway.
if it's consumer stuff? well, as long as kids won't choke on it, it's A-OK. especially if it comes to electronics. just write in the user's guide that always disconnect it from the mains when not in use, if used improperly that's on you, and don't ever think about opening it. that only for professionals who are trained in the dark arts of handling this exact piece of immanetized hell-forged eschaton housed in a convenient beige plastic.
adding a voltage limiter between the LCD panel and the input would cost money. designing it would cost money. adding an analog limiter on the regulator would cost money (plus setting it mechanically is very expensive compared to flashing on some firmware), compartmentalizing the software - by having a segment that's set at assembly that contains the physical properties of connected parts, which communicates the operational limits, and the other segment which can be set via software - would also cost a lot of money.
> there's absolutely no safety mindset for anything behind the cover.
As a counter-point: One persons "safety" is another persons "limitation". Sometimes it's good that things are generally protected but you can break through the protections somewhat.
I'm not advocating for filling out the whole insides with epoxy. (Quite the contrary, I think it'd be great to have better markings on components, and have data sheets - and schematics - for them readily available. I mean it's ridiculous that the whole IP protection legal machinery is justified in the name of incentivizing invention and new works, but in practice all we got is cheaper and cheaper copies/derivatives of the same noname things.)
Lots of real time, safety critical, and control systems rely on software and don't have mechanical or hard wired electronic interlocks or fallbacks. That doesn't make it worse than alternatives.
You could hack the firmware and make the device behave out of spec, but you could also hack the hardware. If you bypassed your voltage limiter on the board then you could blow it up too.
And there is the crucial difference: you would need to bypass the voltage limiter on purpose, your display wouldn't be ruined by mistake just by putting a slider to the maximum possible value.
It won't be ruined by mistake just by putting a slider to the maximum possible value unless you first bypass the firmware on purpose and install your own one that allows voltage limits to be disregarded.
I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar. But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug
For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
> I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar.
I meant hacking as-in messing around, poor choice of word.
> But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug
Hardware bugs can cause hardware damage.
> For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
They're just not. The ABS, stability, and collision avoidance systems in your car can't fail safe if the software fails because the software is required to control the dynamic situation. It can't just say stop everything. Same as control software in airliners. Or industrial control and monitoring systems (although they can have mechanical interlocks in more cases, not all).
And very little that can be _absolutely_ fail-safe, not even purely mechanical devices. How do you make a fail safe bridge?
That's true, although I think the original point was that if software can damage the hardware it's running on then that should be seen as a fault/bug, but with cost reduction/market pressures/etc. it is often ignored
And fail-safe doesn't necessarily mean everything turns off because that can be just as dangerous, I take it more as a systems mindset where thought, care and attention are paid to failure conditions and making sure those outcomes pose the least risk. Again something which can often be ignored for cost or expediency reasons
Perfection is probably an unattainable goal but I've been around software long enough that I wouldn't want someones safety to depend solely on one piece of software
This person speaks the truth, and one would be wise to internalize his perspective. I've seen this first hand, for decades. Lies, half truths, and blind belief someone else's job is looking out for others. Someday in the not so distant future, a large scale automation is going to kill thousands while destroying our entire civilization's belief "the technology people" know what they are doing.
Injecting mRNA into human cells is exactly the kind of brilliant hack you’d expect software engineers to come up with (and those same engineers would of course brush aside any concerns about unintended consequences in complex systems.)
I was hoping in a couple years there would be proper studies about those potential consequences but honestly I can't make myself trust they won't be suppressed at this point. So I can only hope there won't be any severe ones.
You do realize every single virus, many bacteria, and some other germs, are literally injecting molecular/genetic payloads into your body to hijack your body's protein machinery, and your immune system updates itself in response?
when the mrna platform is established, people that control the platform may inject payloads that provide them their desired consequences. this is not the same as 'blind' nature injecting things into you.
Oh yeah, I'd totally rather have blind, chaotic, messy nature inject me, vs a scientifically engineered and highly tested product with a scope even smaller than conventional vaccines.
Blind Mother Nature would never hurt me! (hides list of the most potently toxic compounds on the planet under a carpet... tetrodotoxin, botulinum, ricin...)
i was not advocating that nature is good, im just warning u about the for profit, just-in-time, hand-in-glove regulatory, first to market, fix bugs in future updates (aka boosters) software like cures for your biological problems.
The risk of my home catching on fire each year due to any electrical issue is 0.04%. The risk of me dying or being injured due to such an issue is 0.00004%. That includes not just home electronics but every possible wiring and electrical insanity.
For comparison, my risk of getting into a car accident is north of 1% and the risk of dying in a car accident is around 0.02%.
So in other words compared to all the other risks out there home electronics are very safe.
You're free to Google the numbers yourself or provide your own rather than starting with insults. For the record the fire numbers are roughly the same between the ESFI, NFPA and FEMA.
Assume you have 30 electrical devices in operation. Assume the cost of your house is $1mil. Then avoiding that fire should be worth ~$13 per device. However, the device manufacturer would not need to bear that cost, meaning it goes unpaid.
You'd be correct if every house fire totaled the property and the average house price was a million. It seems house fires cause $1.5billion in property damage per year in the US and there are 360k of them. Assuming electrical fires are twice as damaging as the average fire we end up with a cost of $10k per fire. That works out to around 15 cents per electronic device in your example. Even that is a high estimate since I believe only a minority of electrical fires are due to consumer electronics (versus things like faulty or old wiring).
Narrator : A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one.
Woman on Plane : Are there a lot of these kinds of accidents?
Narrator : You wouldn't believe.
Woman on Plane : Which car company do you work for?
Even to the point where an actual horrific accident doesn't necessarily mean that vehicle is any more dangerous than other vehicles on the road, they just don't have that exact failure mode but do kill people nonetheless.
And no amount of money is going to buy perfect safety either. As always, engineering is all about tradeoffs, no way around it. Car companies have dropped the ball on safety in several cases, but just because somebody died, doesn't mean they did.
Note: marcinzim was referring to the probability of "getting into an accident". It's not clear what the law firm you link is referring to since their source doesn't cite their sources properly, but it looks like they might have been referring to the probability of being injured in a car accident. Even so, I'm not sure where they get their numbers or exactly what the numbers are supposed to refer to. See the sibling comments for some references to statistics that are very different from those that the law firm seems to have gotten from an insurance company.
If you're a mediocre to average inexperienced driver, think one in ten. Well trained and experienced drivers don't crash.
Two rules for anyone reading: [1]: never, ever, be in the way of anyone - don't ever be an obstacle to traffic flow; [2]: if you abide to [1], consider you're the only sain person on the road who really knows how to drive, all others don't - everyone around is a danger to you, so be hyper vigilant, always.
Are you sure? If I drive once a day, to and from a single place, that suggests I’m involved in (365*2/100)= 7 car accidents a year. That seems high, no?
Per a quick glance at NHTSA’s summary figures [1] I wonder if the previous poster is referring to the “1000 injured per 100,000 drivers” figure. Which divides out to 1% I guess, a little more in past years. But that’s a little awkward to express in plain language, in that one wreck can injure lots of people, and people can get injured who are not drivers (drivers comprise around half of the injuries, it looks like, from higher up in the table).
Although the total number of crashes (including the large majority that don’t involve injuries) still looks pretty wild as a proportion of licensed drivers. If I were trying to raise concern about cars, I’d point to that ratio of 1 collision (of any sort) for every 43 licensed drivers every year.
> Are you sure? If I drive once a day, to and from a single place, that suggests I’m involved in (365*2/100)= 7 car accidents a year. That seems high, no?
That's partially because MonkeyClub didn't do the math correctly. If the accident rate is really 1% of trips (which seems doubtful), there is a 99% chance of an accident free trip, a (99%)^N chance of N accident free trips, and a 1 - (99%)^N chance of one or more accidents occurring in N trips. For N = 100, this is 63%, and for N = 365*2 this is 99.9%.
As you mention, the data from the NHTSA seem to indicate a much lower accident/injury rate. Based on this data from the NHTSA [0], and going back to 2018 to avoid any pandemic-related effects on the statistics, it looks like there was on average only 1 (police-reported) crash per 481 thousand vehicle-miles, or one crash involving an injury or fatality per 1.7 million vehicle-miles.
When I wrote:
> For N = 100, this is 63%, ...
I was responding to your comment:
> It means that in out of a hundred trips, it’s pretty certain one will involve an accident.
Whether or not 63% == 'pretty certain' is another matter I suppose.
Probability pedant here. This is not entirely incorrect, at least to the extent it suggests that there's a matching relationship between the two 100s in 1/100 chance and 100 trials.
If there is a 1% chance of something happening during an independent event, then to calculate the probability of it happening at least once across N events, you must use the formula 100% - 99%^N, where the 99% was derived from 100% minus the "1% chance" in the original scenario.
So a 1% chance across 100 trials is 63.4% likely to happen.
>The risk of my home catching on fire each year due to any electrical issue is 0.04%. The risk of me dying or being injured due to such an issue is 0.00004%.
You mean you'll only die or get injured in one out of a thousand home fires? That seems really low. But I'm picking nits.
I think you are conflating quality and safety. While quality control can certainly help with ensuring safe operation of industrial equipment, I don't think a laptop LCD panel breaking is a safety hazard, although it is still a quality issue.
My main argument is that the consumer electronics as small systems are so so sooo optimized for cost. (Which is good, people can afford them.) But somewhere along the way the components inside them stopped being useful by themselves. (Of course a direct consequence of optimization of integrated parts.)
This basically resulted in custom parts for custom systems. And now as software is eating everything custom software is also part of the system. (Though at least it brought back some general parts!)
Safety as a system level property is still there, but completely lost in the parts. And similarly many other desirable properties have been optimized out. (Like reliability, serviceability, etc.)
To be fair, the price of consumer electronics is falling through the floor too. A routine living room television (say a 60" 4k panel) is literally 50x cheaper in real value the 16" color set my family bought in 1982.
You need to look at both sides of that equation. Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch? (It's a reasonably informed guess as to what that would cost.) Maybe some people would. Probably not many. Most people want the $700 laptop which is "just as good", even if the display sometimes fails.
We would be able to find a balance between quality and price if the Fed stopped creating new money to erase lower prices. Your argument is only apparent for high technology because computing advances so fast that it has been able to outrun the policy of inflation. For example, appliances are being designed ever cheaper while also costing more. Consumers end up anchored to the bottom of the market based on sticky expectations of price, the market as a whole never develops a sense of wealth, and economies of scale make it so straying from the herd is very expensive.
(edit: changed "printing" -> "creating" since the former is a tribalism trigger)
> We would be able to find a balance between quality and price if the Fed stopped printing new money to erase lower prices.
That is... a weirdly revisionist interpretation. People have been complaining about consumer electronics quality consistently and pervasively for decades and decades. Absolutely nothing about that point is "modern" or "new". Yet... you really think it's due to events of the last few months? And not even just any events, politically charged events interpreted and explained using partisan language[1]. Really?
[1] Seriously, one of the easiest ways to tell whether or not to pay attention to an economics argument is whether it includes the phrase "printing money".
Erm, no. I'm not talking about the past two months, rather I'm talking about the past several decades. For example, all that offshoring was supposed to "lower prices" thereby giving consumers more purchasing power to make up for the loss in income. But the Fed has drawn a feedback loop around prices and asserted they must always go up, so the net effect of offshoring was only to wreck the manufacturing economy.
Politically, I call the current price inflation "Trumpflation", since that is when the monetary inflation that's driving much of it occurred. We'll see how the Biden administration did in a few years. And while being an Austrian-leaning libertarian, I think the Democrats are at least honest in that they want to use some of the newly created money to compensate for the financial damage that monetary inflation causes, whereas the Republicans want to give it all to the banks while preaching austerity for everyone else.
Yes, price inflation measured by the CPI, which consists of a changing basket of goods from the lower end of the market, has been low.
Let's say a given widget costs $10 to produce, and look at what happens over 4 years. Say offshoring, cost optimization, and technological progress would allow it to be produced for $7. The Fed creates enough new money that the new price is $11. The Fed calls this "2.5% inflation", whereas the actual inflation has been 12%. The sticker price reflects the 2.5%, and the remaining 9.5% is reflected in the item being made cheaper, not supporting the local economy, and the gains of technological progress accruing to the central bank rather than being distributed throughout society.
At the larger level, this does not happen uniformly to every component of CPI. Instead, prices for things that can be bought with new money increase more. So manufactured goods still have relatively low price inflation, where things that the consumer can finance (housing, education, healthcare, vehicles) shoot through the roof.
Bringing this back to the original topic - since the median consumer's expenditure is expected to be ~fixed (slightly rising) for a basket of goods that are decreasing in quality, they're unable to afford the previous baseline quality that is now considered luxury. Rather than seeing a choice between buying what they know and saving money with a lower-quality item, they're given a choice between paying slightly more for the lower quality one or paying much more for the quality that they were used to.
Wow, OK. Your point seems to be "If you discount economic growth, then inflation has been high". Well... OK. Granted. But let's game that out:
It's true, that if you correct for all the inventions and economies that have made its production possible, the relative "cost" of, say, a nice new five-burner induction range is indeed extremely high in comparison to, say, the bow drill your ancestors would have used. Probably in the billions or so, if not higher.
But that's not telling you anything! In point of fact the "cost" measured in hours of labor[1] of collecting fuel and starting fires over the course of a decade or so[2] is VASTLY higher for the paleolithic toolkit. And it's not even remotely close, which is why no one chooses to cook with an open fire and a bow drill except as an amusement.
Basically: you're bending yourself around and measuring the wrong thing to try to make a point about inflation in an area that has nothing to do with it.
[1] Which is, at the end of the day, all we really care about optimizing. We live one life and we want to live it well doing as little work as possible. Frankly this is sort of "postulate zero" of the whole field of economics.
[2] Just assume the range will last for a decade. I don't know what the real average is but it's in that range.
Its not about discounting growth, but rather correctly accounting for growth. Why should the financial benefit of growth accrue to the central bank rather than remaining distributed throughout society? In these terms, decades of high growth have allowed the centralized government (including Wall Street) to balloon. Now that growth has slowed (the low hanging information technology and offshoring fruit has been picked), the costs of those policies will increasingly show themselves.
Furthermore, accounting for optimization via tradeoffs as if it's bona fide growth is doubly wrong. Cost reduction via quality reduction is actually the opposite of growth, but gets counted as increased efficiency for labor rather than reduced quality of life for humans.
Focusing on hours of labor and gradually reducing hours worked would have been a different way to keep the benefits of growth distributed throughout society. Instead full time employment has been fixed at 40 hours through a long period of high growth, with the new money feedback loop soaking up the individual's surplus.
Are they? I used to be a huge lover of Thinkpads. IMO, they've been going downhill since the T60, I had a T430 and I ended up getting rid of it. I kept my X32 still going though.
While I agree in spirit, honestly my T60 broke much more than my current X230. I replaced the T60's keyboard 4-5 times under warranty, while maybe once or twice for the X230 over a longer period of time. I did use the T60 more though (no-desktop phase). I've no experience with more recent models, since I prefer personal computers (ie no ME crapware).
Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch?
YES, please, I beg of the industry give me this.
In a loud, resounding voice.
Buying a new laptop takes days of investment to get it all set up just right. Maintaining the software and OS to keep it snappy is also a timesink. The initial cost of the hardware is a trivial portion of the TCO for me.
It's also an item I only carry around one of (lugging around a backup device would be too inconvenient even if it only cost a dollar), so reliability is paramount.
My current laptop (Dell Precision from ~2011) cost a little over your price point, and has been upgraded many times over the years. Finding something I'm happy to replace it with has been a conundrum, there's a ton of absolute garbage out there. (Framework almost does what I need and is a leading contender).
> lugging around a backup device would be too inconvenient
I kind of do this. I bought two used laptops a few years ago, one 13" XPS and a big bulky ~17" ThinkPad. The XPS is great for meetings, the other one is great for software development, and I have a backup ready and set up, ready to go. And if I travel for more than a day I sometimes take both. (So far the strategy seems to be flawless, as both work in well their own sub-par broken but reliable way, as Windows machines tend to, maybe each one is kept blinking by pride, or just to spite the other one. :D)
I'd definitely want to pay on quality on some stuff, the problem is that it is very hard to spot that quality and not just product being more expensive because of a bunch of features I don't need, or just plainly on brand name.
The other problem is that niche high quality stuff also would not benefit from economies of scale as much, and at some point buying 4 of the cheap might get you thru longer than one of the "reliable" one
The top-end electronics are maybe a bad example as (at least till now, it seems to slow down at last) the performance is also a big factor, so buying $700 laptop you will want to replace anyway in few years is sensible over "will never break" $4000 one that will just go out of date.
But on like, just about everything else ? Reliability and repairability please, I will pay extra.
Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch?
Isn't that what Emperor Linux is (nominally) about?
Not that I have ever tried them out because that is way beyond my pay grade, but several of their machines are in that price range.
> Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch?
Absolutely. Yes please. That would mean I can use it for 10 years without major problems, I'm able to repair it, no Jail breaking needed... make it 5k. More than happy.
But I understand, I'm not the majority of the market.
Nintendo sells a product that includes hardware and software. As a product it is safe. They are no more responsible for the damages caused when you modify the product than they would be if you took the Switch and bludgeoned someone across the head repeatedly.
If its about hardware security measures it may be its spatial cost.
Having each circuit / subcircuit bring its own safety is certainly gonna be subobtimal when optimizing for size.
On the software side I reckon the driving circuit is the deciding factor, which a vendor (of displays) can't control.
> How come these things are not secured against at the LCD controller side? Why would a general purpose controller ne designed to accept e.g. too high voltage levels?
Why would they be secured there? The device doesn't allow setting any of the dangerous settings, so noone will break their displays this way.
Look at cars for example... pretty much cars have systems in place not to overheat (thermostatic valves, fans, etc.). Most even have code to go into limp mode and turn off if they overheat. Now imagine someone taking the ECU out of the car, installing gentoo on it, putting it back in, and forget to write a script to check the temperature and turn on the fans when needed... the car would probably work ok when driving high airflow) but when stopped, it would heat, overheat and eventually something would break down. Do we need some kind of a hardware system in our cars to turn on the fans, or something that turns off the main relay, because someone decided to hack the software and forgot to implement sotware limits and checks?
The car is _designed_ so that it doesn't get to hot. If, despite this, it gets hot it will be stopped.
Now, those are the requirements and some suppliers might disregard them with the prize of their liability.
The car has mechanisms, some of them implemented in software (eg turning on cooling fans) to not get hot.
So does a switch.
Someone installing gentoo on a cars ECU, and not implementing the feature to turn the fans on will easily overheat and destroy the car... the same is happening here with the lcd controller (and yes, the switch is designed so that the user can never go above some brightness level... unless the user hacks the switch and installs some random linux on it).
The car won't shut off because that would be a dangerous thing to do in traffic.
The car will alert the driver than something is wrong and should stop as soon as it is safe.
Because stopping engine abruptly in middle of highway could be very dangerous.
A lot of cars also have so-called "limp mode" where some failures cause car to limit engine power and other stuff, basically to get to the next point the car can be stopped and towed to shop
So you're saying a car has software features in the ECU preventing the user from destroying a car. So does the switch in its software (OS).
We're talking about someone taking a device, hacking it, installing some random software (whatever hacked version of linux runs on switch), and that software does not have the feature of limiting the max brightness at an accaptable (non-damaging level). So the same as if you took an ecu of a car, put linux on it, didn't implement the limp mode feature and then blame the hardware for overheating.
> Why would a general purpose controller be designed to accept e.g. too high voltage levels?
Pragmatic design decisions. My bet is they decided that adding voltage regulation was unnecessary since they can limit it via software which they have control. Adding voltage regulation would increase the component count which takes up board space and lengthens the BOM (bill of materials.)
This reminds me of installing uLinux on a Palm IIIxe around 2000-2001. During reboot, one of the transparent diagonal LCD traces behind the LCD went black for several seconds and then faded back to clear.
I thought I fried the thing, but it went away it on its own and the display continued to work. I couldn’t figure out a mechanism for causing it to happen, but this explains it.
> How come these things are not secured against at the LCD controller side?
Because we make generic LCD controllers that can service a wide range of panels.
Using generic parts with adjustable outputs is standard practice. It keeps prices down, keeps supply chains flowing, and makes it easier to design new systems around common parts. It also reduces the amount of waste because common parts can be re-used in new designs and resold if unused.
Many things around you are controlled by software settings without separate hardware limits to keep them in check. If you have an enthusiast motherboard, you can reboot right now into the BIOS and set the CPU and RAM voltages to numbers that will fry your chips in short order if you want, and it won't stop you at the hardware level.
Generic parts with a wide output range are great, but it requires care and attention to make sure the software is providing the right settings.
The simplest hardware design is just running it at say 10% max in flashlight mode but allowing for short bursts of overdrive for flashing. The LED is big enough to handle short bursts, but not thermally cooled well enough to work at full power all the time. So you rely on firmware/software to do its job instead of having specialised hardware controller that's only job would be to make sure LED isn't on on 100% for more than say half a sec.
You control software so you don't GAF, but people putting custom one have to take same amount of care
Second example: You're an engineer and need to drive a backlight. You can
* slap a constant-current controller (buck or two of parts) so 100% is a maximum safe level all while regulating it at >90% efficiency
* slap a high value resistor costing $0.01 so 100% is maximum level is safe but you lose a lot of power in the resistor
* slap a low value resistor then just drive it at 20% duty cycle and waste less heat in resistor all while still costing $0.01
They just most likely picked 3rd. Or picked 1st and misengineered the limits I guess...
Phones use flash LED controllers that limit the time the LED is able to turn on in high power mode. Though apparently you can misdesign the HW with these, too, as I've recently discovered.
Because you don't know what the final design spec might need to be, under all circumstances. I've got a board design that's used in production that the moment where - depending on configuration - it could blow the device it's connected to up in about three seconds if you set it to full power in normal operation. It's designed to go that high, because it may be running from a very degraded power supply and it may be necessary to "kick" the actuator it controls quite hard with short bursts of full power to unstick it as it wears.
I updated my Framework‘s Arch install (to kernel 5.19.12) the other day and the display began flickering on and off on boot up. Had to get out a live USB to revert.
I thought I had a hardware issue! I only got the flickering upon resume from sleep/hibernation and eventually git bisected the kernel package on Arch to find that it was indeed 5.9.12...
According to my package history, I got 5.19.12 installed for around 1.5 days. Would that have been enough to damage my professionnal laptop? I don't know, I didn't spot any issue with the screen.
Linux is great on laptops. A bug can happen anywhere. And macOS is way too locked down for many people. Of course Linux is great for servers too but why stop there? I really love KDE as a desktop. It's just more free and configurable than either Windows or Mac. I don't like being stuck with the choices made by the developer. For this reason I don't use gnome either but it's good that it exists for those who do subscribe to the opinionated software concept. That's the biggest strength of Linux. It can be whatever you want it to be.
PS using FreeBSD as my daily driver desktop myself :) But not on a laptop but on a NUC.
That philosophy pertained to userspace tools, not the OS as a whole. And the waters have been muddied a lot (think systemd which does a lot of things and is still embraced for servers and desktop alike).
Linux on laptops is great, especially ThinkPad's and machines older than a a few generations. I just started using gnome after being a loyal xfce user for years and it's refreshing with all it's integration (with lots of extensions for customization).
I really like KDE, but there's always something that annoys me enough I move away. I try most new major releases (GNOME too), then jump back to XFCE.
For example, does it use the same keyring as the rest of the applications yet? Does the WiFi menu still select an entry different than the one you click?
Well, if you use gnome/GTK apps, of course it uses gnome-keyring.
If you use Qt apps, it will use KDE's keyring. This is simply caused by the lack of standardisation in such elements of Linux desktop environments.
I tend to use mostly Qt apps, because they look the most 'native' on KDE and have the best integration. They also have the same philosophy (the more user choice and settings the better) which I subscribe to, so I naturally gravitate towards them.
And no the wifi applet always worked correctly for me (I don't use wifi on my main desktop but on laptops it works fine for me)
There's also things I don't like with KDE but there's almost always an option to change it. Whereas with Gnome there is almost never any such option, it could be there is an extension that does it but having too many extensions tends to drag you into a quagmire of version dependencies making it really hard to upgrade.
The one thing I really don't like about KWin is that the virtual desktops of each display can't be switched independently like with i3 for example. They're all stuck together. But this is a minor inconvenience compared to all the things I dislike about Gnome.
While I agree that Mac is still a better desktop, IMHO this is a hardware bug. It should not be possible to damage a computer with a simple setting. Things like intentionally wearing out SSD with endless writes are unavoidably possible but the hardware should not allow a driver bug to brick it.
Pretty much any computer can be destroyed by SW or firmware (which is also just SW, BTW). Any laptop or smartphone has a PMIC that can produce out of range voltages, thermal protection can often be worked around or disabled, battery can be overcharged or overstressed, etc. etc. With USB-PD, you can just configure the HW wrongly and let the USB PSU send you 15V when you can only handle 5V, which will surely brick something. There are way too many ways to brick the HW.
Lot of these highly dangerous things are controlled over I2C or SPI buses, which don't use any checksum mechanisms, so SoC can send "set CPU core voltage to 1.1V" and PMIC can plausibly read "set CPU core voltage to 1.8V" due to noise on the data line, or what not, and just do it.
It's kind of interesting that failures don't happen more often.
If you are going down that route then you won't use any consumer grade OS ever, since they all have bugs like these every once in a while, from hardware damaging bugs to full lockout and major security vulnerabilities.
Note that unlike said macOS bug this one isn't in a stable operating system release. It's the equivalent of finding a bug in the macOS Ventura alpha. How else was this bug supposed to get fixed if not by people running the latest kernel and finding said bug?
> >> I definitely had no plans to backport any of that stuff,
> >> but I guess the automagics did it anyway.
> >> Looks like stable is at least missing this pile of stuff:
Did a half-finished feature end up in the release due to an automatic merge?
By "automagics" he probably means the artificial intelligence bot which tries to guess which commits should be backported to the "stable" (in this case, 5.19.x with x other than 0) kernel, even though they have not been explicitly marked to be backported. That bot has been controversial for some time, see for instance the article at https://lwn.net/Articles/863505/ and the older articles it links to.
That's.. an interesting approach. I can understand why they want to have a bot help out but personally I'd feel very wary of a bot selecting commits to merge. In my completely uninformed opinion it sounds like there's process improvements that could be made alongside using the bot to point out interesting commits that can be reviewed by a human.
Interestingly I have a similar experience of flashing displays, though my issue reflected the backlight and not the panel poweron sequence. After chip-level-flashing an Ivy Bridge Dell laptop with a corrupted BIOS chip, I was disappointed to find that the backlight was dimmed using PWM at 100 Hz (10ms periods) (CORRECTION: 200 Hz), where 50% brightness in Linux sets the light to turn on for 5ms, then off, and repeat every 10ms. This causes noticeable flicker when I move my hand in front of the screen.
Reading through the i915 driver and Sandy/Ivy Bridge GPU datasheets, I found that the backlight was controlled by two GPU registers at 0x48250 and 0x48254 (CPU-written?), with mirrors-ish at 0xC8250 and 0xC8254 (PCH-written?). There's actually a script to decrease the backlight period register at https://github.com/edio/intelpwm-udev, but the problem is that Linux still scales the pulse width register based on the original period (10ms) at time of bootup and doesn't see the userspace tool writing a shorter period (higher frequency). If you halve the backlight period to 5ms, 50% brightness suddenly configures the GPU to turn the screen on for 5 of 5 ms, setting the screen to full brightness instead (all lower brightness values are doubled, and all higher ones are technically illegal chip configurations). As an added gotcha, if you write to the wrong register mirror (0xCxxxx vs 0x4xxxx), you get seizure-inducing screen backlight flicker comparable to the issue report at https://gitlab.freedesktop.org/drm/intel/-/issues/7013.
I tried recompiling the i915 driver to increase the PWM frequency at boot time, but was unable to compile and replace that driver alone due to symbol version mismatches (and I didn't want to rebuild the whole kernel on an obsolete dual-core Ivy Bridge). So I tried changing the backlight frequency in the BIOS itself, which was OS-agnostic and didn't require editing Linux drivers. I began decompiling the UEFI firmware in Ghidra and tracing control flow across multiple undocumented labyrinthine EFI executables, finding that I had to modify a VBT file's backlight PWM frequency field to change the refresh rate. Sadly this only affected pure UEFI boot and not CSM mode, but disabling CSM causes Windows 7 (the OS I used when the laptop was new, and which I keep this laptop just to run) to show a black screen. And I got burnt out from reversing EFI, and broke a flash chip leg and two motherboard pads reflashing my BIOS (and barely managed to patch the BIOS chip circuit back together with bodge wire soldered to the chip's stub)... so I'm still stuck with 100Hz flickering...
Sorry, I misremembered, the native flicker frequency is at 200 Hz, I had to look up my notes again and verify by listening to my solar panel hooked up to a 3.5mm jack.
I forgot to mention, I actually managed to write a program that would dynamically rewrite the period and pulse width registers to play music off the screen backlight, based off a conversion of the Monkey Island tunes from https://www.thanassis.space/monkeyisland.html. It almost worked... except that whenever I decreased the period (raised the pitch), there was a random chance the new period would be greater than the current phase, and so the display would hang at full or zero brightness nonstop (producing a gap in the sound) until the 16-bit counter running at 0.98 MHz (= 125/128) rolled over, rather than instantly setting the counter to zero and turning the display back on. I've recorded my "best effort" attempt at music, at https://www.youtube.com/watch?v=7qt0ssFk410 (every recording has different gaps when pitch increases).
I remember back in 1998 when I was in a strong discussion on how software couldn't damage hardware: no matter what you did, you wouldn't be able to damage hardware with your bits.
Yes, those who said that are long gone. Me, and the few that said it was doable (and did, moving those 5"1/4 floopies drive beyond the heads' limits), are here, watching the news...
Well, early XFree86 had strong warnings that wrong settings could result in monitor damage (which made configuring X11 even more daunting). Nothing new under the sun.
Whoever was claiming that in 1998 was wrong, tho. It was actually a fair bit easier back then; in particular CRT monitors could react very badly to bad signals.
One of the first chromebooks would melt and burn if you fired up alsamixer and tried toggling a few of the toggles.
I encountered this myself fiddling with the audio settings and ended up with magic smoke and melting plastic before I quickly powered it off.
I wonder if something like this is what happened to my 2013 chromebook pixel. About a month after the warranty ran out, the audio quality from the left speaker rapidly degraded to distorted crap over the course of a few days, then stopped forever. Shortly later the same thing happen to the right speaker, and that computer never made a sound again.
Not an expert but that sounds like the voice coils overheated. In theory the drivers should prevent you from doing this, but in practice insufficient prevention measures in drivers/DSP combined with running too close to the sun seems to have made it possible to easily do this on some laptops, hence DELL voiding their warranty for people who turn the volume too high in VLC.[1]
Anything you can do with VLC's volume control can be done in the audio file itself - it doesn't touch the hardware at all. This is just dodging responsibility for defective design.
It's true, though frankly most audio files are not distorted to shit, whereas it probably needs to be in order to actually do this. Still, I really think it's on them to protect their hardware. Ideally in hardware, but if they can't even do it in their own drivers it's pretty pathetic.
Sounds like they were letting very low frequencies through to the speakers and/or accidentally producing DC.
I only read the one thread on this, so I'm guessing a lot here, but it sounds like you could patch the <100hz frequency problem in hardware for like $0.50 with a high pass filter soldered in at the speaker?
That thread is a little hard to read, so I don't know if there really is a dc problem. That's a little harder to fix in the speaker cavity.
Yes, you could. A high-pass filter that is able to drive a laptop voice coil down to 100 Hz would probably cost about that much, which is 50x more than the motherboard manufacturer wants to spend.
A high-pass filter in the DSP/driver software is free, sell a million Chromebooks and that's $500k of pure profit from cutting costs. Unless you account for warranty recalls due to buggy drivers, in which case a 0.1% failure rate is enough to make this a bad idea.
A high pass filter is essentially a RC filter in which the resistor part can be the speaker coil, so one only needs two capacitors, one per channel, which would cost a lot less than $0.50 in small quantities (example: Vishay ZSC00BM2211AARL, 220 uF - 10Vdc: €0.14100 in 10 quantity at tme.eu, a lot less in 100 or 500 qty).
The problem however is either the amplifier ic which is too powerful, or the speaker itself being too weak to sustain its power. That would be bad design though; one should never assume the signal won't contain certain frequencies; it's good practice to pick a speaker that can sustain at least twice the maximum amplifier power indefinitely, and even more during peaks, regardless of what frequencies are reproduced.
Wow that Google group thread is really something else. So many of those people really need to take a break from having Linux be part of their personality.
> Is this howto useful? I think it is. Cause if you have device broken in some way and you want to get it replaced you can just run it and hope for replacement instead of repair.
You're looking at one message with quoted messages so the oldest messages are those with the highest level of '>' so usually start there for some context to where things started and work out.
I started reading mail in the 90's with a program called "pine" in the command line of a BSD machine... I find that mail easier to understand than outlook. :)
Pine and Mutt were my jam back in those days. It really did depend on whether you were keen to use Pico or Vim as your reading/composing tool. (Although you could pretty much use whatever you wanted)
Mailing list emails end up full of markup, but the people who send them tend to be very consistent—always quoting previous messages, always posting new text at the bottom (instead of the top, which is default email client behavior these days). Email apps can apply some formatting to make them easier to read, too, for this same reason.
So while they often get overly-full of markup like these ones, the markup follows a pattern that's rarely broken, and it becomes very easy to follow after you've gotten through a few threads.
I find Twitter equally as hard to read as emails like this, or any group conversation in email really.
For both, it seems like I read messages in random order and then have to guess at the general gist. There's seems like no easy way to get an accurate timeline of things.
I think the problem is made worse when people forward (or retweet) as part of a conversation. There's often forwards of other email chains included as a reply with or without unique new messages being added.
Sometimes people are left off part of the CC chain for some messages, so there are gaps in the flow.
The problem is compounded when there are multiple email threads about the same thing, often because someone replied to an old version that turned into a new conversation. Or they read just the first sentence in the original email and replied about that in the newest follow-up in a 100 email chain.
---
As an off topic side note, text chat programs are the ultimate form of communication. It has the fewest flaws of all mediums. It's linear in a single timeline that everybody has (and has the history to). It's pretty hard to mess up the history of what happened or who said what.
I enjoy it when people get frustrated about text chat. It's almost always because they can't dominate the conversation by talking over people or "win by talking loudest" which makes them frustrated and uncomfortable.
> For both, it seems like I read messages in random order and then have to guess at the general gist
I don't use Twitter so I don't know what it does, but if you look at the email, the oldest posts are quoted first, so you just read the message top to bottom like anything else.
And if that's too confusing, there are links to every message in the thread at the bottom.
How do you mean? There are links to the full thread at the bottom of the page.
If you're talking about the quoting, the ">" marks denote one level of quoting, so the more ">" marks in a line, the older the message. As long no unwashed heathen has top-posted their reply, then you can just read the message top to bottom in chronological order.
They are very comfortable to read with email software like Mutt, when you’re actually on the mailing list (and are auto-sorting the list mails into a dedicated folder). There are keyboard shortcuts to jump to the next message in a thread, or to the next unread message, to collapse/expand (sub)threads, and you get a nice tree view of the threaded messages, displaying the subject line only on messages where the subject changes; the pager can be set to automatically jump to the first unquoted part of a message, and so on. On par with Usenet TUI clients, it’s the most efficient discussion medium I known of.
Is there a layman's explanation for what is happening here?
It talks about power and general speaking I would have thought that outside extreme cases most electronics just draw the amount of power they need but not more. Can a kernel determine this somehow?
Not sure what is the case here. But I can say something: current electronics are getting ridiculously complicated in what power supply concerns.
The project I'm working now, and the last I was, we had in a 4x4 inch board more than 10 voltages (1.0v 1.1v 1.3v 1.6v 3.3v 4v 5v 6v and I do not know what more) , all generated by micro controller configured power supply circuits. Those 10 voltages had to follow a very specific sequence, failing to follow it, could in worst case, damage the whole board. Basic explanation: if circuit part B is powered before part A, power flows "backwards" to A, melting it.
In addition, an error in the configuration of the supply ASICs would also lead to too high voltages. That is, the output voltage was configured in one register.
I think something along the lines is going on here.
What you call "power" is in fact two different things: voltage (measured in volts) and current (measured in amperes). Voltage is, essentially, how much each individual electron "wants" to move, while current is how many electrons flow.
Electronic circuits will only let a certain amount of electrons flow. If the power supply has way more electrons "available" than necessary, that's no problem, you only encounter problems if the power supply can't keep up.
However, electronic circuits are built to run at a particular voltage. If the electrons "want" to move too much, they may jump across gaps in unintended ways and generally cause havoc.
So in short: A power supply can't damage electronics by providing too high current, but it can damage electronics by providing too high voltage.
I don't know if that's what's happening here, I haven't read about the actual bug, but that's a basic primer on how it's possible to damage electronics even though they only draw the amount of current they need. And software is often involved in setting the voltages which are being supplied to certain components.
Power supplies don't supply electrons. Amount of electrons in the circuit is pretty much static and it's just a property of matter itself. If there is to be electric current (or better said a transmission of power), (free) electrons must already be present in the whole circuit. Power supplies just supply power via various mechanisms and this power is distributed in the circuit using electric fields without electrons moving much at all.
If we're talking about DC, power supplies absolutely make electrons move; the amount of electrons in the circuit is constant, but the system does work because electrons move from one end to the other. Now these electrons aren't moving fast, but they are moving.
At least that's a prevalent and very useful picture of how electricity works, and what's being taught in university courses. It's probably a good enough explanation to answer "why can too much power destroy electronics if electronics control how much current they draw".
The movement of electrons is almost irrelevant to the functioning of the circuit or transfer of power, and is only thought maybe in the first electronics lesson and then never again. (at least that's how it was when I studied EE school) And it has not much to do with the electrical current. (certainly not in the way most non-EE educated people would imagine it as individual electrons moving around carrying energy from palce to place)
> An electric current is a stream of charged particles, such as electrons or ions, moving through an electrical conductor or space.
From Wikipedia, sourced from The art of electronics.
Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant? If it turns out I (and Wikipedia, and all material I've seen on the topic) is wrong, I'd certainly love to know. I'm just interested in this stuff; I have only taken introductory courses at university and learned on a hobby basis, I haven't taken advanced courses.
I said it's irrelevant to transfer of power. (I guess I kinda overstepped with it being irrelevant to electrical current, yes :))
And power is what destroys things, mostly, by over heating them and transforming them into a different shape that no longer functions as expected.
> Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant?
Not really, but consider when was this slow drift (~3 mm/s) of electrons ever of interest/topic in your education, instead of much faster changes in charge distribution on the surfaces of conductors caused by (or creating) electrical fields?
3 mm/s is extremely slow, you'd very much notice if any phenomenon you routinely worked with in EE courses was this slow.
The eDP spec specifies a set of timings that should be waited on in between certain actions. There is a minimum timing between power cycling the panel, between powering-on and sending auxiliary messages, between setting modes, etc. Those timings are read from the a BIOS table called the VBT (among other conflicting sources sometimes), and the patch in question reworks VBT code.
In practice not respecting these timings is kinda like toggling your ceiling lights on/off repeatedly. I bet your parents used to tell you the house could be set on fire if you did that, but you did it anyway and nothing ever happened. I think it's unlikely somebody will actually be able to damage their panels with that bug. But hey I'm pulling this guess out of my ass so don't quote me on that. But that can result in the panel failing to turn on and giving you a black or flickering screen.
In fact, at least a few years ago when I looked at this, the Intel driver was very conservative regarding those numbers because a long time ago in a galaxy far away the VBT values for some laptop models were bogus, so as a result nearly everybody had timeouts longer than what they needed to. There's a chance that even with a bogus VBT you're waiting more than you should for your panel. But that doesn't really affect real people very much, it's only really a significant problem if you're testing Display code and doing thousands of modesets per minute. Unless you're getting black screens, of course.
I decided on Sunday to switch my Arch kernel to latest from LTS, I guess its just dumb luck it also brought Grub down and I had to roll back to using the LTS kernel.
If I'm right the venerable ThinkPad X220 (T420 and so on) with Sandy Bridge (Intel HD3000) does use LVDS instead of eDP. And only some generations later Intel supported PSR with eDP. So it is safe?
I did a quick Google search, I didn't find any case where someone's hardware was destroyed by simply installing or updating Windows. I did however see many cases, like your example where someone did by installing another piece of software and put the blame on Windows.
FYI if you're running Arch Linux, Linux 5.19.13 has already been released into [core] so you should be OK, assuming that your mirror is up-to-date and you've run pacman -Syu recently. https://archlinux.org/packages/core/x86_64/linux/
I moved to linux-lts after 5.19 started inexplicably making my X1 nano unusable after a few minutes of uptime. Load creeps higher and higher until you can't do anything at all. Couldn't find anything in the logs.
Ooph that sucks. The 5.19 kernel completely broke audio for my Ryzen APU laptop too, I have to wait for a 5.19.10+ kernel in my distro (pop os) to get a fix.
I dunno what's up but the 5.19 kernel has had some pretty shoddy releases or major bugs getting through. I kind of think the video, audio, etc. drivers for these highly integrated SoCs are just getting way too complex and unwieldy for anyone to reason about or review.
247 comments
[ 3.9 ms ] story [ 141 ms ] threadJudging by https://community.frame.work/t/psa-dont-upgrade-to-linux-ker..., it has been solved in 5.9.13 already.
Date: Tue, 4 Oct 2022:
> 5.19.13 is now released with 8 reverts for this driver, hopefully that sould [sic] resolve this issue. thanks, greg k-h
https://lore.kernel.org/all/YzxDIXMPIWqsELmj@kroah.com/
Does that mean you experienced the "potentially bogus panel power sequencing delays, which may harm the LCD panel" ? If so, was your LCD panel harmed?
As another commenter mentioned, fancy pants filesystems that support snapshots simplify this situation.
This is what I used. zfsbootmenu is an EFI executable with support for doing zfs rollbacks (and any other arbitrary zfs command) so as long as my EFI partition is left untouched, I don't need a livecd or another partition or anything.
Maybe just didn’t want to boot on faulty kernel at all, now that the risk of permanently damaging the display was known.
> Linux fedora 5.19.13-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Oct 4 15:42:43 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
So sounds like it can cause some out of spec stuff at the analog level, which could plausibly result in damage, but also probably dependant on exactly what bogus values are sent in a particular case and how resilient a particular LCD is.
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
https://lore.kernel.org/all/YzwooNdMECzuI5+h@intel.com/
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
My framework laptop was affected by this. When I booted 5.19.12 my display was flickering like crazy. Rebooting with 5.19.11 corrected it. 6.0 is also fine.
[0] https://lore.kernel.org/all/YzwooNdMECzuI5+h@intel.com/
> No idea if that was real though
Chose one :) You can't state it was a myth and then later say you don't know!
I've heard the same thing about older CRT monitors and remember reading about people damaging their CRT monitors by careless programming in regards to refresh rates. But I haven't actually seen in real life, and I must have read about this in the early 90s or something like that I think, so long time ago.
However, I have seen people having Mew back when I played some Gameboy myself, that one is _not_ a myth :)
The RNG method to encounter Mew in the wild was only discovered years and years later and most definitely wasn't known 20 years ago.
The word myth generally has two meanings. One is that it's a false belief. The other is that it's a legendary story of which the truth is not known. GP obviously intended the latter definition.
The Amiga could output stock NTSC/Pal and some close variants, and many monitors existed which could handle that lower scan frequency (15khz), as well as higher res output with Picasso cards.
https://bigbookofamigahardware.com/bboah/product.aspx?id=466
Anyhow, we always tested new monitors before selling them. Monitors which could handle 15khz and higher frequencies too, were expensive and rare.
Often customers would plug in a cheaper, standard PC monitor, and so we wanted to offer those too.
We plugged in one such, and when the switch came to 15khz? It exploded. Like, the magic grey smoke escaped, along with flames and melting plastic.
Every other monitor brand we tested just went blank screen, or reported "out of sync" on the display.
In as customers might accidentally leave passthrough on/setup, we figured selling this monitor to them to be a mistake.
So if it can happen with too low of a frequncy, surely crappy monitors also exist which blow when too high a frequency is passed.
But that's just terrible, crappy hardware.
A typical modeline calculator warning:
It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk.
<https://arachnoid.com/modelines/>
My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
> My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
It's done in the monitor.
One little oopsie, and that monitor had a line through it for the rest of its life.
- A modeline used to output 480i SDTV-compatible signals (525 scanlines) from a PC, differs from the same resolution's modeline under Coordinated Video Timings (arachnoid.com generates a 516-line modeline for 480i, and Linux's cvt tool doesn't document its interlacing flag because interlacing is not part of VGA or something).
- DVI and HDMI signals are effectively continuous signals with CRT-like timings, translated into digital signals (discrete-time at your GPU's configured dot clock, and quantized) and encoded using TMDS with special pixel values on the blue channel (outside of the 0-255 range) for hblank and vblank. Whereas DP signals are packetized in some manner I haven't researched.
- One common way to output 480i is through HDMI-to-component converters. But 480i has a too low pixel clock below the HDMI spec's minimum timing, and many GPUs cannot put out such a slow signal or converters cannot understand it. (I wonder how DP-to-component would fare, given it's packet-based and might not suffer from a minimum dot clock readable by the receiver chip.) A common workaround recommended by the developers "CRT Emudriver" (AMD GPU drivers modded by in-place binary patching) is to set a 2560x240p or 480i "super resolution", then configure emulators and games to output stretched signals. Unfortunately, neither non-RetroArch games nor Windows's CRT Emudriver cannot rescale their image to non-square pixels and their 1440x480 images were squashed to a 4:3 aspect ratio, so I had to switch to Linux and xrandr for square images.
- I had to pick 1440x480i because otherwise the vblank pulses generated by my AliExpress HDMI-to-component converter were insufficiently staggered between interlaced and non-interlaced scanlines. Since I don't have an oscilloscope, I diagnosed this by piping the sync-on-green composite signal into my motherboard's 192khz line-in capture, then recording in Audacity and comparing to correct NTSC timings (the vertical serrations should be evenly spaced and they weren't).
- The Linux amdgpu driver is well capable of outputting a 1440x240p resolution (there are many NTSC modelines, with varying undesirable horizontal offsets and stretching, and vertical offsets), and xrandr is an excellent way to scale a 1280x960 framebuffer to 1440x240 or such (which is scaled back to square aspect ratio on-screen). Unfortunately Linux amdgpu's dc driver for its display controller (compatible with atomic modesetting) has missing support for interlacing, the easiest workaround being to pass `amdgpu.dc=0` to the Linux kernel command line (this disables atomic modesetting, switches to the legacy display controller driver, breaks HDMI audio, and makes the mouse cursor unaffected by Redshift so Plasma's text cursor becomes practically invisible on white text fields).
- - I debugged this extensively at https://gitlab.freedesktop.org/drm/amd/-/issues/1636, but failed to solve the problem. If I hack the driver to force interlacing on (not realizing I needed interleaving as well), the resulting analog signal repeats the first scanline hundreds of times followed by a birth-defect serration pulse, which I would be unsurprised if it would physically destroy some CRTs. I recorded a video (epilepsy warning) at https://www.youtube.com/watch?v=GoQ9q1lwKHI.
- - Antonio Giner claims to have a fix for interlacing in amdgpu.dc=1 mode, for his Gr...
Also not mentioned there but on the MSX 1 you could 'burn out" the tape drive relay by switching it on and off very fast.
If at all truth, it was in very specific HW (I was in touch with really, really, really big amounts of people in the industry and HW, and have never first hand heard of that happening).
How come these things are not secured against at the LCD controller side? Why would a general purpose controller be designed to accept e.g. too high voltage levels?
But is that really the case for these laptops? Seems kind of negligent from the manufacturer if so.
edit: https://www.diodes.com/assets/Datasheets/AP3019A.pdf example of simple one. The value of the single resistor decides the max current.
there's absolutely no safety mindset for anything behind the cover.
if it's industrial, just put a big sticker on it, write something about it in the mandatory occupational hazards training kit, maaaaaaaybe consider adding a fence, but it's fine anyway.
if it's consumer stuff? well, as long as kids won't choke on it, it's A-OK. especially if it comes to electronics. just write in the user's guide that always disconnect it from the mains when not in use, if used improperly that's on you, and don't ever think about opening it. that only for professionals who are trained in the dark arts of handling this exact piece of immanetized hell-forged eschaton housed in a convenient beige plastic.
adding a voltage limiter between the LCD panel and the input would cost money. designing it would cost money. adding an analog limiter on the regulator would cost money (plus setting it mechanically is very expensive compared to flashing on some firmware), compartmentalizing the software - by having a segment that's set at assembly that contains the physical properties of connected parts, which communicates the operational limits, and the other segment which can be set via software - would also cost a lot of money.
As a counter-point: One persons "safety" is another persons "limitation". Sometimes it's good that things are generally protected but you can break through the protections somewhat.
You could hack the firmware and make the device behave out of spec, but you could also hack the hardware. If you bypassed your voltage limiter on the board then you could blow it up too.
For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
I meant hacking as-in messing around, poor choice of word.
> But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug
Hardware bugs can cause hardware damage.
> For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
They're just not. The ABS, stability, and collision avoidance systems in your car can't fail safe if the software fails because the software is required to control the dynamic situation. It can't just say stop everything. Same as control software in airliners. Or industrial control and monitoring systems (although they can have mechanical interlocks in more cases, not all).
And very little that can be _absolutely_ fail-safe, not even purely mechanical devices. How do you make a fail safe bridge?
That's true, although I think the original point was that if software can damage the hardware it's running on then that should be seen as a fault/bug, but with cost reduction/market pressures/etc. it is often ignored
And fail-safe doesn't necessarily mean everything turns off because that can be just as dangerous, I take it more as a systems mindset where thought, care and attention are paid to failure conditions and making sure those outcomes pose the least risk. Again something which can often be ignored for cost or expediency reasons
Perfection is probably an unattainable goal but I've been around software long enough that I wouldn't want someones safety to depend solely on one piece of software
It is.
And I'm still waiting to hear how that absolutely fail-safe bridge is going to work...
The fact is, Engineering has become the Art of specifying the worst (read: cheapest) implementation one can get away with.
It can involve software though.
Same the other way round, just because the hardware shouldn't allow setting a value to X, doesn't mean the software should request the setting.
Obligatory xkcd post
https://xkcd.com/2030/
mRNA vaccines just cut out the middle man^w bug.
Blind Mother Nature would never hurt me! (hides list of the most potently toxic compounds on the planet under a carpet... tetrodotoxin, botulinum, ricin...)
For comparison, my risk of getting into a car accident is north of 1% and the risk of dying in a car accident is around 0.02%.
So in other words compared to all the other risks out there home electronics are very safe.
Woman on Plane : Are there a lot of these kinds of accidents?
Narrator : You wouldn't believe.
Woman on Plane : Which car company do you work for?
Narrator : A major one.
Reputational damage is so high from consumer deaths now days, the balance sheet comes out in favor of fixing issues.
Even to the point where an actual horrific accident doesn't necessarily mean that vehicle is any more dangerous than other vehicles on the road, they just don't have that exact failure mode but do kill people nonetheless.
And no amount of money is going to buy perfect safety either. As always, engineering is all about tradeoffs, no way around it. Car companies have dropped the ball on safety in several cases, but just because somebody died, doesn't mean they did.
https://en.m.wikipedia.org/wiki/Unsafe_at_Any_Speed
There's not as large of an incentive for product durability and repairability today as there was or should be.
1% of what?
Or “one in a hundred”.
It means that in out of a hundred trips, it’s pretty certain one will involve an accident.
https://ehlinelaw.com/blog/odds-of-being-injured-car-acciden...
Two rules for anyone reading: [1]: never, ever, be in the way of anyone - don't ever be an obstacle to traffic flow; [2]: if you abide to [1], consider you're the only sain person on the road who really knows how to drive, all others don't - everyone around is a danger to you, so be hyper vigilant, always.
In general, be polite and out of the way (both on the road and in life), and you’ll avoid most scratches and crashes.
And presuming everyone (else) is probably nuts doesn’t hurt either :)
Per a quick glance at NHTSA’s summary figures [1] I wonder if the previous poster is referring to the “1000 injured per 100,000 drivers” figure. Which divides out to 1% I guess, a little more in past years. But that’s a little awkward to express in plain language, in that one wreck can injure lots of people, and people can get injured who are not drivers (drivers comprise around half of the injuries, it looks like, from higher up in the table).
Although the total number of crashes (including the large majority that don’t involve injuries) still looks pretty wild as a proportion of licensed drivers. If I were trying to raise concern about cars, I’d point to that ratio of 1 collision (of any sort) for every 43 licensed drivers every year.
[1] https://cdan.nhtsa.gov/tsftables/National%20Statistics.pdf
That's partially because MonkeyClub didn't do the math correctly. If the accident rate is really 1% of trips (which seems doubtful), there is a 99% chance of an accident free trip, a (99%)^N chance of N accident free trips, and a 1 - (99%)^N chance of one or more accidents occurring in N trips. For N = 100, this is 63%, and for N = 365*2 this is 99.9%.
As you mention, the data from the NHTSA seem to indicate a much lower accident/injury rate. Based on this data from the NHTSA [0], and going back to 2018 to avoid any pandemic-related effects on the statistics, it looks like there was on average only 1 (police-reported) crash per 481 thousand vehicle-miles, or one crash involving an injury or fatality per 1.7 million vehicle-miles.
[0] https://cdan.nhtsa.gov/tsftables/National%20Statistics.pdf, other formats and more data available here: https://cdan.nhtsa.gov/tsftables/tsfar.htm
Or at all, since it’s just how possibilities work. I wasn’t calculating the annual possibility.
When I wrote: > For N = 100, this is 63%, ... I was responding to your comment: > It means that in out of a hundred trips, it’s pretty certain one will involve an accident.
Whether or not 63% == 'pretty certain' is another matter I suppose.
Yep, totally.
Remember the counter resets with every ride: it’s the first of the hundred, with 1% possibility of (any) car accident.
That seems about right. It’s one (probably minor) car accident per driver every 20 years.
If there is a 1% chance of something happening during an independent event, then to calculate the probability of it happening at least once across N events, you must use the formula 100% - 99%^N, where the 99% was derived from 100% minus the "1% chance" in the original scenario.
So a 1% chance across 100 trials is 63.4% likely to happen.
Look up the Birthday Paradox for more.
You mean you'll only die or get injured in one out of a thousand home fires? That seems really low. But I'm picking nits.
My main argument is that the consumer electronics as small systems are so so sooo optimized for cost. (Which is good, people can afford them.) But somewhere along the way the components inside them stopped being useful by themselves. (Of course a direct consequence of optimization of integrated parts.)
This basically resulted in custom parts for custom systems. And now as software is eating everything custom software is also part of the system. (Though at least it brought back some general parts!)
Safety as a system level property is still there, but completely lost in the parts. And similarly many other desirable properties have been optimized out. (Like reliability, serviceability, etc.)
The quality of consumer goods is decaying everyday. It is all about the last millionth of a cent to be spared.
Just nobody cares.
You need to look at both sides of that equation. Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch? (It's a reasonably informed guess as to what that would cost.) Maybe some people would. Probably not many. Most people want the $700 laptop which is "just as good", even if the display sometimes fails.
(edit: changed "printing" -> "creating" since the former is a tribalism trigger)
That is... a weirdly revisionist interpretation. People have been complaining about consumer electronics quality consistently and pervasively for decades and decades. Absolutely nothing about that point is "modern" or "new". Yet... you really think it's due to events of the last few months? And not even just any events, politically charged events interpreted and explained using partisan language[1]. Really?
[1] Seriously, one of the easiest ways to tell whether or not to pay attention to an economics argument is whether it includes the phrase "printing money".
Politically, I call the current price inflation "Trumpflation", since that is when the monetary inflation that's driving much of it occurred. We'll see how the Biden administration did in a few years. And while being an Austrian-leaning libertarian, I think the Democrats are at least honest in that they want to use some of the newly created money to compensate for the financial damage that monetary inflation causes, whereas the Republicans want to give it all to the banks while preaching austerity for everyone else.
Let's say a given widget costs $10 to produce, and look at what happens over 4 years. Say offshoring, cost optimization, and technological progress would allow it to be produced for $7. The Fed creates enough new money that the new price is $11. The Fed calls this "2.5% inflation", whereas the actual inflation has been 12%. The sticker price reflects the 2.5%, and the remaining 9.5% is reflected in the item being made cheaper, not supporting the local economy, and the gains of technological progress accruing to the central bank rather than being distributed throughout society.
At the larger level, this does not happen uniformly to every component of CPI. Instead, prices for things that can be bought with new money increase more. So manufactured goods still have relatively low price inflation, where things that the consumer can finance (housing, education, healthcare, vehicles) shoot through the roof.
Bringing this back to the original topic - since the median consumer's expenditure is expected to be ~fixed (slightly rising) for a basket of goods that are decreasing in quality, they're unable to afford the previous baseline quality that is now considered luxury. Rather than seeing a choice between buying what they know and saving money with a lower-quality item, they're given a choice between paying slightly more for the lower quality one or paying much more for the quality that they were used to.
It's true, that if you correct for all the inventions and economies that have made its production possible, the relative "cost" of, say, a nice new five-burner induction range is indeed extremely high in comparison to, say, the bow drill your ancestors would have used. Probably in the billions or so, if not higher.
But that's not telling you anything! In point of fact the "cost" measured in hours of labor[1] of collecting fuel and starting fires over the course of a decade or so[2] is VASTLY higher for the paleolithic toolkit. And it's not even remotely close, which is why no one chooses to cook with an open fire and a bow drill except as an amusement.
Basically: you're bending yourself around and measuring the wrong thing to try to make a point about inflation in an area that has nothing to do with it.
[1] Which is, at the end of the day, all we really care about optimizing. We live one life and we want to live it well doing as little work as possible. Frankly this is sort of "postulate zero" of the whole field of economics.
[2] Just assume the range will last for a decade. I don't know what the real average is but it's in that range.
Furthermore, accounting for optimization via tradeoffs as if it's bona fide growth is doubly wrong. Cost reduction via quality reduction is actually the opposite of growth, but gets counted as increased efficiency for labor rather than reduced quality of life for humans.
Focusing on hours of labor and gradually reducing hours worked would have been a different way to keep the benefits of growth distributed throughout society. Instead full time employment has been fixed at 40 hours through a long period of high growth, with the new money feedback loop soaking up the individual's surplus.
Yes. This is also why I do exactly that. Thankfully there’s still one company making good laptops left, Apple.
Unfortunately, all the brands I used to buy from decided it was better to cut the cost by half by cutting the quality by 9/10s.
The ones from 2011 are.
YES, please, I beg of the industry give me this.
In a loud, resounding voice.
Buying a new laptop takes days of investment to get it all set up just right. Maintaining the software and OS to keep it snappy is also a timesink. The initial cost of the hardware is a trivial portion of the TCO for me.
It's also an item I only carry around one of (lugging around a backup device would be too inconvenient even if it only cost a dollar), so reliability is paramount.
My current laptop (Dell Precision from ~2011) cost a little over your price point, and has been upgraded many times over the years. Finding something I'm happy to replace it with has been a conundrum, there's a ton of absolute garbage out there. (Framework almost does what I need and is a leading contender).
I kind of do this. I bought two used laptops a few years ago, one 13" XPS and a big bulky ~17" ThinkPad. The XPS is great for meetings, the other one is great for software development, and I have a backup ready and set up, ready to go. And if I travel for more than a day I sometimes take both. (So far the strategy seems to be flawless, as both work in well their own sub-par broken but reliable way, as Windows machines tend to, maybe each one is kept blinking by pride, or just to spite the other one. :D)
The other problem is that niche high quality stuff also would not benefit from economies of scale as much, and at some point buying 4 of the cheap might get you thru longer than one of the "reliable" one
The top-end electronics are maybe a bad example as (at least till now, it seems to slow down at last) the performance is also a big factor, so buying $700 laptop you will want to replace anyway in few years is sensible over "will never break" $4000 one that will just go out of date.
But on like, just about everything else ? Reliability and repairability please, I will pay extra.
Isn't that what Emperor Linux is (nominally) about? Not that I have ever tried them out because that is way beyond my pay grade, but several of their machines are in that price range.
Absolutely. Yes please. That would mean I can use it for 10 years without major problems, I'm able to repair it, no Jail breaking needed... make it 5k. More than happy.
But I understand, I'm not the majority of the market.
On the software side I reckon the driving circuit is the deciding factor, which a vendor (of displays) can't control.
Why would they be secured there? The device doesn't allow setting any of the dangerous settings, so noone will break their displays this way.
Look at cars for example... pretty much cars have systems in place not to overheat (thermostatic valves, fans, etc.). Most even have code to go into limp mode and turn off if they overheat. Now imagine someone taking the ECU out of the car, installing gentoo on it, putting it back in, and forget to write a script to check the temperature and turn on the fans when needed... the car would probably work ok when driving high airflow) but when stopped, it would heat, overheat and eventually something would break down. Do we need some kind of a hardware system in our cars to turn on the fans, or something that turns off the main relay, because someone decided to hack the software and forgot to implement sotware limits and checks?
So does a switch.
Someone installing gentoo on a cars ECU, and not implementing the feature to turn the fans on will easily overheat and destroy the car... the same is happening here with the lcd controller (and yes, the switch is designed so that the user can never go above some brightness level... unless the user hacks the switch and installs some random linux on it).
The car will alert the driver than something is wrong and should stop as soon as it is safe.
Because stopping engine abruptly in middle of highway could be very dangerous.
A lot of cars also have so-called "limp mode" where some failures cause car to limit engine power and other stuff, basically to get to the next point the car can be stopped and towed to shop
We're talking about someone taking a device, hacking it, installing some random software (whatever hacked version of linux runs on switch), and that software does not have the feature of limiting the max brightness at an accaptable (non-damaging level). So the same as if you took an ecu of a car, put linux on it, didn't implement the limp mode feature and then blame the hardware for overheating.
Pragmatic design decisions. My bet is they decided that adding voltage regulation was unnecessary since they can limit it via software which they have control. Adding voltage regulation would increase the component count which takes up board space and lengthens the BOM (bill of materials.)
I thought I fried the thing, but it went away it on its own and the display continued to work. I couldn’t figure out a mechanism for causing it to happen, but this explains it.
Because we make generic LCD controllers that can service a wide range of panels.
Using generic parts with adjustable outputs is standard practice. It keeps prices down, keeps supply chains flowing, and makes it easier to design new systems around common parts. It also reduces the amount of waste because common parts can be re-used in new designs and resold if unused.
Many things around you are controlled by software settings without separate hardware limits to keep them in check. If you have an enthusiast motherboard, you can reboot right now into the BIOS and set the CPU and RAM voltages to numbers that will fry your chips in short order if you want, and it won't stop you at the hardware level.
Generic parts with a wide output range are great, but it requires care and attention to make sure the software is providing the right settings.
The simplest hardware design is just running it at say 10% max in flashlight mode but allowing for short bursts of overdrive for flashing. The LED is big enough to handle short bursts, but not thermally cooled well enough to work at full power all the time. So you rely on firmware/software to do its job instead of having specialised hardware controller that's only job would be to make sure LED isn't on on 100% for more than say half a sec.
You control software so you don't GAF, but people putting custom one have to take same amount of care
Second example: You're an engineer and need to drive a backlight. You can
* slap a constant-current controller (buck or two of parts) so 100% is a maximum safe level all while regulating it at >90% efficiency * slap a high value resistor costing $0.01 so 100% is maximum level is safe but you lose a lot of power in the resistor * slap a low value resistor then just drive it at 20% duty cycle and waste less heat in resistor all while still costing $0.01
They just most likely picked 3rd. Or picked 1st and misengineered the limits I guess...
https://lore.kernel.org/all/YzsfrkJcwqKOO+E%2F@intel.com/
I updated my Framework‘s Arch install (to kernel 5.19.12) the other day and the display began flickering on and off on boot up. Had to get out a live USB to revert.
Me: "Crap, I got 5.19 running"
Also me: "Calm down, it's only 5.19.13"
Rollercoaster of emotions :)
Linux is great on laptops. A bug can happen anywhere. And macOS is way too locked down for many people. Of course Linux is great for servers too but why stop there? I really love KDE as a desktop. It's just more free and configurable than either Windows or Mac. I don't like being stuck with the choices made by the developer. For this reason I don't use gnome either but it's good that it exists for those who do subscribe to the opinionated software concept. That's the biggest strength of Linux. It can be whatever you want it to be.
PS using FreeBSD as my daily driver desktop myself :) But not on a laptop but on a NUC.
UNIX philosophy - do one thing and do it right?:)
Linux on laptops is great, especially ThinkPad's and machines older than a a few generations. I just started using gnome after being a loyal xfce user for years and it's refreshing with all it's integration (with lots of extensions for customization).
For example, does it use the same keyring as the rest of the applications yet? Does the WiFi menu still select an entry different than the one you click?
If you use Qt apps, it will use KDE's keyring. This is simply caused by the lack of standardisation in such elements of Linux desktop environments.
I tend to use mostly Qt apps, because they look the most 'native' on KDE and have the best integration. They also have the same philosophy (the more user choice and settings the better) which I subscribe to, so I naturally gravitate towards them.
And no the wifi applet always worked correctly for me (I don't use wifi on my main desktop but on laptops it works fine for me)
There's also things I don't like with KDE but there's almost always an option to change it. Whereas with Gnome there is almost never any such option, it could be there is an extension that does it but having too many extensions tends to drag you into a quagmire of version dependencies making it really hard to upgrade.
The one thing I really don't like about KWin is that the virtual desktops of each display can't be switched independently like with i3 for example. They're all stuck together. But this is a minor inconvenience compared to all the things I dislike about Gnome.
Of course YMMV and that is why we have Linux <3
https://invent.kde.org/frameworks/kwallet/-/merge_requests/1...
Consider me excited.
I think both Gnome and KDE are pretty good but Gnome's design decisions and philosophy don't match my preferences.
Lot of these highly dangerous things are controlled over I2C or SPI buses, which don't use any checksum mechanisms, so SoC can send "set CPU core voltage to 1.1V" and PMIC can plausibly read "set CPU core voltage to 1.8V" due to noise on the data line, or what not, and just do it.
It's kind of interesting that failures don't happen more often.
Bug free software doesn't exist. Hardware destroying bugs are thankfully very rare, but they do exist.
https://www.macrumors.com/2019/02/22/adobe-premiere-pro-fix-...
Note that unlike said macOS bug this one isn't in a stable operating system release. It's the equivalent of finding a bug in the macOS Ventura alpha. How else was this bug supposed to get fixed if not by people running the latest kernel and finding said bug?
If you don't mind the ads that are coming your way ...
https://news.ycombinator.com/item?id=33069696
> >> I definitely had no plans to backport any of that stuff, > >> but I guess the automagics did it anyway. > >> Looks like stable is at least missing this pile of stuff:
Did a half-finished feature end up in the release due to an automatic merge?
Here's an article about the machine learning bits: https://lwn.net/Articles/764647/
This is a lesson we've learned many times over by now: Software limits alone are insufficient.
Reading through the i915 driver and Sandy/Ivy Bridge GPU datasheets, I found that the backlight was controlled by two GPU registers at 0x48250 and 0x48254 (CPU-written?), with mirrors-ish at 0xC8250 and 0xC8254 (PCH-written?). There's actually a script to decrease the backlight period register at https://github.com/edio/intelpwm-udev, but the problem is that Linux still scales the pulse width register based on the original period (10ms) at time of bootup and doesn't see the userspace tool writing a shorter period (higher frequency). If you halve the backlight period to 5ms, 50% brightness suddenly configures the GPU to turn the screen on for 5 of 5 ms, setting the screen to full brightness instead (all lower brightness values are doubled, and all higher ones are technically illegal chip configurations). As an added gotcha, if you write to the wrong register mirror (0xCxxxx vs 0x4xxxx), you get seizure-inducing screen backlight flicker comparable to the issue report at https://gitlab.freedesktop.org/drm/intel/-/issues/7013.
I tried recompiling the i915 driver to increase the PWM frequency at boot time, but was unable to compile and replace that driver alone due to symbol version mismatches (and I didn't want to rebuild the whole kernel on an obsolete dual-core Ivy Bridge). So I tried changing the backlight frequency in the BIOS itself, which was OS-agnostic and didn't require editing Linux drivers. I began decompiling the UEFI firmware in Ghidra and tracing control flow across multiple undocumented labyrinthine EFI executables, finding that I had to modify a VBT file's backlight PWM frequency field to change the refresh rate. Sadly this only affected pure UEFI boot and not CSM mode, but disabling CSM causes Windows 7 (the OS I used when the laptop was new, and which I keep this laptop just to run) to show a black screen. And I got burnt out from reversing EFI, and broke a flash chip leg and two motherboard pads reflashing my BIOS (and barely managed to patch the BIOS chip circuit back together with bodge wire soldered to the chip's stub)... so I'm still stuck with 100Hz flickering...
100Hz flicker is terrible. It's amazing vendors still are so clueless.
I forgot to mention, I actually managed to write a program that would dynamically rewrite the period and pulse width registers to play music off the screen backlight, based off a conversion of the Monkey Island tunes from https://www.thanassis.space/monkeyisland.html. It almost worked... except that whenever I decreased the period (raised the pitch), there was a random chance the new period would be greater than the current phase, and so the display would hang at full or zero brightness nonstop (producing a gap in the sound) until the 16-bit counter running at 0.98 MHz (= 125/128) rolled over, rather than instantly setting the counter to zero and turning the display back on. I've recorded my "best effort" attempt at music, at https://www.youtube.com/watch?v=7qt0ssFk410 (every recording has different gaps when pitch increases).
Wonderful writeup BTW!
Yes, those who said that are long gone. Me, and the few that said it was doable (and did, moving those 5"1/4 floopies drive beyond the heads' limits), are here, watching the news...
https://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-spea... https://groups.google.com/g/comp.os.linux.advocacy/c/QslNrtx...
(note it doesn't actually require installing another distro - alsamixer was available in the base chromeos install)
Tbh I'm still pretty salty about it.
[1]: https://www.dell.com/community/Laptops-Wiki/How-Using-the-VL...
I only read the one thread on this, so I'm guessing a lot here, but it sounds like you could patch the <100hz frequency problem in hardware for like $0.50 with a high pass filter soldered in at the speaker?
That thread is a little hard to read, so I don't know if there really is a dc problem. That's a little harder to fix in the speaker cavity.
A high-pass filter in the DSP/driver software is free, sell a million Chromebooks and that's $500k of pure profit from cutting costs. Unless you account for warranty recalls due to buggy drivers, in which case a 0.1% failure rate is enough to make this a bad idea.
Not nice.
Just a matter of getting used to, I guess.
So while they often get overly-full of markup like these ones, the markup follows a pattern that's rarely broken, and it becomes very easy to follow after you've gotten through a few threads.
For both, it seems like I read messages in random order and then have to guess at the general gist. There's seems like no easy way to get an accurate timeline of things.
I think the problem is made worse when people forward (or retweet) as part of a conversation. There's often forwards of other email chains included as a reply with or without unique new messages being added.
Sometimes people are left off part of the CC chain for some messages, so there are gaps in the flow.
The problem is compounded when there are multiple email threads about the same thing, often because someone replied to an old version that turned into a new conversation. Or they read just the first sentence in the original email and replied about that in the newest follow-up in a 100 email chain.
---
As an off topic side note, text chat programs are the ultimate form of communication. It has the fewest flaws of all mediums. It's linear in a single timeline that everybody has (and has the history to). It's pretty hard to mess up the history of what happened or who said what.
I enjoy it when people get frustrated about text chat. It's almost always because they can't dominate the conversation by talking over people or "win by talking loudest" which makes them frustrated and uncomfortable.
I don't use Twitter so I don't know what it does, but if you look at the email, the oldest posts are quoted first, so you just read the message top to bottom like anything else.
And if that's too confusing, there are links to every message in the thread at the bottom.
If you're talking about the quoting, the ">" marks denote one level of quoting, so the more ">" marks in a line, the older the message. As long no unwashed heathen has top-posted their reply, then you can just read the message top to bottom in chronological order.
From top to bottom, like we did for centuries.
Replies at the top are the devil’s work. Or maybe Microsoft.
It talks about power and general speaking I would have thought that outside extreme cases most electronics just draw the amount of power they need but not more. Can a kernel determine this somehow?
The project I'm working now, and the last I was, we had in a 4x4 inch board more than 10 voltages (1.0v 1.1v 1.3v 1.6v 3.3v 4v 5v 6v and I do not know what more) , all generated by micro controller configured power supply circuits. Those 10 voltages had to follow a very specific sequence, failing to follow it, could in worst case, damage the whole board. Basic explanation: if circuit part B is powered before part A, power flows "backwards" to A, melting it.
In addition, an error in the configuration of the supply ASICs would also lead to too high voltages. That is, the output voltage was configured in one register.
I think something along the lines is going on here.
Electronic circuits will only let a certain amount of electrons flow. If the power supply has way more electrons "available" than necessary, that's no problem, you only encounter problems if the power supply can't keep up.
However, electronic circuits are built to run at a particular voltage. If the electrons "want" to move too much, they may jump across gaps in unintended ways and generally cause havoc.
So in short: A power supply can't damage electronics by providing too high current, but it can damage electronics by providing too high voltage.
I don't know if that's what's happening here, I haven't read about the actual bug, but that's a basic primer on how it's possible to damage electronics even though they only draw the amount of current they need. And software is often involved in setting the voltages which are being supplied to certain components.
At least that's a prevalent and very useful picture of how electricity works, and what's being taught in university courses. It's probably a good enough explanation to answer "why can too much power destroy electronics if electronics control how much current they draw".
From Wikipedia, sourced from The art of electronics.
Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant? If it turns out I (and Wikipedia, and all material I've seen on the topic) is wrong, I'd certainly love to know. I'm just interested in this stuff; I have only taken introductory courses at university and learned on a hobby basis, I haven't taken advanced courses.
And power is what destroys things, mostly, by over heating them and transforming them into a different shape that no longer functions as expected.
> Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant?
Not really, but consider when was this slow drift (~3 mm/s) of electrons ever of interest/topic in your education, instead of much faster changes in charge distribution on the surfaces of conductors caused by (or creating) electrical fields?
3 mm/s is extremely slow, you'd very much notice if any phenomenon you routinely worked with in EE courses was this slow.
In practice not respecting these timings is kinda like toggling your ceiling lights on/off repeatedly. I bet your parents used to tell you the house could be set on fire if you did that, but you did it anyway and nothing ever happened. I think it's unlikely somebody will actually be able to damage their panels with that bug. But hey I'm pulling this guess out of my ass so don't quote me on that. But that can result in the panel failing to turn on and giving you a black or flickering screen.
In fact, at least a few years ago when I looked at this, the Intel driver was very conservative regarding those numbers because a long time ago in a galaxy far away the VBT values for some laptop models were bogus, so as a result nearly everybody had timeouts longer than what they needed to. There's a chance that even with a bogus VBT you're waiting more than you should for your panel. But that doesn't really affect real people very much, it's only really a significant problem if you're testing Display code and doing thousands of modesets per minute. Unless you're getting black screens, of course.
Also spend some time reading product forums. Windows and MacOS have plenty of bugs...
Anyhow, a quick google search yields stuff like this: https://www.makeuseof.com/tag/fix-windows-10-screen-flashing...
I dunno what's up but the 5.19 kernel has had some pretty shoddy releases or major bugs getting through. I kind of think the video, audio, etc. drivers for these highly integrated SoCs are just getting way too complex and unwieldy for anyone to reason about or review.