This is a false equivalence. If the farmer had some processing step which had to be done by hand, having mountains of unprocessed crops instead of a small pile doesn’t improve their throughput.
Can a carrier ever surreptitiously lock an unlocked phone, or is it only on phones financed or purchased through the carrier? For example, if I bought an unlocked phone and attached it to my Verizon plan, could Verizon lock it?
Historically phone locking was done at the modem level via an NCK code - if a phone is supplied by a carrier the modem will come pre-locked and will only be unlocked upon entry of an NCK code which the carrier has the secret key to generate (hash(secret+imei)). With this system if the phone is not locked to begin with I am not aware of any way to toggle this mechanism remotely.
With smartphones however, the game has changed. Apple for example no longer locks their modems at all and instead rely on a software-level check as part of the "activation" process (at first boot where it also gets its client certificates/etc to talk to Apple services) - said activation policy can be changed remotely, and Apple are very cagey about their full capabilities. I have read of some vendors selling iPhones that would be unlocked at first but lock themselves to the first carrier they see.
It's unlikely Apple would ever enforce or change an activation policy on a phone purchased directly from them, so you should be safe. But technically, it's up to the phone manufacturer. I am not sure what the Android situation is in comparison.
> I have read of some vendors selling iPhones that would be unlocked at first but lock themselves to the first carrier they see.
Yeah, there's no official documentation, but that's how the Best Buy ones are. I've seen it called "US Reseller Flex" and "SIM Out" policies. There are some shady websites that have a GSX login that will report the policy name, anti theft lock status, and service history if you put in the IMEI. The intent is to prevent having to keep separate stocks of identical hardware pre-assigned to each carrier you sell for.
IIRC, Best Buy isn't supposed to sell you a phone without at least adding it to an existing carrier account. They act as an agent of the carrier, not selling the phone standalone like Apple does. It's possible that someone could then resell it while in-box as a scam, but that's not what Apple/carrier intended.
If you don't have the key, how? I browsed XDA forums a lot in the past to try and ulock and old phone, and there didn't seem to be any way. All of the guides ended up being nonsense.
Someone above said you need the NCK code which is generated from a secret only the carrier has - how does having root get around this?
The lock is basically implemented as an "is the SIM's carrier on a whitelist" check, which can obviously be patched out or modified arbitrarily once you have full access to the firmware which root does. It's important to remember that the lock is entirely on the phone's side, to prevent it from connecting to any other carrier than the one it's locked to. A carrier can implement an "official" unlocking method essentially as an app that runs on the phone to validate the unlock code, but that is no obstacle to root.
If you jailbreak an iPhone, the lock is also easily removable in the same manner.
If we're talking NCKs it means the modem is locked, so you need a modem/baseband-level exploit. Root helps you talk to said modem but doesn't directly allow you to modify its firmware without some other exploit.
Not really familiar with other platforms, but on Mediatek platforms the modem firmware is just loaded from the filesystem --- which you have full access to as root.
Can you recommend any good guides to read more about this? I was trying to unlock a Boost phone a few years ago, which was perfectly good and compact but unusable outside of Boost. I no longer have the need but still have the curiosity.
> get people to independently create an artifact representing their priorities
Except trying to get most stakeholders to be alone with their thoughts to be condensed upon a blank document before them causes them to violently open outlook and schedule a meeting with everyone instead.
Pre-alignment-meeting alignment! A good thing to explicitly exclude.
Definitely need a healthy culture when asking for honesty and openness about what people think, including they see as unclear, unknown, inconsistent with others, and/or outside the existing box.
Because when they're not blinding everyone they work really, really, really, well (to the safety and convenience of the users) and so anyone who tries to "do anything" will be caught trying to mediate between the two groups of screeching idiots and this is a fairly mundane issue so the upside is pretty small. Nobody's career takes off because they brokered a revision of headlight rules.
The whole situation reeks of the kind of thing that'll be mostly solved with technological progress over time (one of the german makes already has something that exempts a car in front of you from having the LEDs focused on it, I assume development is ongoing) and it really just remains to be seen if we get some law (which probably won't be decisive since this is a fairly subjective issue with no "obvious" answer) along the way.
It’s not an issue with limitations of current technology. In some cases it’s just greed and laziness. I’ve had two vehicles that have the ability to be more friendly to other drivers, but that functionality is only enabled outside of the U.S. (matrix headlights or the equivalent).
GM vehicles had been notorious for having poorly adjusted headlights from the factory. The fact that Xenon systems seemed to always come with auto leveling and LED often does not is crazy.
High beams also work really really well when they're not blinding everyone. We managed that tradeoff by putting them on a toggle switch and teaching drivers to use them only when appropriate, rather than making them the only headlights the car is equipped with.
Not blinding other traffic on the road is a safety critical concern. A few seconds of being blinded is enough to cause a serious accident. This means that any technology that is intended to legitimate brighter headlights by masking other traffic needs to have something like a ≥99% efficacy. (Exact number doesn't really matter.)
> one of the german makes already has something that exempts a car in front of you
… and this technology does not have that level of efficacy, and neither do any of the others.
> The whole situation reeks of the kind of thing that'll be mostly solved with technological progress over time
Stuffing ever more controllers, cameras, and sensors in there to focus and aim LEDs just sounds like the most over-engineered solution to this problem imaginable. The dealers are just going to love all the income from repairing all these points of failure. All for what gain? Yes, yes, “safety,” I know. Consider, though, that as drivers feel more comfortable on the road with their white dwarves, they are likely going to drive faster and more recklessly. It’s the same as American Football helmets switching away from leather—the hits get harder.
>Stuffing ever more controllers, cameras, and sensors in there to focus and aim LEDs
I agree it's all overcomplicated bullshit in order to polish another percent or two out of the turd but the overcomplicated bullshit is already in the field so why not write software that uses it a little better?
>Consider, though, that as drivers feel more comfortable on the road with their white dwarves, they are likely going to drive faster and more recklessly. It’s the same as American Football helmets switching away from leather—the hits get harder.
Faster when adjusted for equivalent safety sounds like a good thing to me.
The issue is not the technology or the absolute brightness of a bulb.
The problem is that replacement bulbs have a different beam pattern and the headlight mount needs to be adjusted. That's it.
In the vast majority of cases, car headlights are blinding simply because they're aimed too high. On most(all?) vehichles there is an adjustment mechanism under the hood. Problem is it takes special tools and procedures that nobody knows or cares about.
As a sibling commenter said, we've managed to survive for the better part of a century with toggleable high beams. This isn't a complicated problem.
>In the vast majority of cases, car headlights are blinding simply because they're aimed too high.
No, it's almost always true that the light output is far, far too bright. Adjusting headlight aim is good and should be done, but it does not solve the problem, and notably is not effective in road conditions other than smooth (bumps cause lights to go up and down), flat (inclines cause the harmful light level to change), and dry (water or ice on the ground cause reflective glare).
I couldn’t fathom running lawn equipment in the morning. If I try to mow in the morning my clippings are just globs of wet spinach thanks to all the dew. I get much better performance out of the equipment if I wait until the afternoon once everything has had a chance to dry out.
Surprised they missed follow! It’s a bit odd to use, but once you get used to it it’s better than tail in many circumstances IMO. `less +F` starts less following stdin or whatever file argument you’ve provided. <C-c> breaks following, allowing you to search around a business-as-usual `less` session. Hitting `F` (that’s uppercase) starts following again. Yes, you can just start following within a session with `F` too if you forgot to add +F to the `less` invocation.
If you're following a pipe (such as `kubectl logs | less +F`), <C-c> is sent to all processes in a pipeline, so it stops less from following and it stops the other process entirely. Then you can't start following again with F, or load more data in with G.
Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.
Funnily enough, it literally tells you right there on the bottom line: “Waiting for data... (^X or interrupt to abort)”. No shame in not noticing, just another case of blindness to long-familliar messages I guess.
By the shell or by the kernel’s terminal discipline or by the terminal emulator? AFAIU the shell is basically out of the picture while `less` is running.
> I can <C-z> while less is running to background that process using the shell, so the shell is clearly not completely gone.
The shell isn’t gone, but it isn’t active either from what I understand. The function of converting the user’s typing ^Z on a terminal (or a ^Z arriving on the master end of a pseudoterminal) into a SIGTSTP signal to the terminal’s foreground process group is[1] a built-in function of the kernel, much like for ^C and SIGINT or ^\ and SIGQUIT. (The use of ^Z resp. ^C or ^\ specifically, as well as the function being active at all, is configurable via a TTY ioctl wrapped by termios wrapped in turn by `stty susp` resp. `stty intr` or `stty quit`.) So is the default signal action of stopping (i.e. suspending) the process in response to that signal. The shell just sees its waitpid() syscall return and handles the possibility of that having happened due to the process stopping rather than dying (by updating its job bookkeeping, making itself the foreground process group again, and reëntering the REPL).
I am not saying that doing job control by filtering the child’s input would be a bad design in the abstract, and it is how terminal multiplexers work for instance. I admit the idea of kernel-side support for shell job control is pretty silly, it’s just how it’s traditionally done in a Unix system.
Whew! Advanced Unix system programming level stuff. I've dabbled a bit in that field, in C, on Unix, some older versions on PCs. It was fun. Any recommendation for a tutorial style book or site or blog on the subject, other than man pages and the Kerrisk book (TLPI, which is more of a reference), for Linux?
With `tail` you can press enter a few times to put some empty lines after the last line. This is useful e.g. when you trigger a function multiple times and want to easily see line groups from each attempt. It's the only reason I still use `tail` for following when `less` is available.
A visual mark would be nice, agreed. I haven't tried it, but I wonder if you could approximate it with the bookmarking feature that less(1) does have. It wouldn't be visible, but it would scroll to a consistent mark.
I usually use tail when I need to do some ad-hoc log following.
Having to set bookmarks and remember them is a PITA I can usually do without. If I'm looking at "normal" log output, it's usually set up in a nice aggregator somewhere, where I can easily exclude noise and otherwise uninteresting output.
Maybe OT, but I thought for a long time that "follow" was some sophisticated file descriptor trickery that required you to somehow "stream" the file while reading and would therefore be incompatible with opening a file "normally".
My mind was blown when finding out its really just "keep on polling after EOF". Meaning there is absolutely no difference between opening a file normally and "following" a file - and software could easily switch between the two "modes" on the fly.
It would be nice to have a mode that follows in the sense of automatically picking up new output, but that simultaneously would let you navigate around, similar to how terminals behave. Then you’d only need an autoscroll toggle for when you’re at the bottom.
To elaborate on this, lnav (https://lnav.org) is always polling files to check for new data and will load it in automatically. It does not require the user to do anything.
As far as following the tail of the file: if the focused line is at the end of the file, the display will scroll automatically; otherwise, the display will stick to the current position. Also, if there is a search active, matches in the new data will be found and highlighted.
I would say it's a bad UX and not just odd. I can't see any benefit to making it modal. It should just load new data as it becomes available without making the user do anything.
I track my propane in an LPG commodity at a fixed price per season. It saved me about $100 once when a transaction wouldn’t balance. I was accidentally partially charged for a short load delivery on one of my tanks at almost double the rate. Even if it seems silly to track at this fidelity in the moment, I wouldn’t have caught this tracking USD alone. Billing mistakes happen and can be costly!
Nice! That sounds really useful; in my case the KWH usage (and price/KWH) I pull directly out of the ConEd bill, so my only chance to notice those sorts of things would be post hoc looking back in time for big jumps in rate or usage I think.
But good to hear the positive story side for this.
reply