..or zypper install, or emerge. For other tasks though, exact arguments might differ a bit:
1,024 karma · joined July 3, 2016
Problem is - LLMs pull answers from their behind, just like a lazy student on the exam. "Halucinations" is the word people use to describe this.
Those are extremely hard to spot - unless you happen to know the right answer already, at which point - why ask? And those are everywhere.
One example - recently there was quite a discussion about llm being able to understand (and answer) base16 (aka "hex") encoding on the fly, so I went on to try base64, gzipped base64, zstd-compressed base64, etc...
To my surprise, LLM got most of those encoding/compressions right, decoded/uncompressed the question, and answered it flawlessly.
But with few encodings, LLM detected base64 correctly, got compression algorithm correctly, and then... instead of decompressing, made up a completely different payload, and proceeded to answer that. Without any hint of anything sinister going.
We really need LLMs to reliably calculate and express confidence. Otherwise they will remain mere toys.
qcom,max-voltage-uv = <0x43e6d0>;
As for charge limiting... limit at 80% is an okay workaround (certainly better than no limit at all!), but it's far from perfect. Namely, with this approach, charge controller chip doesn't know cut-off is coming, and will shove several amperes into the battery until last second, thus overshooting safe voltage level. This wears the battery (less so than with no limit, but still more than necessary).
Battery charging limiting should be done by voltage: this way, controller chip knows where to stop, so it makes soft taper-off at the end of charge cycle, by gradually nudging current down to stay within voltage envelope.
Charging profile could be observed from a rooted adb console:
grep NOW <$(find /sys/devices/platform \
| grep battery/uevent$ | head -1)
I always give out myname+tag@... to places that ask for email, and have an incoming message rule that puts bare myname@ straight into spam folder.
So far, the only messages to bare address were service updates from my email provider itself.
Not quite. If server has "command=rsync ..." in ~/.ssh/authorized_keys file, for some ssh key (to allow rsync access, but deny shell access), this vulnerability will allow attacker in possession of that ssh key to go around that restriction, and get shell nonetheless.
People living in "bad neighborhoods" have to spend more energy and money on locks, fences, security cameras, self-policing as to not go out alone after dark, etc.
Problem is, Internet (and international phone system, to a lesser degree) makes everything so much closer, that scammers from half-way around the globe are "local" for all intents as purposes. Thus, online, every neighborhood is a "bad neighborhood".
I mean, audience of this site should be better-then-average fit for message of:
- Found a problem with crowd-sourced/open-source piece? Don't complain. Make a quality contribution where you can. Otherwise - see if there is a bug report already, maybe submit one if there is none. On wikipedia, that's via "Talk" section.
Switching it, is a fair amount of pain, as you can no longer run binaries from stock under your new mipsel FW.
https://askubuntu.com/q/150066#998435
However, both Xephyr/Xnest and "xrandr --setmonitor" create separate non-overlapping screen(s), which means sharing part of a window (say, browser sans chrome [1]) can't be done here, but is possible with OP's tool.
[1] EDIT: "chrome", as in - parts of browser's window other than webpage itself: tabs, URL bar, bookmarks, etc...
Yes. Assuming signal strengths for both are comparable. Say, within 20 dB of each other.
> (possibly garbled if carrier wave was off)
Nah. If both stations have sufficient energy fall into receiver's bandwidth window (IF filter for analog receiver), no garbling. If one of stations has carrier sufficiently off to fall entirely outside IF, only other will be audible.
You are probably thinking about SSB, where two stations with carrier offset indeed produce weird sounding interference.
Rarely used, yet pretty much universally understood.
E.g., I don't have xdg on one of my systems, so "default browser" is not a meaningful concept there. Still, the only browser I have, keeps showing me the sad-face "Firefox is not your default" prompt.
In my personal experience, obtuse monitor's firmware is often to blame.
Using a switch with one extra input port, where all data pins are connected to ground (via series resistors), and switching to that port for a brief moment, before switching again to the real intended input, usually helps some.
Obscure Chinese brands made such android phones for few more years.
All Google Pixels (2016 and later), and virtually any android phone made after circa 2018 are safe from naive bootloader attack: user data is encrypted, plus you have to "OEM unlock" to even get the recovery to run.
Mozilla has been repeatedly resetting "Always check if Firefox is your default browser" option to "yes" with upgrades. I don't see why "private-attribution submission enabled" wouldn't be reset in future in the same way.
Plenty fast enough for a floppy bit-stream, of course.
id:5:initdefault:
x1:5:respawn:/etc/rc-x11
ff:5:respawn:/etc/rc-firefox
Specifically, most common Li-ion fires start when overcharged (especially with high current and in cold), and from short-circuits (e.g. when pierced). But only have a very small chance of spontaneously igniting from just disassembly alone [1]. Still non-zero chance, don't open them!
Primary/metal lithium batteries, on the other hand, are much more likely to burst into flames when opened. Notably, lithium-iron disulfide (AA/AAA "alkaline replacement") cells are notorious to do that just from air exposure, even if one is very careful to not short/pierce anything.
Thinking being that you'd compare outputs of the two, and under assumption of the results being statistically independent from each other and of similar quality, say 1% difference between the two in said comparison, would suggest ~ 0.5% error rate from "ground truth".
I mean - one can build a 16-fiber, CWDM16 monstrosity that would transport an 8x 128GT/s PCIe using mere 8 Gbit/s per channel - all of which is technology that was "groundbreaking" circa 2005.
Even a 60kW unit [0] looks to be pretty large and listed as "call us for price".
[0] https://www.heliox-energy.com/us-products/60-kw-dc-charger
Specifically, supposed inevitability of BSL->OSI transition is dubious. If anything, there are examples of the opposite - terraform itself being prime one.
There are a fair few sites, where most all content is perfectly readable without JS, except things like "1920x1080@60Hz" are displayed as literal "[email protected]" text.
Was it one of those cheap tablets/netbooks that shipped with fully-64-bit-capable CPU (Atom Z3735F) but with dreaded 32-bit-only UEFI firmware?
GRUB can boot NetBSD there, although it's a bit of a hassle to set up.
> I just wish DNS would follow suit
Technically, this is super-easy. Just select an anycast IP that would always go user's ISP's DNS - just like any other anycast DNS front-end IPs (1.1.1.1, 8.8.8.8, et al.) go to a nearest PoP of CF/google/etc.
Just to reiterate - there is no reason why an anycast IP has to be held by the same entity globally. "Federated" anycast IP, where each user reaches their local ISP would work just as well. Then make it an internet standard. Once that standard gets implemented in end-devices, there no longer any need to negotiate DNS server IP, same one works across different ISPs, always going to the nearest one. Still complex, but all the complexity is now on ISP side.
Practically, this is overwhelmingly unlikely to happen. There is a significant momentum among internet users to actively distrust their ISP, and mechanisms to cloak DNS traffic from user's ISP (DoH, DoT, ...) are somewhat popular, based on that exact motivation, in part.
> advocate for yoinking the v4 space that e.g. the DoD, Daimler, Ford or Apple doesn’t use
Isn't it a travesty that owning a sizeable chunk of limited-supply IP addresses doesn't cost much, but exact same number of (nearly-)unlimited-supply domains does cost dearly per-domain to own?
We don't hear horror stories how somebody is hoarding 16 millions .com domains, right? Too expensive to do so.
On the other hand, as an ISP, you can pull some of those addresses for your CGNAT's external address pool. Your customers' gear will never see those. Server side will, though. But then, troubleshooting cloud/server front-end to reliably let those through sounds like a more doable chore?
That percentage should be well above 99% for a popular website operator to even consider going IPv6-only; needless to say, in most markets, this figure is way lower, with no clear path to improving.
Ikea, for example, ships tons of "smart lightbulbs" with silabs/EFR32.