[HN Gopher] Intel Laptop Users Should Avoid Linux 5.19.12 to Avo...
___________________________________________________________________
Intel Laptop Users Should Avoid Linux 5.19.12 to Avoid Damaging the
Display
Author : electricant
Score : 324 points
Date : 2022-10-05 08:57 UTC (14 hours ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| thrillgore wrote:
| 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.
| bitL wrote:
| There is some weird bug on Intel NUC11TNK that makes displays at
| 5k2k@60/TB4 show overlapping regions with changing "soft"
| boundaries (like when overclocking CRT monitors that can't handle
| the resolution) and that bug is present on all 5.5-5.19 kernels
| I've tested. Maybe it's related to this bug?
| capableweb wrote:
| _Intel GPU_ Users
|
| Judging 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/
| stop50 wrote:
| I had this error. 13 fixed it.
| ronjouch wrote:
| > _" I had this error."_
|
| 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?
| stop50 wrote:
| damaged maybe, but i have an framework were it happened, so
| the maximum potential damage was lower.
| [deleted]
| makeworld wrote:
| My display was not damaged. Switched back to an older
| kernel version and it was fine.
| snapplebobapple wrote:
| 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.
| CameronNemo wrote:
| 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.
| nemetroid wrote:
| Using a live image for the once-in-a-decade event that a
| kernel doesn't boot properly isn't a huge hassle.
| craftkiller wrote:
| > 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.
| snapplebobapple wrote:
| 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.
| dhruvmittal wrote:
| 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.
| pooper wrote:
| Thank you, Fedora maintainers. I think I didn't even see
| 5.19.12. I think I got skipped directly to 13.
|
| > 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
| jonp888 wrote:
| What does he mean by:
|
| > >> 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?
| cesarb wrote:
| 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.
| bentcorner wrote:
| 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.
|
| Here's an article about the machine learning bits:
| https://lwn.net/Articles/764647/
| forgotpwd16 wrote:
| Intel drivers have been filled with issues on 5.x.x, from
| frequent hungs to this.
| 0x38B wrote:
| I guess I got hit by this?
|
| 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.
| hyperpl wrote:
| 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...
| woliveirajr wrote:
| 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...
| bewo001 wrote:
| 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.
| asddubs wrote:
| and way back when, you could just tell a hard drive to
| essentially destroy itself
| anthk wrote:
| 30-70h, 50-168v. Correct settings for my CRT back in the day.
| [deleted]
| Waterluvian wrote:
| How does one read this classic style email chain? Do people use
| an application? Or do they just become experts at reading it
| correctly?
| f1shy wrote:
| 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. :)
|
| Just a matter of getting used to, I guess.
| nobleach wrote:
| 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)
| anthk wrote:
| I still use Mutt with mbsync (isync it's the package name)
| and msmtp. Heaven.
| tmtvl wrote:
| I use isync with maildir-utils (aka mu) through Emacs'
| mu4e. With HTML mail disabled it is wonderful.
| anthk wrote:
| I use Lynx for HTML mail, it dumps the text and it shows
| up under mutt.
| RulerOf wrote:
| 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.
| bgro wrote:
| 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.
| bityard wrote:
| > 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.
| BeetleB wrote:
| Scroll down and you'll see the thread - navigate the tree as
| you wish.
| rtkwe wrote:
| 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.
| layer8 wrote:
| 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.
| bityard wrote:
| 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.
| duxup wrote:
| 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?
| mort96 wrote:
| 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.
| megous wrote:
| 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.
| mort96 wrote:
| 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".
| megous wrote:
| 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)
| mort96 wrote:
| > 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.
| megous wrote:
| 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.
| dyingkneepad wrote:
| 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.
| f1shy wrote:
| 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.
| duxup wrote:
| Man no protections at all... yikes.
| megous wrote:
| Sounds like any smartphone.
| pipeline_peak wrote:
| Year of the Linux desktop, everybody should use Linux....just not
| one of those rare iterations where it umm permanently screws up
| your display.
| Mikeb85 wrote:
| There's been bugs like this in Windows and MacOS too. But
| they'll just blame the hardware vendor and it'll get
| warrantied...
|
| 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...
| deeblering4 wrote:
| 2022 the year if linux on the... oh nevermind
| osmarks wrote:
| Does it actually "damage" the display or just make it not work
| while 5.19.12 is loaded?
| dmm wrote:
| 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.
|
| [0] https://lore.kernel.org/all/YzwooNdMECzuI5+h@intel.com/
| Sphax wrote:
| 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.
| dooglius wrote:
| From TFA:
|
| > 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.
| GTP wrote:
| 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.
| capableweb wrote:
| "Potentially" and "may" harm the actual display.
|
| > 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/
| y04nn wrote:
| 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.
| mrmckizzle wrote:
| https://xkcd.com/1328/
| KerrickStaley wrote:
| 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/
| yjftsjthsd-h wrote:
| Alternatively, if you use linux-lts then you never got this in
| the first place (which is an _excellent_ example of why
| https://wiki.archlinux.org/title/System_maintenance#Install_...
| suggests it).
| throitallaway wrote:
| 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.
| ho_schi wrote:
| 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?
| sirwitti wrote:
| Me: Furiously typing uname -a into terminal.
|
| Me: "Crap, I got 5.19 running"
|
| Also me: "Calm down, it's only 5.19.13"
|
| Rollercoaster of emotions :)
| prmoustache wrote:
| 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.
| asddubs wrote:
| if a laptop screen gets damaged in the woods, and no one can
| tell the difference, is it even damaged?
| capitainenemo wrote:
| 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.
|
| 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)
| qwertox wrote:
| > 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.
|
| Not nice.
| MichaelCollins wrote:
| 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.
|
| Tbh I'm still pretty salty about it.
| jchw wrote:
| 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]
|
| [1]: https://www.dell.com/community/Laptops-Wiki/How-Using-
| the-VL...
| xani_ wrote:
| Sooo they put too weak drivers/too strong amplifier and are
| trying to blame users on it ?
| blarghyblarg wrote:
| 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.
| squarefoot wrote:
| 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: EUR0.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.
| LeifCarrotson wrote:
| 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.
| dTal wrote:
| 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.
| jchw wrote:
| 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.
| dagmx wrote:
| 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.
| gambiting wrote:
| 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.
| bbarnett wrote:
| 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.
|
| 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.
| GekkePrutser wrote:
| It's very common in a range of hardware throughout the years:
| https://en.m.wikipedia.org/wiki/Killer_poke
|
| 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.
| f1shy wrote:
| 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).
| amiga-workbench wrote:
| 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.
| flyinghamster wrote:
| 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.
| dredmorbius wrote:
| 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._
|
| <https://arachnoid.com/modelines/>
|
| My understanding is that monitors and/or graphics cards/drivers
| would reject potentially harmful configurations.
| nyanpasu64 wrote:
| 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 GroovyArcade arcade CRT
| distribution, but it's not upstreamed, it doesn't currently
| work on my GPU, and I never did get around to porting it to
| my older RX 570, finding the correct modeline, and testing
| that it works. Turns out modern games like Stray aren't
| optimized for interlaced displays (vsync caused horrendous
| input lag) or 480-line-tall screens (HUD elements and jump
| prompts are too small to see), who would've known! I do think
| Celeste would work fairly well in 240p mode, but I haven't
| gotten around to testing that either (in either amdgpu.dc=0
| or porting my patch).
|
| - Compensating for CRT television overscan (since modern
| games like Stray draw HUD elements like jump prompts right on
| the edge of the screen) is a nightmare. On amdgpu, xrandr's
| underscan option can only take off <=128 pixels evenly split
| between the left and right, or the top and bottom. Worse yet,
| the display controller outputs eg. 1340x460 of non-black
| image, by downscaling (in hardware?) a _second_ time from the
| 1440x480 framebuffer downscaled in software from 1280x960,
| creating unnecessary vertical blur.
|
| - - Since I don't know how to perform both downscaling steps
| in hardware with unmodified amdgpu drivers (like a non-
| square-pixel VSR), I opted to perform both downscaling steps
| in software, by writing a shell script to kill plasmashell
| and open a full-screen mpv showing a black .png file on a
| 1440x1030 framebuffer, then use KWin rules to overlay a
| 1280x960 borderless window of Stray at a precise position
| over mpv (with black mpv borders on all 4 sides), use xrandr
| to downscale 1440x1030 to 1440x480i, then kill mpv once Stray
| exits. It's a terrible setup and I wish there was a better
| way. But CRTs and overscan is dead, interlacing is dead,
| 640x480 is dead, and only a fool or experimenter (or someone
| with complex-trauma depression seeking comfort in nostalgia
| and cats) would try hooking up modern computers and games to
| triply-dead CRT SDTVs and expecting them to work.
| dbttdft wrote:
| 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.
|
| It's done in the monitor.
| blarghyblarg wrote:
| yep, 13 year old me had one of these around the first time
| I was using X. Way back when you had to write your config
| files by hand.
|
| One little oopsie, and that monitor had a line through it
| for the rest of its life.
| formerly_proven wrote:
| 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.
| mirekrusin wrote:
| Yes, it was real, the same with moving hard drive head outside
| of the disk so it falls off.
| darkr wrote:
| No idea if there was a virus doing this, but it was definitely
| possible to permanently damage at least some CRTs by setting
| refresh rate too high
| capableweb wrote:
| > reminds me of a myth from 20+ years ago
|
| > 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.
| omnibrain wrote:
| 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.
| gambiting wrote:
| 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.
| Cthulhu_ wrote:
| What I'm reading is that Mew was "handed out" in magazines
| and events, although this article does mention a method of
| getting it, probably involves RNG manipulation and bit
| flippery: https://www.ign.com/wikis/pokemon-red-blue-
| yellow-version/Me...
| gambiting wrote:
| 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.
| capableweb wrote:
| Yeah, I'm in the same camp :) Heard/read about it, never
| seen it myself.
|
| However, I have seen people having Mew back when I played
| some Gameboy myself, that one is _not_ a myth :)
| radarsat1 wrote:
| > 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.
| capableweb wrote:
| I was not aware of this, so thank you for clarifying it for
| me.
| protoman3000 wrote:
| 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?
| ablob wrote:
| 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.
| MisterTea wrote:
| > 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.)
| pas wrote:
| 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.
| protoman3000 wrote:
| > built on a throne of lies, shit, pain, and weapons-grade
| idiocy
|
| Obligatory xkcd post
|
| https://xkcd.com/2030/
| uwagar wrote:
| kortex wrote:
| 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?
|
| mRNA vaccines just cut out the middle man^w bug.
| uwagar wrote:
| 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.
| kortex wrote:
| 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...)
| uwagar wrote:
| 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.
| jtc331 wrote:
| 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.)
| hoseja wrote:
| 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.
| uwagar wrote:
| exactly and those are the same software engineers
| naysaying the voting system.
| rayiner wrote:
| Are you allowed to make that joke anymore in 2022?
| [deleted]
| marcinzm wrote:
| 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.
| pennaMan wrote:
| I would like to know where you got the hat you are pulling
| those numbers out of
| marcinzm wrote:
| 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.
| dbttdft wrote:
| They're still broken. Not an argument.
| tacker2000 wrote:
| Who defines broken? Thats a feature, not a bug.
| nixpulvis wrote:
| See that's a "feature" though. Now you need to buy
| another device.
|
| There's not as large of an incentive for product
| durability and repairability today as there was or should
| be.
| sicp-enjoyer wrote:
| > getting into a car accident is north of 1%
|
| 1% of what?
| MonkeyClub wrote:
| Of the trips you'll have.
|
| Or "one in a hundred".
|
| It means that in out of a hundred trips, it's pretty
| certain one will involve an accident.
| 8jef wrote:
| 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.
| MonkeyClub wrote:
| Solid advice, which has gotten me out of more than one
| right spot.
|
| 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 :)
| kleinsch wrote:
| Which is completely fabricated. Quick Google search has
| 1/366 for every 1000 miles you drive.
|
| https://ehlinelaw.com/blog/odds-of-being-injured-car-
| acciden...
| z2h-a6n wrote:
| 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.
| alwa wrote:
| 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.
|
| [1] https://cdan.nhtsa.gov/tsftables/National%20Statistic
| s.pdf
| z2h-a6n wrote:
| > 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.
|
| [0] https://cdan.nhtsa.gov/tsftables/National%20Statistic
| s.pdf, other formats and more data available here:
| https://cdan.nhtsa.gov/tsftables/tsfar.htm
| MonkeyClub wrote:
| > That's partially because MonkeyClub didn't do the math
| correctly.
|
| Or at all, since it's just how possibilities work. I
| wasn't calculating the annual possibility.
| MonkeyClub wrote:
| > Are you sure?
|
| Yep, totally.
|
| Remember the counter resets with every ride: it's the
| first of the hundred, with 1% possibility of (any) car
| accident.
| hedora wrote:
| Assuming each collision involves two parties, 1 in 43
| means about 1 in 21 people are driving during a collision
| each year.
|
| That seems about right. It's one (probably minor) car
| accident per driver every 20 years.
| MonkeyClub wrote:
| What is more, these are all things that would befall _you_,
| rather than the manufacturer, so as GP said, it's A-OK.
| FeepingCreature wrote:
| 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.
| marcinzm wrote:
| 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).
| jonhohle wrote:
| 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?
|
| Narrator : A major one.
| com2kid wrote:
| Meanwhile in reality, cars undergo multiple recalls every
| year to fix a myriad of issues.
|
| Reputational damage is so high from consumer deaths now
| days, the balance sheet comes out in favor of fixing
| issues.
| jack_pp wrote:
| replace cars with drugs and it's the same old story
| toast0 wrote:
| Cost of settlements went way up too.
| therealjumbo wrote:
| Do you have inside knowledge of how the recalls are done?
| It's a lot more complicated than that:
| https://www.newyorker.com/magazine/2015/05/04/the-
| engineers-...
|
| 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.
| MonkeyClub wrote:
| The first rule of recalls is we don't talk about recalls.
| nfriedly wrote:
| (For folks who didn't catch the reference, this quote is
| from the movie Fight Club -
| https://www.youtube.com/watch?v=IA2EBWFCULg )
| hedora wrote:
| And that scene is almost certainly referring to Ralph
| Nader's best-selling book, Unsafe at any Speed:
|
| https://en.m.wikipedia.org/wiki/Unsafe_at_Any_Speed
| whoisthemachine wrote:
| 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.
| scarface74 wrote:
| 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.
| throwawaylinux wrote:
| 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.
| GTP wrote:
| 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.
| throwawaylinux wrote:
| 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.
| mojzu wrote:
| 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
| throwawaylinux wrote:
| > 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?
| mojzu wrote:
| > Hardware bugs can cause hardware damage.
|
| 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
| throwawaylinux wrote:
| > if software can damage the hardware it's running on
| then that should be seen as a fault/bug
|
| It is.
|
| And I'm still waiting to hear how that absolutely fail-
| safe bridge is going to work...
| salawat wrote:
| Easy. You set your safety factor in excess of expected
| everyday load.
|
| The fact is, Engineering has become the Art of specifying
| the worst (read: cheapest) implementation one can get
| away with.
| mdtusz wrote:
| Building in a high safety factor is not a failsafe. A
| failsafe requires that in the event of failure, the
| system goes into a safe state.
| iso1631 wrote:
| If you're not practicing defense in depth, especially for
| safety critical systems, that is a big problem.
| throwawaylinux wrote:
| I didn't say you're not.
|
| It can involve software though.
| chuckSu wrote:
| capableweb wrote:
| > 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.
| collegeburner wrote:
| facts, if there was a regulator some hackernews would be on
| here complaining about how it's "not hackable" or whatever.
| pas wrote:
| 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.)
| bsenftner wrote:
| 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.
| foobarbecue wrote:
| Thank you for introducing me to the phrase "immanetize the
| eschaton."
| FoeNyx wrote:
| btw, seems there's a small typo (see wikipedia article
| "Immanentize the eschaton", from adjective "immanent")
| foobarian wrote:
| Sounds like in this case they are monetizing it
| f1shy wrote:
| Sooo much truth has been spoken!
|
| The quality of consumer goods is decaying everyday. It is all
| about the last millionth of a cent to be spared.
|
| Just nobody cares.
| ajross wrote:
| 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.
| tristor wrote:
| > Would you be willing to pay, say, $4000 for a laptop
| where all the quality engineering was top notch?
|
| 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.
| pipeline_peak wrote:
| Didn't they face a class action lawsuit due to keyboard
| defects a couple year back?
| pclmulqdq wrote:
| Thinkpads are still decent, and some other manufacturers
| do okay too.
| xani_ wrote:
| They've been sold to Lenovo, it's just a matter of time
| pipeline_peak wrote:
| It's been 17 years, they aren't IBM quality, but they're
| still very sturdy.
| RunSet wrote:
| > Thinkpads are still decent
|
| The ones from 2011 are.
| tristor wrote:
| 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.
| mindslight wrote:
| 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).
| tmtvl wrote:
| _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.
| xani_ wrote:
| 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.
| rkagerer wrote:
| _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).
| mindslight wrote:
| 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)
| ajross wrote:
| > 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".
| mindslight wrote:
| 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.
| ajross wrote:
| Inflation has been at historic lows over the past several
| decades. I don't see how that follows, sorry.
| mindslight wrote:
| 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.
| ajross wrote:
| 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.
| mindslight wrote:
| 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.
| f1shy wrote:
| > 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.
| [deleted]
| ajsnigrutin wrote:
| > 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?
| hulitu wrote:
| Cars are mostly immune to such things. Mostly due to previous
| experience which has showed that SW alone will not protect
| hardware.
| ajsnigrutin wrote:
| So, what exactly stops the car when it gets too hot? Or
| when there's no oil? (except the eventual engine failure)
| hulitu wrote:
| 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.
| ajsnigrutin wrote:
| 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).
| tremon wrote:
| The driver.
| xani_ wrote:
| 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
| ajsnigrutin wrote:
| 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.
| xattt wrote:
| 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.
| PragmaticPulp wrote:
| > 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.
| megous wrote:
| Rising brightness too high has nothing to do with LCD
| controller.
| gambiting wrote:
| 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.
| xani_ wrote:
| 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 ?
|
| edit: https://www.diodes.com/assets/Datasheets/AP3019A.pdf
| example of simple one. The value of the single resistor
| decides the max current.
| esperent wrote:
| Well that's fair for the switch. It's a locked down platform
| and sold as such. If you hack, you're doing so at your own
| risk.
|
| But is that really the case for these laptops? Seems kind of
| negligent from the manufacturer if so.
| Gordonjcp wrote:
| 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.
| xani_ wrote:
| First example: LED used as flash in phones.
|
| 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...
| megous wrote:
| 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.
| nyanpasu64 wrote:
| 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...
| dbttdft wrote:
| Nice trek.
|
| 100Hz flicker is terrible. It's amazing vendors still are so
| clueless.
| nyanpasu64 wrote:
| 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).
| csdvrx wrote:
| That's the kind of things I'd try lol
|
| Wonderful writeup BTW!
| pjmlp wrote:
| So, 30 years later and the advice regarding bad X Windows
| configurations still apply.
| akho wrote:
| This is not X, failure is in early stages of boot.
| kjoedion wrote:
| ranguna wrote:
| 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.
| grnmamba wrote:
| Because macos doesn't have hardware destroying bugs?
|
| 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-...
| nyanpasu64 wrote:
| I have a friend who tried installing Ventura Beta on a Mac,
| and it overheated and cooked two of her SD cards.
| ben-schaaf wrote:
| macOS Monterey shipped with a firmware that could (soft) brick
| T2-based devices. You needed a 2nd mac to recover it:
| https://www.macrumors.com/2022/03/17/macos-monterey-
| bricking....
|
| 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?
| amelius wrote:
| > If you want Unix in a competent OS get a MacBook.
|
| If you don't mind the ads that are coming your way ...
|
| https://news.ycombinator.com/item?id=33069696
| GekkePrutser wrote:
| I have to disagree here.
|
| 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.
| CoolCold wrote:
| > Of course Linux is great for servers too but why stop
| there?
|
| UNIX philosophy - do one thing and do it right?:)
| GekkePrutser wrote:
| 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).
| _-_-__-_-_- wrote:
| I have to agree with you.
|
| 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).
| PcChip wrote:
| If you think gnome is good, wait till you see KDE
| RunSet wrote:
| Yeah after they see KDE they'll _really_ think gnome is
| good.
| doubled112 wrote:
| 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?
| GekkePrutser wrote:
| 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.
|
| Of course YMMV and that is why we have Linux <3
| api wrote:
| 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.
| jvermillard wrote:
| Apple hardware which can be destroyed by software, the M1
| speakers: https://github.com/AsahiLinux/docs/wiki/Feature-
| Support#spea...
| hulitu wrote:
| It is not a hardware bug. Is a feature. The spec is to make
| it cheap and implement SW protection.
| megous wrote:
| 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.
| qbasic_forever wrote:
| 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.
| yc-kraln wrote:
| Surprised no one has mentioned the Therac-25 debacle:
| https://en.wikipedia.org/wiki/Therac-25
|
| This is a lesson we've learned many times over by now: Software
| limits alone are insufficient.
| jiripospisil wrote:
| It looks like the issue was caused by a wrong merge, not by a
| particular commit.
|
| https://lore.kernel.org/all/YzsfrkJcwqKOO+E%2F@intel.com/
___________________________________________________________________
(page generated 2022-10-05 23:02 UTC)