Windows 3.11 or Windows for Workgroups. Maybe they were the same thing, I don’t really remember.
I needed reliable networking, the ability to process large documents (which word couldn’t do at the time), and actual multitasking was nice. The system was a bit rough but quite usable. It’s not as if Windows was great at the time anyway.
I picture these pages being inviting and helpful, with maybe ascii art “awk sweet awk” or the like, rather than the current “maintenance locker full of random tools” vibe
I used Windows XP not for too long after switching from Windows 98. It was that time when Vista was just released and I knew this is not what I wanted to put on my brand new PC.
Very first impressions since I literally just downloaded before writing this, and haven’t read the manual, I may change my mind with more experience.
It’s incredibly snappy, to my eyes as fast as Helix.
A lot of stuff that took me a while to figure out in VS Code was immediately obvious. How to toggle inlay hints for Rust? Parameter Icon > Inlay Hints (with the keyboard shortcut there for easy toggling).
Interactive is generally intuitive because it seems pretty permissive. Tab vs Enter to autocomplete? Either! ctrl-shift-Z vs ctrl-Y to redo? Same thing!
After being so used to Helix I often reach for keybinds that don’t exist. I might have to learn Vim keybinds because I’m definitely going to keep trying Zed.
Not sure how I feel about what seems to be an inline discord-like chat/voice-call feature.
Going to check out if there’s git integration, because I couldn’t easily find it.
Git integration seems to be so embedded that it’s easy to miss. Open a git repository folder and you can switch branches and whatnot. But, like, in the command palette, there’s no Git > Pull or Git > Clone as in vscode. (I have barely scratched the surface so it might be there hiding in plain sight.)
Going to check out if there’s git integration, because I couldn’t easily find it.
Asking this because I’m noob, not elitist ass: Why a git integration in ide instead of using the cli? I’ve been working only on few projects where git is used, but the cli seems to be a ton easier to understand how to work with than the git integration in vscode which I discarded after few attempts to use
I mainly use git with cli, the one thing that’s been super helpful in vscode is gitlens, which shows you who last updated the line you’re on, and lets you look at the commit
Git has some counterintuitive commands for some commands you may want to do when you want to quickly do something. Being able to click a button and have the IDE remember the syntax for you is nice.
Some IDEs have extra non-native Git features like have inlined “git blame” outputs as you edit (easily see a commit message per-line, see who changed what, etc.), better diff/merge tooling (JetBrain’s merge tool comes to mind), being able to revert parts of the file instead of the whole file, etc.
the git integration in vscode which I discarded after few attempts to use
I’m going to be honest, I don’t really like VS Code’s Git integration either. I find it clunky and opinionated with shitty opinions.
Yeah… ‘git merge main’ weirds me out because my brain likes to think the command is merging current branch TO main instead of other way around
Some IDEs have extra non-native Git features like have inlined “git blame” outputs as you edit (easily see a commit message per-line, see who changed what, etc.), better diff/merge tooling (JetBrain’s merge tool comes to mind), being able to revert parts of the file instead of the whole file, etc.
Okay this sounds very good, so they actually improve git cli feature wise in addition to implementing GUI for it.
I’m probably more of a git noob than you, but I do usually use the cli. I figured if I’m going to give a gui editor an honest shake I should try to do things the inbuilt, gui, way. And more to the point, I do appreciate a good user interface with information at a glance or click instead of having to type out a command each time.
And more to the point, I do appreciate a good user interface with information at a glance or click instead of having to type out a command each time.
Agreed with good user interface, my criticism was specifically for the vscode default git plugin which I was not compatible with at all but it could be just a me-problem
A great git integration can work well in an editor. I use Magit in Emacs, which is probably as full-featured Git-client as there can be. Granted, for operations such as cherry-picking or rebasing on top of a branch I most often use the command line (but Magit for interactive rebase).
But editor support for version management can give other benefits as well, for example visually showing which lines are different from the latest version, easy access to file history, easy access to line-based history data (blame), jumping to versions based on that data, etc.
As I understand it vscode support for Git is so basic that it’s easy to understand why one would not see any benefits in it.
Better/simpler experience out of the box. With Helix you install the LSPs for languages you use and you’re set with a fully featured editor. Manual configuration is only needed for setting themes, keybinds, and small setting changes. It also feels much faster than a fully configured vim/neovim. Lastly its keybinds are inspired by Vim/Kakoune, but different from both.
I started with that and then have slowly disabled a number of them as I come to appreciate the Helix defaults, and have realized that some of these vim-bindings are overriding other Helix bindings that I wanted.
<span style="color:#323232;"> man -k printf
</span><span style="color:#323232;"> Search the short descriptions and manual page names for the keyword
</span><span style="color:#323232;"> printf as regular expression. Print out any matches. Equivalent to
</span><span style="color:#323232;"> apropos printf.
</span>
I think Zed is quite different from Atom. But Pulsar might be your thing. A direct fork of the last release of Atom being developed by ex Atom developers :)
Just to clarify, the Pulsar devs aren’t ex-Atom devs. Some of the team are from atom-community but none of the core Pulsar team were part of the official Atom team.
Watch this space for the full history, I’m literally putting the final touches on a blog post that will go into details of how Atom started then how it became Pulsar as a little celebration after we hit 3k stars.
The code for Zed itself is available under a copyleft license to ensure any improvements will benefit the entire community (GPL for the editor, AGPL for server-side components). GPUI, the UI framework that powers Zed, is distributed under the Apache 2 license, so that you can use it to build high-performance desktop applications and distribute them under any license you choose. zed.dev/blog/zed-is-now-open-source>
This distinction is not as meaningful as it used to be before LSPs; there’s little a PyCharm IDE can do that you can’t do in VS Code editor for example.
Nope I didn’t, but the problem doesn’t seem to be the Python version, but instead the fact that now Python is “externally managed” and therefore I cannot install packages using pip install packagename as it used to be.
I know that this is done for security reasons and that the good practice would be using pipx or conda, but the problem is that howdy istallation still tries to use the “old approach”
Thank you, but the problem is that is howdy installation (that gets automatically executed after I run sudo apt install howdy that tries to run “old fashioned” pip commands. So I should either find a way to tweak Howdy install (like building it from source after changing something maybe?) or disable this system security feature temporarily, install howdy and re-enable it immediately after
I’m no python expert but reading around it seems your only real solution is using a virtual environment, through pipx or venv as you already had found out, or using the
I wouldn’t trust that article on iOS 15 jailbreaks. A lot of those is misleading/fake (e.g. Checkra1n only supports iOS 12-14, unc0ver does not support iOS 15 and unc0ver virtual doesn’t exist).
iOS 15 currently only has Dopamine and Palera1n as supported and recommended jailbreaks. Though if you only need to side load apps, take a look at TrollStore, which lets you side load apps indefinitely, but isn’t a full jailbreak (made by the same dev as Dopamine).
FYI Checkra1n isn’t that old, but there are a lot of jailbreaks that end in “ra1n” :)
It appears to be a couple of versions behind … and have some issues with dynamically linked libraries that hinder LSPs. Neither of these is Zed’s fault. I’m sure the packaged version will be up to date momentarily (given the interest in Zed, sooner rather than later). Not sure how easy the LSP thing will be to fix, though there are some workarounds in the github issue.
yeah the editor is being updated way too fast for nix to keep up. I’m sure it’ll be easier once it has its stable release. I see the have a nix flake in the repo, it would be great if they added a package to the outputs instead of just a devshell, nix users could easily build it from master or whichever tag they want.
There are solutions in this issue to the LSP issue. The editor would need to be built in an fhs-env, or they will need to find a way to make it uses binaries installed with nix instead of the ones it downloads itself. VSCode had a similar issue, so there is a version of the package that let’s you install extensions through nix, and another that uses an fhs-env that allows extensions to work out of the box.
That was my first thought as well, but I will say that uBlue distros had a signing issue preventing updates recently, due to an oversight with how they rotated their image signing keys, and the easiest (maybe only?) solution was to pipe a curl command to sh. Even though uBlue is trustworthy, they still recommended inspecting the script, which was only a few lines of code.
In this case, though, I dunno why they don’t just package it as a flatpak or appimage or put it up on cargo.
Edit: nvm, they have some package manager options.
As long as they just use it for their community and don’t fucking lock documentation behind discord I don’t really care. But this trend has been so annoying. Due to this I’m in so many servers I have to quit a server just to join a new one
It is worrisome that all the smug elitists are too incompetent to just leave off the pipe and review from stdout, or redirect to a file for further analysis.
Same people will turn around and full throat the aur screaming ‘btw’ to anyone who dares look in their direction.
By that logic you have to review the Zed source code as well. Either you trust Zed devs or you don’t - decide! If you suspect their install script does something fishy, they could do it just as well as part of the editor. If you run their editor you execute their code, if you run the install script you execute their code - it’s the same thing.
Aur is worse because there usually somebody else writes the PKGBUILD, and then you have to either decide whether to trust that person as well, or be confident enough for vetting their work yourself.
Eh using aur is a bit different since most of# them pull the projects git repo directly anyway. Yeah the project might have vulns but thats on you to inspect before building it as well as the pkgbuild itself
Security wise it doesn’t matter, you run the code they wrote in any case. So either trust them or don’t. Where it matters is making a mess on your computer and possibly leaving cruft behind when uninstalling. But packages are in the works, Arch even has it since before linux support was announced officially.
I think you slipped in the discussion intendations somewhere, this branch of the discussion tree is about the implications of piping curl into bash vs. installing packages
Is it really worse tho? A single build, against a single runtime, free from distro specificities, packaged by the devs themselves instead of offloading the work on distro maintainers?
It is. Security problem in core library? Good luck waiting for 27 randos releasing an update. Whereas the distro updates it even before the issue becomes public.
AFAIK it’s the copy cost for the memory. GPU makes sense only when the hardware allows this copy to go away. Generally, desktop PCs don’t have such specialized hardware.
I don’t see why you’d have to copy all that much. Depending on the rendering architecture, once all the glyphs are there you’d only need to send the relevant text data to be rendered. I don’t see that being much of a problem even when using SDFs. It’s an extremely small amount of data by today’s standards and it can be updated on demand, but even if it couldn’t it would still be extremely fast to send over every frame. If games do it, so can text editors. Real time text rendering on the GPU is a fairly common practice nowadays, unfortunately not in most GUI applications…
At this point I’m not expert enough to explain more details. You can check font renderers.
Below is what’s in my mind but it’s just a guess.
In typical PC architectures you have IO between the storage and the RAM, and then there’s the copying from the RAM to the VRAM, and editors maybe also want copying from the VRAM to RAM for decoration purposes etc.
I am familiar with the current PC and GPU architectures.
IO is a non issue. Even a massive file can be trivially memory mapped and parsed without much hassle, and in the case of a text editor you’d have to deal with IO only when opening or saving said file, not during rendering.
As for the rendering side, again, the amount of memory you’d have to transfer between RAM and VRAM would be minimal. The issue is latency, not speed, but that can be mitigated though asynchonous transfer operations, so if done properly stutters are unlikely.
Rendering monospaced fonts (with decorators and control characters) at thousands of frames a second nowadays is computationally trivial, take a look at refterm for an example. I suspect non-monospaced fonts would require more effort, but it’s doable.
As I said at the beginning, it’s not impossible, just a pain. But so is font rendering in general honestly :/
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.