Almost the entirety of the technology world is English-native. That ship has sailed a long time ago. One can’t learn about any new technology without English, whether it’s a new algorithm, a new library, or a new SaaS service. I don’t think HN should be that exception. Just learn English. (English isn’t my first language either, but then I look back at my parents forcing me to learn English from a young age and really appreciate that.)
> Almost the entirety of the technology world is English-native.
I wonder if the Chinese might have to say something about that [1]: 33% of 2 million funded studies were in Chinese. I posit that as China strengthens and no longer feels the need to be admired internationally, that declining % will reverse.
Another example is of the Huawei Matebook Fold [2]. It's an interesting dual-screen PC Laptop (?) that I saw in a YouTube video from India, but the product page doesn't even come up in Google search results. Its product page is in Chinese, and the only way to find it seems to be through the wiki page [3].
Almost the entirety of the technology world is English-speaking, not English-native.
Pretending that it's English-native is why there's unspoken incentives to sound more "native", and thus use these grammar-correcting tools.
Some of the intelligent comments on here come from people who learned English in recent months or years, rather than in childhood.
Their English isn't always fluent or well-structured. If they rely slightly more heavily on suggested-next-word tools or AI translations, is that a reason to exclude them from the conversation?
Conversely, many English learning resources for non-native speakers focus on strict formal language, similar to AI-generated text. Do we risk excluding people who have learned a style more formal than we're used to?
There is very significant overlap between browsers’ implementation of JS and WASM. For example in V8, the TurboFan compiler works for both JS and WASM. Compilation aside, all the sandboxing work done on JS apply to WASM too. This isn’t NaCl.
> It might be worthwhile to ensure that a web app you're developing will work on a less powerful machine
If that’s your goal this machine is still too powerful. Web apps generally care about single thread performance. The machine has a single thread performance that exceeds any and all Intel/AMD processors, according to Geekbench (A18 Pro: 3445; Ryzen 9 9950X: 3385). My own test for ensuring my web app performs well involves a machine less than half as fast, and my web app runs with all assertions turned on.
React doesn’t really force you to make your props immutable data. Using mutable data with React is allowed and just as error prone as elsewhere. But certainly you are encouraged to use something like https://immutable-js.com together with React. At least that’s what I used before I discovered ClojureScript.
> This analysis will be “necessarily case-by-
case” because it will “depend on the circumstances, particularly how the AI tool operates and
how it was used to create the final work.”
This seems the opposite of the cut and dry "cannot be copyrighted" stance I was replying to.
Yes it does depend on the circumstances. You are free to waste your own time to try this at the copyright office, but in my opinion, this project's 100% LLM output where the human element is just writing prompts and steering the LLM is the same circumstance as my linked case where the human prompted Midjourney 624 times before producing the image the human deemed acceptable. The copyright office has this to say:
> As the Office described in its March guidance, “when an AI technology receives solely a prompt from a human and produces complex written, visual, or musical works in response, the ‘traditional elements of authorship’ are determined and executed by the technology—not the human user.”
Why is Control-C ambiguous? Oh wait, you guys use Control-C for copy, but you have forgotten that both Windows and Linux support Control-Insert for copy. That's what I use.
That would not be a good approach on Macs where most users are using reduced/laptop keyboards that have no Insert key.
In this respect, Apple got pretty lucky. Most users were not using reduced keyboards in 1987 when they originally decided to add the Control key separate from Command. Plus, Mac OS didn't even have a native terminal at the time; I assume there were terminal emulators for networking/serial use but I can't imagine that was top-of-mind for Apple either.
Regardless, Cmd-C is definitely a more convenient shortcut than Control-Insert, even if you do have the keys for the latter.
> Mac OS didn't even have a native terminal at the time; I assume there were terminal emulators for networking/serial use but I can't imagine that was top-of-mind for Apple either.
I think it was in their mind. The manual for the keyboard (yes, keyboards had manuals back then) says the keyboard has “special keys that work in applications running in alternative operating systems” (https://www.cvxmelody.net/Apple%20Extended%20Keyboard%20II%2...)
I agree with you about Cmd-C being more convenient but that’s besides the point.
My point was that on all three operating systems Ctrl-C has an unambiguous feature: send SIGINT. It is more important to have SIGINT be consistent than have copy be consistent. Accidentally sending SIGINT to a job that has been running for an hour? That hour of work may now be gone. This is a deliberate action that should not be a mistake. Copying is not that? Win+C on Windows doesn’t do any destructive actions.
Not using the combination for one of its ambiguous purposes does not strip it of ambiguity, you've just trained yourself to avoid those circumstances.
That, of course, is one of the pain points that the article addresses: Training yourself to do so is additional cognitive load that never should have been necessary in the first place.
I flip between macOS and Linux and, occasionally, Windows. On one of my laptops, insert is also a Fn switch away, so I have to either remember that this machine needs Ctrl-Fn-F11 specifically when I'm copying from terminal.
On another keyboard I have the same problem, but insert is mapped to a different key entirely, so it is ctrl-fn-equals, and fn is on the opposite side of the keyboard from ctrl.
Contort my fingers in which way on which keyboard? Mental load and annoyance I don't need.
That’s a hardware problem. I avoid mental load and annoyance by using the same keyboard layout everywhere. Even on Windows the bottom left modifier keys on my keyboard are Ctrl Alt Win, and not Ctrl Win Alt.
The keyboard is the most important input device on a computer. It’s worthwhile to customize your key mappings to fit your muscle memory.
The "goto line" feature on most Mac text editors is Cmd+L. And it's consistent.
On the Mac the Control shortcuts are used for text manipulation everywhere and they come from Emacs: C-a, C-e, C-f, C-b, C-k, etc. The Cmd key is not the standard for text editing; it is the standard for all app-specific commands. For example Cmd+I usually makes text italic in a word processor, but in a non-word processor app italic makes no sense, so for example in Finder it means bring up the inspector.
> The Control key is used with terminal-emulation programs for control-key sequences. For all other applications, it is reserved for end-user-defined shortcut key sequences using a macro-key facility.
I find that a good reason. It's prioritizing the experience of terminal emulation programs. Control-C means SIGINT. And also in Cocoa text controls, many Emacs keybindings with Control are available: C-a, C-e, C-k, C-b, C-f, etc. (And it's very easy to add Emacs keybindings with the Meta key too: it's a somewhat obscure functionality but Apple never broke it. I have configured my computer with M-f and M-b for example.)
> When GNU reimplemented the UNIX userspace, the vector ran from proprietary to free. Stallman was using the limits of copyright law to turn proprietary software into free software. […] The vector in the chardet case runs the other way.
That’s just your subjective opinion which many other people would disagree. I bet Armin Ronacher would agree that an MIT licensed library is even freer than an LGPL licensed library. To them, the vector is running from free to freer.
Forking and multi threading do not coexist. Even if one of your transitive dependencies decides to launch a thread that’s 99% idle, it becomes unsafe to fork.
Im curious as to the down votes on this. It's absolutely true, and when I was maintaining a job runner daemon that ran hundreds of thousands of who knows what Python tasks/jobs a day on some shared infra with arbitrary code for a certain megacorp from 2016-2020 or so, this was one of insidious and ugly failure modes to go debug and handle. The docs really make it sound like you can mix threading and multiprocessing but you can never really completely ensure that threading and then bare fork will ever be safe, period. It's really irritating that the docs would have you believe that this is OK or safe, but is in keeping with the Python philosophy of trying to hide the edge of the blade you're using until it's too late and you've cut the shit out of yourself.
In general only the thread calling fork() gets forked, so unless you call exec() soon after, there are a lot of complications with signals, shared memory.
What are the complications? A single thread with its own process sandbox with everything from the parent is exactly what I'd expect coming from C land. Are the complications you refer to specific to the python VM or more general?
Even treating the process as read only after forking is potentially fraught. What if a background thread is mutating some data structure? When it forks the data structure might be internally inconsistent because the work to finish the mutation might not be completed. Imagine there are locks held by various threads when it dies, trying to lock those in the child might deadlock or even worse. There's tons of these types of gotchas.
Okay so just all the usual threading gotchas. Nothing specific to Python.
Conceptually fork "just" noncooperatively preempts and kills all other threads. Use accordingly. Yes it's a giant footgun but then so is all low level "unmanaged" concurrency.
If you have multiple threads, you almost certainly have mutexes. If your fork happens when a non-main thread holds a mutex, your main thread will never again be able to hold that mutex.
An imperfect solution is to require every mutex created to be accompanied by some pthread_atfork, but libraries don’t do that unless forking is specifically requested. In other words, if you don’t control the library you can’t fork.
If you have enough discipline to make sure you only create threads after all the forking is done, then sure. But having such discipline is harder than just forbidding fork or forbidding threads in your program. It turns a careful analysis of timing and causality into just banning a few functions.
And what do you do with that information? Refuse to fork after you detect more than one thread running? I haven’t seen any code that gracefully handles the unable-to-fork scenario. When people write fork-based code, especially in Python, they always expect forking to succeed.
But not the reverse, if its a bare fork and not strictly using basically mutex and shared resource free code (which is hard), and there's little or no warning lights to indicate that this is a terrible idea that fails in really unpredictable and hard to debug ways.
reply