3,057 karma · joined December 24, 2022
This sounds way worse than dystopian, Orwellian or big-brotherly, in a world where you can't even get a human to review the 'autonomously placed lock' on your email or social media account. The Terminator saga is perhaps a good fit. But I have a feeling that they won't stop even at that.
So they took something that works well and created a bad UX around it, while ignoring the working, yet languishing UI/UX that was already around?
Bold of you to assume that I or the others didn't. I made my statement in spite of reading it. Not because I didn't read it. So my opinion is unchanged here.
The point here is simple. Documentation is a very important addition. But you can't paper over other deficiencies with documentation, especially if you find yourself referring the same documentation again and again. It's an indication that you're dealing with an abstraction that can't easily be internalized. Throwing the book at everyone isn't a good solution to every problem.
> Have you read the [0] docs for Python's 'subprocess' library? The ...
Yes, I have! All of those. Their difference with bash documentation is that you get the idea in a single glance. I spend much less time wondering how to make sense of it all. Python's abstractions are well thought out, carefully selected, consistently and orthogonally implemented and stays out of the way - something I can hardly say about bash. If that's not enough for you, Python has something that bash lacks - PEPs. The documents that neatly outline the rationale behind their decisions. That's what a lot of programmers want to know and every programmer should know.
Fun fact: The Epstein files contain a copy of the bash manual! Of course they weren't involved in his crimes. It was just one of the documents found on his system. A sysadmin is believed to have downloaded it for reference. But it's telling that it wasn't the Python manual, or the Perl manual, or something else. Meanwhile, I don't really think that Epstein was running Linux on his system.
> Unless you want to underdocument and leave important parts of the behavior for users to incorrectly guess, such documentation is going to be much larger than a cheat sheet would be.
If properly designed, such expansive documentation would be unnecessary, as they would be obvious even with the abstractions. For example when you use a buffer abstraction in modern languages, you have a fairly good idea what it does and why you need it, even though you may not care about its exact implementation details. That's the sort of quality where bash and other POSIX shells fail on several counts. In fact, check how many other shells break POSIX compatibility to solve this problem. Fish and nushell, for example.
"The developer is too lazy to read the documentation" isn't the appropriate stance to assume when so many are expressing their frustration and displeasure at it. At some point, you have to concede that there are genuine problems that cannot be blamed on the developer alone.
That's not what will happen. We've already seen examples of what will happen. So let me just list them instead:
1. The Secure Boot chain for UEFI initially mandated that only OS that were signed by Microsoft would be allowed to boot on PCs where SB is enabled. This was partially rolled back after public backlash.
2. iOS devices and majority of Android devices already don't allow you to install an alternate OS or distro.
3. Platform attestation proposals like Web Environment Integrity and its Android version.
4. Mandate that every developer must register with and pay an MNC to be able to release any app on their platforms.
Basically, they'll just take away your ability to control your device in any way. Don't be surprised if it turns out that these MNCs were behind such legislations. But this legislation is especially dangerous in that it will effectively kill user-controlled general-purpose computing, even from vendors like Pine64, Framework, System76, Fairphone and Purism who are willing to offer those.
Considering the amount of damage caused by these sort of legislative BS, those who propose and vote for such bills should be investigated publicly for corruption, conflict of interests and potential treason. They should be forced to divulge any relationship, directly or indirectly, with the benefactors of these bills. On the other side, rich corporations should be banned from 'lobbying' or bribery more appropriately, in matters that they have a stake in. And they should have stiff penalties for any violations. Not those couple of million dollar slaps on their wrist. At least 5% of their annual global profits, incarceration of top executives and breaking up the company. There has to be a consequence that's uncomfortable enough, for any fairness to be reestablished. This should apply even more for those professional lobbying firms and 'industry advocacy groups'.
People also need to start strongly opposing, rejecting and condemning justifications like this that rely on the cliche tropes of CSAM, terrorism, public safety, national security, etc. None of those measures are necessary or even useful in preventing any of those. Insistence on the contrary should be treated as an admission of inability and incompetence of the respective authorities in tackling the problem. In fact, why do they assume that kids, especially teens, are unimaginative and incapable of working around the problem? They should at least be starting with awareness campaigns to get the kids and the parents on their side and empower parents to enforce parental controls, instead of reaching for such despotic measure right away. This is like banning drugs before the problem of drug addiction is addressed. Black markets exist, even for cyberspace. It will just make the problem a whole lot worse.
And finally, don't let people without clearly proven vested interests anywhere near such regulations. And choose professionals or at least competent people for taking such decisions. You can't rein in this attack on ordinary people without stemming the uncontrolled corruption in the public offices that deal with it.
I keep asking what advantages passkeys offer over TLS self-signed client certificates. I haven't got any answers so far. Perhaps increase the security by encrypting the private key with a password or an external token. This is safe, like SSH and unlike regular passwords, because no secrets are sent to the server. TLS certs and (encrypted) keys are more tangible and easier to manage.
Perhaps passkeys do offer some advantages over TLS certs. But can't those be added to TLS, rather than rollout an entirely new system? The infuriating part is that this facility exists in browsers. They just let it rot to an extend that it's practically unusable. Meanwhile, Gemini browsers are using it quite successfully (for those who use Gemini).
"Just" seven US Letter pages? You're talking about redirections alone, right? How many such features exist in Bash? I find Python, Perl and even Lisps easier to understand. Some of those languages wouldn't have been even conceived if shell languages were good enough.
There is another shell language called 'execline' (to be precise, it's a replacement for a shell). The redirections in its commands are done using a program named 'fdmove' [1]. It doesn't leave any confusion as to what it's actually doing. fdmove doesn't mention the fact that it resorts to FD inheritance to achieve this. However, the entire 'shell' is based on chain loading of programs (fork, exec, FD inheritance, environment inheritance, etc). So fdmove's behavior doesn't really create any confusion to begin with. Despite execline needing some clever thinking from the coder, I find it easier to understand what it's actually doing, compared to bash. This is where bash and other POSIX shell languages went wrong with abstractions. They got carried away with them.
> I'm zero Lisp expert
and this:
> I don't feel comfortable at all reading this snippet
are related. The comfort in reading Lisp comes from how few syntactic/semantic rules there are. There's a standard form and a few special forms. Compare that to C - possibly one of the smallest popular languages around. How many syntactical and semantic rules do you need to know to be a half decent C programmer?
If you look at the Lisp code, it has just 2 main features - a tree in the form of nested lists and some operations in prefix notation. It needs some getting used to for regular programmers. But it's said that programming newbies learn Lisps faster than regular programming languages, due to the fewer rules they have to remember.
It's not that hard. Consider the following:
$ command &2>&1
$ command 2>1
$ command 2>&1
Honestly, I wish I could ask the person who designed it, why they made such decisions.
There is no end to the examples of how it harms ordinary people. And yet, you decide to just hand wave away those concerns as if those don't exist for you or the others. There is no debate when all you do is ignore the counter arguments. It's like those science deniers who stick to their beliefs, no matter how much evidence is presented.
The situation where this is going to cause confusion is when you do this for multiple commands. It looks like they're all writing to a single file. Of course, that file is not an ordinary file - it's a device file. But even that isn't enough. You have to know that each command sees its own incarnation of /dev/stdout, which refers to its own fd1.
The shell syntactical sugars also have some weird gotchas. The &2>&1 question and its answer are a good example of that. You're just trading one complexity (low level knowledge) for another (the long list of syntax rules). Shell languages break the rule of not letting abstractions get in the way of insight and intuitiveness.
I know that people will argue that shell languages are not programming languages, and that terseness is important for the former. And yet, we still have people complaining about it. This is the programmer ego and the sysadmin ego of people clashing with each other. After all, nobody is purely just one of those two.
> Respectfully, what was the purpose of this comment, really?
Judging by its replies alone, not everyone considers it purposeless. And even though I know enough to use shell redirections correctly, I still found that comment insightful. This is why I still prefer human explanations over AI. It often contains information you didn't think you needed. HN is one of the sources of the gradually dwindling supply of such information. That comment is still on-topic. Please don't discourage such habits.
As if that wasn't bad enough, these models cannot be trained on your regular home computer. But instead of striving to improve the energy efficiency of these models, those big corporations build and run massive gas guzzling data centers to train them. They ruin the quality of life for the neighbors through pollution, water depletion and electricity price rise. It also disproportionately affects the poor in the world by reducing supply of essential computing components like RAM (which are needed for medical devices, utility and manufacturing installations and every other aspect of modern life), and by aggravating the climate crisis, whose victims are the poorest.
They don't give you those models out of the goodness of their hearts. Those are just advertisements and trial pieces for their premium services. They also peddle the agenda of its creators. So yes, those models are empowering only in a very narrow sense without any foresight. They are still the money making engines for the rich that subject you to their benevolence, whims and fancies.
Right now they're 'flooding the zone' - a Steve Bannon slang for confusing and causing fatigue among people with far too many scandals far too often. I hope history will will remember him and his ilk with the reputation they deserve.
And then people found a way to use the same copyright law to widely distribute their work without the fear of losing attribution or being exploited. Here comes along LLMs that abuse the 'fair use' argument to break attribution and monetize someone else's work. Which way does the money flow? To the corporations again.
IP when it suits them, fair-use when it benefits us. One splendid demonstration of this hypocrisy is how clawd and clawdbot were forced to rename (trademark law in this case). By twisting and reinterpreting laws in whatever way it suits them, these glorified marauders broke a trust mechanism that people relied on for openly sharing their work.
It incentivices ordinary people to hide their work from public. Don't assume that AI is going to solve that loss. The level of original thinking in LLMs is very suspect, despite the pompous and deceitful claims by its creators to the contrary. Meanwhile, the lack of knowledge sharing and cooperation on a global scale will throw civilizational growth rate back into the dark ages. Neither AI, nor corporations are yet anywhere near the creativity and original thinking as the world working together. Ultimately, LLMs serve only the continued one-way transfer of wealth in favor of an insatiably greedy minority, at the cost of losing the benefit of the internet (knowledge sharing) and an enormous damage to the environment - all of which actively harm the public.
1. The ownership of security can be entrusted with the user. For example, if the user wants to install a 3rd party app store that doesn't use developer registration, they should be able to do so. The consequences of that decision should be on the owner. FDroid is one such app store. But I trust it over play store any day.
2. Careless users can be prevented from making such decisions, and capable users can be prevented from making mistakes, by careful UI designs that provide copious warnings and require deliberate actions. We have plenty of examples for both. An example for a system that prevents mistakes with warnings is the certificate trust override in browsers. They allow you to override rejection of untrustworthy certificates, but not before you read a lengthy warning message and click a couple of buttons. Similarly, an example of a deliberate action is when you want a repo to be deleted on github or gitlab. They force you to type in the repo name as confirmation. Not only does it take multiple key strokes, it forces you to review what you're actually deleting.
> Google is not doing this to harm developers but to protect their users.
No. Google is doing this to satisfy their insatiable appetite for profit growth by squeezing their current revenue streams. This protects no one, but their shareholders and top executives. I'm a bit ashamed to have to explain this on HN.
I don't know much about the internal architecture of FreeCAD. As far as I know, FreeCAD does a lot of heavy lifting including managing TNP. It's supposed to be handled by the CAD kernel - OpenCASCADE in this case. I suspect that the reason why open source CAD lags behind their proprietary counterparts is really the CAD kernel. Many proprietary CAD software share the same kernel, in fact. For example, SolidWorks, Solid Edge and OnShape use Parasolid. It tells you how critical the kernel is.
Perhaps we should be focusing more on a more capable open source CAD kernel. There are a few projects around that are trying this. But they either have very limited scopes, or don't have enough support and momentum.
Why does any of them deserve any special treatment? Please don't try to normalize this reprehensible behavior. It's a greedy, exploitative and lawless behavior, no matter how much they downplay it or how long they've been doing it.
That's not true. The user-equivalent of the man pages directory on Linux and BSDs is `~/.local/share/man`. You can have your mandb index it too. You can achieve more complex manpath indexing setups using the `~/.manpath` file.
Though not distro wikis, there's also a wealth of information on the Linux documentation site and the kernel newbies site. A lot of useful information is also present on Stack Overflow. I just wish that they hadn't shot themselves in the foot by alienating their contributors like this.
Other documentation sources like BSDs' are a bit more organized than that of Linux's, thanks to their strong emphasis on documentation. I wish Linux documentation was a more integrated single source, instead of being scattered around like this. It would have required more effort and discipline regarding documentation. Nevertheless, I guess that I should be grateful for these sources and the ability to leverage them. While I do rely on LLMs occasionally for solutions, I'm not very found of them because they're often very misguided, ill advised and lack the tiny bits of insight and wisdom that often accompany human generated documentation. It would be a disaster if the latter just faded into oblivion due to the over reliance on LLMs.