nickelpro
> Timing exploits has been known to the security community since the mid-nineties. From a real world standpoint the attack is not practical.
And this is basically the state of the art today, even with Spectre. You can demonstrate the vulnerability under controlled conditions but having those conditions arise in production is not practical in the engineering sense.
> This has taken a backseat, as I now believe that there is something more important than license: community. The community around a software project is what dictates the values of the project. A strong copyleft license does still signal that the project cares about software freedom, but, by itself it is not enough.
I don't care about community at all, the license is the only thing that has any "signal" when comes to someone caring about software freedom. If you release all your code as GPL (or MIT, or Apache, etc), you care about software freedom. Nothing is more important than the license.
The list of bullet points the author then provides are completely irrelevant to "caring about software freedom".
Fabrice Bellard doesn't need to personally administer to the ongoing development and community functions of QEMU or ffmpeg, it is sufficient that he released the code as open source, and others carry the torch from there.
And if people disagree about the form those communities take, they can split them as they see fit. As happened with libav and ffmpeg for a number of years. This too is fine, and is only possible because of the license.
If I keep my code proprietary, you are beholden to the shape of the community I dictate.
The license is first, it precedes, any notion about community.
People don't loudly announce they're not going anywhere and not changing anything, of course you only perceive the ones who do otherwise.
It doesn't mean they there's a wide spread trend.
I don't ever host anyone in my tiny city apartment, we go out. It would be far worse to "host at home". There a places dedicated to hosting, it's a service, why would we not engage with that service?
Spending 3 hours at Qahwah and then wandering over to Port Sa'id is not some lesser experience than doing it all at home. If anything it's a much better experience
The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.
AI writing is rife with high-level, generic language. AI prose rarely addresses concrete concerns, instead preferring hedged generalizations. The "It may A, B, and C, but it will not X, Y, and Z." Where both lists are broad categories instead of specific mechanisms is a calling-card of AI prose.
A human identifies and addresses specific concerns. They need not hedge with "may", because they are stating known facts to support their premise, and an argument from those facts follows naturally.
"The OpenAI API requires tokenization in proprietary format, unavailable and unusable by other providers. Deepseek and Anthropic are following suit."
I do not think the whole article is AI generated. I do not think this was a simple prompt of "Write an article about proprietary chat session formats". However, much of the rhetoric is either LLM drafted or had an LLM pass over it.
This is so obviously AI generated it is painful. Once or twice in an article is rhetorical flourish, but the entire text is inundated with it.
No. It is cutting unused features to make a manageable product.
* "That won't work on GCC 5.5." We don't support GCC 5.5, or any compiler which wasn't shipped this decade.
* "What about FreeBSD?" What about it? We only have Linux servers
* "This only works on systemd." Good, we're a systemd shop.
In my space this is usually something like, "X won't work on POSIX make", being a reason not to add X to the build system. Well, it works on Ninja, and on GNU make, so it just won't work on POSIX make and the handful of deployments still using POSIX make just won't use X.
It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production.
"We're not trying to build a perfect solution here" is saying "We acknowledge not everything will be covered, we're setting the requirements at the 90th percentile use case".
This is why the upstream didn't take it seriously, this has been known for literal decades.
Fabien Sanglard's HN handle is fabiensanglard
I won't pretend to speak to specific numbers, but a huge amount of work and maintenance is from these programmers, or funded via the corporate actors which employ these programmers. Those actors are either on this list, or don't have a problem with this list.
What remains are the handful of truly independent contributors, which are a minority in terms of LoC (though they often have an outsized impact), and the peanut gallery.
Open source wasn't always this way, it would be a different discussion 30 years ago when independents were the only guys in town, but it is now.
You say this as if these players aren't members of "the open source folks". It's not an exclusive club.
>The database you are helping build for a trustworthy government does not stay in trustworthy hands. Administrations change. A registry that merely catalogs who you are today becomes, under a future government, a map of who to find.
This is an objection to driver license databases, to passports; they don't want face scans at airports, much less for banking or insurance. They want off-the-grid, untrackable anonymity. This is incompatible with much of modern life, at least in the mainstream.
Which is fine, you have an idiosyncratic view of modern mathematical pedagogy (at least as it exists in the US). When you're a high school math teacher you can argue with your state dept. of ed. about it.
These calculators are also used at the undergrad level, fwiw, so the "high school level" (whatever limit you're putting on that, many high schools will accelerate students into undergrad stats and as far as Calc II), is not a factor in their use overall.
Teaching students to use lookup tables at all is a largely pointless exercise. Teaching students to graph or use statistical functions on an advanced calculator transfers very well to other environments.
This starts to hurt bad when the compiler producing the build is not clang. If you try to use a compile database describing C++20 module compile lines for GCC, clangd will choke badly. If you're using MSVC flags that clang-cl hasn't been taught yet, clangd falls over. If you're using CMake to produce the compile database, it will leave out synthetic targets from the database and you will see errors because clangd cannot find the interfaces described by those targets. If you're not using CMake you need to configure bear or ninja or whatever to produce a compilation database for you. Etc, etc.
[1]: https://clang.llvm.org/docs/JSONCompilationDatabase.html
Some languages are more severe than others on this. For example, in C++ your editor is not going to be able to make efficient use of the clangd language server without intervention from the programmer to understand and configure it. On the other hand, for Python the Pyright LS will be mostly fine without additional configuration.
A programmer having to learn how language servers work isn't a pain point, it's their job. It takes a couple hours to learn. A couple hours to learn how to do part of your job isn't notable. Complaining about learning how to do one's job makes one unqualified.
If you don't use language servers, you don't engage with development environments which rely on them, you need not learn them.
If you're making chips on a Monarch 60 you don't need to learn shit about CNC. If you're pushing buttons on a Haas you do.
If you're coming from a Monarch and want to try pushing buttons on the Haas on the kids are using, you need to learn how CNC works. That's your job. If you want to switch from notepad to Zed, you need to learn how language servers work.
If your tool is TextMate, you should learn how TextMate grammars work. If your tool is vi, you should learn how modal editing works. If your tool is Ed, you don't need to learn anything because "Ed is the standard text editor".[1]
You are a craftsman, learn your tools. Could you imagine the equivalent from other professionals? A machinist saying, "Understanding the differences and interop places between the DRO, hand controls, and CNC controls for the lathe can be a big confusing time hog."
It takes a couple of hours, and it's a tool you use every single day. Learning how it works is the price of entry, not a mountain to overcome.
There has been no significant jump in capabilities such that a meaningful demonstration of general purpose or cryptographically-relevant quantum computing could be performed on "public hardware".
Presumably the organizers know this but still have incentives to drum up news about QC. So they ignore that problem and focus on how to obscure the fact this is a dog-and-pony show.
"Good news, we added a debugger"
"CMake has a debugger? Who would ever want that?"
Sigh.
Working on CMake has taught me a lot about the futility of pleasing everyone.