Apparently you can now ZOLA_VERSION to _any_ version you desire in v1 and the build system will install it on demand. I didn't realize that part had changed.
On the other hand, v2 doesn't even have Zola; my builds failed with a "failed to find zola command".
I guess we're now set for life, and will never have to wait for Cloudflare to update the image in order to bump the version. Less headaches for everyone.
async/await is about superimposing useful CPU computations with slow I/O operations.
For example, you would read data fragment D0 from a network socket, and right before doing any work on it, you ask the OS to fetch data fragment D1, etc.
This would is faster than reading and working in distinct time intervals. And despite whatever you seem to believe, it would also be faster than reading and working using thread parallelism. Because even if you eliminate the synchronization overhead or you devise a good lock-free algorithm, thread context switches still have a massive overhead, not to mention issues related to memory bandwidth and cache coherence.
Still, how does one gather the nerve to call a feature present in most modern languages, from C# to Zig, a hype?
I should add that the concurrent algorithm I described for processing data from a socket, i.e asynchronously read data fragment (i + 1) then do work on data fragment i, would only be optimal if the throughout of the work you do on the data is higher than reading throughout.
Even if the above condition doesn't hold, you would have to be very careful to do better with threads.
Is it just an arbitrary design decision that NodeJS is single-threaded?
The great news is that just like you're not forced to buy an Android or iOS device, you're not forced to travel to Qatar.
"Vote with your feet" applies to jurisdictions just like it applies to technologies. Of course, like with technologies, making such a choice has the potential to limit you in other ways.
Do not worry, the WEF and UN will be diligently taking notes of this field test and by the time it's rolled out in your country this will be resolved.
I cannot wait to have a social credit score! It is a wonderful idea and I am only disappointed that our wise un-elected WEF and UN leaders are being so shy in rolling it out.
No kidding. If we miraculously pull out of this nose dive before climate change erases us all we’re immediately going to be tossed into a world where AI makes us basically zoo animals for the ultra wealthy.
> a world where AI makes us basically zoo animals for the ultra wealthy.
... for about 3 years, before one of the ultra wealthy elites presses the wrong button and the AI ends up putting them in the zoo (or paperclip raw materials hopper) too.
Last summer I had to travel to South Korea for business, I was required to install a government app due to covid. Obviously this app was only for android and iOS. I had an iphone so i didnt have issues. But if i had a pinephone, i probably would had to board the next plane out of the country.
Crazy how our lives are becoming so dependent on private company techs.
Even if the government went to the trouble of creating the Debian package, they wouldn't allow it to run on an OS that doesn't support a particularly restrictive "Secure Boot" setup, which would provide the mobile network with a remote attestation that you are running only "certified" packages and system services (including a minimal set of mandatory ones).
Naturally, this certification process would ban apps which could spoof the UI of any official apps, but the ban would have to go further and include any apps which users have built from source themselves. End-to-end encrypted messaging apps (without backdoors) would similarly be banned.
At that point, the fact that you have the source code for all of the software running on your surveillance device isn't much comfort. What good is a phone when you are unable to speak?
I did worry that my comment might incorrectly imply that, so I deliberately reworded it to say a particularly restrictive "Secure Boot" setup, but I guess that's still ambiguous.
You're right, Debian "supports" such a set of restrictions, in the sense that a manufacturer could build devices that would comply with these hypothetical laws while only using vanilla Debian packages, but my point was that such a device wouldn't really feel like Debian, since the moment you installed an unapproved application (or removed a mandatory application) half the functionality would stop working.
No. Debian supports Secure Boot, and that means anybody can add their own signing key and sign and boot their own kernel, packages and everything else.
As long as users can update the signing keys it's all good.
That's assuming the hardware supports it. I'm imagining a (very likely) world where devices will either no longer support self-generated keys, or where using such keys makes your device unable to access the mobile network or the internet. (The latter sort of device might in theory be buildable, and run Debian just fine, but I don't think it would have enough buyers for a manufacturer to waste money on producing it).
> If not, it's tivoization, and it breaches GPL.
Contracts (and software licences) cannot override the law. If a government wants to ban self-generated keys (and/or make anti-Tivoization clauses unenforceable), then it can easily do so, and make all "Debian phones" either not feel like Debian, or not feel like phones.
> That would require abandoning copyright enforcement.
Who do you think writes copyright laws?
Obviously I'm not suggesting a government would just abandon the entire concept of copyright, but it could amend its copyright law to say that a copyright holder cannot claim (in court) that their proprietary rights were breached solely due to a defendant applying "security measures" to prevent software tampering.
That would be grossly unfair to people whose code is then used in ways that go against their wishes, but government policies don't have to be fair. (For the avoidance of doubt, I'm not accusing you of saying that they have to be fair, I'm just providing some obvious context to help make my position clearer to anyone reading this).
That’s cute, except that of course in the real world you get some nice quality time with border control/the police/secret services well before that if you try playing these games.
Or: try arguing about the fourth amendment, human rights and the constitution when a uniformed thug wants to seize your phone when you fly into the US. It does not sound that clever in the real world.
The linker/compiler discrepancy sounds incredibly weird. This Linux levels of "things don't work together as expected" but how can a uniform system developed by a sole company include nonsense like this?
Reliably saving state in the face of sudden total failure is both very tricky and app-specific. Just saving state changes automatically won't do it -- partial writes of complex state are likely to be inconsistent without luck or careful design and QA controls (tests, testing, on-going controls to ensure nothing new operates or relies on anything outside the safe state-saving mechanism).
It makes a lot more sense to put the effort into making the OS continue as well as it can, vs requiring every app to harden itself against sudden total failures.
A text editor without a well rounded GUI story isn't worth it for me. There are all these desperate projects each with their own focus, ranging from "simple graphics acceleration" to "tons of bells and whistles, animations and ad-hoc UI extensions".
UI should be thought out at PRs and issues, but the same people who develop the main core. But they don't have to, because they're making a terminal application, which has its use cases.
But I so no reason why I should type my text in a terminal, when I can use a proper GUI application.
And I'm not even suggesting VSCode, even Emacs is better in this regard, which is what I use.
One of the main features of NeoVim over VIM is that NeoVIM can be embedded into other programs and new GUIs can be built that use libvim. There are now programs you can download that do that, for example [1]. Certainly, this is still an experimental line of software and I don't use the NeoVIM GUIs and don't claim that this has been proven a success yet, but there are some encouraging signs.
By vim user count alone, I would conjecture that the venn circle of
philosophically opposed devs has more people insisting on the absence of
a GUI story, than those insisting on one.
Of course the vast majority of devs use whatever suits them, GUI or not.
And you couldn't have picked an editor with a worse GUI story.
You're right. An environment that's all text and generally uses fixed width fonts is not at all the proper place to run an editor for dealing text that is best understood by displaying it with fixed width fonts.
Is this a sarcastic remark? If not, this seems like an extremely reductive stance. Surely one could imagine another skilled person preferring a GUI over the terminal, even if it's not an opinion they share :)
Your terminal application is an emulator of a decades old technology originally used in physical consoles, with layers upon layers of enhancements that add support for colors, cursor control, etc. At it's core, it's just a grid of characters. The GUI as a platform is quite literally a superset of the terminal, for example because the terminal emulator app is a GUI itself. Hacking the grid of characters to render lines as if it was a GUI is hardly "superior".
I say all that as an avid neovim user myself by the way. On mac/linux I use it through the terminal, on Windows I use it through the QT application.
The new generation of terminals are nothing like what you’re describing: GPU acceleration, full color support, font shaping, support for ligatures, built-in support for multiplexing, SSH and more.
WezTerm [1] is probably the best example right now but there are others.
Of course they are. Your new generation terminals still use decade old protocols, using the same escape sequences to control the cursor position, colors etc.
The "lines" and other UI elements you see in those next generation terminals when you run TUI apps like neovim are still simple characters aligned next to each other to look like a line etc.
Stuff like GPU acceleration is only another layer which was put on top of all of that. At the core they're still using the same old technology.
OTOH it's already probably a couple decades since some more fresh terminal emulator projects have popped up that kick a bit into the old cruft and provide both lightweight stuff and actual drawing routines for specific stuff. From a graphics dev pov it's not nonsense to decide for rendering on a grid, even for UI, i see it a bit like voxel 3D engines.
So i'm really not sure the "layers upon layers" critique is well suited for terminals, in comparison with say some qt/gtk/electron/<your gui>. Also GP is mentioning emacs, which is mostly the same old cruft as a terminal emulator.
1. GCC has more backends than LLVM.
2. Competition is good in general.
3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.
Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.
> I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.
More likely that GCC has to follow all the bugs and quirks of rustc or no people will use GCC for Rust.
Apparently you can now ZOLA_VERSION to _any_ version you desire in v1 and the build system will install it on demand. I didn't realize that part had changed.
On the other hand, v2 doesn't even have Zola; my builds failed with a "failed to find zola command".
I guess we're now set for life, and will never have to wait for Cloudflare to update the image in order to bump the version. Less headaches for everyone.
Source: https://developers.cloudflare.com/pages/platform/language-su...