2,123 karma · joined April 22, 2018
And to be clear, it is reasonable to expect an author to invest more effort than a reader, because the work in question will reach many more readers and demand time and attention from all of them.
This principle was a part of basic netiquette back in the days of Usenet. I wish I could find the document (maybe it was a FAQ?) where I first saw it stated succinctly.
Moreover, granting permissions on the sysfs nodes won't distinguish between a user who is logged in to the current virtual console and one who is not. Wayland correctly delegates keyboard ownership to compositors, but they have no way to expose the keyboard's outputs (the LEDs) because Wayland hasn't yet defined a protocol for doing so.
X11 has a protocol for this, and X servers handle it just fine. They account for different users and LED states on each virtual console, and do not require clients to have any special permissions. It's an area where Wayland fails to be a suitable replacement.
Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences.
Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.
It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland.
This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.
Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.
It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.
When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.
When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.
What an aggravating, disruptive, and completely unnecessary waste of my time and attention.
I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.
I think it was called vSide.
When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)
However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.
At the same time, it's often technically true, but for a good reason that you neglected to mention:
Those old tools tend to be very capable email clients, not web apps with their awkward attempts to simplify complex conversation structure. A good email client can handle large, high-traffic, frequently branching, long-lived threads with ease. All the web forums I've ever used fail miserably here.
The people who are tasked with participating in large scale discussion groups (like the LKML) know this through experience. They prefer email because it works better. It makes their lives easier. It helps them to be more efficient, which is absolutely necessary given the sheer volume of messaging that they handle.
Yes, a specialized tool is required to get these benefits, just as a specialized tool is required to make web server output easily readable. Thankfully, these tools have existed for decades.
20 years ago, Mercurial was not the wrong choice.
- Its internal design was very similar to Git's.
- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)
- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.
- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)
So you weren't wrong back then...
...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.
So while I believe you about all those difficulties existing today, it's plausible that they would mostly fade away over time. I think temporary growing pains would be an acceptable price for the significant long-term public benefit.
Then let us hire different leaders into government. Public servants, not overlords.
Many of us find it unethical to give money to scalpers.
> a handful of .net domains that are under $100
And this is why.
I suppose it might be true for .city.state.us subdomains, but those fail my first criterion (they're not short), and are themselves a privacy hazard since they substantially narrow the search space for personal info about the domain owner. So it doesn't refute my criticism.
Unfortunately, it forbids WHOIS privacy services, which makes it a privacy and security hazard for personal domains. Pity, that.
I assume the possibility of spurious Rx state is why FTDI chose to wire Rx to the tip pin of the female TRS connector: It's the last pin to make contact with anything when plugging in, and therefore least likely to be bridged to ground. I suppose the mechanical design of any particular jack would determine whether it's possible at all.
The same issue applies to PCB header pins.
And the same goes for 25-pin D-sub connectors, which have been widely used as RS-232, parallel printer, and SCSI ports.
Voltages vary, too.
This is why we check before wiring them to other things.
But yes, if someone happens to be using their serial line for some kind of sensitive signaling, then I would agree that choosing a more isolated connector (or just avoiding hotplug) would make sense.
I added one to my single-board computer enclosure, following FTDI's wiring. Now I can easily connect whenever I need to use the serial console, and a standard 3.5mm audio extension cable will let me reach across the room without moving my main computer. Replacement parts, if I ever need them, are cheap and easy to find.
Here's the pinout:
https://www.ftdichip.com/Support/Documents/DataSheets/Cables...
Languages with rich standard libraries provide enough common components that it's feasible to build things using only a small handful of external dependencies. Each of those can be carefully chosen, monitored, and potentially even audited, by an individual or small team.
That doesn't make the resulting software exploit-proof, of course, but it seems to me much less risky than an ecosystem where most programs pull in hundreds of dependencies, all of which receive far less scrutiny than a language's standard library.
It is a special when the usual price is $2 each.
> Why not?
Because I'm not interested.
Nobody has suggested that they malfunction.
I thought this was obvious, but to spell it out: I was suggesting that they might not necessarily be programmed to apply a different price depending on quantity. An item might have a flat price of $1 each, but labeled on the shelf/bin as "special: five for $5" to encourage larger purchases.
I have personally encountered this. Meanwhile, I do not recall an example of buying a quantity smaller than suggested and being charged a higher price per item. Hence my question about labeling and law.
> Also, if you do not have a member/loyalty account, you do not get those discounts.
I'm not talking about membership discounts.
Have you tested this by buying just one, and checking the price on the receipt?
I ask because someone once told me this was illegal in the US; that a shop was allowed to display the sale price only for a larger quantity, but they had to honor the same price per unit if you only bought one. (I think we were discussing produce at the time, in case that matters.) I've long wondered if that was true or just an urban legend.