The wonderful thing about Krita isn't it's features (although they are excellent); it's the fact it's the only graphics program with modern capabilities that someone could transition into from Microsoft Paint without needing to load up a series of YouTube tutorials.
I commend the Krita team for not merely copying Photoshop/GIMP, but actually writing a program an idiot like me can pick up and actually be productive with.
My understanding was that they were transitioning from paint (to krita or paint.net or something else). So krita has cross-platform going for it as a paint.net alternative.
Pinta is a Mono-based clone of Paint.net for Linux. I am a heavy Paint.net user at work and I find Pinta at home to be just as useful. I haven't used Gimp in years.
I do have Krita both at work on Windows and at home on Linux, but I rarely have to pull it out unless I need a tool specific to that application.
Paint.NET/Pinta and XPaint are made as enhanced Paint, so someone that wants a not-trivial graphics editor will find those perfect.
>I commend the Krita team for not merely copying Photoshop/GIMP
Krita (as well as MyPaint) is mainly a painting software whereas Photoshop/GIMP are mainly photo editors. You can do similar things in both, but they target different niches.
Photoshop STARTED OUT as a photo editor but it has grown to become a sprawling beast that has long since incorporated painting tools. Photoshop does not target any one niche any more; it can do photo editing, it can paint, it can animate, it’s got some vector capabilities... there’s a ton of professional artists who use Photoshop for a painterly workflow.
Do not be fooled by its name. That merely tells you where it began; it does not tell you what it is useful for after nearly thirty years of adding on one feature after another.
Perhaps, because arguably, an image editing software should be using a lot MORE memory than a chat service?
I appreciated the comment as a light humoured jab at the insane amount of memory slack needs just to send some text to each other (over simplification).
No, VSCode doesn't run great. Maybe compared to IntelliJ and Visual Studio, but far worse than sublime text and vim.
I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
I still remember the days when users of various vi clones derided emacs as "Eight Megabytes And Constantly Swapping" and now a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. My actually running emacs with slime loaded in the middle of debugging a lisp application is 127MB, which is still smaller than a freshly opened atom instance.
> a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB.
this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4.
And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
We could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers be array indices; replace the `brk()` system call by the `resize()` method; reimplement `malloc()` on top of that.
And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas.
(No, I'm not actually serious. Though we could imagine something similar on some new language.)
> We could have 32-bit pointers with a bit of hacking:
We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
Anything that is going to mmap a file of 1GB or larger will probably want 64-bit addressing, which will include any document editor that is designed around mmap.
That's somewhat specialized, but not as much as you might think.
For exactly the reason alias_neo provided. It's madness to think that a chat program developed by a company of ~1 thousand employees valuated at 7.1 billion $, should take more memory, more disk space, and be less portable (Krita also works on FreeBSD and Haiku which Slack does not support) and be slower than a full-fledged art software developed at 100% by mostly unpaid open-source volunteers.
that IMO is not a valid comparison, not even remotely valid, because those two products are built with completely different stacks. Krita is native, slack is webby. Also assuming that just because it is developed by unpaid open-source volunteers it should somehow be slower than something developed by an expensive for-profit company is passing judgement on people who are donating their free time and effort into building this, and that is not cool.
We should all just stop comparing native apps to electron based apps, those things are soooo different. Electron/Chrome/Firefox/$browser are doing a ton of stuff behind the scenes, they are basically little virtual machines running the web platform. Comparing that to native is meaningless. You can of course prefer native apps, no one is arguing that, and yes you're correct that native apps will often use less resources, but it is the same as saying that a jumbo jet is much faster than a kickscooter, it might be true but what kind of comparison is that?! people are not building stuff with electron because they want to use less resources, the reasoning behind it is usually something else that those teams think is a valid trade-off
It's a valid comparison because of all of your points. The question here is: why use Electron as a stack at all.
The general arguments are to do with building modern, aesthetic, easy-to-use cross-platform apps with less dev resources. Slack as a company are not dev-resource-constrained, so this makes Krita an exemplary counter-example to anyone who ever defended Electron for these reasons.
At my last startup in SF, when slack was really starting to takeoff, most of the business/marketing folks who spent the bulk of their time chatting and sharing memes on slack loved it.
They simply didn't know any better, and were enamored with the new level of internal communication vs. previous jobs.
Man it was such a time sink. Between the open office floorplan and slack this was the least productive environment I'd ever seen for an engineering company, and it's largely caused me to walk away from the industry.
We use it in our company and I really like it. It's opened up a lot of workflows and data streams that either wouldn't exist or would go ignored. However, it might be relevant data that I am the boss and chose it ;-)
I don't think "like" is the word I would use. I don't "like" or "dislike" my power drill, but it is more efficient than a screwdriver or hand drill, it gets the job done, and it rarely leaves me wanting for something bigger or with more features.
By the same token, Slack fulfills a need and does so adequately; its features are enough to do interoffice communication without having to fall back on email or texting. I'm sure there are better tools out there, and Slack is definitely slower on our Core i3 based workstations compared to our beefier machines, but we don't "like" or "dislike" it.
40 comments
[ 3.0 ms ] story [ 94.2 ms ] threadI commend the Krita team for not merely copying Photoshop/GIMP, but actually writing a program an idiot like me can pick up and actually be productive with.
I do have Krita both at work on Windows and at home on Linux, but I rarely have to pull it out unless I need a tool specific to that application.
>I commend the Krita team for not merely copying Photoshop/GIMP
Krita (as well as MyPaint) is mainly a painting software whereas Photoshop/GIMP are mainly photo editors. You can do similar things in both, but they target different niches.
Do not be fooled by its name. That merely tells you where it began; it does not tell you what it is useful for after nearly thirty years of adding on one feature after another.
I appreciated the comment as a light humoured jab at the insane amount of memory slack needs just to send some text to each other (over simplification).
I read it as a comment on Slack's performance, not as an attack on Electron.
e.g. https://news.ycombinator.com/item?id=15599319
I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4.
And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas.
(No, I'm not actually serious. Though we could imagine something similar on some new language.)
We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
That's somewhat specialized, but not as much as you might think.
Why would you compare that with Slack?
We should all just stop comparing native apps to electron based apps, those things are soooo different. Electron/Chrome/Firefox/$browser are doing a ton of stuff behind the scenes, they are basically little virtual machines running the web platform. Comparing that to native is meaningless. You can of course prefer native apps, no one is arguing that, and yes you're correct that native apps will often use less resources, but it is the same as saying that a jumbo jet is much faster than a kickscooter, it might be true but what kind of comparison is that?! people are not building stuff with electron because they want to use less resources, the reasoning behind it is usually something else that those teams think is a valid trade-off
The general arguments are to do with building modern, aesthetic, easy-to-use cross-platform apps with less dev resources. Slack as a company are not dev-resource-constrained, so this makes Krita an exemplary counter-example to anyone who ever defended Electron for these reasons.
I use it at work and church and I have yet to find anyone who likes it (including myself).
They simply didn't know any better, and were enamored with the new level of internal communication vs. previous jobs.
Man it was such a time sink. Between the open office floorplan and slack this was the least productive environment I'd ever seen for an engineering company, and it's largely caused me to walk away from the industry.
By the same token, Slack fulfills a need and does so adequately; its features are enough to do interoffice communication without having to fall back on email or texting. I'm sure there are better tools out there, and Slack is definitely slower on our Core i3 based workstations compared to our beefier machines, but we don't "like" or "dislike" it.